Resumen

  • RFC 5880 convierte BFD en un medio independiente del protocolo para detectar fallos en una ruta de reenvío bidireccional, potencialmente con latencia muy baja.
  • La señal no es una política de selección de rutas: las aplicaciones crean y consumen sesiones, mientras que los temporizadores agresivos imponen costes de tráfico, procesamiento y falsos positivos.

Una señal estrecha con consecuencias amplias

BFD observa la ruta bidireccional entre dos motores de reenvío. RFC 5880 indica que puede incluir interfaces, enlaces de datos y, cuando sea posible, los propios motores. El protocolo es deliberadamente independiente del medio, del protocolo de datos transportado y del protocolo de enrutamiento que consuma su estado.

Ese alcance estrecho explica su valor. Un protocolo de enrutamiento no tiene por qué esperar a que venza su propio temporizador Hello o de inactividad para saber que la ruta de reenvío falló. Un servicio puede consumir el mismo estado subyacente. Sin embargo, BFD no decide qué prefijo debe moverse, qué siguiente salto debe ganar ni si debe cerrarse una adyacencia. Informa del estado; el cliente conserva la autoridad sobre la política.

RFC 5882 traza la frontera con claridad. Para una aplicación, BFD verifica la conectividad entre dos sistemas para un protocolo de datos y una ruta concretos. No pretende demostrar que el protocolo de control esté sano. Un estado Down puede justificar una reacción de enrutamiento, pero no prueba que todos los procesos de control fallen ni que una alternativa concreta sea segura.

Crear una sesión es una decisión de autorización

BFD no tiene mecanismo de descubrimiento. La aplicación proporciona la dirección remota y los demás parámetros. La cobertura se configura, no se deduce: una ruta que nunca se vinculó a una sesión no queda protegida porque BFD funcione en otra parte del equipo.

RFC 5882 también establece que varios clientes que vigilan la misma ruta del mismo protocolo de datos deberían compartir una sesión BFD. El estado se convierte así en una dependencia común. Un responsable debe decidir qué aplicaciones pueden consumirlo, qué familia de direcciones y ruta representa y cómo un cambio se propaga a distintos sistemas de control.

La operación de un solo salto concreta estas fronteras. RFC 5881 exige sesiones separadas para IPv4 e IPv6 si ambos se vigilan sobre la misma ruta. También exige TTL o Hop Limit 255 en los paquetes Control recibidos, limitando su aceptación a un par directamente conectado. La autenticación puede protegerlos, pero el despliegue y la gestión de claves siguen siendo responsabilidades del operador.

La compatibilidad importa por igual. Si se considera que un vecino no admite BFD, RFC 5882 dice que la adyacencia del protocolo de control no debería bloquearse solo por esa ausencia. BFD añade una señal de fallo; no autoriza a hacer depender la conectividad básica de una función no disponible.

El tiempo de detección se compra con capacidad

En modo Asynchronous, cada sistema envía periódicamente paquetes Control. Si el número negociado no llega dentro del tiempo de detección, la sesión pasa a Down. Demand puede suprimir los paquetes periódicos una vez que la sesión está Up, pero solo si otro mecanismo comprueba la conectividad de forma independiente. La función Echo opcional prueba la ruta enviando paquetes que el sistema remoto devuelve mediante su plano de reenvío.

Los intervalos cortos no crean certeza gratuita. RFC 5881 exige dimensionar BFD para no congestionar el enlace, las colas de entrada ni el procesador. Si el monitor sobrecarga la ruta o el equipo, los paquetes BFD retrasados pueden parecer la evidencia del fallo que el propio monitor ayudó a producir. Un temporizador rápido reduce un agujero negro real, pero también puede convertir congestión transitoria en retirada de rutas o inestabilidad del servicio.

RFC 7419 reduce el riesgo de interoperabilidad con un conjunto común de intervalos. Resuelve la negociación, no la decisión de capacidad. Un valor compatible entre dos equipos no es automáticamente apropiado para cualquier número de sesiones, arquitectura de colas, dominio de fallo o política de recuperación.

Estar Up no equivale a ser estable

La máquina de estados básica mantiene la sesión Up si llegan suficientes paquetes Control dentro de la ventana de detección. Pérdidas aisladas pueden no cambiar el estado. RFC 9978, publicada como especificación Experimental, añade una forma de contar paquetes Control BFD ausentes mediante números de secuencia meticulosos y un modelo YANG. Busca mostrar el deterioro antes de que dure lo suficiente para declarar Down.

La extensión tiene límites estrictos. Mide pérdida de paquetes BFD, no pérdida ni latencia del tráfico de usuario. ECMP y la agregación de enlaces pueden reordenar paquetes, por lo que una comparación simple puede confundir reordenación con pérdida. La señal puede orientar una investigación OAM, pero no identifica por sí sola la causa raíz.

Pruebas y límites

RFC 5880, 5881 y 5882 definen el mecanismo, las restricciones de un salto y la relación con las aplicaciones. RFC 7419 normaliza intervalos comunes. RFC 9978 añade una medición experimental de estabilidad.

Las fuentes no ofrecen un temporizador seguro universal, un censo actual de despliegues ni garantías de proveedores. Tampoco hacen que BFD revele la causa o elija la ruta superviviente.

Fuentes