quarta-feira, 25 de maio de 2016

Anúncio de Rota Default via Protocolo BGP

Olá Pessoal,

Quando um AS contrata conexão com uma operadora de telecomunicações, há necessidade de que seja estabelecida uma sessão BGP entre as partes para que a empresa possa anunciar seus próprios prefixos e receber as informações de roteamento que permitam alcançar toda a Internet. Nesse contexto é comum a operadora oferecer ao seu cliente a possibilidade de escolher se deseja receber a tabela completa de rotas (full route), a tabela parcial de rotas (partial route) ou apenas uma rota padrão (default route).

  • Default Route: Basicamente a operadora anuncia apenas uma rota padrão (default) para seu cliente, apontando que todo tráfego de saída para qualquer prefixo na Internet deve ser direcionado através dela. Essa ação é comum, por exemplo, quando a empresa está conectada à Internet a partir de uma única operadora, mas utiliza BGP porque é um AS e tem seus próprios recursos públicos para anunciar. Também é comum quando a empresa não tem interesse nenhum em definir políticas de engenharia de tráfego;
  • Partial Route: Além de anunciar uma rota padrão para qualquer prefixo na Internet, a operadora também anuncia rotas específicas para seus próprios prefixos com o intuito de otimizar a alcançabilidade destes, a fim de evitar que seu cliente tente alcançar seus prefixos por outro caminho que certamente seria uma opção pior; 
  • Full Route: A operadora anuncia a tabela BGP completa com todos os prefixos da Internet, ação que certamente requer equipamentos de borda com poder de memória e processamento para lidar com aproximadamente 600.000 prefixos IPv4 (atualmente), além de milhares de rotas, já que podem existir múltiplas rotas apontando para o mesmo prefixo.




Não existe uma regra "mágica" que diga qual é a melhor opção, já que a escolha por uma dessas opções vai depender do interesse da empresa em aplicar suas próprias políticas de engenharia de tráfego, da competência técnica dos seus recursos humanos em configurar o BGP, dos equipamentos disponíveis, do orçamento para aquisição de novos equipamentos, etc.

Através do mesmo laboratório utilizado no artigo anterior, oportunidade em que expliquei o processo de configuração de atributos e filtros no BGP (cliqe aqui para ler), já vimos que há duas fontes de aprendizado dos prefixos nos roteadores de borda R1 (conectado ao R4 do ISP no AS 40) e R3 (conectado ao R5 do ISP no AS 50), sendo um aprendizado através do vizinho interno iBGP e outro através do vizinho externo. O BGP dá preferência pelo aprendizado eBGP, ou seja, em R1 haverá preferência por escoar o tráfego através de R4, enquanto que em R3 haverá preferência por escoar o tráfego através de R5. Antes qualquer configuração, convém verificar as tabelas BGP dos roteadores da empresa:


R1> show ip bgp
BGP table version is 15, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path

*> 36.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 37.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 38.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 39.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 40.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 41.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 42.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i


R3> show ip bgp
BGP table version is 8, local router ID is 3.3.3.3

   Network          Next Hop            Metric LocPrf Weight Path

* i36.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i37.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i38.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i39.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i40.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i41.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i
* i42.0.0.0         10.0.3.1                 0    100      0 40 60 i
*>                  10.0.5.2                               0 50 60 i

Já  em R2 que está posicinado atrás de R1 e R3, podemos observar o aprendizado de duas rotas para cada um dos prefixos anunciados através dos pareamentos iBGP com seus vizinhos no mesmo AS. 

R2> show ip bgp
BGP table version is 15, local router ID is 2.2.2.2

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

Neste artigo assumiremos que a empresa cliente não deseja receber a tabela BGP completa ou parcial, de forma que seus provedores serão configurados para anunciar apenas a rota padrão. Esse procedimento pode ser realizado através dos comandos listados abaixo:

!-- Configuração de R4 no AS 40
01. R4(config)# ip access-list standard TUDO
02. R4(config-std-nacl)# permit any
03. R4(config-std-nacl)# exit
04. R4(config)# route-map BGP-FILTRO deny 10
05. R4(config-route-map)# match ip address TUDO
06. R4(config-route-map)# route-map BGP-FILTRO permit 20
07. R4(config-route-map)# exit
08. R4(config)# router bgp 40
09. R4(config-router)# neighbor 10.0.4.1 route-map BGP-FILTRO out
10. R4(config-router)# neighbor 10.0.4.1 default-originate
11. R4(config-router)# end
12. R4# clear bgp all 123 soft

!-- Configuração de R5 no AS 50
01. R5(config)# ip access-list standard TUDO
02. R5(config-std-nacl)# permit any
03. R5(config-std-nacl)# exit
04. R5(config)# route-map BGP-FILTRO deny 10
05. R5(config-route-map)# match ip address TUDO
06. R5(config-route-map)# route-map BGP-FILTRO permit 20
07. R5(config-route-map)# exit
08. R5(config)# router bgp 50
09. R5(config-router)# neighbor 10.0.5.1 route-map BGP-FILTRO out
10. R5(config-router)# neighbor 10.0.5.1 default-originate
11. R5(config-router)# end
12. R5# clear bgp all 123 soft

Nas linhas de 01-07 criamos um filtro negando TODOS os prefixos que posteriormente (linha 9) foi aplicado no sentido sainte (out) da vizinhanga eBGP dos ISPs com o respsectivo roteador de borda no AS 123. Ou seja, o ISP responsável pela configuração de R4 aplicou o filtro na saída da vizinhança com R1 para negar que qualquer prefixo seja anunciado para a empresa. O mesmo procedimento foi feito pelo ISP responsável por R5 em relação a R3. 

Se as configurações cessassem nesse ponto, os roteadores do AS 123 não receberiam absolutamente nenhum anúncio dos provedores. É por isso que na linha 10 os ISPs configuram seus roteadores para que façam o anúncio de uma rota default (0.0.0.0/0) para que todo o tráfego de saída seja direcionado pelo seu AS. Embora haja outros métodos para anunciar a rota padrão, utilizar o parâmetro default-originate é uma boa solução porque injeta artificialmente uma rota default na tabela BGP de um vizinho específico, sem interferir nas demais vizinhanças. 

Obs.: Outra opção para anunciar uma rota padrão na tabela BGP seria utiliar o comando "network 0.0.0.0", desde que a rota padrão exista previamente na tabela de roteamento. Também é possível redistribuir a rota padrão a partir de outro protocolo de roteamento, mais uma vez desde que essa rota exista previamente na tabela de roteamento. Uma terceira possibilidade seria utiliar o parâmetro default-information originate de maneira global nas sub-configurações do BGP, uma estratégia que nem sempre é desejável porque faria o BGP injetar artificialmente uma rota padrão em todos os seus vizinhos BGP. A solução utilizada neste artigo é a mais flexível porque permite injetar artificialmente a rota padrão apenas para um vizinho específico, de maneira que todos os demais prefixos podem ser filtrados na saída sem afetar a rota artificial.

Uma vez que o procedimento de anunciar apenas a rota padrão foi realizado por ambos os provedores, os roteadores da empresa no AS 123 selecionam aquela saída que entendem ser a melhor, conforme observado nas tabelas abaixo. Seguindo a lógica do BGP, os roteadores R1 e R3 preferem a rota padrão do vizinho eBGP (por R4 em R1 e por R5 em R3), enquanto que o roteador R2 prefere a rota padrão do vizinho iBGP com menor router-ID (através de R1). 

R1> show ip bgp
BGP table version is 23, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path
* i0.0.0.0          10.0.3.2                 0    100      0 50 i
*>                  10.0.4.2                 0             0 40 i



R2> show ip bgp
BGP table version is 23, local router ID is 2.2.2.2

   Network          Next Hop            Metric LocPrf Weight Path
* i0.0.0.0          10.0.2.2                 0    100      0 50 i
*>i                 10.0.1.1                 0    100      0 40 i



R3> show ip bgp
BGP table version is 17, local router ID is 3.3.3.3

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          10.0.5.2                 0             0 50 i
* i                 10.0.3.1                 0    100      0 40 i


Reparem que depois das configurações realizadas nos provedores (AS 40 e AS 50), os roteadores da empresa (no AS 123) não aprendem mais todos os prefixos individualmente, o que certamente alivia bastante a exigência de memória e processamento dos equipamentos de borda. Por outro lado, a empresa perde de aplicar qualquer ação no sentido de definir suas próprias políticas de engenharia de tráfego. 

Façam seus testes...

Samuel.

sexta-feira, 20 de maio de 2016

Configuração de Atributos e Filtros no Protocolo BGP

Olá Pessoal,

O BGP é um protocolo de roteamento externo (EGP) utilizado para troca de rotas entre diferentes Sistemas Autônomos na Internet através de um processo denominado pareamento (peering). Esse protocolo foi um dos novos tópicos adicionados recentemente no currículo CCNA 6.0 (exame 200-125), no entanto a cobrança pela sua configuração no exame está restrita apenas aos aspectos básicos. Para aqueles interessados em estudar os aspectos básicos do protocolo BGP para o novo CCNA, recomendo a leitura e a resolução do Laboratório 30 (Roteamento Externo via BGP) do livro Laboratórios de Tecnologias Cisco em Infraestrutura de Redes (2a Edição)

Em outro artigo do blog, intitulado Manipulação de Atributos PA do Protocolo BGP, o leitor encontra a resolução comentada do Laboratório 33 do meu livro de laboratórios, oportunidade para conhecer alguns detalhes dos aspectos mais complexos de configuração desse protocolo. Neste artigo utilizarei esse mesmo laboratório, cuja topologia é apresentada na figura abaixo, para que o leitor possa praticar outras configurações do BGP. Proponho na sequência uma atividade em forma de exercício, sendo que apresento também duas possíveis resoluções comentadas para o mesmo problema.


REQUISITO: Você é responsável pela configuração do BGP na empresa detentora do AS 123, portanto suas ações de configuração estão restritas apenas aos roteadores R1, R2 e R3. A empresa está conectada à Internet a partir de dois provedores, sendo que R1 possui um pareamento eBGP com o roteador R4 no AS 40 e que R3 possui um pareamento eBGP com o roteador R5 no AS 50. A empresa deseja que todo tráfego de acesso aos prefixos 36.0.0.0/8, 37.0.0.0/8 e 38.0.0.0/8 seja "escoado" pelo AS 50, ou seja, passe necessariamente pelo seguinte caminho:

(...) > R3 > R5 > R6 > (...)

LEMBRE-SE: Nos roteadores de borda R1 (conectado ao R4 do ISP no AS 40) e R3 (conectado ao R5 do ISP no AS 50) há duas fontes de aprendizado dos prefixos 36.0.0.0/8, 37.0.0.0/8 e 38.0.0.0/8, sendo uma através do roteador vizinho iBGP dentro do próprio AS da empresa e outra através do roteador externo eBGP com um dos ISPs. Por padrão, o BGP dá preferência pelo aprendizado eBGP, ou seja, em R1 haverá preferência por escoar o tráfego através de R4, enquanto que em R3 haverá preferência por escoar o tráfego através de R5. Esse comportamento pode ser confirmado através dos destaques nas tabelas BGP abaixo que foram extraídas dos roteadores R1 e R3:

R1> show ip bgp
BGP table version is 15, local router ID is 1.1.1.1


   Network          Next Hop            Metric LocPrf Weight Path
*> 36.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 37.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 38.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 39.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 40.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 41.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 42.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i


R3> show ip bgp
BGP table version is 8, local router ID is 3.3.3.3


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

Já em R2 que aprende os prefixos através dos roteadores internos R1 e R3 via iBGP no mesmo AS, o caminho preferido é aquele através de R1 que possui menor router-id (1.1.1.1) do que R3 (3.3.3.3), conforme pode ser constatado na tabela BGP abaixo:

R2> show ip bgp
BGP table version is 15, local router ID is 2.2.2.2

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



1a SOLUÇÃO: Como o exercício pede que TODO o tráfego para os prefixos 36/8, 37/8 e 38/8 seja escoado por R5, então é necessário ajustar apenas as configurações de R1 (ligado ao R4) para forçar sua saída por R3 (ligado ao R5). Uma solução seria configurar R1 para diminuir o valor da métrica Local-Preference para 50 (padrão = 100) apenas para os prefixos desejados. Dessa forma o comportamento padrão do BGP seria alterado, de maneira que o aprendizado através do vizinho iBGP (R3) seria preferido por ter maior valor de Local-Preference. Não é necessário fazer nenhuma configuração adicional em R2, já que os valores da métrica Local-Preference são propagados internamente no mesmo AS.

01. R1(config)# ip access-list standard PREFIXO-36-37-38
02. R1(config-std-nacl)# permit 36.0.0.0 0.255.255.255
03. R1(config-std-nacl)# permit 37.0.0.0 0.255.255.255
04. R1(config-std-nacl)# permit 38.0.0.0 0.255.255.255
05. R1(config-std-nacl)# exit
06. R1(config)# route-map BGP-LocalPref permit 10
07. R1(config-route-map)# match ip address PREFIXO-36-37-38
08. R1(config-route-map)# set local-preference 50
09. R1(config-route-map)# route-map BGP-LocalPref permit 20
10. R1(config-route-map)# exit
11. R1(config)# router bgp 123
12. R1(config-router)# neighbor 10.0.4.2 route-map BGP-LocalPref in
13. R1(config-router)# end
14. R1# clear bgp all 40 soft

Nas linhas 01-05 criamos uma ACL denominada PREFIXO-36-37-38 com a correpondência para os prefixos que pretendemos manipualar na sequência. Nas linhas 06-10 criamos uma route-map denominada BGP-LocalPref para instruir o roteador de que os prefixos da ACL anterior (match) devem ter seu valor de Local-Preference diminuídos para 50 (set). Por fim, nas linhas 11-14 aplicamos essa route-map na entrada (in) do tráfego recebido pelo vizinho R4 (10.0.4.2). Os resultados podem ser observados nas tabelas BGP de R1 e R2 listadas abaixo, oportunidade em que os melhores caminhos estão destacados em amarelo e os caminhos manipulados estão destacados em azul:

R1> show ip bgp
BGP table version is 18, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path
*  36.0.0.0         10.0.4.2                       50      0 40 60 i
*>i                 10.0.3.2                 0    100      0 50 60 i
*  37.0.0.0         10.0.4.2                       50      0 40 60 i
*>i                 10.0.3.2                 0    100      0 50 60 i
*  38.0.0.0         10.0.4.2                       50      0 40 60 i
*>i                 10.0.3.2                 0    100      0 50 60 i
*> 39.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 40.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 41.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 42.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i


R2> show ip bgp

BGP table version is 18, local router ID is 2.2.2.2

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

Obs.: Observem que essa solução diminui a prioridade dos prefixos 36/8, 37/8 e 38/8 através de R4 (no AS 40), já que o objetivo foi tornar mais atrativo o caminho via R5 (no AS 50). No entanto, o caminho via R4 ainda está disponivel na tabela BGP de R1, de forma que em caso de queda do pareamento entre R3 e R5, a empresa utilizará o caminho alternativo via R4 para alcançar os prefixos manipulados.



2a SOLUÇÃO: Como o exercício pede que TODO o tráfego para os prefixos 36/8, 37/8 e 38/8 seja escoado por R5, então é necessário ajustar apenas as configurações de R1 (ligado ao R4) para forçar sua saída através de R3 (ligado ao R5). Outra possibilidade de configuração alternativa à manipulação das métricas do BGP é configurar um filtro através do recurso route-map negando (deny) todos os anúncios recebidos por R1 (ligado ao R4) dos prefixos desejados de serem acessados através do AS 40.

01. R1(config)# ip access-list standard PREFIXO-36-37-38
02. R1(config-std-nacl)# permit 36.0.0.0 0.255.255.255
03. R1(config-std-nacl)# permit 37.0.0.0 0.255.255.255
04. R1(config-std-nacl)# permit 38.0.0.0 0.255.255.255
05. R1(config-std-nacl)# exit
06. R1(config)# route-map BGP-Filtro deny 10  
07. R1(config-route-map)# match ip address PREFIXO-36-37-38
08. R1(config-route-map)# route-map BGP-Filtro permit 20
09. R1(config-route-map)# exit
10. R1(config)# router bgp 123
11. R1(config-router)# neighbor 10.0.4.2 route-map BGP-Filtro in
12. R1(config-router)# end
13. R1# clear bgp all 40 soft

Nas linhas 01-05 criamos uma ACL denominada PREFIXO-36-37-38 com a correpondência para os prefixos que pretendemos filtrar na sequência. Nas linhas 06-09 criamos uma route-map denominada BGP-Filtro para instruir o roteador de que os prefixos da ACL anterior (match) devem ser negados (deny). Por fim, nas linhas 10-13 aplicamos essa route-map na entrada (in) do tráfego recebido pelo vizinho R4 (10.0.4.2). Os resultados podem ser observados nas tabelas BGP de R1 e R2 listadas abaixo, oportunidade em que os melhores caminhos estão destacados em amarelo, lembrando que os caminhos filtrados sequer aparecem em R1 como opção. Os resultados podem ser observados nas tabelas BGP de R1 e R2:

R1> show ip bgp
BGP table version is 24, local router ID is 1.1.1.1

   Network          Next Hop            Metric LocPrf Weight Path
*>i36.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>i37.0.0.0         10.0.3.2                 0    100      0 50 60 i
*>i38.0.0.0         10.0.3.2                 0    100      0 50 60 i
*> 39.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 40.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 41.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i
*> 42.0.0.0         10.0.4.2                               0 40 60 i
* i                 10.0.3.2                 0    100      0 50 60 i


R2> show ip bgp
BGP table version is 24, local router ID is 2.2.2.2

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

Obs.: Observem que essa segunda solução, por ser baseada na filtragem de prefixo, elimina qualquer possibilidade de tráfego por R4 para os prefixos 36/8, 37/8 e 38/8. Ou seja, em caso de queda do pareamento entre R3 e R5 (no AS 50), a empresa não será capaz de alcançar esses prefixos nem mesmo pelo caminho alternativo via R4 (no AS 40), já que os prefixos foram negados. 



Para aqueles interessados em estudar mais detalhes do BGP, há outros artigos no blog:

Convenhamos que material para estudar não falta, não é? ;-) Reforço que essas configurações dos atributos do BGP abordados neste e em outros artigos do blog não fazem parte do recente curículo CCNA 6.0 que compõe o novo exame 200-125.

Façam seus testes...

Samuel.

terça-feira, 17 de maio de 2016

Nova Atualização no Currículo CCNA R&S

Olá Pessoal,

Hoje de tarde foi oficialmente divulgado pelo programa Cisco Networking Academy que o atual currículo CCNA 5.0 Routing & Switching (RS) está em fase de substituição para o novo currículo CCNA 6.0. Os instrutores das academias oficiais já têm à sua disposição o curso complementar intitulado CCNA R&S Bridging Course com conteúdo adicional de adaptação às alterações entre os dois currículos. É justo destacar que a resposta do programa NetAcad para alinhar os cursos às novas alterações foi bem rápida!


Essa alteração acontece cerca de 3 anos após o lançamento do currículo CCNA R&S 5.0, ocorrido em março de 2013, que trouxe algumas mudanças estruturais importantes na maneira pela qual o curso de CCNA R&S era ministrado nas academias oficiais. Nessa nova atualização as mudanças foram menos estruturais e mais de conteúdo mesmo, oportunidade para remover alguns tópicos legados (ou menos utilizados) e adicionar outros mais alinhados com o mercado. Acho conveniente relacionar somente aqueles tópicos que foram removidos e adicionados para facilitar a organização das informações para aqueles que já estão em fase de estudos.

Os seguintes tópicos foram removidos:

  • Frame-Relay
  • WAN Serial
  • CEF (Cisco Express Forwarding)
  • Pilha-Dupla do IPv6
  • VRRP e GLBP (em FHRP)

Os seguintes tópicos foram adicionados:

  • Noção de Componentes da Infraestrutura (Firewall, AP, WLC)
  • Arquitetura Tradicional em Camadas x Arquitetura de Núcleo Colapsado
  • Configuração e Verificação da Autoconfiguração SLAAC em IPv6
  • Endereço IPv6 Anycast
  • Protocolo LLDP
  • Fundamentos do Serviço DNS e DHCP
  • Conceito de Topologias WAN (Single-Homed x Dual-Homed)
  • Configuração Básica de BGP (eBGP)
  • VPN (DMVPN, Site-to-Site e Client-to-Site)
  • Monitoramento de Dispositivos via Syslog
  • Backup e Recuperação de Configurações dos Dispositivos
  • Conceitos de Computação em Nuvem
  • Conceitos de SDN (Software-Defined Network)
  • Conceitos de QoS
  • Aplicação Patch Trace (APIC-EM)

Em termos de mudança, observa-se aquela tendência de cobrança cada vez maior por conteúdo relacionado a IPv6, incluindo práticas de configuração. Outra alteração que já era esperada desde a publicação do currículo anterior foi a remoção da tecnologia legada Frame-Relay. Das demais alterações, percebe-se uma maior carga de fundamentos relacionados a tópicos recentes que envolvem computação em nuvem e programabilidade de redes. Talvez as únicas surpresas tenham sido BGP e QoS que, até então, eram explorados apenas em outras certificações. 

O antigo exame composto 200-120 (CCNA v2.0) poderá ser realizado até 20/08/2016, assim como os exames individuais 100-101 (ICND1) e 200-101 (ICND2). O novo exame composto passa a ser identificado pelo código 200-125 (CCNA v3.0), enquanto que os novos exames individuais passam a ser identificados pelos códigos 100-105 (ICND1 v3.0) e 200-105 (ICND2 v3.0). A partir de 20/ago deste ano, o candidato a CCNA R&S somente poderá realizar os novos exames. 

Os pesos das categorias abordadas no exame estão dispostos da seguinte forma:

  • [15%]  Fundamentos de Redes
  • [21%]  Tecnologias de Switching (LAN)
  • [23%]  Tecnologias de Roteamento
  • [10%]  Tecnologias de Longa Distância (WAN)
  • [10%]  Serviços de Infraestrutura
  • [11%]  Segurança na Infraestrutura
  • [10%]  Gerenciamento da Infraestrutura

Ao leitor interessado na relação detalhada de todo o conteúdo específico de cada uma das categorias acima, recomendo a leitura do blueprint oficial disponibilizado pela Cisco. Esse material pode ser acessado na íntegra a partir do link abaixo:


Bons estudos...

Samuel.

domingo, 15 de maio de 2016

VPN Site-to-Site no Firewall Cisco ASA do Packet Tracer

Olá Pessoal,

No artigo anterior apresentei ao leitor os procedimentos para realizar aquelas configurações mais básicas do firewall Cisco ASA 5505 (clique aqui para ler), um componente incorporado no Cisco Packet Tracer desde junho/2014 (versão 6.1.0). Expliquei que as opções de configuração do dispositivo ainda são bastante limitadas no simulador e agora aproveito para explorar neste artigo outra funcionalidade suportada, dessa vez relacionada à configuração de uma VPN Site-to-Site (também chamada de LAN-to-LAN) entre duas unidades de uma empresa que possuem firewalls ASA na borda das suas redes.

Observem na topologia da figura abaixo que a empresa possui uma matriz em São Paulo que contém a rede local 192.168.100.0/24 e uma filial no Rio de Janeiro que contém a rede 192.168.200.0/24. Cada unidade possui um firewall ASA na borda que está diretamente conectado na Internet e também na rede local de sua respectiva unidade. O ASA será configurado para conectar as duas unidades remotas através da Internet pública, uma prática bastante comum no mercado como alternativa aos tradicionais links corporativos de longa distância (WAN) que são caros. As VPNs também são frequentemente utilizadas como solução de backup para empresas que já têm um link corporativo. 

Abaixo vou trazer todas as configurações necessárias organizadas em diferentes seções e deixarei para fazer os comentários depois da relação dos comandos para facilitar a reprodução das configurações. A configuração do ASA 5505 em SP deve ficar da seguinte maneira:

!--
!-- 1. Configurações Básicas das Interfaces e Rota Default
!-- 

01. ciscoasa(config)# hostname ASA-SP
02. ASA-SP(config)# int vlan 1
03. ASA-SP(config-if)# nameif inside
04. ASA-SP(config-if)# security-level 100
05. ASA-SP(config-if)# ip address 192.168.100.1 255.255.255.0
06. ASA-SP(config-if)# int vlan 2
07. ASA-SP(config-if)# nameif outside
08. ASA-SP(config-if)# security-level 0
09. ASA-SP(config-if)# ip address 203.0.113.2 255.255.255.252
10. ASA-SP(config-if)# exit
11. ASA-SP(config)# route outside 0.0.0.0 0.0.0.0 203.0.113.1

!--
!-- 2. Definição do Perfil de Trafego (Objetos e ACLs)
!-- Repare que todo tráfego está liberado, uma prática não recomendada

12. ASA-SP(config)# object network LAN-SP
13. ASA-SP(config-network-object)# subnet 192.168.100.0 255.255.255.0
14. ASA-SP(config-network-object)# object network LAN-RJ
15. ASA-SP(config-network-object)# subnet 192.168.200.0 255.255.255.0
16. ASA-SP(config-network-object)# exit
17. ASA-SP# configure terminal
18. ASA-SP(config)# access-list TRAFEGO-VPN extended permit icmp object LAN-SP object LAN-RJ
19. ASA-SP(config)# access-list ENTRADA extended permit icmp any any
20. ASA-SP(config)# access-list ENTRADA extended permit  udp any any
21. ASA-SP(config)# access-list ENTRADA extended permit  tcp any any
22. ASA-SP(config)# access-group ENTRADA in interface outside

!--
!-- 3. Definição das Políticas de Segurança (IKEV1/IPSec)
!--

23. ASA-SP(config)# crypto ikev1 policy 1
24. ASA-SP(config-ikev1-policy)# authentication pre-share
25. ASA-SP(config-ikev1-policy)# encryption aes
26. ASA-SP(config-ikev1-policy)# hash sha
27. ASA-SP(config-ikev1-policy)# group 2
28. ASA-SP(config-ikev1-policy)# exit
29. ASA-SP(config)# crypto ikev1 enable outside
30. ASA-SP(config)# crypto ipsec ikev1 transform-set IPSEC esp-aes esp-sha-hmac

!--
!-- 4. Criação do Túnel Virtual p/ Site Remoto
!--

31. ASA-SP(config)# tunnel-group 198.51.100.2 type ipsec-l2l
32. ASA-SP(config)# tunnel-group 198.51.100.2 ipsec-attributes
33. ASA-SP(config-tunnel-ipsec)# ikev1 pre-shared-key SENHA
34. ASA-SP(config-tunnel-ipsec)# exit

!--
!-- 5. Definição da VPN (Junção dos Parâmetros de Segurança)
!--

35. ASA-SP(config)# crypto map VPN 1 match address TRAFEGO-VPN
36. ASA-SP(config)# crypto map VPN 1 set peer 198.51.100.2
37. ASA-SP(config)# crypto map VPN 1 set ikev1 transform-set IPSEC
38. ASA-SP(config)# crypto map VPN interface outside


A primeira seção (linhas de 01 a 11) traz apenas as configurações básicas das interfaces inside e outside, além da rota default que aponta para o provedor de cada unidade. No segundo bloco de configuração (linhas de 12 a 22) criamos dois objetos correspondentes às sub-redes da matriz (192.168.100.0/24) e da filial (192.168.200.0/24). Na sequência criaremos uma ACL dizendo que o tráfego de interesse da VPN será aquele originado na matriz (192.168.100.0/24) e destinado à filial (192.168.200.0/24), fazendo referência ao tráfego que sairá para a Internet através da interface outside (ACL TRAFEGO-VPN). Também aproveitaremos para permitir a entrada de tráfego vindo do site remoto na interface outside do ASA (ACL ENTRADA), já que sua política padrão não permite nada vindo da Internet.

Em relação às configurações de segurança (linhas de 23 a 30), primeiro é necessário definir uma política ISAKMP (IKEV1) para fins de estabelecimento dos canais cifrados entre as duas pontas remotas, através do qual será negociada associação (security association). Neste exemplo optamos por utilizar um par de chave compartilhada previamente configurado em cada site (pre-shared key). Também é necessário definir o conjunto de transformação do IPSec (transform-set) que será utilizado para realizar a cifragem dos pacotes de dados (AES) e também para autenticação (HMAC). São várias as opções de transform-set, por isso é importante estar atento para que ambos os lados sejam configurados de maneira idêntica nesse quesito.

Na sequência fazemos a configuração do túnel virtual entre os dois sites (linhas de 31 a 34), destacando que em cada localidade o nome do túnel deve fazer referência ao IP do site remoto. Por fim, nas linhas de 35 a 38, utilizamos o recurso crypto-map para unificar todas as configurações de segurança realizadas anteriormente e ativamos o túnel na interface outside do ASA para que a VPN possa ser estabelecida. Observem que é nessa etapa que utilizamos aquela ACL denominada TRAFEGO-VPN para instruir que todo tráfego entre as duas unidades remotas deverá ser direcionado pelo túnel, ao invés de roteado da maneira tradicional, além de criptografado antes de trafegar pela Internet pública.

A configuração do ASA no RJ é muito parecida, com alguns detalhes invertidos:

!--
!-- 1. Configurações Básicas das Interfaces e Rota Default
!--

ciscoasa(config)# hostname ASA-RJ
ASA-RJ(config)# int vlan 1
ASA-RJ(config-if)# nameif inside
ASA-RJ(config-if)# security-level 100
ASA-RJ(config-if)# ip address 192.168.200.1 255.255.255.0
ASA-RJ(config-if)# int vlan 2
ASA-RJ(config-if)# nameif outside
ASA-RJ(config-if)# security-level 0
ASA-RJ(config-if)# ip address 198.51.100.2 255.255.255.252
ASA-RJ(config-if)# exit
ASA-RJ(config)# route outside 0.0.0.0 0.0.0.0 198.51.100.1

!--
!-- 2. Definição do Perfil de Trafego (Objetos e ACLs)
!-- Repare que todo tráfego está liberado, uma prática não recomendada

ASA-RJ(config)# object network LAN-SP
ASA-RJ(config-network-object)# subnet 192.168.100.0 255.255.255.0
ASA-RJ(config-network-object)# object network LAN-RJ
ASA-RJ(config-network-object)# subnet 192.168.200.0 255.255.255.0
ASA-RJ(config-network-object)# exit
ASA-RJ# configure terminal
ASA-RJ(config)# access-list TRAFEGO-VPN extended permit icmp object LAN-RJ object LAN-SP
ASA-RJ(config)# access-list ENTRADA extended permit icmp any any
ASA-RJ(config)# access-list ENTRADA extended permit  udp any any
ASA-RJ(config)# access-list ENTRADA extended permit  tcp any any
ASA-RJ(config)# access-group ENTRADA in interface outside

!--
!-- 3. Definição das Políticas de Segurança (IKEV1/IPSec)
!--

ASA-RJ(config)# crypto ikev1 policy 1
ASA-RJ(config-ikev1-policy)# authentication pre-share
ASA-RJ(config-ikev1-policy)# encryption aes
ASA-RJ(config-ikev1-policy)# hash sha
ASA-RJ(config-ikev1-policy)# group 2
ASA-RJ(config-ikev1-policy)# exit
ASA-RJ(config)# crypto ikev1 enable outside
ASA-RJ(config)# crypto ipsec ikev1 transform-set IPSEC esp-aes esp-sha-hmac

!--
!-- 4. Criação do Túnel Virtual p/ Site Remoto
!--

ASA-RJ(config)# tunnel-group 203.0.113.2 type ipsec-l2l
ASA-RJ(config)# tunnel-group 203.0.113.2 ipsec-attributes
ASA-RJ(config-tunnel-ipsec)# ikev1 pre-shared-key SENHA
ASA-RJ(config-tunnel-ipsec)# exit

!--
!-- 5. Definição da VPN (Junção dos Parâmetros de Segurança)
!--

ASA-RJ(config)# crypto map VPN 1 match address TRAFEGO-VPN
ASA-RJ(config)# crypto map VPN 1 set peer 203.0.113.2
ASA-RJ(config)# crypto map VPN 1 set ikev1 transform-set IPSEC
ASA-RJ(config)# crypto map VPN interface outside

A configuração de VPN site-to-site no Packet Tracer ainda apresenta bastante instabilidade, por isso é normal que seja necessário forçar a geração do tráfego IPSec através da ferramenta de simulação do software para que o túnel seja estabelecido. Para saber se as configurações funcionaram, além de fazer o ping até as máquinas das unidades remotas, também é recomendado utilizar os comandos abaixo (destaque em amarelo) para exibir o status da VPN:

ASA-SP# show crypto isakmp sa

IKEv1 SAs:


  Active SA: 1

  Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1

1   IKE Peer: 198.51.100.2
    Type    : L2L             Role    : responder
    Rekey   : no              State   : QM_IDLE

There are no IKEv2 SAs



ASA-SP# show crypto ipsec sa


interface: outside

    Crypto map tag: VPN, seq num: 1, local addr 203.0.113.2

      permit icmp object MATRIZ-SP object FILIAL-RJ

      local   ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/1/0)
      remote  ident (addr/mask/prot/port): (192.168.200.0/255.255.255.0/1/0)
      current_peer 198.51.100.2
      (...) Saída Omitida
      local crypto endpt.: 203.0.113.2/0, remote crypto endpt.:198.51.100.2/0
      (...) Saída Omitida

Façam seus testes...

Samuel.