BGP – Mandatory Well-Known (Path Attributes)

O Protocolo BGP utiliza diversos parâmetros para escolha de melhor rota quando há diversos caminhos para o mesmo destino, esses parâmetros são chamados de Path Atributes.

Cada atualização do BGP consiste em uma ou mais sub-redes (prefixos) vinculadas aos seus atributos.

Os Path Atributes são classificados em Well-Known ( bem conhecido ) ou Optional (opcional). Alguns desses atributos são obrigatórios e outros opcionais com validade local na tabela de roteamento, local no AS, etc.

Os atributos Well-Known são classificados em Mandatory(obrigatório ) e Discretionary ( arbitrário).

No tópico de hoje citaremos os atributos MandatoryWell-Known (bem conhecidos e obrigatórios).

Mandatory Well-Known

São 3 os atributos Mandatory Well-Known – Origin, AS-Path e Next-hop:

Origin: Relaciona a maneira que a rota foi aprendida pelo BGP. Se a rota foi declarada com o comando network ou via agregação de rotas ela será exibida com a letra “i”, para as rotas aprendidas via redistribuição é utilizado o caracter “?”. Há ainda a possibilidade da rota ser aprendida via o protocolo EGP,”e” mas atualmente o mesmo está em desuso.

AS-Path: Quando um prefixo é injetado no BGP e compartilhado entre os AS, inicialmente o AS-Path é atribuído como vazio, cada vez que a rota atravessa um AS(Sistema Autônomo) é adicionado pelos roteadores de Borda o numero do AS que ele pertence. É possível rastrear a sequencia de Sistemas Autônomos utilizando o atributo AS-Path.

Next-hop: Indica o endereço do próximo salto do Roteador que recebeu o prefixo. Geralmente o roteador que anuncia determinado prefixo repassa com o next-hop o seu próprio IP, exceto em sessões iBGP.

SHOW

O comando show ip bgp exibirá a saída da tabela BGP do Roteador com Cisco IOS:

Router>show ip bgp
BGP table version is 2709, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop        Metric LocPrf Weight Path
   Network          Next Hop        Metric LocPrf Weight Path
* i1172.31.1.0/29   0.0.0.0              0    100  32768 i
* i1172.16.10.0/24  0.0.0.0              0    100  32768 ?
* i1172.16.11.0/24  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?
* i1172.16.12.0/22  192.168.85.22        0    100      0 65510 65544 65516 65541 ?
*>                  192.168.85.23        0             0 65510 65544 65516 65541 ?

[saída omitida]

! A rede 172.31.1.0/29 está diretamente conectada no Roteador e inserida processo via comando Network ! Já a rede 172.16.10.0/24 foi inserida na tabela BGP via processo de redistribuição

Peering BGP

O comando show ip bgp summary exibe os “peerings” BGP:

Router>show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 65500
BGP table version is 2709, main routing table version 2709
258 network entries using 29154 bytes of memory
510 path entries using 24480 bytes of memory
6725/10 BGP path/bestpath attribute entries using 672500 bytes of memory
2 BGP rrinfo entries using 48 bytes of memory
856 BGP AS-PATH entries using 32108 bytes of memory
270 BGP community entries using 7536 bytes of memory
12 BGP extended community entries using 304 bytes of memory
197 BGP route-map cache entries using 6304 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 772434 total bytes of memory
BGP activity 449536/418807 prefixes, 1538082/1477309 paths, scan interval 60 secs

Neighbor      V    AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down  State/PfxRcd
192.168.85.22 4 65510  962698  517851  2701   0    0 1w2d         24
192.168.85.23 4 65510  517865  517853  2701   0    0 1w2d         25
Router>

Até logo!

BGP Communities

O protocolo BGP possui a versatilidade de agregar redes e atributos; anunciando e modificando cada prefixo de maneira individual. Um desses atributos, o Community permite “taguear”  o anuncio de cada rede individualmente de acordo com o negócio, políticas de roteamento ou para fins de troubleshooting.

De forma básica o uso de community (ou “comunidade BGP” em português) pode ser usado como uma flag para marcar um determinado grupo de rotas.

Provedores de Serviço utilizam essas marcações para aplicar políticas de roteamento específicas em suas redes, por exemplo alterando o Local PreferenceMED ou Weight.

O atributo community é opcional e transitivo (optional transitive)  e de tamanho variável, isto é, implementações BGP não necessitam reconhecer o atributo e fica ao critério do administrador de rede alterar ou reencaminhar para outros pares . O atributo consiste em um número de 32 bits que específica uma community. Sendo que sua representação é feita AA:NN onde o AA é o Autonomous System (AS) e o NN é o número da community.

Um prefixo pode participar de mais de uma community e  os roteadores BGP podem tomar uma ação em relação à um prefixo baseado em uma, algumas ou todas as communities associadas ao prefixo.

O comando utilizado para configurar uma community em um Roteador Cisco (baseado no IOS) é via set community dentro de um route-map:

R1(config-route-map)#set community ?
  <1-4294967295>  community number
  aa:nn           community number in aa:nn format
  additive        Add to the existing community
  internet        Internet (well-known community)
  local-AS        Do not send outside local AS (well-known community)
  no-advertise    Do not advertise to any peer (well-known community)
  no-export       Do not export to next AS (well-known community)
  none            No community attribute

O comando “set community” apaga a comunidade existente vinculada a um prefixo substituindo-o pela nova community, a menos que seja especificado o comando additive após o valor da community.

 R1(config-route-map)#set community 65535:1 additive

A community pode ser aplicada em um ou mais prefixos  com a utilização de route-maps nos seguintes itens do processo BGP:

  • No peering BGP de in/out
  • Redistribuição
  • Comando network

Três communities são definidas e reservadas na RFC 1997 para implementações  BGP: NO-EXPORT (0xFFFFFF01 ), NO-ADVERTISE (0xFFFFFF02 ), and NO-ADVERTISE-SUBCONFED (0xFFFFFF03 ). Adicionalmente, NO-PEER (0xFFFFFF04 ) tem sido proposta em um draft para Internet [3].

NO-EXPORT é geralmente utilizado dentro de um AS para instruir os roteadores para não exportar o prefixo para vizinhos eBGP.

NO-ADVERTISE instrui um roteador BGP para não encaminhar o prefixo “tagueado” para qualquer vizinhos, seja iBGP ou eBGP.

NO-ADVERTISE-SUBCONFED é utilizado para prevenir um prefixo de ser anunciado para outros membros dentro da confederação.

NO-PEER é usado em situações onde é necessário o controle de engenharia de tráfego ao longo de um prefixo “mais específico”,  restringindo a sua propagação apenas aos prestadores de trânsito e não seus pares. Ou seja, o prefixo é anunciado de AS para AS, desde que haja uma relação de trânsito / cliente, ao contrário do NO-EXPORT, que restringe a propagação do prefixo somente ao AS adjacente.  Atualmente tal comunidade não é reconhecido pela maioria dos fabricantes e requer uma implementação manual.

Durante processos complexos de redistribuição de IGPs no BGP, o uso de community pode ser usado para detectar o protocolo de origem (por exemplo, uma community para IS-IS outra definida para OSPF, etc).

Community List

A Community-list é como uma ACL, só que para communities. Essas listas são adicionadas com o comando “ip community-list ” onde o valor é representado por “AA:NN” ou por caracteres especiais como, por exemplo, “*” que representa tudo.

Exemplo de configuração

No exemplo abaixo iremos anunciar 3 prefixos do ASN 65524, dois serão marcados com community e um sem  community. No ASN 65525 iremos atribuir um valor de local preference para cada prefixo de acordo com a comunidade atribuída.

Roteador R4
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Configurando as route-maps para atribuir o valor de community
route-map SET_COMM_B permit 10
 set community 65524:2
!
route-map SET_COMM_A permit 10
 set community 65524:1
!
router bgp 65524
 no synchronization
 bgp log-neighbor-changes
 network 172.16.100.0 mask 255.255.255.0 route-map SET_COMM_A
 network 172.16.101.0 mask 255.255.255.0 route-map SET_COMM_B
 network 172.16.102.0 mask 255.255.255.0
! Anunciando as redes no processo BGP de acordo com as communities atribuídas 
 neighbor 192.168.45.5 remote-as 65525
 neighbor 192.168.45.5 send-community
! Permitindo o envio de community para o peer BGP 
 no auto-summary
!
ip classless
ip route 172.16.100.0 255.255.255.0 Null0
ip route 172.16.101.0 255.255.255.0 Null0
ip route 172.16.102.0 255.255.255.0 Null0
!
end
Roteador R5
!
ip bgp-community new-format
! Exibe o valor da community de 32 bits dividido em 2 de 16 separados por ":"
!
! Community-list para filtro de valores de Communities
ip community-list standard LOCAL_PREF_150 permit 65524:1
ip community-list standard LOCAL_PREF_200 permit 65524:2
!
!
route-map SET_LOCAL_PREF permit 10
 match community LOCAL_PREF_150
 set local-preference 150
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 20
 match community LOCAL_PREF_200
 set local-preference 200
! Atribuindo o local preference aos prefixos da community-list
!
route-map SET_LOCAL_PREF permit 30
!
router bgp 65525
 neighbor 192.168.45.4 remote-as 65524
 neighbor 192.168.45.4 send-community
 neighbor 192.168.45.4 route-map SET_LOCAL_PREF in
! Atribuíndo os route-maps configurados no peering BGP
 no auto-summary
!
ip classless
!
end
!
! Verificando o valor de Local Preference atribuído a cada prefixo
R5#show ip bgp
BGP table version is 4, local router ID is 192.168.45.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure
Origin codes: i - IGP, e - EGP, ? – incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.100.0/24  192.168.45.4             0    150      0 65524 i
*> 172.16.101.0/24  192.168.45.4             0    200      0 65524 i
*> 172.16.102.0/24  192.168.45.4             0             0 65524 i
!
! Verificando o valor de community atribuído ao prefixo
R5#show ip bgp 172.16.100.0
BGP routing table entry for 172.16.100.0/24, version 2
Paths: (1 available, best #1)
  Not advertised to any peer
  65524
    192.168.45.4 from 192.168.45.4 (192.168.45.4)
      Origin IGP, metric 0, localpref 150, valid, external, best
      Community: 65524:1

Até logo!!!

Referências

http://babarata.blogspot.com.br/2010/05/bgp-atributo-community.html

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-2/bgp_communities.html

http://www.rfc-editor.org/rfc/rfc1997.txt

Roteamento entre VRFs com MP-BGP

A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamento virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.

Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.

A configuração de VRFs é bem simples. Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para  nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…

Habilitando o import e export das VRFs

Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)

RD

Como explicado anteriormente,  as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .

O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente  como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.

O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.

R1(config-vrf)#rd ?
  ASN:nn or IP-address:nn  VPN Route Distinguisher
! Configurando a VRF para os clientes A B e C 
ip vrf Cliente_A
 rd 65000:1
!
ip vrf Cliente_B
 rd 65000:2
!
ip vrf Cliente_C
 rd 65000:3

Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.

RT
Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.

O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos).
Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.

!
ip vrf Cliente_A
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1
 route-target import 65000:2
!
ip vrf Cliente_B
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2
 route-target import 65000:1
!
ip vrf Cliente_C
 rd 65000:3
 route-target export 65000:3
 route-target import 65000:3
!

Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 ip vrf forwarding Cliente_A
 ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
 ip vrf forwarding Cliente_B
 ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
 ip vrf forwarding Cliente_C
 ip address 3.3.3.3 255.255.255.0
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary
 !
 address-family ipv4 vrf Cliente_A
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_B
 redistribute connected
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf Cliente_C
 redistribute connected
 no synchronization
 exit-address-family
!

Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs e o teste de ICMP

R1#show ip route vrf Cliente_A
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback1
2.0.0.0/24 is subnetted, 1 subnets
B 2.2.2.0 is directly connected, 00:08:22, Loopback2
R1#ping vrf Cliente_A 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms



Para dúvidas ou sugestões deixe um comentário.

BGP AFI / SAFI

O MP-BGP (Multiprotocol BGP) é uma extensão do BGP que permite ao protocolo transportar informações de roteamento para endereços de rede (unicast e multicast) e address families.

Quando o MP-BGP está configurado, o BGP instala as rotas MP-BGP em diferentes tabelas de roteamento. Cada tabela de roteamento é identificada pela familia do protocolo Address Family Indicator (AFI) e Subsequent Address Family Identifier (SAFI). A lista fornecida pelo IANA pode ser encontrada abaixo:

Address Family Identifiers (AFI)
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

Subsequent Address Family Identifier (SAFI)
http://www.iana.org/assignments/safi-namespace

Segue abaixo alguns exemplos da combinação AFI, SAFI:

AFI=1, SAFI=1, IPv4 unicast
AFI=1, SAFI=2, IPv4 multicast
AFI=1, SAFI=128, L3VPN IPv4 unicast
AFI=1, SAFI=129, L3VPN IPv4 multicast
AFI=2, SAFI=1, IPv6 unicast
AFI=2, SAFI=2, IPv6 multicast
AFI=25, SAFI=65, BGP-VPLS/BGP-L2VPN

Para novas implementações como BGP EVPN, o NLRI utiliza o AFI 25 reservado para L2VPN e o SAFI 70 para BGP EVPNs. A partir daí os vendors podem incluir novas implementações que desejarem em seus OS, para transporte de quaisquer endereços utilizando o BGP.

Resumindo…

O AFI é compartilhado entre roteadores BGP pares durante a messagem OPEN como parte do MP-BGP capabilities extension. É utilizado para descrever a o protocolo de rede associado com o endereço de rede enviado durante a mensagem BGP Update com o NLRI. O SAFI provê informações adicionais sobre o tipo de NRLI anunciado.

Referências

https://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/routing-enabling-multiprotocol-bgp.html
https://supportforums.cisco.com/discussion/10616871/bgp-afisafi-numbers
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
https://thebetternetwork.wordpress.com/2015/02/12/bgp-address-family-identifiers-afi-and-subsequent-address-family-identifiers-safi/