Resumen

  • Una sesión LDP puede fallar sin que falle el canal de datos. También puede volver mientras el reenvío continúa roto. Capacidad, estado conservado y entrega son pruebas distintas.
  • La continuidad exige que ambos extremos preserven el estado de reenvío, que las asociaciones etiqueta/FEC se reconcilien antes de caducar y que ninguna asignación concurrente dé un segundo significado a una etiqueta retenida.

Dos cronómetros en el mismo incidente

El primer cronómetro se detiene cuando desaparece la conexión TCP que sostiene una sesión LDP. El segundo sólo se detiene cuando los paquetes dejan de cruzar el plano de datos. RFC 3612 dice expresamente que el primer hecho no implica el segundo, incluso con un canal de control dentro de banda. La señalización fuera de banda hace todavía más visible la separación.

Esta distinción cambia la respuesta operativa. Si los dos routers siguen activos y sólo se pierde la sesión, puede quedar intacta la maquinaria de reenvío. Si reinicia el nodo o su componente LDP, la inicialización de control comienza de nuevo, aunque el hardware quizá conserve entradas. Y si se avería el recurso físico, puede perderse el plano de datos aunque exista memoria de control. Un único evento “LDP down” no identifica cuál de esas realidades ocurrió.

RFC 3612 se publicó en septiembre de 2003 como documento informativo de la corriente IETF. Compara el reinicio elegante de RFC 3478 y la tolerancia a fallos de RFC 3479; no es por sí mismo una norma de Internet ni una declaración sobre una red desplegada. RFC 3036 era la especificación LDP a la que remitía aquel trabajo y fue sustituida después por RFC 5036.

El diseño base ligaba la caída de TCP al desmontaje de LSP y a la liberación de etiquetas. Las extensiones permiten conservar estado durante un intervalo y volver a sincronizarlo. La mejora evita empezar desde cero, pero crea un periodo en el que una asociación sigue actuando después de fallar la sesión que le dio autoridad.

La capacidad no es el contenido conservado

Los pares anuncian que entienden una extensión. Esa negociación no demuestra que, en un fallo concreto, el equipo haya logrado preservar su estado MPLS. RFC 3478 utiliza el FT Reconnect Timeout para pedir al vecino que mantenga entradas existentes mientras vuelve el control. El Recovery Time describe cuánto tiempo conserva el router reiniciado lo que sobrevivió. Cero significa que el estado no fue preservado o dejó de estar disponible.

Las entradas supervivientes quedan marcadas como obsoletas. Una nueva asociación puede refrescarlas; las que no reciben confirmación se eliminan cuando vence el temporizador. El plazo es una licencia temporal, no un certificado. Cuanto más largo sea, mayor es la posibilidad de completar una base grande, pero también mayor el tiempo durante el cual una asociación errónea puede seguir enviando paquetes.

RFC 3612 fija una condición decisiva: para que el tráfico no resulte afectado, ambos extremos de la sesión deben conservar al menos el estado de reenvío. Si sólo uno lo hace, RFC 3478 puede acelerar la recuperación posterior, pero no conserva el tráfico durante la ruptura. “Soporta graceful restart” y “preservó el servicio” son afirmaciones de capas diferentes.

La carga de recuperación tampoco es constante. Depende del número de LSP, la velocidad del canal, la capacidad del proceso y el ritmo de cambios. Una sesión dirigida y estable acumula una deuda distinta de una sesión de descubrimiento que reacciona a cambios IGP. Configurar el mismo plazo no iguala esas deudas.

El acuse guarda un mensaje, no su efecto

RFC 3479 añade números de secuencia, protección por etiqueta, acuses, checkpoints y reemisión de operaciones perdidas. En un cierre planificado puede asegurar el historial anterior y suspender cambios nuevos. Esta modalidad exige participación de ambos pares y una forma de auditar el estado de control reconstruido frente al de reenvío.

Un detalle impide leer demasiado en los acuses: el receptor puede confirmar una operación cuando la ha registrado de forma segura, antes de procesarla por completo. Una solicitud durable aún no es un mapeo producido; un mapeo recibido aún no es una entrada instalada; una entrada instalada aún no es un paquete entregado. Cada transición necesita su propio verbo y su propia evidencia.

Acusar con frecuencia reduce la cola reciente que podría perderse, a costa de trabajo adicional. Hacer checkpoints espaciados simplifica la implementación, pero amplía la ventana que deberá reconstruirse. El checkpoint delimita intención de control asegurada; no fotografía simultáneamente todos los componentes del router.

RFC 5919 incorporó más tarde End-of-LIB para indicar el final de la fase inicial de anuncios. La notificación no está garantizada y un temporizador local puede sustituirla. Incluso cuando llega, sólo cierra esa fase: no prueba instalación remota, coherencia global ni tránsito de paquetes.

El estado equivocado también sobrevive

RFC 3612 no trata la conservación como virtud automática. Advierte que puede retener estado incorrecto y que, en un caso extremo, ese estado puede haber provocado el fallo. Persistencia y corrección son propiedades independientes.

La reproducción completa de asociaciones puede depurar lo que ya no recibe confirmación, pero puede recrear el mismo error mediante la misma lógica. La reconstrucción desde otro camino puede evitar una clase de fallo y conservar otra. Por eso la auditoría debe comparar la tabla anterior, las respuestas de pares, la tabla resultante y el comportamiento de datos.

Durante ese intervalo aparece un riesgo concreto. El router ascendente puede seguir enviando una FEC con una etiqueta antigua mientras el descendente asigna ese número a otra FEC. Una asociación retenida y una nueva publicación pueden ser localmente plausibles y globalmente incompatibles. Retrasar asignaciones o aislar espacios reduce el solapamiento; el nombre del mecanismo no lo elimina.

También pueden competir una configuración estática, otra instancia LDP u otro protocolo de distribución. Si comparten el espacio, necesitan una autoridad común o particiones verificables. Reutilizar una etiqueta antes de expirar la autoridad anterior puede causar entrega a un destino distinto. RFC 3479 llega a señalar servicio no autorizado o denegación como consecuencias concebibles. Son límites de seguridad del diseño, no noticias de un incidente observado.

Un recibo con ambas líneas de tiempo

El registro defendible identifica par, época, tipo de fallo y planos afectados. Conserva capacidades y temporizadores, enumera cada entrada retenida y registra etiqueta, espacio, FEC, siguiente salto, asignador y estado: obsoleta, refrescada, reemplazada, retirada o caducada.

Después conserva el recorrido de ejecución: mensaje recibido, asegurado, procesado, instalado y observado. Indica el checkpoint, las operaciones reemitidas, la llegada de End-of-LIB o su sustitución por tiempo, y cualquier conflicto con una asignación nueva.

La última columna pertenece al plano de datos. Sondas en ambos sentidos, contadores en los dos extremos y muestras sobre FEC representativas deben seguir separados del estado LDP. Si no existen, el resultado es “no observado”. Convertir una resynchronización correcta en continuidad implícita sólo detiene el cronómetro equivocado.

Fuentes