Rutas aprendidas de eBGP no distribuidas a los vecinos de iBGP

8

Tengo (en GNS3) tres Cisco 3640 que funcionan con 12.4 (23) conectados en serie (R1 -> R2 -> R3). R1 y R2 son pares de eBGP, R2 y R3 son pares de iBGP. R1 anuncia la red 192.168.1.0/24. R2 recibe esta ruta, pero no la anuncia a R3.

¿No deberían anunciarse las rutas aprendidas de eBGP a iBGP?

Aquí está la configuración completa como se ingresó:

loop0(R1)s0/0 <--> s0/0(R2)s0/1 <--> s0/1(R3)

R1:
configure terminal
interface s0/0
ip address 172.16.1.1 255.255.255.252
no shutdown
interface loopback0
ip address  192.168.1.1 255.255.255.0
router bgp 1
neighbor 172.16.1.2 remote-as 2
network 192.168.1.0 mask 255.255.255.0

R2:
configure terminal
interface s0/0
ip address 172.16.1.2 255.255.255.252
no shutdown
interface s0/1
ip address 172.16.1.5 255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.1 remote-as 1
neighbor 172.16.1.6 remote-as 2

R3:
configure terminal
interface s0/1
ip address 172.16.1.6  255.255.255.252
no shutdown
router bgp 2
neighbor 172.16.1.5 remote-as 2

— usuario1038451
fuente

14

Suponiendo que no tiene IGP configurado (como EIGRP / OSPF / ISIS / RIP), la explicación más simple es que R3 no tiene una ruta al siguiente salto de 192.168.1.0/24 cuando la actualización de iBGP llega a R3.

loop0(R1)s0/0 <-----------> s0/0(R2)s0/1 <-------------> s0/1(R3)
    AS 1                       AS 2                        AS 2

              --------->                  ----------->
              Prefix: 192.168.1.0/24      Prefix: 192.168.1.0/24
              AS-path: 1                  AS-path: 1
              Next-hop: 172.16.1.1        Next-hop: 172.16.1.1
              *via eBGP*                  *via iBGP*

Dado que iBGP no restablece el siguiente salto cuando recibe la actualización de R1, el siguiente salto de 192.168.1.0/24 (172.16.1.1) tiene que ser accesible (vea Por qué los enrutadores ignoran las rutas BGP para más detalles).

La forma más básica de probar esto es configurar una estática en R3:

ip route 172.16.1.0 0.0.0.3 172.16.1.5 name BAD_HACK_FOR_IBGP

Obviamente, esa es la solución incorrecta, pero es una prueba muy simple para ilustrar por qué las cosas están rotas (tenga en cuenta que es posible que deba esperar un poco para que se ejecute el escáner BGP next-hop antes de instalar la ruta 192.168.1.0/24) .

Hay dos posibles soluciones que vienen a la mente, pero solo una tiene sentido en la mayoría de las redes ...

La mejor solución : configure un IGP ... elija el IGP que desee y anuncie 172.16.1.0/30 en AS 2 en ese IGP
Solución opcional : configure la sesión de emparejamiento entre R2 y R3 para establecernext-hop-self

La accesibilidad al siguiente salto es uno de los problemas más básicos al comprender BGP; Casi todos se encuentran con este problema cuando están experimentando con el protocolo.

— Mike Pennington
fuente

1

Excelente explicación No sabía que iBGP pasa el siguiente salto sin modificar.

— user1038451

Mike, ¿podrías dar un ejemplo de cuándo no querrías usarlo next-hop-self(aparte de que ya tengo un IGP que anuncia la dirección del próximo salto del par eBGP)? Inicialmente iba a hacer otra pregunta para esto, pero pensé que sería un complemento fácil para su respuesta. Recientemente, después de haber estado analizando BGP, y sigo encontrándome con esto, me da curiosidad saber por qué next-hop-self no era el comportamiento predeterminado.

— Eddie

Puedo agregar información sobre esto, pero pueden pasar algunos días antes de que tenga tiempo. Breve historia: el costo de IGP para el próximo salto de BGP es parte del algoritmo de selección de ruta eBGP predeterminado

— Mike Pennington

0

Debería tener que anunciar sus interfaces conectadas en R2. porque la única red 192.168.1.0 ahora no sabe cuál es el próximo salto. Puede verificar con "show ip bgp" en R3.

Como puede ver 192.168.1.0 en la tabla R3 bgp pero no insertado en la tabla de enrutamiento. Porque no sabe cuál es el próximo salto

Solución:

Redistribuir interfaces conectadas en R2
Digamos vecino EBGP que quién es el próximo salto como " vecino 172.16.1.2 next-hop-self " en R1 .

— Deniz KAYDIRAK
fuente