Resumen

  • RFC 1267 enviaba primero la tabla BGP completa y después solo cambios incrementales, por lo que cada hablante debía conservar la tabla actual de su par mientras durara la conexión.
  • RFC 4271 convirtió el cierre de conexión en un retiro implícito; RFC 4724 creó una excepción negociada que retiene rutas por familia, las marca como stale y las elimina por reemplazo, End-of-RIB o vencimiento.
  • RFC 8538 separó los errores aptos para tratamiento graceful del Hard Reset completo, y RFC 9494 exigió más etiquetas, menor preferencia, límites de propagación y activación explícita para una memoria aún más larga.

Una ruta incremental hereda su contexto

RFC 1267 describía una sesión BGP-3 que empezaba con una transferencia completa. Después de abrir la conexión e intercambiar los mensajes iniciales, cada hablante enviaba toda su tabla de enrutamiento BGP. A partir de ahí, los UPDATE comunicaban solamente lo que cambiaba.

La reducción de tráfico tenía un precio lógico. Un incremento aislado no reconstruye la tabla de la que forma parte. Por eso cada hablante debía conservar la versión actual de la tabla de cada par durante la conexión. La memoria compartida era una condición del significado, no una optimización accidental.

También tenía fecha de caducidad. KEEPALIVE comprobaba que la conexión seguía viva. Un error conducía a NOTIFICATION y al cierre, y la máquina de estados liberaba los recursos ligados a esa conversación antes de volver hacia Idle o Active.

La tabla retenida no era una escritura eterna de identidad, propiedad o autorización. Era información de control recibida de un par dentro de una sesión concreta. Que el canal estuviera vivo no garantizaba la corrección de cada anuncio; que una ruta estuviera en memoria no demostraba un estado de reenvío equivalente ni la entrega de paquetes.

El cierre retiraba la evidencia del par

RFC 4271 separó tres registros conceptuales: Adj-RIBs-In para lo aprendido, Loc-RIB para la selección local y Adj-RIBs-Out para lo que se prepara para anunciar. Esa separación evita que recibir, elegir y exportar parezcan un solo acto.

El documento definió tres maneras de retirar una ruta. Puede llegar una retirada explícita, puede aparecer una ruta sustitutiva o puede cerrarse la conexión BGP. El cierre elimina implícitamente del servicio todas las rutas que esa pareja de hablantes se había anunciado.

En la ruta de error, se borra la Adj-RIB-In asociada, se invalidan las entradas locales que dependían del par, se recalcula la mejor ruta y se anuncian retiradas o reemplazos. No se afirma que el vecino físico deje de existir. Se afirma que su evidencia de control ya no conserva vigencia bajo la regla base.

Una entrada de hardware podría durar algo más. Ese residuo responde a otra capa y debe medirse por separado. El protocolo no permite llamarlo nueva evidencia solo porque todavía sea observable.

Stale era una condición, no una aprobación

RFC 4724 permitió que ciertas rutas atravesaran la terminación y el restablecimiento de TCP cuando un plano de control BGP se reiniciaba y el reenvío podía haberse conservado. Pero la excepción no se deducía de la caída: se negociaba mediante Graceful Restart Capability y se acotaba por AFI/SAFI.

La capacidad, el estado de reinicio y la indicación de estado de reenvío no son sinónimos. La primera dice que se entiende el mecanismo. La segunda sitúa al hablante en un reinicio. La tercera declara qué familia cree haber preservado. Ninguna prueba por sí sola el resultado de un paquete.

El receptor puede mantener las rutas de las familias negociadas, pero debe marcarlas stale. La etiqueta no asegura calidad. Conserva la diferencia entre una ruta recién confirmada y otra que se usa provisionalmente aunque la sesión que la originó ya terminó.

La excepción termina de varias formas. Si la sesión no vuelve antes de Restart Time, las rutas stale se borran. También desaparecen de inmediato si la nueva sesión no confirma el estado de reenvío, no incluye la familia o no anuncia la capacidad. Un UPDATE nuevo reemplaza su versión antigua.

End-of-RIB resuelve el resto. Puede ser un UPDATE vacío cuando no hay rutas que anunciar: su función es declarar que la primera transferencia de una familia ya acabó. Tras ese marcador, cualquier ruta que siga stale debe retirarse. El silencio deja de ser ambiguo porque existe un recibo explícito de finalización.

RFC 4724 no presenta esa secuencia como recuperación garantizada. Advierte sobre bucles o agujeros negros transitorios y sobre el menor beneficio cuando IGP y BGP se reinician juntos sin mecanismos compatibles. Retener control y mantener reenvío siguen siendo hechos distintos.

Hard Reset negó el permiso de memoria

RFC 8538 amplió el tratamiento graceful a la recepción de NOTIFICATION y al vencimiento de Hold Time cuando ambos pares habían negociado el bit N. Eso convirtió algunas clases de error en candidatas explícitas a la retención.

También creó un límite legible. Cease/Hard Reset solicita la conducta completa de reinicio de la regla base. El motivo del error y la decisión de desechar la memoria deben quedar como registros distintos. Hard Reset no diagnostica por sí solo la causa, pero evita que una excepción graceful se aplique donde ya no se confía en el estado anterior.

El RFC exige un temporizador configurable para rutas stale, sugiere 180 segundos y prohíbe que la retención infinita sea el valor predeterminado. Sin ese límite, una secuencia de reinicios podría convertir lo provisional en una permanencia nunca revalidada.

LLGR extendió tanto el tiempo como el riesgo

RFC 9494 definió Long-Lived Graceful Restart para conservar rutas más allá del Restart Time ordinario. Los helpers añaden la comunidad transitiva LLGR_STALE; las rutas con NO_LLGR quedan fuera; las retenidas pasan a ser las menos preferidas y normalmente no se propagan a pares sin capacidad LLGR.

Long-Lived Stale Time se negocia por AFI/SAFI y puede reducirse localmente. La función requiere configuración afirmativa para cada familia y no puede estar activa por defecto. La duración adicional queda así registrada como una decisión, no escondida como comportamiento ambiental.

El propio RFC advierte que una ruta stale de larga vida usada para alcanzabilidad convencional puede causar pérdida de conectividad. Una preferencia mínima solo dice qué elegir cuando existe una alternativa mejor. No certifica el siguiente salto, la política actual ni el reenvío. Limitar la propagación reduce la exposición; no la convierte en cero.

Fuentes