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.

Um comentário:

  1. Parabéns Samuel,

    Muito interessante o post, assim que possível, irei configurar esse cenário..

    Att,

    ResponderExcluir