Al configurar MP-BGP, en el hardware de Juniper, puede surgir una situación de restablecimiento del vecindario (no) obvia. La razón se describe en detalle en la base de conocimiento Junuper KB20870 , aquí hay un breve recuento con mis comentarios.
Como sabes, cuando trabajas con VPN, se utilizan varias tablas de enrutamiento. Estaremos interesados en 2 principales: vrf.inet.0 y bgp.l3vpn.0 (en adelante, se describe la situación con L3VPN, pero esto también es cierto para otros servicios donde BGP es un protocolo de señalización).
La tabla bgp.l3vpn.0 contiene todas las rutas recibidas de los vecinos BGP.
Las rutas directas / estáticas de un enrutador PE específico se colocan en la tabla vrf.inet.0 , así como las rutas entrantes de los vecinos de la tabla bgp.l3vpn.0 que satisfacen la política de importación (si está configurada).
Al mismo tiempo, no se exporta desde vrf.inet.0 a bgp.l3vpn.0 , y las rutas se anuncian directamente a los vecinos.
Si el enrutador actúa como un reflector de ruta, o si hay vecinos MP eBGP, las rutas se colocan tanto en la tabla vrf.inet.0 como en bgp.l3vpn . En este caso, se realiza una comparación con las rutas locales y (si es necesario) se selecciona la mejor ruta.
Por lo tanto, el enrutador puede funcionar en uno de los dos modos definidos:
- no hay reflector de enrutador configurado en el enrutador y no hay vecinos eBGP;
- el enrutador es un reflector de ruta y / o hay vecinos eBGP en él.
Cambiar los modos implica reiniciar las sesiones MP-BGP. Claramente, esto se puede ver en la siguiente topología:
En la primera versión (Fig. 1), se presenta el esquema clásico iBGP de malla completa. Ahora imagine que necesitamos agregar el enrutador R4. Por una razón u otra, decidimos hacer esto configurando R1 como reflector de ruta para R4 (Fig. 2). Realizar la configuración del reflector de ruta en R1 implicará la reinstalación de todas las sesiones MP-BGP (con enrutadores R2 y R3), lo que implicará un tiempo de inactividad en la prestación de servicios.
Para evitar esto, se propone transferir firmemente el enrutador al segundo modo de operación. Una forma es crear un grupo ficticio eBGP. Por ejemplo:
group fake-vpn { type external; description "## Preventing mpbgp sessions flap ##"; passive; family inet { any; family inet-vpn { any; family iso-vpn { unicast; family l2vpn { signaling; family evpn { signaling; family inet-mvpn { signaling; family inet-mdt { signaling; neighbor 192.0.2.1 { peer-as 65536; }
AS: 65536 e IP: 192.0.2.1 pueden ser absolutamente cualquier cosa, y el modo pasivo le permite evitar intentos innecesarios de establecer una sesión inexistente desde el enrutador.
Cuando puede ser útil:
- No hay reflectores de ruta dedicados en la red. El papel de RR son los enrutadores principales de la red. Al mismo tiempo, existe la posibilidad de un cambio en su función (por ejemplo, de un enrutador P a un P / RR o viceversa);
- existe la posibilidad de que aparezca una interfaz eBGP con la familia MP-BGP, por ejemplo, Inter-AS.