CREATE ACCOUNT

FORGOT YOUR DETAILS?

BGP Origin Path Attribute e Next Hop Self

by / segunda-feira, 07 novembro 2016 / Published in Cisco, Configuração, Routers

(Mais uma semana começando…)

Aproveitando o gancho do post anterior (e a topologia e a configuração…), vamos falar do Origin Path Attribute e do Next Hop Self.

Rota Default no BGP

O Origin Path Attribute (um dos atributos que os anúncios BGP carregam), sinaliza como a rota foi inserida na tabela BGP originalmente.

Podemos ver os códigos do Origin Path Attribute (“i”, “*” e “?”) quando inserimos o comando show ip bgp.

  • IGP (i): Indica que a rota foi inserida no BGP originalmente através através dos comando network, neighbor default-originate ou aggregate-address (em alguns casos; veja abaixo).
  • EGP (e): Indica que a rota foi inserida pelo Exterior Gateway Protocol, protocolo anterior ao BGP e já não utilizado. Note que não há relação entre EGP e eBGP.
  • Incomplete (?): Sinaliza que a rota foi inserida no BGP através dos comandos redistribute, default-information originate ou aggregate-address (em alguns casos; veja abaixo).

Quando usamos o comando aggregate-address para a sumarização manual, dependendo de como fazemos a configuração, a rota terá Origin Path Attribute “i” ou “?”.

  • Se o as-set não for utilizado, a rota sumarizada terá o código “i”.
  • Se o as-set for utilizado, tanto a rota sumarizada quanto as rotas componentes (que fazem parte da rota sumarizada), terão o código “i”.
  • Se a opção as-set for utilizada, mas existir ao menos uma rota componente com código “?”, a rota agregada terá o Origin Code “?”.
A coluna Patch mostra como a rota foi inserida no BGP inicialmente.
R2#sh ip bgp
BGP table version is 38, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
*>i 0.0.0.0          10.1.1.1                 0    100      0 i
*>i 4.4.4.4/32       10.1.1.1                 0    100      0 ?
* i 10.1.1.0/24      10.1.1.1                 0    100      0 ?
*>                   0.0.0.0                  0         32768 ?
*>i 10.10.0.0/24     10.1.1.1                 0    100      0 ?
  *>i 172.16.0.0/24    10.1.1.1                 0    100      0 ?
R2#

Rota default anunciada por R1, usando a opção neighbor default-originate (veja post anterior).

R2#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 27
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.1 from 10.1.1.1 (172.16.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
R2#

Rota para 4.4.4.4 anunciada por R1, usando o comando redistribute static (veja poste anterior).

R2#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 20
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.1.1.1 from 10.1.1.1 (172.16.0.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
R2#

E por que isso importa?

O BGP tem um longo processo para a escolha da melhor rota, e um dos passos para a escolha pode ser avaliar o Origin PA, sendo que uma rota (NLRI – Network Layer Reachability Information) com Origin PA IGP é preferida à uma rota EGP, que por sua vez é preferida a uma rota incomplete (?).

Next Hop Self

No post anterior tínhamos R1 e R2 no mesmo AS (10), enquanto R3 estava em um AS diferente (30). E na configuração do BGP no R1, tínhamos o comando neighbor 10.1.1.2 next-hop-self.

R1#sh run | sec router
router ospf 40
router bgp 10
bgp log-neighbor-changes
redistribute connected
redistribute static
neighbor 10.1.1.2 remote-as 10
 neighbor 10.1.1.2 next-hop-self
neighbor 10.1.1.2 default-originate
neighbor 10.10.0.2 remote-as 30
R1#

Quando um roteador envia updates para um peer eBGP (roteador em outro AS), o NEXT_HOP Path Attribute é alterado para o IP do roteador que está fazendo o anúncio. Ou seja, no nosso exemplo, todos os updates que R3 recebe de R1 vem com o NEXT HOP 10.10.0.1 (IP utilizado por R1 para enviar os updates).

R3#sh ip bgp
BGP table version is 7, local router ID is 10.10.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
*>  3.3.3.3/32       0.0.0.0                  0         32768 ?
*>  4.4.4.4/32       10.10.0.1                0             0 10 ?
*>  10.1.1.0/24      10.10.0.1                0             0 10 ?
*>  10.10.0.0/24     0.0.0.0                  0         32768 ?
*                    10.10.0.1                0             0 10 ?
*>  172.16.0.0/24    10.10.0.1                0             0 10 ?
R3#

No entanto, quando R1 envia os updates para R2 (estão no mesmo AS) o NEXT HOP informado por padrão é o IP do último roteador eBGP por onde o anúncio passou.

Com isso as rotas anunciadas por R3 chegariam ao R2 com o IP do R3, o que pode causar problemas no roteamento (se não houver uma rota para o NEXT HOP a rota não pode ser considerada best, ou ainda pode ser necessário a verificação recursiva, que causa aumento no consumo da CPU).

Com o comando next-hop-self em R1:

R2#sh ip bgp
BGP table version is 8, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
*>i 0.0.0.0          10.1.1.1                 0    100      0 i
*>i 3.3.3.3/32       10.1.1.1                 0    100      0 30 ?
*>i 4.4.4.4/32       10.1.1.1                 0    100      0 ?
*>  10.1.1.0/24      0.0.0.0                  0         32768 ?
* i                  10.1.1.1                 0    100      0 ?
*>i 10.10.0.0/24     10.1.1.1                 0    100      0 ?
*>i 172.16.0.0/24    10.1.1.1                 0    100      0 ?
R2#

Removendo o comando next-hop-self de R1:

R2#sh ip bgp
BGP table version is 5, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
*>i 0.0.0.0          10.1.1.1                 0    100      0 i
* i 3.3.3.3/32       10.10.0.2                0    100      0 30 ?
* i 4.4.4.4/32       172.16.0.2               0    100      0 ?
r>i 10.1.1.0/24      10.1.1.1                 0    100      0 ?
*>i 10.10.0.0/24     10.1.1.1                 0    100      0 ?
*>i 172.16.0.0/24    10.1.1.1                 0    100      0 ?
R2#

Da mesma forma que podemos mudar o comportamento de peers iBGP usando o comando next-hop-self, podemos mudar o comportamento de peers eBGP usando o comando next-hop-unchanged.

Até a próxima.

2 Responses to “BGP Origin Path Attribute e Next Hop Self”

  1. Luciano Rodrigues da Silva says : Responder

    Ainda estou tentando entender a lógica do BGP e já vi que vai dar trabalho…. =/

    Por curiosidade, onde vc está fazendo esse diagrama dos roteadores? Obrigado!

Deixe uma resposta

TOP