Resumen

  • BFD comprueba con rapidez la vida de un trayecto y protocolo de datos definidos; la sesión queda ligada a extremos, encapsulación y parámetros.
  • El estado Up no demuestra que todos los miembros ECMP, familias, rutas, MTU o servicios usen el mismo camino sano.
  • Una afirmación de servicio necesita un recibo unido: identidad y temporizadores BFD, RIB/FIB, cobertura por miembro, pruebas bidireccionales de tamaño real y una transacción de aplicación.

El indicador verde y el flujo perdido

Imagine esta escena: termina una ventana de mantenimiento. Las adyacencias de enrutamiento vuelven y el panel muestra BFD Up hacia el siguiente salto del cliente, así que se cierra el cambio. Poco después, las transferencias grandes siguen bloqueándose. Los pequeños paquetes de control caen en un miembro sano del grupo; parte del tráfico real se distribuye hacia otro miembro con una entrada de reenvío o un tratamiento de MTU incorrectos.

BFD no ha mentido. Se ha ampliado indebidamente el alcance de su observación. El verde pertenece a una sesión concreta y al trayecto recorrido por sus paquetes. “El servicio es alcanzable” abarca selección de ruta, todos los miembros relevantes, ambos sentidos, tamaños de producción y la propia aplicación.

RFC 5880 asigna a BFD una tarea deliberadamente estrecha: detectar fallos en el camino bidireccional entre dos motores de reenvío, incluidos enlaces y, en lo posible, los propios motores. Opera con independencia del medio y del protocolo de enrutamiento. Esa independencia le da rapidez y utilidad compartida, pero obliga a registrar qué cliente y qué camino reciben su señal.

BFD no descubre por sí solo la sesión. Una aplicación decide crearla y proporciona direcciones y parámetros. Hay una sesión separada por camino de comunicaciones y protocolo de datos. Un enlace físico, un circuito virtual, un túnel, un LSP MPLS y un camino multihop pueden tener controles distintos; el significado de Up queda atado a la encapsulación examinada.

Qué registra realmente Up

En modo asíncrono, ambos sistemas envían periódicamente paquetes BFD Control; dejar de recibir suficientes paquetes conduce a Down. En Demand, el intercambio periódico puede detenerse porque otro mecanismo debe verificar la conectividad, y una secuencia Poll permite pedir una comprobación explícita. Echo hace que el extremo remoto devuelva paquetes por su plano de reenvío.

Las pruebas no son equivalentes. Echo puede encontrar fallos de reenvío que no ve el intercambio de control. Demand depende de una comprobación independiente. Una implementación situada en el plano de control puede compartir destino con el proceso de routing; el bit C solo declara si la implementación remota es independiente de ese plano. Guardar únicamente Up elimina el contexto que permite interpretar el resultado.

También importan los temporizadores. El intervalo de transmisión deseado, el intervalo mínimo de recepción y el multiplicador fijan el tiempo de detección en modo asíncrono. Up a una hora concreta significa que la máquina de estados no había declarado un fallo bajo esos parámetros. No garantiza el segundo siguiente ni que el protocolo cliente haya instalado la reacción prevista.

RFC 5881 concreta el alcance para IPv4 e IPv6 de un salto. La sesión queda ligada al sistema remoto, interfaz y protocolo. IPv4 e IPv6 requieren sesiones separadas en un mismo enlace. Varias sesiones solo añaden evidencia de diversidad cuando atraviesan caminos de red realmente distintos.

El documento describe BFD como OAM para comprobar conectividad en servicios de red y excluye su uso ordinario como detector aplicación-a-aplicación a través de Internet. Un paquete BFD recibido por el vecino no equivale a que una consulta, compra o transferencia haya terminado para el usuario.

El cliente decide la consecuencia

RFC 5882 concede a BFD un papel asesor. Los protocolos de routing y otros clientes reciben el estado y aplican mecanismos propios. BFD no transporta información específica de la aplicación. Down puede acelerar la retirada de una ruta, pero el cliente sigue siendo dueño de la adyacencia, la topología y el reenvío.

Incluso el historial puede filtrarse. Una implementación puede ocultar a sus clientes una transición rápida Up/Down/Up mediante histéresis. AdminDown expresa intención administrativa y no necesariamente un fallo del camino. Estado actual, transiciones, notificación y acción del cliente son registros diferentes.

ECMP puede separar el camino de BFD del de los usuarios. Un paquete pequeño puede pasar donde uno de tamaño de servicio falla. La vuelta puede estar rota, una ruta puede existir en RIB sin la FIB deseada y la aplicación puede rechazar tráfico que la red entregó bien. Por eso una sola celda verde no basta para cerrar el incidente.

Fuentes