cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
1850
Visitas
5
ÚTIL
7
Respuestas

NEXT-HOP BGP

madrileño18
Level 1
Level 1

Se me ha presentado un caso en una conexión PE-CE por eBGP en el que el PE anuncia una serie de rutas al CE y el CE anuncia las mismas rutas, añadiendo las que origina, de nuevo al PE con el mismo NEXT-HOP con el que se las anuncia el PE, es como si estuviera reflejando las rutas que le anuncia el PE. El PE por supuesto no las instala, pero yo creí que esto no era posible en una conexión eBGP y en general de los protocolos de routing, que se supone que tienen mecanismos para no enviar a un vecino las mismas redes que el vecino te está publicando.

Si hago un debug de las actualizaciones de BGP me muestra este mensaje, que no sé si es aclaratorio

 

*Jan  8 12:04:03.456: BGP(0): 172.16.1.1 NEXT_HOP is on same subnet as the bgp peer and set to 172.16.1.1 for net 192.168.240.0/20, flags 200, sb: 512E1000, mask: FFFFFE00

 

7 RESPUESTAS 7

Hola,

Seria de revisar la configuracion, podria existir una mala configuracion. Has revisado si esa direccion IP del next hop no esta siendo advertida a traves de BGP y algun protocolo de enrutamiento IGP como OSPF, EIGRP, etc. Por defecto un router cambia el next hop a su propia IP a una ruta BGP cuando la advierte. 

 

Revisa este enlace:

https://community.cisco.com/t5/routing/next-hop-attribute-in-bgp/td-p/2425033




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

El único protocolo que existe en el CE es BGP, y en la VRF del PE también hay BGP solamente. No sé si me he explicado lo raro no es que cambie el Next-Hop sino que no lo hace. La ip del Next-Hop no se anuncia a través de BGP.
Lo que pasa es que el PE recibe una serie de rutas y se las anuncia por eBGP al CE, con Next-hop la ip del PE, el CE las recibe por BGP y las vuelve a anunciar al PE con Next-Hop el PE, es decir, refleja lo que recibe del PE hacia el PE de nuevo. No intervienen más protocolos, solo BGP.
En el CE que se comporta de esta manera recibo el siguiente mensaje al hacer un debug ip bgp update:
*Jan 8 12:04:03.456: BGP(0): 172.16.1.1 NEXT_HOP is on same subnet as the bgp peer and set to 172.16.1.1 for net 192.168.240.0/20, flags 200, sb: 512E1000, mask: FFFFFE00
En los que no se comporta así este mensaje no lo muestra.
He buscado información sobre el significado de este mensaje, por si podía ayudarme, pero no encuentro nada.

Hola

Es muy raro ver que se publique el next hop via BGP, por lo general se utiliza un IGP, para crear la comunicacion entre las interfaces. Voy a simularlo y te comparto la info. 




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Gracias Julio. Pero el problema no es que se publique el next-hop o al menos yo no lo entiendo así.

Para centrarlo un poco más el asunto es ¿por qué una ruta que me anuncia mi vecino eBGP (el PE en este caso) se la vuelvo anunciar con los mismos atributos, sin modificar el next-hop ni nada? 

Lo que quiero decir es que en routing normalmente se dice que hay mecanismos para evitar esto. Es decir que si un vecino me anuncia una ruta, esa misma se la anuncie yo al vecino que es lo que me sucede. Obviamente luego el PE las descarta. Pero no sé a que se puede deber que si el CE recibe una ruta del vecino eBGP (un PE) le vuelva a anunciar esa misma ruta, exactamente la misma. Es decir un vecino eBGP anuncia una ruta y este se la vuelve anunciar sin modificar nada al mismo vecino que te le ha publicado , sin pasar por mas equipos intermedios ni nada, directamente.

Hola,

 

En mi opinion creo que Julio tiene razón, revisa la configuración del CE.

 

Con eBGP  (connección entre entre diferente sistemas autonomos (AS)), cuando usas este tipo de sesión, el PE tiene un AS diferente al CE,  existe un mecanismo automático que previene que las rutas reflejadas como las que observas en tu PE sean instaladas en la tabla de enrutamiento, ya que cuando el PE ve su propio número de AS en las rutas recibidas, este sabe que provienen de sí mismo. (next-hop-self).

 

Para responder tu pregunta acerca de porque esto esta sucediendo te comento, que en BGP solo en el caso de iBGP, donde todos los vecinos comparten el mismo numero de AS, es donde se aplica la regla que dice: ninguna ruta recibida de un vecino iBGP puede ser anunciada o re-enviada a ningun otro vecino BGP.  Si el otro router vecino iBGP necesita esa ruta tiene que establecer su propia sesion con el origen.

  

Comunmente en iBGP se utiliza una configuracion especial llamada router reflectors. El cual podria hacer ver el sintoma de anunciar las rutas recibidas del PE de regreso, tal como las describes;, puede que hayas configurado el CE erroneamente como un router reflector.

 

Una recomendación que hago siempre es filtrar todo vecino BGP ya sea con route-map+ACLs, o con prefix lists, las cuales se pueden aplicar a cada vecino de manera individual o grupal en cualquier dirección, IN/OUT, lo cual en tu caso evitaría que enviaras desde el CE lo mismo que recibes del PE.

 

Nota: despues de aplicar el filtro se debe reiniciar la session BGP con el comando clear ip bgp x.x.x.x  o clear ip bgp x.x.x.x soft in/out.

 

Tambien lo que dice Luis es posible, revisa si tienes los comandos

 

       neighbor ip-address ebgp-multihop ttl

       neighbor ip-address next-hop-unchanged

 

Porque el no modificar el next-hop (excepción) solo es posible cuando se usa eBGP multihop y se le instruye al router a comportarse así.

 

Saludos y espero te sirva de ayuda mi comentario.

 

 

 

 

 

Gracias bonillajose. El PE efectivamente sabe que provienen de sí mismo por eso no las instala en la tabla de enrutamiento. Es decir el CE recibe las rutas del PE y se las vuelve a anunciar al PE, pero no entiendo bien porque ocurre yo pensaba que si un equipo le anuncia rutas a otro vecino eBGP no se pueden volver a anunciar hacia el vecino que te las anunció a ti (aunque luego se descartan). De hecho yo he intentado reproducirlo en un laboratorio y no lo he conseguido.