Summary

  • BGP End-of-RIB indica que terminó la actualización inicial de una familia tras establecer la sesión; no es un certificado global para todos los AFI/SAFI.
  • Graceful Restart permite conservar rutas marcadas como stale mientras continúa el reenvío. Su reemplazo, eliminación, selección local, programación del FIB y viabilidad del plano de datos son pruebas distintas.
  • Hace falta un recibo por par y familia que una causa del reinicio, capacidad negociada, conjunto retenido, EOR, limpieza, FIB y pruebas vivas de ruta.

La sesión volvió antes que la evidencia

Supongamos que una sesión BGP se restablece tras un reinicio. Llega el EOR de IPv4 unicast y el monitor pinta la sesión de verde. Sin embargo, una segunda familia aún contiene rutas de la sesión anterior, y un flujo utiliza una entrada de reenvío construida antes del reinicio.

El primer EOR no contradice esa situación. Cierra la actualización inicial de una familia concreta. No habla por las demás familias negociadas ni prueba la viabilidad del estado de reenvío preservado. El error no es confiar en EOR, sino convertir un hecho protocolario acotado en un veredicto global de frescura.

La generalización es tentadora porque Graceful Restart busca continuidad. Retener el reenvío evita churn y pérdidas transitorias. Pero el mismo mecanismo crea un intervalo en el que «seguir reenviando» y «estar validado de nuevo» no son equivalentes.

Qué cierra realmente EOR

RFC 4724 define EOR para IPv4 unicast como un UPDATE sin NLRI alcanzable ni retirado. Para otras familias usa MP_UNREACH_NLRI sin rutas retiradas para el <AFI, SAFI> específico. El speaker lo envía al completar la actualización inicial de esa familia, incluso si no había anuncios que transmitir.

El alcance está incorporado en la codificación. Un EOR de IPv4 no dice nada de IPv6, VPN, EVPN u otra familia. Incluso dentro de esa familia solo afirma que el emisor terminó lo que pretendía enviar. El receptor aún debe aplicar las actualizaciones, reemplazar rutas stale, eliminar las restantes, ejecutar selección y programar el reenvío.

RFC 4724 también separa la producción de EOR de la capacidad de preservar forwarding. Un speaker puede anunciar Graceful Restart sin incluir ninguna familia solo para indicar que generará EOR y ayudará a un par que reinicia. Ni la capacidad ni el marcador demuestran por sí mismos que se preservó un estado utilizable.

El bit Restart State resuelve un problema de coordinación distinto. El speaker que reinicia lo activa en el nuevo OPEN, y su par no debe esperar el EOR de ese speaker antes de volver a anunciarle rutas. Restablecida la sesión, el speaker aplaza la selección de una familia hasta recibir EOR de los pares pertinentes o hasta que expire Selection_Deferral_Timer. Solo entonces selecciona rutas, actualiza el reenvío, elimina su propio estado stale y envía el EOR de esa familia. Registrar EOR sin esa secuencia mezcla el fin de los anuncios de los pares con la terminación del reenvío local.

Las rutas retenidas se llaman stale por una razón

Cuando el receptor detecta la pérdida de una sesión cuyo par anunció Graceful Restart para una familia, conserva las rutas de esa familia y las marca stale. Al reenviar no las distingue del resto. Es continuidad deliberada, no una afirmación de frescura.

Las reglas de limpieza aportan el reloj. Si la sesión no vuelve dentro del Restart Time, las rutas deben eliminarse. Tras el restablecimiento también se borran inmediatamente si la nueva capacidad omite la familia, su bit Forwarding State no está activo o no se recibe la capacidad. Los nuevos anuncios reemplazan rutas stale; al llegar EOR de esa familia, cualquier ruta aún stale debe retirarse.

Importa la identidad y el destino de las rutas, no el color del panel. Antes de EOR una ruta puede esperar reemplazo. EOR fija el límite para limpiar lo restante. Después, la selección local y el FIB todavía deben producir un resultado usable.

La viabilidad del reenvío es otra observación

El bit Forwarding State por familia se refiere a la preservación del forwarding durante el reinicio. RFC 4724 lo vincula a preservación real, con una salvedad de configuración. No es una prueba de paquetes. El RFC deja fuera de alcance cómo decidir si el forwarding del par sigue siendo viable y menciona BFD o la supervisión de capa 2 solo como ejemplos.

Un next hop preservado puede dejar de servir mientras las rutas siguen retenidas. El FIB local puede ir detrás del RIB. Puede haber blackholes o bucles aunque la sesión haya regresado y EOR se haya procesado. A la inversa, una marca stale no prueba fallo: el forwarding retenido puede funcionar exactamente como se diseñó.

RFC 8538 extiende el tratamiento graceful a determinadas NOTIFICATION y a la expiración de Hold Time cuando se intercambia el bit N. Ambos speakers actúan entonces como receptores y conservan las rutas del otro. Hard Reset exige un reinicio completo. Con el bit N intercambiado se relaja la regla que eliminaba una ruta ya stale ante reinicios consecutivos; por eso el temporizador pasa a ser el límite esencial contra la retención indefinida. La extensión hace obligatorio un stale timer configurable, sugiere 180 segundos y advierte que una retención larga o infinita causa problemas operativos.

Fuentes