Resumen

  • LLGR permite retener rutas por AFI/SAFI durante un segundo periodo, pero el tiempo anunciado por el vecino no demuestra que el next hop, el FIB ni el servicio sigan funcionando.
  • La continuidad solo es defendible cuando la capacidad y el límite aceptado se unen a marcas, selección, alcance, paquetes y una retirada verificable al recibir EoR, vencer el tiempo o intervenir el operador.

Imaginemos un caso construido para aislar el mecanismo. Una sesión BGP desaparece y su periodo normal de Graceful Restart termina. El helper conserva seis horas más una ruta específica, ahora marcada como obsoleta y colocada al final de la preferencia. Existe una ruta reciente menos específica. Sin embargo, los paquetes dirigidos al prefijo retenido siguen escogiendo la coincidencia más larga. El panel conserva una ruta; el destino ya no conserva el servicio.

El ejemplo no presupone una implementación defectuosa. RFC 9494 autoriza precisamente una segunda custodia de estado cuando la retirada inmediata tendría un coste elevado. La posibilidad es valiosa para información que tarda en reconstruirse. En alcance IP convencional, también puede alargar un agujero negro o una decisión inconsistente.

La cuestión de mando no es si un fabricante ofrece LLGR. Es qué parte puede proponer el plazo, quién acepta el riesgo local, qué dependencias caducan antes y qué evidencia tiene fuerza suficiente para terminar la retención.

La recuperación ordinaria no desaparece

RFC 4724 aporta la base. La capacidad Graceful Restart tiene el código 64 e incluye un Restart Time y estado por familia. Cuando una sesión termina, el receiving speaker puede conservar temporalmente las rutas del speaker que reinicia. El marcador End-of-RIB señala que este ha completado su actualización inicial para un AFI/SAFI.

La causa de la terminación importa. RFC 8538 permite que dos pares que intercambian el bit N usen semántica de recuperación ante muchas NOTIFICATION y ante la expiración del Hold Time. Un Cease con el subcódigo Hard Reset reclama una terminación completa. Una cronología que solo dice «la sesión cayó» omite una decisión normativa central.

RFC 9494 añade la capacidad 71. Cada entrada identifica AFI, SAFI, flags y Long-Lived Stale Time. LLST ocupa 24 bits y se expresa en segundos. El estándar no establece un valor predeterminado, porque una ruta de alcance, una restricción de Route Target o un estado de descubrimiento no tienen la misma vida útil.

LLGR reutiliza la máquina de estados, EoR y el reinicio de GR. Por eso una capacidad LLGR sin la capacidad GR debe ignorarse. Ver el número 71 en una salida no basta: también se necesita el 64, la familia concreta y los parámetros aplicables en ambos extremos.

Los dos periodos pueden ser consecutivos. Primero actúa GR, durante el cual la retención no rebaja por sí misma la preferencia. Después actúa LLGR, que convierte las rutas guardadas en least preferred. Antes de restablecerse la sesión, la retención máxima de protocolo es Restart Time más LLST, siempre sujeta a los límites locales.

Un periodo puede valer cero. El receptor puede reducir el tiempo propuesto. El envío de una cifra, por tanto, no crea una obligación unilateral: ofrece un presupuesto que la política local puede acortar, rechazar por familia o excluir por ruta.

Menor preferencia no equivale a ausencia

Al comenzar LLGR, el helper inicia un temporizador por AFI/SAFI y añade LLGR_STALE. IANA registra esta comunidad bien conocida como 0xFFFF0006 o 65535:6. La ruta debe perder frente a cualquier candidata que no sea least preferred. Si todas las candidatas tienen esa condición, vuelve a aplicarse el desempate normal.

La medida busca que una alternativa fresca gane, pero no fabrica alternativas. Una ruta stale puede seguir siendo best path. Además, una ruta fresca agregada no evita que el FIB use un prefijo stale más específico. RFC 9494 advierte que el uso de alcance convencional puede producir pérdida persistente para los destinos cubiertos.

En un núcleo hop-by-hop aparece otro límite. Dos routers iBGP pueden observar distinto estado de sesión y rebajar de manera diferente la misma ruta. Uno envía hacia la alternativa y el otro hacia el camino retenido. La divergencia puede crear un bucle de reenvío. El propio RFC no recomienda LLGR para esos conjuntos cuando la red decide salto a salto.

El transporte por túneles reduce aquella clase de bucle, pero no certifica el extremo. La exigencia de resolubilidad de RFC 4271 sigue vigente. El estándar menciona BFD como señal adicional posible sobre la viabilidad del next hop. Una sesión BFD tampoco prueba que una aplicación o una cadena de servicio responda.

LLGR cambia el momento de retirar la ruta; no cambia la naturaleza de la prueba. No autentica el origen, no autoriza el prefijo, no confirma el hardware y no convierte el estado de control en entrega de paquetes.

La posibilidad de negarse viaja en una comunidad

NO_LLGR, registrado como 0xFFFF0007 o 65535:7, marca las rutas que no deben entrar en la retención prolongada. Puede llegar desde el speaker o resultar de una política configurada en el helper. Cuando comienza el periodo LLGR, esas rutas se eliminan según el comportamiento normal de BGP.

Esta marca permite separar información con vidas útiles diferentes. No es una firma. RFC 1997 define el atributo Communities, pero el valor no autentica a quien lo escribió. Una política intermedia puede conservar, sustituir o eliminar comunidades. La prueba tiene que mostrar el atributo recibido y anunciado en cada límite material.

La propagación también está limitada. Una ruta LLGR_STALE no debería anunciarse a un vecino que no haya anunciado LLGR. De ese modo, el estado prolongado queda dentro de un perímetro cuyos speakers entienden la depreferencia. Mantener una ruta localmente y exportarla son dos autorizaciones distintas.

Existe una excepción para adopción parcial, no una libertad general. RFC 9494 permite anunciar a un vecino iBGP o de confederación sin LLGR si se añade NO_EXPORT y se fija LOCAL_PREF en cero. La red debe aplicar ese cero de manera coherente. La consistencia es lo que evita que diferentes speakers construyan realidades de selección incompatibles.

El temporizador sigue corriendo cuando vuelve el verde

El bit F de LLGR declara por familia si el estado se preservó en el reinicio anterior. Si la sesión restablecida deja de incluir el AFI/SAFI, no marca F o no vuelve a presentar las capacidades necesarias, el helper debe borrar inmediatamente las rutas stale de esa familia.

Los reinicios consecutivos no renuevan libremente la deuda. Salvo intervención manual, un LLST en curso no se actualiza hasta que el par haya establecido y sincronizado una nueva sesión. La sincronización se produce por familia cuando llega EoR o vence el Selection_Deferral_Timer de GR.

Incluso después de llegar a Established, el LLST sigue avanzando hasta EoR. Si vence durante la sincronización, se retiran las rutas antiguas que el vecino no ha actualizado. Por eso una sesión verde puede acompañar un conjunto de rutas en proceso de desaparición. El inventario relevante es la diferencia entre lo retenido y lo realmente refrescado.

EoR cierra una época de anuncios. No prueba el resultado del reenvío. Una ruta renovada puede no resolver su next hop, no entrar en hardware, conservar una etiqueta inadecuada o terminar en un servicio caído. La evidencia de control y la evidencia de entrega deben permanecer separadas.

No todo estado BGP envejece igual

BGP transporta más que prefijos de Internet. Route Target constraints, FlowSpec, descubrimiento y ciertos estados VPN se parecen a configuración distribuida. Reconstruirlos puede tardar, y retirarlos de inmediato puede crear churn o desactivar servicios aunque el dato subyacente siga siendo válido. LLGR puede ser razonable en ese contexto.

El estándar obliga, sin embargo, a habilitarlo afirmativamente por AFI/SAFI y prohíbe activarlo por defecto. Esa regla impide presentar LLGR como una mejora genérica. La decisión depende de la semántica del dato, del modelo de reenvío y de la duración segura de cada dependencia.

La dependencia puede ser una etiqueta MPLS. Una ruta VPN stale puede seguir apuntando a una etiqueta retirada. Si el PE de salida la reasigna a otro VPN antes de que los ingress abandonen la ruta antigua, el problema deja de ser disponibilidad y pasa a ser aislamiento. RFC 9494 exige que la demora mínima de reutilización sea mayor que el LLST máximo.

Las guías de Cisco, Juniper y Nokia muestran además que la prueba ha de incluir producto y versión. Cisco documenta tiempos enviados y aceptados y el ciclo de BGP persistence. Juniper separa receiver, restarter, familias, políticas y borrado manual. Nokia expone capacidades y temporizadores propios de SR OS. Ninguna lista de familias o valor predeterminado debe trasladarse a otra plataforma.

Cómo demostrar un periodo obsoleto

La primera capa es negociación. Se conservan los OPEN o una salida autorizada del vecino con GR, LLGR, AFI/SAFI, Restart Time, LLST y bits N y F. Junto al tiempo anunciado debe aparecer el máximo aceptado localmente. Son cifras con autores y consecuencias distintas.

La segunda capa es entrada. Se registra causa y subcódigo del reset, fin de GR e inicio de LLGR. Para cada ruta se observa la adición de LLGR_STALE, la exclusión NO_LLGR, el resultado de selección y cualquier anuncio a otro speaker. La presencia de una comunidad sin el efecto de política no cierra la prueba.

La tercera capa es forwarding. Incluye resolución recursiva, entrada FIB, etiqueta o encapsulado cuando proceda y sondas de paquetes o de servicio durante el tiempo stale. Una ruta visible en Loc-RIB no demuestra una salida instalada, y una salida instalada no demuestra que el destino responda.

La cuarta capa es terminación. EoR, expiración o clear manual deben producir la retirada de lo no refrescado. El operador verifica la nueva publicidad cuando el servicio regresa y la retirada completa cuando no regresa. El dueño del límite y del rollback ha de estar identificado antes de que comience el incidente.

Fuentes