Manipulação de Atributos PA do Protocolo BGP

Manipulação de Atributos PA do Protocolo BGP - Hallo my friends,, This post is entitled Manipulação de Atributos PA do Protocolo BGP, All of the content is aim for reader satisfaction. Hopefully all the posts will be easy to understand and likeable.

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 teria que acontecer 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. 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 bgp50

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.

Ok, That's all about Manipulação de Atributos PA do Protocolo BGP Thank you for visiting, and have a nice day

Manipulação de Atributos PA do Protocolo BGP