Início / Notas técnicas / Sessão de eco de um braço do BFD inativa

O eco de um braço do BFD não sobe: a regra do IP de origem que ninguém lê

O eco de um braço do BFD não testa nada além de se o seu próprio pacote sobrevive a uma viagem de ida e volta — e se o IP de origem desse pacote assumir por padrão o mesmo valor do IP de destino, uma lista confirmada de switches Huawei simplesmente o descarta, sem erro, sem log. A regra de encaminhamento por trás disso, os modelos de switch afetados, a solução com endereço Loopback, e um caso em que um recurso totalmente diferente produziu exatamente o mesmo sintoma.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Um pacote UDP, duas formas de errar

O eco de um braço não testa o peer de forma alguma — testa se o seu próprio pacote de eco consegue sobreviver a uma viagem de ida e volta através dele. Esse é o detalhe que quase ninguém lê até uma sessão se recusar a subir.

O eco de um braço do BFD existe para exatamente uma situação: o peer não suporta BFD, ou não o habilitou. Em vez de uma verdadeira troca bidirecional de BFD, o dispositivo local monta um pacote UDP endereçado ao IP da sua própria interface de saída e simplesmente pede ao peer para encaminhá-lo de volta diretamente — um teste de loopback, não uma negociação. Se o IP de origem do pacote não for configurado explicitamente, ele assume por padrão o mesmo valor do IP de destino, o que o torna um pacote de origem e destino idênticos. Uma longa lista de dispositivos de rede, incluindo switches, trata essa forma de pacote como anômala e o descarta de imediato — sem erro, sem log, nada além de uma sessão que permanece silenciosamente inativa.

A seguir está como o pacote é realmente montado, três casos reais de campo — uma interconexão simples que permaneceu inativa desde o primeiro dia, a lista confirmada de modelos onde esse comportamento de encaminhamento aparece, e um caso em que um recurso totalmente diferente (tráfego de relay DHCPv6 disparando um limitador de taxa) produziu uma oscilação do BFD que parecia exatamente uma falha real de link — além das respostas de perguntas frequentes que aparecem sempre que esses chamados são discutidos.

Onde olhar primeiro — dois sintomas muito diferentes

Uma sessão de eco de um braço que nunca sobe e uma que sobe e depois oscila são duas falhas diferentes com duas causas raiz diferentes — não busque a mesma solução para as duas.

Colocar primeiro o sintoma nesta árvore indica se você está diante de uma regra de encaminhamento de pacotes ou de um recurso não relacionado emprestando o sintoma do BFD.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Ambos os ramos produzem o mesmo sintoma final — BFD inativo — mas apenas um deles é realmente um problema de BFD. O ramo direito é um recurso de proteção do plano de controle reagindo a tráfego não relacionado, e nenhuma releitura da configuração do BFD vai corrigi-lo.

Como o pacote é montado, e o que dá errado

Três casos reais de campo — os campos exatos do pacote de eco de um braço, por que ele é descartado, e um caso em que o BFD oscilou por um motivo que não tinha nada a ver com o BFD.

Como o eco de um braço realmente monta seu pacote

Antes de rastrear a falha, vale a pena saber exatamente o que o dispositivo local coloca no pacote — a regra que causa tudo isso está em quatro campos.

IP de origem: o endereço configurado em source-ip na linha de comando bfd bind — se não for definido, assume por padrão o IP da própria interface VLANIF local.
IP de destino: o próprio endereço IP da interface VLANIF do dispositivo local — isso é fixo, não configurável.
MAC de origem: o endereço MAC correspondente ao IP da interface local.
MAC de destino: o endereço MAC correspondente ao IP da interface do 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 para S5720-SI: BFD inativo desde o primeiro dia

NE8000 e um S5720-SI interconectados diretamente; o lado do NE8000 reportava a sessão BFD inativa e nunca se recuperava.

Capture o que realmente chega ao S5720-SI: um pacote de eco de um braço do BFD com IP de origem e IP de destino ambos 10.1.1.14, MAC de origem f4de-afe7-ac69, MAC de destino o próprio MAC da interface VLANIF7 do S5720-SI.
Verifique se há um pacote de retorno em direção ao MAC do NE8000 (f4de-afe7-ac69) — nenhum é enviado. O S5720-SI recebeu o pacote de eco, mas nunca o encaminhou de volta.
Reproduza em laboratório: configure uma sessão de eco de um braço usando o mesmo IP de origem e IP de destino, e confirme que o estado da sessão permanece inativo; depois mude apenas o source-ip para um endereço Loopback (um endereço diferente da interface de saída) e confirme que a sessão sobe imediatamente, com o S5720-SI agora encaminhando o pacote de volta corretamente.
Causa raiz: o lado do NE8000 nunca havia definido um IP de origem explícito para sua sessão de eco de um braço, então o IP de origem assumia por padrão o mesmo valor do IP de destino. O próprio comportamento de encaminhamento do S5720-SI descarta pacotes com essa forma — mesma origem, mesmo destino — então o eco nunca retorna.

[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 — A lista confirmada de modelos, e o alerta sobre URPF

Dois switches conectados diretamente, um executando eco de um braço e o outro apenas encaminhando tráfego de camada 3 normalmente — a sessão nunca se estabeleceu.

Primeiro confirme a conectividade básica: se um ping simples entre os dois dispositivos falhar, resolva isso antes de mexer no BFD.
Reverifique os parâmetros do comando bind do eco de um braço: peer-ip é o endereço IP do dispositivo peer; interface é a interface de saída local em direção ao peer (a VLANIF correspondente, se for assim que o IP é configurado); source-ip deve ser um endereço diferente do próprio IP da interface de saída.
Se source-ip for deixado no padrão (idêntico ao IP da interface de saída), uma lista específica e confirmada de modelos de switch descarta o pacote diretamente: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S (a partir de V200R022C00) — mais o S5720-SI do Caso 1 acima. O mesmo descarte também acontece em qualquer dispositivo com ip anti-attack source-ip equals destination-ip drop habilitado, independentemente do modelo.
Separadamente, se o peer tiver URPF habilitado, ele também precisa de uma rota válida de volta para o endereço configurado como source-ip — caso contrário, o URPF descarta o pacote de eco por um motivo totalmente diferente, e a solução acima não será suficiente por si só.

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 — O tráfego de relay DHCPv6 dispara o HOSTCAR, o BFD oscila como uma falha de link

Um S12700E executando DHCP Relay tinha uma sessão BFD completamente normal com seu peer — até começar a oscilar entre inativo e ativo sem nenhum evento de link por trás.

Primeiro verifique os logs: o evento de queda da sessão BFD é registrado com Diagnostic=DetectDown — o lado local simplesmente parou de receber pacotes BFD a tempo, o que por si só não diz o motivo.
Verifique display arp para o IP do peer do BFD. A entrada ARP existia, mas havia envelhecido, significando que o dispositivo havia perdido brevemente a capacidade de alcançar o peer na camada 2 — vale a pena verificar o que mais estava acontecendo naquela interface no mesmo momento.
Verifique os logs em torno desse timestamp exato em busca de descartes do HOSTCAR (HOSTCAR_DROPPKT). Neste caso, o MAC de origem que gerava a entrada ARP do peer do BFD também era a principal fonte de pacotes descartados DHCPv6 Request, ND e ARP — todos esbarrando em um limite de taxa CAR de nível de usuário de 10pps.
Causa raiz: uma rajada de pacotes DHCPv6 Request daquele peer disparou a limitação de taxa em nível de usuário da interface (HOSTCAR), que começou a descartar pacotes ARP da mesma origem junto com o tráfego DHCPv6 que de fato deveria limitar. A entrada ARP envelheceu, a alcançabilidade de camada 2 até o peer do BFD quebrou brevemente, e o temporizador de detecção do BFD expirou — produzindo uma oscilação de sessão que parece exatamente uma falha real de link.

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 coisas que vale a pena saber antes de mexer em uma sessão de eco de um braço

Depois que a árvore acima indicar se é uma regra de encaminhamento ou um recurso não relacionado, esses cinco pontos explicam a maior parte do que realmente está errado.

1. Pacotes de eco com origem e destino idênticos são descartados silenciosamente

SINTOMAA sessão de eco de um braço simplesmente nunca chega a ficar ativa. Nenhum erro é registrado em nenhum dos lados — o pacote simplesmente não retorna.

CAUSASe source-ip não for configurado explicitamente no comando bfd bind, ele assume por padrão o mesmo endereço do IP de destino (o próprio IP da interface de saída local). Muitos dispositivos, ao receber um pacote cujo IP de origem e destino são idênticos, o tratam como anômalo e o descartam — a mesma lógica de encaminhamento que protege contra certos padrões de spoofing também pega esse pacote de eco totalmente legítimo.

SOLUÇÃOSempre configure source-ip explicitamente para um endereço diferente do próprio IP da interface de saída — nunca deixe no padrão.

2. A lista confirmada de modelos onde esse comportamento de encaminhamento aparece

SINTOMAA mesma configuração exata de eco de um braço funciona em um modelo de switch e permanece inativa em outro.

CAUSAA partir da V200R022C00, uma lista específica de modelos descarta diretamente pacotes com IP de origem e destino idênticos: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S — e o S5720-SI confirmado separadamente no Caso 1. Separadamente, em qualquer modelo, habilitar ip anti-attack source-ip equals destination-ip drop produz exatamente o mesmo descarte, independentemente do switch.

SOLUÇÃOTrate isso como um fato do plano de encaminhamento a verificar em qualquer modelo que esteja na outra ponta de uma sessão de eco de um braço, não como um caso extremo — e verifique se o comando anti-attack está habilitado mesmo em modelos que não estão na lista acima.

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

3. Use um endereço Loopback como source-ip, não o próprio endereço da interface de saída

SINTOMAA sessão está inativa; source-ip está tecnicamente configurado, mas por acaso coincide com o próprio IP da interface de saída mesmo assim.

CAUSAConfigurar source-ip com o mesmo valor da interface à qual está vinculado tem o efeito idêntico de deixá-lo sem definir — ainda produz um pacote de origem e destino idênticos. A solução não é «configurar source-ip», é «configurar source-ip para algo genuinamente diferente».

SOLUÇÃOUse o endereço de uma interface Loopback como source-ip sempre que houver uma disponível — é estável, inequívoco, e garantidamente não colide com o próprio endereço da interface de saída.

4. O URPF no peer pode desfazer silenciosamente sua correção

SINTOMAsource-ip está corretamente configurado para um endereço diferente, o problema de origem e destino idênticos desapareceu, mas a sessão ainda está inativa.

CAUSASe o dispositivo peer tiver URPF habilitado, ele verifica se tem uma rota válida de volta ao IP de origem do pacote antes de aceitá-lo. Um endereço Loopback usado como source-ip ao qual o peer não tem rota é descartado pelo URPF — um modo de falha completamente diferente que parece idêntico de fora.

SOLUÇÃOCertifique-se de que o peer tenha uma rota válida e alcançável para o endereço configurado como source-ip antes de assumir que a solução Loopback sozinha vai funcionar.

5. Uma inundação de DHCPv6/ARP dispara o HOSTCAR, que então parece exatamente uma falha de link do BFD

SINTOMAO BFD oscila entre inativo e ativo com Diagnostic=DetectDown, mas não há nenhum evento real de link físico, oscilação de interface, ou mudança de configuração perto do timestamp.

CAUSAUma rajada de um protocolo específico de um único MAC de origem — DHCPv6 Request neste caso — pode disparar o limite de taxa CAR em nível de usuário da interface (HOSTCAR), que então também descarta outros pacotes de protocolo dessa mesma MAC, incluindo ARP. O envelhecimento de ARP resultante quebra a alcançabilidade de camada 2 até o peer do BFD por tempo suficiente para que o próprio temporizador de detecção do BFD expire.

SOLUÇÃOQuando o BFD oscila sem um evento real de link, verifique entradas de log HOSTCAR_DROPPKT em torno do mesmo timestamp antes de assumir que é um problema de BFD ou de camada física — desabilitar a limitação de taxa desnecessária em nível de usuário em interfaces voltadas para a rede é a solução padrão assim que esse padrão for confirmado.

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

O que realmente diferencia o eco de um braço do BFD bidirecional normal?

O BFD normal é um protocolo bidirecional real — ambos os lados executam BFD, trocam pacotes de controle, e rastreiam o estado da sessão de forma independente. O eco de um braço não é uma negociação de forma alguma: apenas o dispositivo local executa BFD; ele envia um pacote UDP endereçado ao IP da sua própria interface e simplesmente espera que o peer o encaminhe de volta diretamente, sem modificação. Ele existe especificamente para peers que não suportam BFD, ou não o habilitaram.

O source-ip aparece como opcional na sintaxe do comando — eu realmente preciso configurá-lo?

Sim, sempre. Ele só é opcional no sentido de que o comando aceita omiti-lo — na prática, omiti-lo significa que o IP de origem assume por padrão o IP de destino, que é exatamente a forma de origem e destino idênticos que é descartada em uma lista confirmada de modelos de switch. Sempre configure source-ip explicitamente para um endereço diferente, idealmente um Loopback.

Meu peer realmente suporta BFD — ainda devo usar eco de um braço?

Não. O eco de um braço é uma solução alternativa para peers que não conseguem executar BFD real. Se ambos os lados suportarem, configure em vez disso uma sessão BFD bidirecional padrão (modo assíncrono, com ou sem função de eco) — ela oferece uma detecção bidirecional genuína em vez de um teste de loopback unilateral.

Uma sessão voltou a ficar ativa sozinha, mas oscilou sem nenhum evento real de link — qual é a lista de verificação?

Primeiro verifique display arp para a entrada do peer — se ela envelheceu bem antes do evento de queda, algo quebrou brevemente a alcançabilidade de camada 2. Depois verifique os logs em torno desse timestamp exato em busca de HOSTCAR_DROPPKT ou eventos similares de descarte por proteção de CPU; uma rajada de algum outro protocolo do mesmo MAC de origem disparando um limitador de taxa é uma causa comum que não tem nada a ver com o BFD ou com o próprio link físico.

Por que levou cerca de 10 segundos para o BFD voltar a ficar ativo após uma breve queda?

Isso é esperado, não uma falha. Quando uma sessão BFD cai, se a extremidade remota envia um pacote BFD reportando estado ativo antes de ter recebido a notificação de queda do lado local, o lado local ignora deliberadamente esse relatório ativo desatualizado e permanece inativo em vez de se restabelecer imediatamente com base nele — isso evita oscilação de estado. O atraso extra é essa margem de segurança, não um mau funcionamento.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia em implantações de BFD de eco de um braço em switches Huawei série S e roteadores série NE, usando os comandos display bfd session / display arp mostrados acima. A lista confirmada de modelos e o comportamento de descarte refletem testes da era V200R022C00 — sempre verifique o tratamento de origem e destino idênticos diretamente na sua própria versão de firmware e modelo, já que a lista de compatibilidade da Huawei pode mudar entre versões. Não cobre BFD para cenários underlay de VXLAN/EVPN, nem BFD multi-hop em profundidade.

Sessão de eco de um braço travada inativa, ou oscilando sem razão óbvia?

Conte-nos o modelo do switch e seu comando bfd bind, junto com a saída de display bfd session / display arp, e ajudamos você a interpretá-la.

WhatsApp com um engenheiro →