Resumen

  • La capability 74 permite que dos peers acuerden que BFD será una condición previa para BGP, pero no negocia los valores locales de hold-down ni todos los temporizadores que gobiernan la espera.
  • Un router puede llegar a Established mientras el otro todavía espera estabilidad BFD; si el holdtime expira antes de que lleguen KEEPALIVEs, el control diseñado para reducir churn lo produce.
  • La aceptación operativa exige una línea temporal por extremo y pruebas deliberadas con temporizadores desiguales, no solo una sesión que subió una vez.

A los 18 segundos, el router oeste declaró BFD estable y dejó que BGP entrara en Established. El router este exigía 30 segundos de estabilidad. Oeste empezó a contar su holdtime mientras este todavía no podía enviar KEEPALIVEs. La ruta apareció, desapareció y volvió a intentarlo. Cada equipo registró una causa local coherente.

No existía un reloj común que explicara la pareja.

La revisión 19 de draft-ietf-idr-bgp-bfd-strict-mode formaliza una solución importante: cuando ambos OPEN anuncian la capability 74, BFD Up se convierte en condición previa de la sesión BGP. La propuesta evita que BGP anuncie rutas mientras el detector rápido de fallos sigue sin estar listo o es inestable. Pero el acuerdo binario sobre la capacidad no convierte automáticamente todos los parámetros temporales en un contrato compartido.

El documento está fechado el 26 de agosto de 2026, sigue activo en IDR y pretende avanzar por Standards Track si recibe aprobación. No es un RFC. Datatracker mantiene preguntas de revisores, y la propia sección de estabilidad reconoce que valores incompatibles pueden cerrar o bloquear sesiones.

La capability negocia una regla, no una duración

El intercambio tiene una lógica limpia. Cada speaker incluye la capability de longitud cero cuando soporta y habilita strict mode. Solo si ambos la anuncian se marca BfdStrictNegotiated. Entonces el FSM BGP espera BFD antes de enviar el KEEPALIVE que permite avanzar.

Ese acuerdo responde quién acepta la regla. No responde cuánto tiempo considera estable cada peer. El hold-down BFD puede exigir que la sesión permanezca Up antes de liberar BGP. El valor es local. La revisión recomienda intervalos similares, una formulación que ya reconoce que no hay negociación de una cifra única.

Además existe BfdHoldTime, con 30 segundos por defecto, y BfdHoldTimer para el caso en que el holdtime BGP negociado vale cero. Si el holdtime BGP es distinto de cero, su propia cuenta limita cuánto puede esperar un lado sin KEEPALIVEs. BFD puede tener dampening adicional después de un fallo. La sesión se rige así por varias duraciones con dueños distintos.

La relación crítica no es cada número aislado, sino su desigualdad. Tiempo de inicio BFD más hold-down remoto debe caber dentro de la paciencia BGP del otro extremo. Si no cabe, un peer puede avanzar antes, comenzar a esperar mensajes y cerrar precisamente porque el vecino sigue cumpliendo su período de estabilidad.

La revisión 19 recomienda registrar un mensaje cuando la sesión se cierra por expiración del hold timer mientras espera el hold-down BFD. Esa pista es útil, pero sigue siendo local. Para reconstruir el mecanismo hacen falta ambos relojes y ambos estados.

El estado pendiente contiene información causal

Los nuevos subestados evitan que “OpenSent” signifique demasiadas cosas. ConnectDelayOpenBfdUpPending y ActiveDelayOpenBfdUpPending conservan cómo llegó la conexión al punto de espera. OpenSentBfdUpPending dice que se intercambió OPEN pero falta BFD local. OpenSentConfirmedBfdUpPending recuerda que llegó un KEEPALIVE remoto aunque la condición local todavía no se cumplió.

Esa última situación muestra por qué no hay simultaneidad. La sesión BFD del remoto puede subir antes que la local. El remoto libera su BGP y envía KEEPALIVE. El local recibe una prueba de progreso del peer, pero no debe fingir que su propio detector está listo. La revisión 18 recibió una observación BGPDIR sobre esta carrera; la revisión 19 introduce manejo explícito para no convertir automáticamente el KEEPALIVE temprano en error FSM.

Un sistema de observabilidad que solo ofrece BGP=down y BFD=up/down pierde el orden. Debe conservar transición, monotonic timestamp, timer que estaba corriendo, valor inicial, evento recibido y acción resultante. Sin orden temporal, dos estados verdaderos producen una explicación falsa.

Las implementaciones llevan su propia historia

El apéndice de running code del draft agrava la pregunta temporal de forma productiva. Junos 23.2R1 aparece compatible con la revisión 17; IOS XR 24.3.1 con la 12; Nokia 23.7R1 con la 07 y sin soporte del BfdHoldTimer en la implementación citada. La lista prueba que existe código. No certifica que todos esos releases interpreten cada transición de la revisión 19 del mismo modo.

Las páginas actuales de Cisco distinguen strict mode unilateral, strict mode negociado y override. Juniper documenta que el holdtime BGP no nulo domina la espera y que, con holdtime cero, se usa un intervalo BFD configurado. También registra el caso de idle indefinido por configuración desigual. Los nombres comerciales no son intercambiables con el modelo de tiempo del borrador.

Por eso una matriz de compatibilidad debe contener más que vendor y versión. Necesita la semántica exacta del comando, revisión de comportamiento, capability enviada y recibida, soporte de cada timer, regla cuando el peer no anuncia capacidad, y momento en que un cambio de configuración empieza a ser efectivo. La revisión 19 ignora cambios de strict mode una vez Established para la sesión en curso; el cambio puede esperar al próximo reinicio.

Probar desigualdad antes de confiar en igualdad

La prueba nominal —dos routers idénticos, mismos valores, BFD sube rápido— demuestra poco. El riesgo vive en el borde del contrato. Una validación seria usa releases heterogéneos y fuerza cuatro diferencias.

Primero, configura hold-down distintos y confirma qué extremo entra antes en Established. Segundo, fija el holdtime BGP por debajo de la espera remota y verifica que la causa del cierre sea visible. Tercero, deshabilita la capability en un peer y observa si el otro vuelve a comportamiento ordinario o mantiene una política unilateral. Cuarto, cambia strict mode después de Established y comprueba cuándo se aplica realmente.

Cada ensayo necesita un rollback ensayado. Si se elimina el gate, la pareja debe volver a un estado BGP conocido sin dejar un peer esperando una semántica antigua. Las rutas retiradas por BFD Down deben recuperar su proceso normal, y el registro debe conservar el antes y el después.

La seguridad añade otro reloj: un atacante o una congestión puede suprimir paquetes BFD durante el tiempo suficiente para bloquear establecimiento o derribar una sesión activa. La autenticación puede proteger ciertos mensajes; no obliga a entregar paquetes. Una alarma debe distinguir expiración por falta de evidencia, evidencia autenticada de Down y decisión administrativa.

La idea de Heng Lu sobre decisión futura localizada funciona solo cuando la compatibilidad es comprobable. Cada operador puede elegir su hold-down. Ninguno puede asumir que su elección ya es compartida. Capability 74 crea el punto de acuerdo; los temporizadores y la ejecución prueban si ese acuerdo puede vivir.

Dos temporizadores locales no forman un reloj distribuido. El modo estricto mejora la secuencia de admisión cuando la pareja conoce sus diferencias. Cuando las oculta, convierte la prudencia de cada router en una oscilación que ninguno eligió por sí solo.

Fuentes