(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.
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.
