Inicio / Notas técnicas / Sesión de eco de un solo brazo BFD caída

El eco de un solo brazo BFD no se establece: la regla de la IP de origen que nadie lee

El eco de un solo brazo BFD no prueba nada más que si su propio paquete sobrevive a un viaje de ida y vuelta — y si la IP de origen de ese paquete toma por defecto el mismo valor que su IP de destino, una lista confirmada de switches Huawei simplemente lo descarta, sin error, sin registro. La regla de reenvío detrás de esto, los modelos de switch afectados, la solución con dirección Loopback, y un caso donde una función totalmente distinta produjo exactamente el mismo síntoma.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Un paquete UDP, dos formas de equivocarse

El eco de un solo brazo no prueba al peer en absoluto — prueba si su propio paquete de eco puede sobrevivir a un viaje de ida y vuelta a través de él. Ese es el detalle que casi nadie lee hasta que una sesión se niega a establecerse.

El eco de un solo brazo BFD existe para exactamente una situación: el peer no admite BFD, o no lo ha habilitado. En lugar de un verdadero intercambio bidireccional de BFD, el dispositivo local construye un paquete UDP dirigido a la IP de su propia interfaz saliente y simplemente le pide al peer que lo reenvíe directamente — una prueba de bucle, no una negociación. Si la IP de origen del paquete no se configura explícitamente, toma por defecto ese mismo valor de IP de destino, lo que lo convierte en un paquete de origen y destino idénticos. Una larga lista de dispositivos de red, incluidos switches, tratan esa forma de paquete como anómala y lo descartan sin más — sin error, sin registro, nada más que una sesión que permanece silenciosamente caída.

A continuación se explica cómo se construye realmente el paquete, tres casos reales de campo — una interconexión sencilla que permaneció caída desde el primer día, la lista confirmada de modelos donde aparece este comportamiento de reenvío, y un caso donde una función completamente distinta (tráfico de relay DHCPv6 disparando un limitador de tasa) produjo un aleteo de BFD que se veía exactamente como una falla real de enlace — además de las respuestas de preguntas frecuentes que surgen cada vez que se discuten estos tickets.

Dónde mirar primero — dos síntomas muy distintos

Una sesión de eco de un solo brazo que nunca se establece y una que se establece y luego oscila son dos fallas distintas con dos causas raíz distintas — no persiga la misma solución para ambas.

Ubicar primero el síntoma en este árbol indica si está ante una regla de reenvío de paquetes o una función no relacionada que toma prestado el síntoma de BFD.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Ambas ramas producen el mismo síntoma final — BFD caído — pero solo una de ellas es realmente un problema de BFD. La rama derecha es una función de protección del plano de control reaccionando a tráfico no relacionado, y por más que relea la configuración de BFD no la arreglará.

Cómo se construye el paquete, y qué falla

Tres casos reales de campo — los campos exactos del paquete de eco de un solo brazo, por qué se descarta, y un caso donde BFD osciló por una razón que no tenía nada que ver con BFD.

Cómo construye realmente su paquete el eco de un solo brazo

Antes de rastrear la falla, vale la pena saber exactamente qué pone el dispositivo local en el paquete — la regla que causa todo esto está en cuatro campos.

IP de origen: la dirección configurada en source-ip en la línea de comando bfd bind — si no se define, toma por defecto la IP de la propia interfaz VLANIF local.
IP de destino: la propia dirección IP de la interfaz VLANIF del dispositivo local — esto es fijo, no configurable.
MAC de origen: la dirección MAC correspondiente a la IP de la interfaz local.
MAC de destino: la dirección MAC correspondiente a la IP de la interfaz del peer.

#
interface Vlanif1
 ip address 192.168.1.14 255.255.255.0
#
bfd atob bind peer-ip 192.168.1.2 interface Vlanif1 source-ip 192.168.1.14 one-arm-echo
 discriminator local 1
 min-echo-rx-interval 100
 commit
#
// source-ip 192.168.1.14 is identical to the local VLANIF address -> same-source-same-destination
// the peer receives this shape of packet and drops it -> session never comes Up

Caso 1 — NE8000 a S5720-SI: BFD caído desde el primer día

NE8000 y un S5720-SI interconectados directamente; el lado del NE8000 reportaba la sesión BFD caída y nunca se recuperaba.

Capture lo que realmente llega al S5720-SI: un paquete de eco de un solo brazo BFD con IP de origen e IP de destino ambas 10.1.1.14, MAC de origen f4de-afe7-ac69, MAC de destino la propia MAC de la interfaz VLANIF7 del S5720-SI.
Verifique si hay un paquete de retorno hacia la MAC del NE8000 (f4de-afe7-ac69) — nunca se envía ninguno. El S5720-SI recibió el paquete de eco pero nunca lo reenvió de vuelta.
Reprodúzcalo en un laboratorio: configure una sesión de eco de un solo brazo usando la misma IP de origen e IP de destino, y confirme que el estado de la sesión permanece caído; luego cambie solo el source-ip a una dirección Loopback (una dirección distinta de la interfaz saliente) y confirme que la sesión se establece de inmediato, con el S5720-SI ahora reenviando el paquete correctamente.
Causa raíz: el lado del NE8000 nunca había definido una IP de origen explícita para su sesión de eco de un solo brazo, por lo que la IP de origen tomaba por defecto el mismo valor que la IP de destino. El propio comportamiento de reenvío del S5720-SI descarta paquetes con esa forma — mismo origen, mismo destino — por lo que el eco nunca regresa.

[HUAWEI-bfd-session-ato] display this
#
bfd ato bind peer-ip 10.1.1.1 interface Vlanif100 source-ip 10.1.1.2 one-arm-echo
 discriminator local 1
 min-echo-rx-interval 100
 commit
#
[HUAWEI-bfd-session-ato] display bfd session all
--------------------------------------------------------------------------------
Local  Remote   PeerIpAddr    State   Type       InterfaceName
--------------------------------------------------------------------------------
1      -        10.1.1.1      Down    S_IP_IF    Vlanif100
--------------------------------------------------------------------------------
    Total UP/DOWN Session Number : 0/1

// change source-ip to a Loopback address instead of an interface-facing address:
[HUAWEI-bfd-session-ato_1] display this
#
bfd ato_1 bind peer-ip 10.1.1.1 interface Vlanif100 source-ip 1.1.1.1 one-arm-echo
 discriminator local 2
 min-echo-rx-interval 100
 commit
#
[HUAWEI] display bfd session all
--------------------------------------------------------------------------------
Local  Remote   PeerIpAddr    State   Type       InterfaceName
--------------------------------------------------------------------------------
2      -        10.1.1.1      Up      S_IP_IF    Vlanif100
--------------------------------------------------------------------------------
    Total UP/DOWN Session Number : 1/0

Caso 2 — La lista confirmada de modelos, y la advertencia sobre URPF

Dos switches conectados directamente, uno ejecutando eco de un solo brazo y el otro simplemente reenviando tráfico de capa 3 con normalidad — la sesión nunca se estableció en absoluto.

Primero confirme la conectividad básica: si un simple ping entre los dos dispositivos falla, solucione eso antes de tocar BFD.
Vuelva a verificar los parámetros del comando bind del eco de un solo brazo: peer-ip es la dirección IP del dispositivo peer; interface es la interfaz saliente local hacia el peer (la VLANIF correspondiente, si así se configura la IP); source-ip debe ser una dirección distinta de la propia IP de la interfaz saliente.
Si source-ip se deja en su valor predeterminado (idéntico a la IP de la interfaz saliente), una lista específica y confirmada de modelos de switch descarta el paquete directamente: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S (a partir de V200R022C00) — más el S5720-SI del Caso 1 anterior. El mismo descarte también ocurre en cualquier dispositivo con ip anti-attack source-ip equals destination-ip drop habilitado, sin importar el modelo.
Por separado, si el peer tiene URPF habilitado, también necesita una ruta válida de vuelta a la dirección configurada como source-ip — de lo contrario, URPF descarta el paquete de eco por una razón totalmente distinta, y la solución anterior no bastará por sí sola.

bfd session-name bind peer-ip peer-ip [ vpn-instance vpn-instance-name ]
 interface interface-type interface-number [ source-ip ip-address ] one-arm-echo

// source-ip is technically optional, but leaving it unset means it defaults to the
// outbound interface's own IP -> a same-source-same-destination packet -> dropped
// on the confirmed model list above, and on any device with the anti-attack rule enabled

Caso 3 — El tráfico de relay DHCPv6 dispara HOSTCAR, BFD oscila como una falla real de enlace

Un S12700E ejecutando DHCP Relay tenía una sesión BFD completamente normal con su peer — hasta que comenzó a oscilar entre caído y activo sin ningún evento de enlace detrás.

Primero revise los registros: el evento de caída de la sesión BFD se registra con Diagnostic=DetectDown — el lado local simplemente dejó de recibir paquetes BFD a tiempo, lo cual por sí solo no dice por qué.
Verifique display arp para la IP del peer BFD. La entrada ARP existía pero había envejecido, lo que significa que el dispositivo había perdido brevemente la capacidad de alcanzar al peer en la capa 2 — vale la pena verificar qué más ocurría en esa interfaz en ese mismo momento.
Verifique los registros alrededor de esa marca de tiempo exacta en busca de descartes de HOSTCAR (HOSTCAR_DROPPKT). En este caso, la MAC de origen que generaba la entrada ARP del peer BFD también era la principal fuente de paquetes descartados DHCPv6 Request, ND y ARP — todos chocando contra un límite de tasa CAR a nivel de usuario de 10pps.
Causa raíz: una ráfaga de paquetes DHCPv6 Request de ese peer disparó la limitación de tasa a nivel de usuario de la interfaz (HOSTCAR), que comenzó a descartar paquetes ARP de la misma fuente junto con el tráfico DHCPv6 que en realidad debía limitar. La entrada ARP envejeció, la alcanzabilidad de capa 2 hacia el peer BFD se rompió brevemente, y el temporizador de detección de BFD expiró — produciendo un aleteo de sesión que se ve exactamente como una falla real de enlace.

Dec 25 2023 15:03:18 S12700-1 %%01BFD/4/STACHG_TODWN(l)[615983]:BFD session changed to
Down. (Discriminator=8235, Diagnostic=DetectDown, Applications=OSPF, BindInterfaceName=Eth-Trunk99)
Dec 25 2023 15:03:19 S12700-1 %%01BFD/4/STACHG_TOUP(l)[615986]:BFD session changed to Up.

<HUAWEI> display arp
IP ADDRESS      MAC ADDRESS      EXPIRE(M)  TYPE   INTERFACE
------------------------------------------------------------------------------
10.82.192.2     00e0-fc6a-1111   10         D-0/0  Eth-Trunk99
// ARP entry aged -> brief loss of L2 reachability to the BFD peer

Dec 25 2023 15:11:40 S12700-1 %%01DEFD/6/HOSTCAR_DROPPKT(l)[616002]:Rate of packets to
cpu exceeded the HOSTCAR limit. (CarID=5266, PacketInfo=The growth rate of top 3 packets
is: MAC1=00e0-fc6a-1111, Protocol1=dhcpv6-request, MAC2=00e0-fc6a-1111, Protocol2=nd,
MAC3=00e0-fc6a-1111, Protocol3=arp)
// DHCPv6 Request flood from the same MAC tripped the 10pps user-level CAR limit,
// which then dropped ARP packets from that MAC too -> BFD detect timeout -> flap

5 cosas que vale la pena saber antes de tocar una sesión de eco de un solo brazo

Una vez que el árbol anterior le ha indicado si es una regla de reenvío o una función no relacionada, estos cinco puntos explican la mayor parte de lo que realmente falla.

1. Los paquetes de eco con origen y destino idénticos se descartan silenciosamente

SÍNTOMALa sesión de eco de un solo brazo simplemente nunca llega a estar activa. No se registra ningún error en ninguno de los dos lados — el paquete simplemente no regresa.

CAUSASi source-ip no se configura explícitamente en el comando bfd bind, toma por defecto la misma dirección que la IP de destino (la propia IP de la interfaz saliente local). Muchos dispositivos, al recibir un paquete cuya IP de origen y destino son idénticas, lo tratan como anómalo y lo descartan — la misma lógica de reenvío que protege contra ciertos patrones de suplantación también atrapa a este paquete de eco completamente legítimo.

SOLUCIÓNConfigure siempre source-ip explícitamente a una dirección distinta de la propia IP de la interfaz saliente — nunca lo deje en su valor predeterminado.

2. La lista confirmada de modelos donde este comportamiento de reenvío se manifiesta

SÍNTOMALa misma configuración exacta de eco de un solo brazo funciona en un modelo de switch y permanece caída en otro.

CAUSAA partir de V200R022C00, una lista específica de modelos descarta directamente los paquetes con IP de origen y destino idénticas: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S — y el S5720-SI confirmado por separado en el Caso 1. Por separado, en cualquier modelo, habilitar ip anti-attack source-ip equals destination-ip drop produce exactamente el mismo descarte sin importar el switch.

SOLUCIÓNTrate esto como un hecho del plano de reenvío que debe verificar en cualquier modelo que esté en el otro extremo de una sesión de eco de un solo brazo, no como un caso límite — y verifique si el comando anti-attack está habilitado incluso en modelos que no están en la lista anterior.

undo ip anti-attack source-ip equals destination-ip drop
// stops the device from dropping same-source-same-destination packets outright

3. Use una dirección Loopback como source-ip, no la propia dirección de la interfaz saliente

SÍNTOMALa sesión está caída; source-ip está técnicamente configurado, pero resulta que coincide con la propia IP de la interfaz saliente de todas formas.

CAUSAConfigurar source-ip con el mismo valor que la interfaz a la que está vinculado tiene el efecto idéntico que dejarlo sin definir — sigue produciendo un paquete de origen y destino idénticos. La solución no es «configurar source-ip», es «configurar source-ip a algo genuinamente distinto».

SOLUCIÓNUse la dirección de una interfaz Loopback como source-ip siempre que esté disponible — es estable, no ambigua, y garantiza que no colisionará con la propia dirección de la interfaz saliente.

4. El URPF en el peer puede anular silenciosamente su solución

SÍNTOMAsource-ip está correctamente configurado con una dirección distinta, el problema de origen y destino idénticos ha desaparecido, pero la sesión sigue caída.

CAUSASi el dispositivo peer tiene URPF habilitado, verifica si tiene una ruta válida de vuelta a la IP de origen del paquete antes de aceptarlo. Una dirección Loopback usada como source-ip a la que el peer no tiene ruta es descartada por URPF — un modo de falla completamente distinto que se ve idéntico desde afuera.

SOLUCIÓNAsegúrese de que el peer tenga una ruta válida y alcanzable hacia la dirección configurada como source-ip antes de asumir que la solución Loopback por sí sola funcionará.

5. Una inundación de DHCPv6/ARP dispara HOSTCAR, que luego se ve exactamente como una falla de enlace BFD

SÍNTOMABFD oscila entre caído y activo con Diagnostic=DetectDown, pero no hay ningún evento real de enlace físico, oscilación de interfaz, ni cambio de configuración cerca de esa marca de tiempo.

CAUSAUna ráfaga de un protocolo particular desde una MAC de origen — DHCPv6 Request en este caso — puede disparar el límite de tasa CAR a nivel de usuario de la interfaz (HOSTCAR), que entonces también descarta otros paquetes de protocolo de esa misma MAC, incluido ARP. El consiguiente envejecimiento de ARP rompe la alcanzabilidad de capa 2 hacia el peer BFD el tiempo justo para que expire el propio temporizador de detección de BFD.

SOLUCIÓNCuando BFD oscila sin un evento real de enlace, verifique las entradas de registro HOSTCAR_DROPPKT alrededor de la misma marca de tiempo antes de asumir que es un problema de BFD o de capa física — deshabilitar la limitación de tasa a nivel de usuario innecesaria en interfaces orientadas a la red es la solución estándar una vez confirmado este patrón.

Cinco preguntas que surgen constantemente

Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.

¿Qué diferencia realmente al eco de un solo brazo del BFD bidireccional normal?

El BFD normal es un protocolo bidireccional real — ambos lados ejecutan BFD, intercambian paquetes de control, y rastrean el estado de la sesión de forma independiente. El eco de un solo brazo no es en absoluto una negociación: solo el dispositivo local ejecuta BFD; envía un paquete UDP dirigido a la IP de su propia interfaz y simplemente espera que el peer lo reenvíe directamente, sin modificar. Existe específicamente para peers que no admiten BFD, o no lo han habilitado.

source-ip figura como opcional en la sintaxis del comando — ¿realmente necesito configurarlo?

Sí, siempre. Es opcional solo en el sentido de que el comando aceptará omitirlo — en la práctica, omitirlo significa que la IP de origen toma por defecto la IP de destino, que es exactamente la forma de origen y destino idénticos que se descarta en una lista confirmada de modelos de switch. Configure siempre source-ip explícitamente a una dirección distinta, idealmente una Loopback.

Mi peer en realidad sí admite BFD — ¿debería seguir usando eco de un solo brazo?

No. El eco de un solo brazo es una solución alternativa para peers que no pueden ejecutar BFD real. Si ambos lados lo admiten, configure en su lugar una sesión BFD bidireccional estándar (modo asíncrono, con o sin función de eco) — le da una detección bidireccional genuina en lugar de una prueba de bucle unilateral.

Una sesión volvió a estar activa por sí sola, pero osciló sin ningún evento real de enlace — ¿cuál es la lista de verificación?

Primero verifique display arp para la entrada del peer — si envejeció justo antes del evento de caída, algo rompió brevemente la alcanzabilidad de capa 2. Luego verifique los registros alrededor de esa marca de tiempo exacta en busca de HOSTCAR_DROPPKT o eventos similares de descarte por protección de CPU; una ráfaga de algún otro protocolo desde la misma MAC de origen disparando un limitador de tasa es una causa común que no tiene nada que ver con BFD ni con el enlace físico en sí.

¿Por qué tardó unos 10 segundos en que BFD volviera a estar activo después de una breve caída?

Esto es esperado, no una falla. Cuando una sesión BFD cae, si el extremo remoto envía un paquete BFD que informa estado activo antes de haber recibido la notificación de caída del lado local, el lado local ignora deliberadamente ese informe activo obsoleto y permanece caído en lugar de restablecerse de inmediato con base en él — esto evita la oscilación de estado. El retraso adicional es ese margen de seguridad, no un mal funcionamiento.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en implementaciones de BFD de eco de un solo brazo en switches Huawei serie S y routers serie NE, usando los comandos display bfd session / display arp mostrados arriba. La lista confirmada de modelos y el comportamiento de descarte reflejan pruebas de la era V200R022C00 — verifique siempre el manejo de origen y destino idénticos directamente en su propia versión de firmware y modelo, ya que la lista de compatibilidad de Huawei puede cambiar entre versiones. No cubre BFD para escenarios underlay de VXLAN/EVPN, ni BFD multi-salto en profundidad.

¿Sesión de eco de un solo brazo atascada caída, u oscilando sin razón evidente?

Cuéntenos el modelo del switch y su comando bfd bind, junto con la salida de display bfd session / display arp, y le ayudamos a interpretarla.

WhatsApp con un ingeniero →