Resumen

  • RFC 3277 propone mantener el bit Overload durante la recuperación de un router IS-IS y menciona como posibles disparadores un tiempo desde el arranque o un número de prefijos BGP en la Loc-RIB.
  • Un umbral de N solo acredita cardinalidad: no identifica las rutas requeridas, no prueba next hops resueltos, instalación en FIB ni entrega, y tampoco evita que nuevas adyacencias reactiven un LSP de la encarnación anterior.

El panel mostraba la condición exacta de la automatización: 800 000 prefijos BGP. El router borró Overload y volvió a ser candidato de tránsito. Faltaba, sin embargo, la ruta por defecto usada por una parte de la infraestructura. Otras entradas habían ocupado el lugar numérico. El umbral no mintió; se le había pedido que respondiera una pregunta que no podía responder.

RFC 3277 no documenta ese incidente imaginario ni prescribe una cifra concreta. Publicado en abril de 2002 como RFC informativo, explica un mecanismo interoperable para evitar blackholes transitorios en IS-IS sin modificar el protocolo. Cuando un router de tránsito vuelve tras un fallo o reinicio, el IGP puede elegirlo otra vez antes de que BGP haya reconstruido la información externa. Mientras tanto, su LSP puede llevar Overload para conservar la accesibilidad local pero excluirlo de los caminos de tránsito.

El RFC deja el disparador al implementador. Cita “N segundos después del arranque” o “N prefijos BGP en la Loc-RIB” como posibilidades. Esa libertad es razonable: la norma no conoce la arquitectura, la tabla esperada ni el coste de cada red. También traslada una decisión de autoridad al operador.

La misma cifra puede describir otro conjunto

Una cardinalidad no es una identidad. La Loc-RIB puede contener hoy la misma cantidad de rutas que antes del reinicio y, aun así, carecer de miembros críticos. Un peer tardío puede no haber entregado una familia. Una política puede rechazar rutas esenciales mientras recibe miles de alternativas. Un reflector puede estar sincronizado para un subconjunto y retrasado para otro.

Incluso la presencia nominal de la ruta no cierra la cadena. El next hop puede permanecer sin resolver. La ruta seleccionada puede no haber pasado a la FIB. El hardware puede haber rechazado una operación o conservar una versión anterior. El paquete puede tomar la entrada instalada y fallar después en una etiqueta, una interfaz o el siguiente salto.

Por tanto, el umbral puede ser una señal útil, no un veredicto. Para darle autoridad limitada, la política debería registrar qué población esperaba, qué rutas o clases son obligatorias, cuánto cambio de miembros tolera, cómo se obtiene el digest o versión de referencia, qué comprobación RIB/FIB acompaña la cuenta y qué observación revoca el permiso.

El tiempo fijo tiene el problema complementario. Mide cuánto esperó el proceso, no lo que terminó. Una red en crecimiento, una CPU bajo carga, una sesión lenta o una política nueva pueden volver insuficiente el mismo intervalo. Un timer no se convierte en evidencia de BGP por el hecho de haber funcionado ayer.

La carrera empieza antes de medir BGP

Hay una condición todavía más temprana en RFC 3277. El antiguo LSP del router puede permanecer en las bases del dominio después de la caída. Cuando el router vuelve y restablece adyacencias, sus vecinos publican nuevos LSP que describen esos enlaces. El propio router quizá no haya emitido todavía un LSP actualizado con Overload.

SPF combina entonces enlaces nuevos con la descripción antigua del nodo. La topología cruza dos encarnaciones. Las adyacencias son reales; el LSP viejo tuvo un origen legítimo; el conjunto no representa un estado actual coherente.

El RFC recomienda que el router actualice e inunde su LSP inmediatamente cada vez que establece una adyacencia, incluso antes de sincronizar la base. La finalidad es hacer visible Overload antes de que el anuncio vecino devuelva autoridad al registro viejo.

Este orden forma parte del control. Un evento “adjacency UP” no prueba que la auto-descripción actual exista. Un LSP no expirado no prueba que corresponda al proceso que acaba de formar la adyacencia. Sin una identidad de boot o generación, el sistema puede tomar dos hechos correctos y producir una decisión incorrecta.

El recibo de recuperación debe conservar la encarnación, secuencia y origen del self-LSP, el orden de las adyacencias, la recepción de la inundación, el conjunto de entradas usado por SPF y la ruta resultante. La marca de tiempo de una lectura no rejuvenece el objeto leído.

Visible como destino, no autorizado como camino

Vaciar por completo el LSP parece una solución sencilla, pero impediría llegar al loopback del router. En redes de operador, las sesiones iBGP suelen usar esas direcciones; esconderlas bloquearía el protocolo cuya recuperación se espera.

Overload permite separar dos funciones. El router puede seguir siendo destino de tráfico hacia sus redes directamente conectadas y, a la vez, no servir de corredor para destinos ajenos. Es una autorización de rol.

El mecanismo tiene parentesco con OSPF Stub Router Advertisement del RFC 3137, ya tratado por otro artículo de BTW. Aquella pieza conserva la tesis de MaxLinkMetric: preferencia alta, accesibilidad propia y el comportamiento cuando solo existe una ruta. Este texto no repite esa frontera. Su objeto es el umbral de reapertura y la carrera IS-IS en que una arista de la encarnación nueva activa el LSP de la anterior.

Borrar Overload no afirma que el router esté “sano” en sentido universal. Solo permite que los demás vuelvan a calcular tránsito a través de él. Toda interpretación adicional necesita su propio recibo.

La vía alternativa también necesita prueba

Con Overload, IS-IS no calcula caminos de tránsito por el router. Si RtrB es el único acceso a nodos posteriores, excluirlo puede dejar el dominio sin vía factible. La técnica que evita un blackhole en una topología redundante puede empeorar la disponibilidad donde no hay redundancia.

Además, una ruta alternativa dibujada no demuestra capacidad suficiente. Puede compartir la misma fuente de energía, carecer de FIB completa, tener una política distinta o encontrarse congestionada. En el ejemplo del RFC, RtrC se supone estable y completo. En producción, esa suposición requiere telemetría y pruebas.

RFC 3277 también advierte que implementaciones que no traten correctamente Overload pueden provocar bucles. Autenticar el LSP prueba el emisor dentro del modelo de seguridad de enrutamiento; no prueba que todos los equipos interpreten e instalen el mismo resultado.

La decisión debe hacer visible el dilema. Conservar Overload protege la integridad del tránsito, pero puede sacrificar accesibilidad si no hay alternativa. Quitar Overload recupera conectividad posible, pero puede enviar tráfico a una tabla incompleta. Ningún valor global resuelve ambas cosas sin contexto.

RFC 8706 añadió una barrera de generación

RFC 5306 normalizó la señalización de reinicio IS-IS en 2008. RFC 8706 lo sustituyó en 2020 y distingue un restart que conserva forwarding de un start que no lo conserva.

Para el router que arranca sin estado, los LSP de la encarnación anterior pueden sobrevivir y parecer más nuevos que las primeras secuencias emitidas después de reinicializar contadores. RFC 8706 introduce el bit SA en el Restart TLV: el router pide a sus vecinos que no anuncien la adyacencia hasta que reciba una IIH con SA despejado. La adyacencia suprimida tampoco puede entrar en el SPF local del vecino.

La estrategia ya no consiste únicamente en hacer que el LSP nuevo con Overload gane la carrera. También puede impedirse que la nueva arista haga utilizable el nodo viejo. Ese cambio confirma que la identidad de encarnación es una propiedad operativa, no una nota de auditoría posterior.

Un reinicio planificado solo puede sostener adyacencias si el plano de forwarding se conserva realmente. RFC 8706 rechaza señalizarlo sin esa condición porque produciría pérdida importante. La etiqueta de control no fabrica la custodia de la FIB.

La existencia del RFC no demuestra soporte o activación en una red determinada. Deben verificarse versiones, configuración, timers, mezclas de capacidad y conducta ante fallos.

Los mecanismos de recuperación no se heredan evidencia

BGP Graceful Restart puede retener rutas durante una interrupción de control. IP Fast Reroute puede reaccionar localmente a un fallo. Ordered FIB convergence puede imponer un orden a las actualizaciones. Juntos pueden mejorar la continuidad, pero siguen dejando preguntas separadas.

Una ruta marcada stale no identifica el self-LSP IS-IS actual. Una reparación rápida no demuestra que BGP esté completo. Un orden correcto no instala una ruta que nunca llegó. Una FIB poblada no garantiza que el paquete alcanzó el servicio.

La cadena defendible conserva: identidad de proceso; forwarding retenido o perdido; adyacencia; nuevo LSP y secuencia; recepción de Overload; sincronización IS-IS; peers y conjunto BGP requerido; resolución; instalación; admisión controlada; observación de paquetes; resultado; rollback.

La doctrina de Heng Lu incluida en las fuentes pide especificaciones comunes estrechas y autoridad ligada al estado ejecutado. Aplicada aquí, permite estandarizar el significado de “no me uses para tránsito” sin convertir el protocolo en juez de la completitud BGP o del servicio.

El liderazgo no debería preguntar solo cuánto tardó el router en ponerse verde. Debe preguntar qué objeto obtuvo el derecho de quitar Overload, qué evidencia le dio ese derecho y qué señal puede retirárselo.

Incertidumbre

Este análisis no atribuye el mecanismo a una avería, proveedor o despliegue actual. RFC 3277 afirma de forma histórica que la técnica se había usado en varias redes IS-IS grandes, sin nombrarlas ni medir resultados. El soporte de RFC 8706, el tamaño esperado, la política BGP, la FIB y la capacidad alternativa deben comprobarse en cada entorno. No se afirma una reducción cuantificada de pérdida.

Fuentes