Resumen

  • El procedimiento antiguo podía dar por alcanzable a un vecino después de oírlo una sola vez. Los estados Down, Initializing y Up de RFC 5303 distinguen silencio, recepción unilateral y conocimiento de recepción mutua.
  • El System ID vecino y el Extended Local Circuit ID amarran la respuesta al sistema y al enlace esperados. Incluso así, Up solo acredita intercambio IIH; no certifica que la LSDB convergió ni que el tráfico o el servicio llegaron.

La redundancia puede esconder el miembro roto

Conviene empezar por el segundo de los tres fallos del RFC. Dos sistemas están unidos por dos enlaces paralelos. Uno de ellos deja de funcionar en un solo sentido. El equipo de un extremo detecta la pérdida; el del otro no. Como el segundo enlace conserva conectividad, SPF todavía calcula caminos entre ambos sistemas. El extremo que ignora el fallo puede seguir enviando tráfico por la dirección muerta.

El resultado agregado parece razonable: la topología no está partida. El resultado del miembro no lo está. Es una lección operativa incómoda porque muchos cuadros de mando premian la continuidad general y silencian la contradicción local que la hace frágil.

El primer fallo descrito por RFC 5303 ocurre después de que un enlace vuelve o un sistema reinicia. Si se pierde el CSNP y ese enlace constituye un corte único, las bases de estado de enlace pueden tardar un período completo de refresco LSP —hasta dieciocho horas— en sincronizarse. El Hello no era falso. Simplemente se encontraba antes del recibo que importaba.

El tercer fallo cambia la identidad física sin bajar la capa de enlace. Determinados medios pueden reconectar extremos de modo que un equipo reciba paquetes destinados a otro sistema o a otro enlace. Si el receptor conserva la asociación previa, convierte una llegada real en una conclusión equivocada sobre quién está al otro lado.

El documento no informa de una avería contemporánea ni atribuye defectos a un fabricante. RFC 5303 es Standards Track, publicado en 2008 como edición menor de RFC 3373 para elevar el mecanismo. Su utilidad actual es metodológica: reemplaza una suposición invisible por un intercambio verificable y deja claro qué afirmaciones siguen pendientes.

Down, Initializing y Up no son estados decorativos

El nuevo TLV de adyacencia punto a punto, opción 240, anuncia la visión de cada extremo. Down quiere decir que no llegó ningún IIH con la opción. Initializing quiere decir que llegó, aunque el sistema local aún no sabe si el vecino recibe sus IIH. Up quiere decir que sí conoce esa recepción remota.

Este estado a tres vías convive con el estado de adyacencia de ISO 10589. No es su alias. Por ejemplo, un ISH puede modificar la adyacencia ISO y, sin embargo, el estado a tres vías permanece Down hasta recibir el IIH apropiado. Mantener dos máquinas de estado puede parecer menos elegante que un único indicador. Es más honesto, porque cada una responde una pregunta distinta.

La tabla de transición conserva también contradicciones útiles. Si el estado local es Up y llega Down, el proceso vuelve a inicializar. Si el local es Down y se recibe Up, puede eliminar la adyacencia con motivo de reinicio remoto. Una automatización madura no debería esconder esas combinaciones detrás de una media de salud; debería conservarlas como evidencia temporal.

Y Up no es el final. Solo significa que el vecino recibe los IIH. No confirma la entrega del CSNP, la igualdad de las LSDB, la instalación en FIB, la simetría de paquetes de datos ni la respuesta de una aplicación. Cada salto posterior requiere otro instrumento.

El retorno tenía que citar el circuito correcto

Saber que alguien responde no basta si la planta física puede haber conectado a otra persona. RFC 5303 añade Neighbor System ID y Neighbor Extended Local Circuit ID. Cuando están presentes, el receptor los compara con su propio sistema y su circuito extendido; una discrepancia descarta el PDU.

Esta decisión corrige una debilidad del espacio anterior. La codificación histórica hacía visible una limitación implícita de 256 interfaces, aunque la restricción real de LAN era más concreta. En punto a punto, las implementaciones reutilizaban IDs de circuito porque servían sobre todo para detectar un cambio al otro extremo. Reutilizar el número reducía esa capacidad: un cable movido hacia una interfaz con el mismo valor pequeño podía aparentar continuidad.

El Extended Local Circuit ID tiene cuatro octetos, se asigna al crear el circuito y debe ser único entre los circuitos del sistema. No necesita relación con el ID legado. Su función política es relevante: permite que la aceptación cite una relación específica en lugar de una etiqueta reciclada.

La vinculación, sin embargo, puede ser parcial. El campo de estado es obligatorio para quien soporta la opción, mientras que los otros campos son SHOULD. Si no aparecen, el procedimiento continúa. Por eso «tres vías Up» y «tres vías Up con sistema y circuito verificados» no deben entrar en el mismo cajón de auditoría.

El modo antiguo sigue siendo una decisión activa

La compatibilidad se diseña de forma explícita. Un sistema que no entiende la opción la ignora y no la envía. Si un equipo moderno recibe un IIH sin ella, supone que el enlace funciona en ambos sentidos y utiliza las reglas anteriores. Es una forma sensata de migrar sin cortar a los vecinos antiguos. También es una autorización consciente para aceptar menos prueba.

La operación necesita mostrar esa diferencia. Registrar solo la capacidad local no sirve. Hay que observar oferta y eco de la opción, estado anunciado, presencia y coincidencia de las dos identidades, y sesiones que cayeron al supuesto legado. Si tras una actualización desaparece la opción, la adyacencia puede seguir viva mientras la calidad de evidencia se degrada.

La autenticación tampoco rellena las demás columnas. RFC 5303 remite a la seguridad de IS-IS; RFC 5304 y RFC 5310 describen autenticación criptográfica. Esa autenticación habla del origen admitido y de la integridad del mensaje, no necesariamente del cable correcto ni de la base convergente. BFD observa otro objeto: detección rápida de transmisión bidireccional. La arquitectura funciona mejor cuando no obliga a un mecanismo a representar a todos los demás.

Qué no demuestra este texto

No demuestra una carencia en un producto desplegado, una incidencia ni una tasa de adopción. Tampoco convierte dieciocho horas en un pronóstico general: ese máximo pertenece a una combinación concreta de reinicio o retorno, CSNP perdido y corte único. La verificación actual requiere configuración, captura de IIH, estado de base y pruebas de plano de datos.

Una extensión habilitada tampoco elimina todo riesgo. Puede operar con vecinos antiguos, omitir campos recomendados, autenticar con políticas de claves deficientes o formar una adyacencia antes de que las capas posteriores terminen. La precisión evita dos exageraciones simétricas: declarar inútil el handshake porque no prueba el servicio, o declarar sano el servicio porque el handshake terminó.

La regla práctica queda así: no convertir recepción en reciprocidad, reciprocidad en identidad, identidad en convergencia, ni convergencia en experiencia del usuario sin un recibo nuevo en cada frontera.

Fuentes