SIGN IN YOUR ACCOUNT TO HAVE ACCESS TO DIFFERENT FEATURES

CREATE AN ACCOUNT FORGOT YOUR PASSWORD?

FORGOT YOUR DETAILS?

AAH, WAIT, I REMEMBER NOW!

CREATE ACCOUNT

ALREADY HAVE AN ACCOUNT?
GET SOCIAL
  • BLOG
  • SECURITY ALERTS
  • CONTATO
  • PRIVACIDADE
  • SOBRE
  • LOGIN

Brainwork

  • Certificação
  • Cisco
  • Informação
  • Linux
  • Microsoft
  • Network
  • Security
  • UC
  • Virtualização
  • Wireless
  • Home
  • Cisco
  • BGP Origin Path Attribute e Next Hop Self
07/08/2022

BGP Origin Path Attribute e Next Hop Self

BGP Origin Path Attribute e Next Hop Self

by André Ortega / segunda-feira, 07 novembro 2016 / Published in Cisco, Configuração, Network

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

Relacionado

Tagged under: BGP, CCIE, Next hop self, Origin PA, Path attributes

About André Ortega

Formando em Processamento de Dados e Ciência da Computação. Especialista Cisco (CCNP Enterprise e CCNP Security). Dezessete anos de experiência com redes e segurança.

What you can read next

DHCP Relay em switches Nexus
Tamanho da senha no roteador
Informações sobre usuários conectados no AP Cisco

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

  1. Luciano Rodrigues da Silva says :
    07/11/2016 at 12:46

    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!

    1. André Ortega says :
      08/11/2016 at 09:28

      Realmente BGP é um tópico complexo.
      Fiz a topologia no Power Point.

POSTS RECENTES

  • Instalando certificado em roteador Cisco
    Instalando certificado em roteador Cisco
    07/07/2022
  • Meraki Internet Outages
    Meraki Internet Outages
    29/06/2022
  • Cisco Catalyst na dashboard Meraki
    Cisco Catalyst na dashboard Meraki
    15/06/2022
  • Testando acesso com o Test-NetConnection (PowerShell)
    Testando acesso com o Test-NetConnection (PowerShell)
    31/05/2022
  • Cisco Cybersecurity Giveaway
    Cisco Cybersecurity Giveaway
    23/05/2022

Tags

DHCP Sorteio VoIP SDWAN VMware Upgrade Switches Configuração CCIE policy-map switch Brainwork certificação PIX ASA WLC WLAN Controller Backup licença VPN Wireless Cisco IOS QoS FMC Segurança Meraki Firewall CiscoChampion ISE EEM WIFI Vulnerabilidade Catalyst Roteador Access-list IPS FirePower senha aniversário IPv6 CCNA LAB FTD ACL

Arquivo

Login

  • Cadastre-se
  • Acessar
  • Feed de posts
  • Feed de comentários
  • WordPress.org

Acesse Também

  • Blog LabCisco
  • Café com Redes
  • Cisco IOS hints and tricks
  • Cisco Redes
  • Cisco Support Community
  • Coruja de TI
  • Homelaber Brasil
  • Internetwork Expert´s
  • Netfinders Brasil
  • Rota Default
  • TechRebels
  • The Cisco Learning Network

Twitter

Triste realidade... Que atenção você da para seu IPS e demais soluções de monitoramento de rede? #ips #siem #logs pic.twitter.com/pfaffolRP4

Blog: Instalando certificado em roteador Cisco brainwork.com.br/2022/07/07/i… #Certificado #CiscoChampion #Root

Blog: Meraki Internet Outages brainwork.com.br/2022/06/29/m… #CiscoChampion #Meraki #ThousandEyes

Blog: Cisco Catalyst na dashboard Meraki brainwork.com.br/2022/06/15/c… #Catalyst #Cisco #CiscoChampion

@CiscoChampion I'd love to be there 🙁

Seguir @brainworkblog
  1. André Ortega em Testando acesso com o Test-NetConnection (PowerShell)
  2. André Ortega em Alta utilização de CPU – Coletando logs com o Event Manager
  3. Jardel D'Oliveira em Alta utilização de CPU – Coletando logs com o Event Manager
  4. Bruno Veras em Testando acesso com o Test-NetConnection (PowerShell)
  5. André Ortega em Cisco Catalyst na dashboard Meraki
Follow @brainworkblog

Brainwork
@brainworkblog

  • Triste realidade... Que atenção você da para seu IPS e demais soluções de monitoramento de rede? #ips #siem #logs https://t.co/pfaffolRP4
    about 3 semanas ago
    Reply Retweet Favorite

Entre em contato:

  • Email: blog@brainwork.com.br
  • Web: www.brainwork.com.br
  • Facebook: fb.com/brainworkblog
  • Twitter: twitter.com/brainworkblog
  • Youtube: youtube.com/brainworkblog
  • Instagram: instagram.com/brainwork.blog
  • GET SOCIAL
Brainwork

© 2008 - 2022 Brainwork. Todos os direitos reservados.
Customização da página por Brainwork.

TOP