sábado, 29 de dezembro de 2012

Policy-Map na Restrição da Taxa de Tráfego

Olá Pessoal.

Sabe aquele usuário na empresa que acha que toda a banda de Internet é dele ou que banda é um recurso infinito? Então, por pensar assim ele vive fazendo o download de arquivos pesados, ouvindo rádio, assistindo vídeos, entre outras coisas. Nesse post mostrarei como vocês podem usar técnicas de QoS para restringir a banda desse usuário - o vulgo "chupim"! Vamos utilizar o cenário abaixo para exemplificar o processo de configuração e estamos partindo do princípio de que o endereço do "chupim" é bem conhecido (estático ou dinâmico com lease pré-configurado).



O processo de configuração de QoS em dispositivos Cisco consiste em três etapas básicas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na estrada/saída de alguma interface. Esses recursos juntos são poderosos para classificar e marcar diversos tipos de tráfego para fins de QoS. Por exemplo, class-maps podem ser escritas para classificar tráfego de áudio, vídeo, dados, aplicações específicas, etc. Já as policy-maps utilizam a classificação prévia para fazer a marcação dos pacotes, comumente escrevendo os códigos DSCP (6 bits) do campo ToS (8 bits) do cabeçalho IP. 

Nesse exemplo não será feita nenhuma marcação porque nosso objetivo não é priorizar classes distintas de tráfego. Faremos uma classificação bem simples de tráfego de um usuário e então limitaremos a taxa de transmissão para esse nó da rede. Então vamos às configurações:

01. R1(config)# ip access-list extended Host-Chupim
02. R1(config-ext-nacl)# permit ip any host 192.168.0.109
03. R1(config-ext-nacl)# permit ip host 192.168.0.109 any
04. R1(config-ext-nacl)# exit
05. R1(config)#class-map match-all Chupim
06. R1(config-cmap)#match access-group name Host-Chupim
07. R1(config-cmap)#exit

08. R1(config)#policy-map QoS  
09. R1(config-pmap)#class Chupim
10. R1(config-pmap-c)#police rate 128000 bps
11. R1(config-pmap-c-police)# end

12. R1# configure terminal  
13. R1(config)# int f0/0
14. R1(config-if)# service-policy output QoS

Partindo dessa lógica, as linhas de 05 a 07 criam uma class-map associando todo o tráfego originado ou destinado ao usuário "chupim" (linhas de 01 a 03). Nas linhas de 08 a 10 criamos uma policy-map que restringe a banda desse usuário a míseros 128kbps e, por fim, na linha 14 aplicamos nossa policy-map na saída da interface f0/0 do roteador que está conectado na rede local. Tenha cuidado ao fazer isso arbitrariamente na empresa em que você trabalha sem ter o consentimento do seu superior, afinal o "chupim" pode ter a "costa quente"!!! ;-)

Samuel.

terça-feira, 25 de dezembro de 2012

Manipulação de Atributos PA do Protocolo BGP

Olá Pessoal.

Vimos no post anterior que  o BGP é um protocolo de roteamento externo (EGP) utilizado para troca de rotas entre diferentes ASs (Sistemas Autônomos) através de um processo denominado pareamento (peering). O Lab13 do livro explica os principais conceitos desse protocolo e traz algumas práticas importantes relacionadas ao processo de pareamento entre roteadores vizinhos. 

No entanto esse protocolo é BASTANTE complexo e sua operação não se resume apenas ao processo de pareamento, mas também à manipulação do seu comportamento para influenciar o melhor caminho até um destino. Isso só é possível porque na concepção do BGP foram criados vários atributos que o administrador pode configurar para determinar o trânsito dos pacotes não apenas no contexto local, mas também na comunicação inter-AS.

Mais uma vez esse post segue a mesma linha do livro e nosso objetivo não é apresentar os conceitos com grande nível de detalhamento, já que a intenção é trazer um cenário prático em que o leitor possa verificar algumas configurações para se sentir mais confortável com as tecnologias.

Dos vários atributos (ou Path Attributes - PA) do BGP, quatro dos mais importantes são: (i) Weight, (ii) LocalPreference, (iii) MED e (iv) Community. Eu escolhi destacar esses quatro atributos porque cada um deles traz uma funcionalidade diferente que torna mais fácil enxergar o trânsito nos mais variados layouts inter-AS.

Para não deixar todo o conteúdo "solto", vou explicar de maneira bastante sucinta cada um desses atributos. No entanto é importante o leitor lembrar que deve procurar outras fontes para complementar a explicação.

  • O atributo Weight (peso) é na realidade uma métrica local proprietária da Cisco e seu valor não é propagado nas mensagens de atualização do BGP. É exatamente por isso que ele só tem validade no escopo LOCAL do equipamento em que foi configurado. Esse atributo pode ser utilizado pelo administrador para determinar a saída de tráfego através de um determinado vizinho com a configuração de pesos diferentes para uma mesma rota através de dois next-hops distintos.  Quanto maior for o valor associado com uma determinada rota, então ela será preferida;

  • O atributo LocalPreference é MUITO importante no contexto de um Sistema Autônomo. Se considerarmos um AS com múltiplas conexões iBGP entre si, podemos ter um cenário em que uma empresa sai para a Internet através de dois provedores (ISP). Na figura abaixo, por exemplo, o AS123 tem trânsito através de R1 (p/ R4) e R3 (p/ R5). Nesse caso, o atributo LocalPreference pode ser manualmente configurado nas bordas (R1 e R3) para forçar a saída de tráfego por um determinado ISP. Esse atributo é propagado pelas mensagens BGP dentro do AS e TODOS os vizinhos iBGP irão optar por um dado caminho sem a necessidade de configuração de cada roteador individualmente (como aconteceria com a métrica weight). Valores maiores são preferidos e o padrão é 100;

  • O atributo MED (Multi-Exit Discriminator) tem utilidade para os ISPs. O leitor pode tentar entendê-lo como sendo o inverso da LocalPreference. Isso porque nesse caso caberá ao ISP que faz o anúncio das rotas através de uma vizinhança eBGP (ou seja, outro AS) a responsabilidade por setar o valor dessa métrica para determinar o melhor caminho. Por exemplo, imaginem que na figura abaixo os ASs 40 e 50 pertencem a um mesmo provedor. O ISP certamente sabe se a melhor opção para chegar no AS 60 é através de trânsito via R4 (ASN 40) ou via R5 (ASN 50). Nesse caso o provedor pode manipular os valores do atributo MED nos roteadores R4 e R5 de forma que o cliente, sem configuração nenhuma, opte por um determinado caminho. Em relação a esse atributo, os valores menores são preferidos;

  • A Community se comporta de forma parecida com o atributo MED no sentido de que é atribuído por quem faz o anúncio, no entanto traz ainda mais flexibildiade para o cliente. Através desse atributo o ISP pode atribuir valores distintos (marcação) para as rotas anunciadas via R4 e R5, no entanto esses valores não irão determinar o melhor caminho. Caberá ao cliente fazer a leitura da community e determinar qual ação deverá ser tomada com base em um route-map. 

 
Pois bem, no exemplo desse post estaremos manipulando dois desses atributos com base no cenário acima (Community e LocalPreference). O BGP com todas as suas vizinhanças (iBGP e eBGP) já está devidamente configurado e vamos focar apenas no processo de manipulação dos atributos. A princípio, sem manipualação nenhuma, o R2 no AS 123 escolhe chegar nos prefixos de 36/8 até 42/8 através do next-hop 10.0.1.1 que implica no caminho R1>R4>R6.

Vamos imaginar uma situação em que o cliente solicitou uma conexão redundante a um mesmo provedor que possui dois ASs distintos. No caso do nosso cenário, o ISP é representado pelo AS 40 e AS 50. A operadora que possui conhecimento da estrutura interna da sua rede trânsito irá marcar os anúncios eBGP em R5 com a community "50", enquanto que os anúncios por R4 serão marcados com a community "40". 

A empresa, representada pelo AS 123, ficará responsável por fazer a leitura da community e atribuir diferentes valores de LocalProference para as rotas marcadas como "40" e "50". Faremos da seguinte forma: rotas marcadas como "40" (de R4) ao chegar em R1 terão seu valor LocalPreference modificado para 50; já as rotas marcadas como "50" (de R5) ao chegar em R3 terão seu valor LocalPreference modificado para 200.

Vamos fazer isso apenas para as rotas 36.0.0.0/8, 37.0.0.0/8 e 38.0.0.0/8. Ao fazê-lo, veremos que essas rotas saírão por R5, enquanto que as demais irão continuar saindo por R4.

Compreendido o cenário??? Ótimo, então vamos configurar!!! ;-) A configuração de R4 e R5 são praticamente idênticas, com a diferença de que cada um fará uma marcação diferente. Abaixo vocês podem observar nas configurações que ativamos o anúncio da community e aplicamos uma route-map no anúncio eBGP:

ASN40-R4(config)# ip access-list standard ADV-36-37-38
ASN40-R4(config-std-nacl)# permit 36.0.0.0 0.255.255.255
ASN40-R4(config-std-nacl)# permit 37.0.0.0 0.255.255.255
ASN40-R4(config-std-nacl)# permit 38.0.0.0 0.255.255.255
ASN40-R4(config-std-nacl)# exit
ASN40-R4(config)# route-map BGP-MED permit 10
ASN40-R4(config-route-map)# match ip address ADV-36-37-38
ASN40-R4(config-route-map)# set community 40
ASN40-R4(config-route-map)# route-map BGP-MED permit 20
ASN40-R4(config-route-map)# exit
ASN40-R4(config)# router bgp 40
ASN40-R4(config-router)# neighbor 10.0.4.1 send-community
ASN40-R4(config-router)# neighbor 10.0.4.1 route-map BGP-MED out
ASN40-R4(config-router)# end
ASN40-R4# clear bgp all 123 soft 


***

ASN50-R5(config)# ip access-list standard ADV-36-37-38
ASN50-R5(config-std-nacl)# permit 36.0.0.0 0.255.255.255
ASN50-R5(config-std-nacl)# permit 37.0.0.0 0.255.255.255
ASN50-R5(config-std-nacl)# permit 38.0.0.0 0.255.255.255
ASN50-R5(config-std-nacl)# exit
ASN50-R5(config)# route-map BGP-MED permit 10
ASN50-R5(config-route-map)# match ip address ADV-36-37-38
ASN50-R5(config-route-map)# set community 50
ASN50-R5(config-route-map)# route-map BGP-MED permit 20
ASN50-R5(config-route-map)# exit
ASN50-R5(config)# router bgp 50
ASN50-R5(config-router)# neighbor 10.0.5.1 send-community
ASN50-R5(config-router)# neighbor 10.0.5.1 route-map BGP-MED out
ASN50-R5(config-router)# end
ASN50-R5# clear bgp all 123 soft

Por fim, vamos às configurações necessárias em R1 e R3 para que seja feita a leitura da community e manipulação da LocalPreference. Mais uma vez, as configurações são bem parecidas:

ASN123-R1(config)# ip community-list 40 permit 40
ASN123-R1(config)# ip community-list 50 permit 50
ASN123-R1(config)# route-map BGP-LocalPref permit 10
ASN123-R1(config-route-map)# match community 40
ASN123-R1(config-route-map)# set local-preference 50
ASN123-R1(config-route-map)# route-map BGP-LocalPref permit 20
ASN123-R1(config-route-map)# match community 50
ASN123-R1(config-route-map)# set local-preference 200
ASN123-R1(config-route-map)# route-map BGP-LocalPref permit 30
ASN123-R1(config-route-map)# exit
ASN123-R1(config)# router bgp 123
ASN123-R1(config-router)# neighbor 10.0.4.2 route-map BGP-LocalPref in
ASN123-R1(config-router)# end
ASN123-R1# clear bgp all 40 soft

*** 
ASN123-R3(config)# ip community-list 40 permit 40
ASN123-R3(config)# ip community-list 50 permit 50
ASN123-R3(config)# route-map BGP-LocalPref permit 10
ASN123-R3(config-route-map)# match community 40
ASN123-R3(config-route-map)# set local-preference 50
ASN123-R3(config-route-map)# route-map BGP-LocalPref permit 20
ASN123-R3(config-route-map)# match community 50
ASN123-R3(config-route-map)# set local-preference 200
ASN123-R3(config-route-map)# route-map BGP-LocalPref permit 30
ASN123-R3(config-route-map)# exit
ASN123-R3(config)# router bgp 123
ASN123-R3(config-router)# neighbor 10.0.5.2 route-map BGP-LocalPref in
ASN123-R3(config-router)# end
ASN123-R3# clear bgp all 50 soft

Pala saída do comando "show ip bgp" em R1 é possível observar que a manipulação funcionou porque o valor da LocalPreference mudou para as rotas 36/8, 37/8 e 38/8 recebidas de R4:

R1#show ip bgp
BGP table version is 14, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i36.0.0.0         10.0.3.2                 0    200      0 50 60 i
*                   10.0.4.2                       50      0 40 60 i
*>i37.0.0.0         10.0.3.2                 0    200      0 50 60 i
*                   10.0.4.2                       50      0 40 60 i
*>i38.0.0.0         10.0.3.2                 0    200      0 50 60 i
*                   10.0.4.2                       50      0 40 60 i
* i39.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>                  10.0.4.2                               0 40 60 i
* i40.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>                  10.0.4.2                               0 40 60 i
* i41.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>                  10.0.4.2                               0 40 60 i
* i42.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>                  10.0.4.2                               0 40 60 i

E o mais interessante, vejam abaixo a saída do comando "show ip bgp" em R2 (atrás dos vizinhos iBGP) que exibe a tabela BGP com as suas rotas. Reparem que agora os prefixos 36/8, 37/8 e 39/8 têm como next-hop o R3 (10.0.2.2), enquanto que todas as demais rotas saem por R1 (10.0.1.1). Vocês hão de convir comigo que tudo isso é muito lindo!!! ;-)

R2#show ip bgp
BGP table version is 11, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i36.0.0.0         10.0.2.2                 0    200      0 50 60 i
*>i37.0.0.0         10.0.2.2                 0    200      0 50 60 i
*>i38.0.0.0         10.0.2.2                 0    200      0 50 60 i

* i39.0.0.0         10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i
* i40.0.0.0         10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i
* i41.0.0.0         10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i
* i42.0.0.0         10.0.2.2                 0    100      0 50 60 i
*>i                 10.0.1.1                 0    100      0 40 60 i

 

Abraço!

Samuel.

segunda-feira, 17 de dezembro de 2012

Route Reflector (RR) na Minimização de Vizinhança iBGP

Olá Pessoal.

O BGP é um protocolo de roteamento externo (EGP) utilizado para troca de rotas entre diferentes ASs (Sistemas Autônomos) através de um processo denominado pareamento (peering). No entanto, em grandes Sistemas Autônomos é possível parear roteadores pertencentes ao mesmo AS, denominado pareamento iBGP.

A lógica do BGP para evitar loops é que uma rota aprendida por um vizinho iBGP não será propagada para outro(s) vizinho(s) iBGP. O problema disso é a escalabilidade, já que todos os roteadores internos de um AS devem estar pareados entre si (topologia full-mesh) para receberem o anúncio das rotas.

A complexidade de criar uma topologia full-mesh é exponencial e pode ser compreendida através da fórmula (n²-n)/2, sendo que n é a quantidade de roteadores. Ou seja, em um cenário simplista com 4 roteadores, é necessário o estabelecimento de 6 relações de pareamento.

Para minimizar essa complexidade, uma solução atrativa é a utilização de Route Reflectors (RR), conforme pode ser observado no cenário abaixo. Na figura, R1 recebe uma rota eBGP do AS77 e precisa propagá-la para o AS99 e, via de regra, para isso ser possível deveria haver um pareamento iBGP entre R1 e R4. Com R2 configurado como RR, essa regra é quebrada. Ao fazê-lo, reparem que dentro do AS123 passamos a ter apenas três pareamentos, ou seja, exatamente a metade. Pois bem, fica evidente o benefício disso em ambientes grandes.


Felizmente quando um Route Reflector é configurado, existem novas regras que o protocolo deve seguir para evitar a ocorrência de loops, como por exemplo não modificar NENHUM atributo das rotas recebidas (entre outras), daí o nome REFLECTOR. No entanto, a posição do RR deve ser bem pensada para evitar a ocorrência de sub-otimização de roteamento de maneira que clientes escolham caminhos piores até o destino!

O objetivo desse post não é explicar essas particularidades, mas sim mostrar quais são os procedimentos necessários para configurar os roteadores do ASN123 do cenário apresentado.

Para estabelecer a vizinhança eBGP entre R1 e R77 estarei utilizando a interface de loopback porque temos dois links físicos conectando os roteadores. Maiores detalhes sobre o processo de pareamento o leitor pode encontrar no Lab13 do livro "Laboratórios de Tecnologias Cisco". Também já estarei partindo do princípio de que todas as interfaces estão devidamente configuradas e que já existe um IGP em execução para que todos os roteadores conheçam as rotas internas. Assim estaremos focando apenas na configuração do BGP.

Vamos começar a configuração por R1:

01. ASN123-R1(config)# int lo 1
02. ASN123-R1(config-if)# ip address 1.1.1.1 255.255.255.255
03. ASN123-R1(config-if)# exit
04. ASN123-R1(config)# ip route 77.77.77.77 255.255.255.255 f0/0 1
05. ASN123-R1(config)# ip route 77.77.77.77 255.255.255.255 f0/1 2
06. ASN123-R1(config)# router bgp 123
07. ASN123-R1(config-router)# bgp router-id 1.1.1.1
08. ASN123-R1(config-router)# neighbor 77.77.77.77 remote-as 77
09. ASN123-R1(config-router)# neighbor 77.77.77.77 password SENHA
10. ASN123-R1(config-router)# neighbor 77.77.77.77 ebgp-mulihop 2
11. ASN123-R1(config-router)# neighbor 77.77.77.77 update-source Loopback 1
12. ASN123-R1(config-router)# neighbor 10.23.0.2 remote-as 123
13. ASN123-R1(config-router)# neighbor 10.23.0.2 next-hop-self

Todos os detalhes das configurações anteriores podem ser encontrados com mais detalhes no livro (Lab13). Agora vamos para a configuração de R2, o Route-Reflector:

01. ASN123-R2(config)# router bgp 123
02. ASN123-R2(config-router)# bgp router-id 2.2.2.2
03. ASN123-R2(config-router)# bgp cluster-id 1
04. ASN123-R2(config-router)# neighbor 10.23.0.1 remote-as 123
05. ASN123-R2(config-router)# neighbor 10.23.0.1 next-hop-self
06. ASN123-R2(config-router)# neighbor 10.24.0.2 remote-as 123
07. ASN123-R2(config-router)# neighbor 10.24.0.2 next-hop-self
08. ASN123-R2(config-router)# neighbor 10.24.0.2 route-reflector-client
09. ASN123-R2(config-router)# neighbor 10.25.0.2 remote-as 123
10. ASN123-R2(config-router)# neighbor 10.25.0.2 next-hop-self
11. ASN123-R2(config-router)# neighbor 10.25.0.2 route-reflector-client

Reparem que na configuração de R2 (Route Reflector), criamos um grupo lógico (cluster) e informamos nos comandos "neighbor" quais vizinhos iBGP terão as rotas refletidas. Na configuração de R3 e R4 vocês verão que os roteadores clientes não têm nenhuma configuração adicional e para eles é transparente a presença do refletor de rotas:

01. ASN123-R3(config)# router bgp 123
02. ASN123-R3(config-router)# bgp router-id 3.3.3.3
03. ASN123-R3(config-router)# neighbor 10.24.0.1 remote-as 123
04. ASN123-R3(config-router)# neighbor 10.24.0.1 next-hop-self

Por fim, R4 tem também uma vizinhança eBGP com o AS99. Repare que diferente da vizinhança entre R1 e R77 que tinha dois links físicos, agora existe apenas um link e por isso não utilizaremos a interface de loopback.

01. ASN123-R4(config)# router bgp 123
02. ASN123-R4(config-router)# bgp router-id 4.4.4.4
03. ASN123-R4(config-router)# neighbor 10.25.0.1 remote-as 123
04. ASN123-R4(config-router)# neighbor 10.25.0.1 next-hop-self
05. ASN123-R4(config-router)# neighbor 10.26.0.1 remote-as 99
06. ASN123-R4(config-router)# neighbor 10.26.0.1 password SENHA 

O ponto-chave do cenário é:

- Com essa topologia sem o RR, então R4 não aprenderia a rota 37.0.0.0/8 através de R2 porque não existe um pareamento entre R1 e R4. Com o RR, então R2 recebe essa rota de R1 e reflete para seus vizinhos, inclusive R4. Então R4 pode anunciar a rota para o AS 99 através do seu pareamento eBGP.

Abraço.

Samuel.

segunda-feira, 10 de dezembro de 2012

Route-Map na Filtragem de Rotas Redistribuídas

Olá Pessoal.

No Lab4 do livro o leitor pode praticar as configurações mais básicas do processo de redistribuição de rotas que basicamente consiste na inserção de rotas aprendidas por um determinado protocolo de roteamento dentro de outro protocolo de roteamento. No exemplo do livro foram utilizados os protocolos OSPF e o EIGRP (da Cisco). 

No entanto, podem existir algumas situações em que o objetivo é redistribuir algumas rotas de um protocolo para outro (e não todas). Felizmente podemos associar route-maps com o comando de redistribuição de rotas, de maneira que é possível personalizar quais rotas queremos ou não redistribuir.

Para reproduzir esse processo, vamos considerar o cenário abaixo que é bastante simples. Nele existem dois roteadores adjacentes via OSPF em suas interfaces f0/0 (192.168.0.1/30 e 192.168.0.2/30). 



Para "simular" as várias rotas externas, em R2 criei 5 interfaces loopback e as anunciei através de uma instância EIGRP, conforme roteiro abaixo:

R2(config)# interface f0/0
R2(config-if)# ip address 192.168.0.2 255.255.255.252
R2(config-if)# no shut
R2(config-if)# interface loopback 1
R2(config-if)# ip address 1.1.1.1 255.255.255.255
R2(config-if)# interface loopback 2
R2(config-if)# ip address 2.2.2.2 255.255.255.255
R2(config-if)# interface loopback 3
R2(config-if)# ip address 3.3.3.3 255.255.255.255
R2(config-if)# interface loopback 4
R2(config-if)# ip address 4.4.4.4 255.255.255.255
R2(config-if)# interface loopback 5
R2(config-if)# ip address 5.5.5.5 255.255.255.255
R2(config-if)# exit
R2(config)# router eigrp 90
R2(config-router)# no auto-summary
R2(config-router)# network 1.1.1.1 0.0.0.0
R2(config-router)# network 2.2.2.2 0.0.0.0
R2(config-router)# network 3.3.3.3 0.0.0.0
R2(config-router)# network 4.4.4.4 0.0.0.0
R2(config-router)# network 5.5.5.5 0.0.0.0

Depois das configurações básicas em R2, vamos ao roteiro para configurar a redistribuição apenas das rotas 1.1.1.1/32, 2.2.2.2/32 e 4.4.4.4/32, excluindo as rotas 3.3.3.3/32 e 5.5.5.5/32.

01. R2(config)# access-list 35 permit 3.3.3.3 0.0.0.0
02. R2(config)# access-list 35 permit 5.5.5.5 0.0.0.0
03. R2(config)# route-map Filter-Net3-Net5 deny 10
04. R2(config-route-map)# match ip address 35
05. R2(config-route-map)# route-map Filter-Net3-Net5 permit 20
06. R2(config-route-map)# exit
07. R2(config)# router ospf 64
08. R2(config-router)# router-id 2.2.2.2
09. R2(config-router)# network 192.168.0.0 0.0.0.3 area 0
10. R2(config-router)# redistribute eigrp 90 subnets route-map Filter-Net3-Net5
11. R2(config-router)# exit

Pronto! Nas linhas 1 e 2 criamos uma ACL para posteriormente ser utilizada no match do route-map. Repare que o permit da ACL não é reponsável por permitir ou negar as rotas, apenas por enquadrar uma match (conformidade). Nas linhas de 3-5 criamos uma route-map denominado Filter-Net3-Net5 que irá negar as rotas 3.3.3.3/32 e 5.5.5.5/32 e que irá permitir todas as outras entradas. Por fim, nas linhas de 07-09 configuramos a instância OSPF, de maneira que na linha 10 temos a redistribuição das rotas EIGRP filtradas pela route-map. Agora em R1 você poderá observar que somente as rotas permitidas foram adicionadas na tabela de roteamento.

R1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O E2    1.1.1.1 [110/20] via 192.168.0.2, 00:29:38, FastEthernet0/0
     2.0.0.0/32 is subnetted, 1 subnets
O E2    2.2.2.2 [110/20] via 192.168.0.2, 00:29:38, FastEthernet0/0
     4.0.0.0/32 is subnetted, 1 subnets
O E2    4.4.4.4 [110/20] via 192.168.0.2, 00:29:38, FastEthernet0/0
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0



Caso vocês queiram reproduzir o experimento, a configuração de R1 é bem simples e pode ser observada no roteiro abaixo:

R1(config)# interface f0/0
R1(config-if)# ip address 192.168.0.1 255.255.255.252
R1(config-if)# no shut
R1(config-if)# exit
R1(config)# router ospf 64
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 192.168.0.0 0.0.0.3 area 0
R1(config-router)# end 

Abraço!

Samuel.