Home / Notes / BFD One-Arm Echo Session Down
NOTES · BFD TROUBLESHOOTING

BFD One-Arm Echo Won't Come Up: The Source-IP Rule Nobody Reads

One-arm echo BFD tests nothing but whether your own packet survives a round trip — and if that packet's source IP defaults to the same value as its destination IP, a confirmed list of Huawei switches simply drops it, no error, no log. The forwarding rule behind it, the switch models it bites on, the Loopback-address fix, and a case where a completely unrelated feature produced the exact same symptom.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

One UDP Packet, Two Ways To Get It Wrong

One-arm echo doesn't test the peer at all — it tests whether your own echo packet can survive a round trip through it. That's the detail almost nobody reads until a session refuses to come Up.

One-arm echo BFD exists for exactly one situation: the peer doesn't support BFD, or hasn't enabled it. Instead of a real two-way BFD exchange, the local device builds a UDP packet addressed to its own outbound interface's IP and simply asks the peer to forward it straight back — a loopback test, not a negotiation. If the packet's source IP isn't explicitly configured, it defaults to that same destination IP, which makes it a same-source-same-destination packet. A long list of network devices, switches included, treat that shape of packet as anomalous and drop it outright — no error, no log, nothing but a session that quietly stays Down.

What follows is how the packet is actually built, three real field cases — a straightforward interconnect that stayed Down from day one, the confirmed model list this forwarding behavior shows up on, and a case where a completely different feature (DHCPv6 relay traffic tripping a rate limiter) produced BFD flapping that looked exactly like a real link failure — plus the FAQ answers that come up whenever these tickets get discussed.

Where To Look First — Two Very Different Symptoms

A one-arm echo session that never comes Up and one that comes Up then flaps are two different faults with two different root causes — don't chase the same fix for both.

Placing the symptom on this tree first tells you whether you're looking at a packet-forwarding rule or an unrelated feature borrowing BFD's symptom.

One-Arm Echo Session Session Never Comes Upsource-ip = destination-ip Session Comes Up, Then Flapsunrelated feature drops ARP Cases 1 & 2 · Same-source-same-destinationpacket is dropped as anomalous by a confirmedlist of switch models (and by ip anti-attacksource-ip equals destination-ip drop if enabled)→ fix: source-ip = a Loopback address Case 3 · DHCPv6 Relay + HOSTCARa DHCPv6 Request flood trips a 10ppsuser-level CAR limit, ARP entries age out,and BFD detect-timeout fires -> looks likea link failure, but isn't one

Diagram labels are kept in English for engineering clarity.

Both branches produce the same end symptom — BFD Down — but only one of them is actually a BFD problem. The right-hand branch is a control-plane protection feature reacting to unrelated traffic, and no amount of re-reading the BFD configuration will fix it.

How The Packet Is Built, And What Goes Wrong

Three real field cases — the exact fields in the one-arm echo packet, why it gets dropped, and a case where BFD flapped for a reason that had nothing to do with BFD.

How One-Arm Echo Actually Builds Its Packet

Before chasing the fault, it's worth knowing exactly what the local device puts in the packet — the rule that causes all of this sits in four fields.

  1. Source IP: the address configured in source-ip on the bfd bind command line — if left unset, it defaults to the local VLANIF interface's own IP.
  2. Destination IP: the local device's own VLANIF interface IP address — this is fixed, not configurable.
  3. Source MAC: the MAC address corresponding to the local interface's IP.
  4. Destination MAC: the MAC address corresponding to the peer interface's IP.
#
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

Case 1 — NE8000 to S5720-SI: BFD Down From Day One

NE8000 and an S5720-SI interconnected directly; the NE8000 side reported the BFD session Down and never recovered.

  1. Capture what actually arrives at the S5720-SI: a BFD one-arm echo packet with source IP and destination IP both 10.1.1.14, source MAC f4de-afe7-ac69, destination MAC the S5720-SI's own VLANIF7 interface MAC.
  2. Check for a return packet toward the NE8000's MAC (f4de-afe7-ac69) — none is ever sent. The S5720-SI received the echo packet but never forwarded it back.
  3. Reproduce it in a lab: configure a one-arm echo session using the same source IP and destination IP, and confirm the session state stays Down; then change only the source-ip to a Loopback address (a different address from the outbound interface) and confirm the session comes Up immediately, with the S5720-SI now forwarding the packet back correctly.
  4. Root cause: the NE8000 side had never set an explicit source IP for its one-arm echo session, so the source IP defaulted to the same value as the destination IP. The S5720-SI's own forwarding behavior drops packets shaped like that — same source, same destination — so the echo never returns.
[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

Case 2 — The Confirmed Model List, And The URPF Caveat

Two switches directly connected, one running one-arm echo and the other simply forwarding Layer 3 traffic normally — the session never established at all.

  1. Confirm basic reachability first: if a plain ping between the two devices fails, fix that before touching BFD at all.
  2. Re-check the one-arm echo bind command's parameters: peer-ip is the peer device's IP address; interface is the local outbound interface toward the peer (the matching VLANIF, if that's how the IP is configured); source-ip should be an address different from the outbound interface's own IP.
  3. If source-ip is left at its default (identical to the outbound interface's IP), a specific, confirmed list of switch models drops the packet outright: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S (as of V200R022C00) — plus the S5720-SI from Case 1 above. The same drop also happens on any device with ip anti-attack source-ip equals destination-ip drop enabled, regardless of model.
  4. Separately, if the peer has URPF enabled, it also needs a valid route back to whatever address is configured as source-ip — otherwise URPF discards the echo packet for an entirely different reason, and the fix above won't be enough on its own.
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

Case 3 — DHCPv6 Relay Traffic Triggers HOSTCAR, BFD Flaps Like a Link Failure

An S12700E running DHCP Relay had a completely normal BFD session with its peer — until it started flapping Down and Up with no link event behind it at all.

  1. Check the logs first: the BFD session Down event is logged with Diagnostic=DetectDown — the local side simply stopped receiving BFD packets in time, which by itself doesn't say why.
  2. Check display arp for the BFD peer's IP. The ARP entry existed but had aged, meaning the device had briefly lost the ability to reach the peer at Layer 2 — worth checking what else was happening on that interface at the same moment.
  3. Check the logs around that exact timestamp for HOSTCAR drops (HOSTCAR_DROPPKT). In this case, the source MAC generating the BFD peer's ARP entry was also the top source of dropped DHCPv6 Request, ND, and ARP packets — all hitting a 10pps user-level CAR rate limit.
  4. Root cause: a burst of DHCPv6 Request packets from that peer triggered the interface's user-level rate limiting (HOSTCAR), which started dropping ARP packets from the same source alongside the DHCPv6 traffic it was actually meant to throttle. The ARP entry aged out, Layer 2 reachability to the BFD peer broke briefly, and BFD's detect timer expired — producing a session flap that looks exactly like a real link failure.
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 Things Worth Knowing Before You Touch a One-Arm Echo Session

Once the tree above has told you whether it's a packet-forwarding rule or an unrelated feature, these five account for most of what's actually wrong.

1. Same-Source, Same-Destination Echo Packets Get Silently Dropped

SYMPTOMThe one-arm echo session simply never reaches Up. No error is logged on either side — the packet just doesn't come back.

CAUSEIf source-ip isn't explicitly configured on the bfd bind command, it defaults to the same address as the destination IP (the local outbound interface's own IP). Many devices, on receiving a packet whose source and destination IP are identical, treat it as anomalous and drop it — the same forwarding logic that protects against certain spoofing patterns catches this completely legitimate echo packet too.

FIXAlways configure source-ip explicitly to an address different from the outbound interface's own IP — never leave it to default.

2. The Confirmed Model List Where This Forwarding Behavior Bites

SYMPTOMThe exact same one-arm echo configuration works on one switch model and stays Down on another.

CAUSEAs of V200R022C00, a specific list of models drops packets with identical source and destination IP outright: S600-E, S1720, S2720-EI, S5720-LI, S5720S-LI, S5720I-SI, S5735S-H, S5736-S, S6720S-S — and the S5720-SI confirmed separately in Case 1. Separately, on any model, enabling ip anti-attack source-ip equals destination-ip drop produces the exact same drop regardless of which switch it is.

FIXTreat this as a forwarding-plane fact to check for on whichever model sits at the far end of a one-arm echo session, not an edge case — and check whether the anti-attack command is enabled even on models not on the list above.

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

3. Use a Loopback Address As Source-IP, Not the Outbound Interface's Own Address

SYMPTOMThe session is Down; source-ip is technically configured, but it happens to match the outbound interface's own IP anyway.

CAUSEConfiguring source-ip to the same value as the interface it's bound to has the identical effect as leaving it unset — it still produces a same-source-same-destination packet. The fix isn't "configure source-ip", it's "configure source-ip to something genuinely different."

FIXUse a Loopback interface's address as source-ip whenever one is available — it's stable, unambiguous, and guaranteed not to collide with the outbound interface's own address.

4. URPF On The Peer Can Silently Undo Your Fix

SYMPTOMsource-ip is correctly set to a different address, the same-source-same-destination problem is gone, but the session is still Down.

CAUSEIf the peer device has URPF enabled, it checks whether it has a valid route back to the packet's source IP before accepting it. A Loopback address used as source-ip that the peer has no route to gets discarded by URPF — a completely different failure mode that looks identical from the outside.

FIXMake sure the peer has a valid, reachable route to whatever address is configured as source-ip before assuming the Loopback fix alone will work.

5. DHCPv6/ARP Flood Triggers HOSTCAR Which Then Looks Exactly Like a BFD Link Failure

SYMPTOMBFD flaps Down and Up with Diagnostic=DetectDown, but there's no actual physical link event, interface flap, or configuration change anywhere near the timestamp.

CAUSEA burst of a particular protocol from one source MAC — DHCPv6 Request in this case — can trip the interface's user-level CAR rate limit (HOSTCAR), which then also drops other protocol packets from that same MAC, including ARP. The resulting ARP aging breaks Layer 2 reachability to the BFD peer just long enough for BFD's own detect timer to expire.

FIXWhen BFD flaps without a real link event, check for HOSTCAR_DROPPKT log entries around the same timestamp before assuming it's a BFD or physical-layer problem — disabling unnecessary user-level rate limiting on network-facing interfaces is the standard fix once this pattern is confirmed.

Related solution designs

Resilient Data Center NetworkBFD is the fast-failure-detection layer underneath this design — a one-arm echo session silently staying Down defeats the whole point of it. Enterprise Campus Network SolutionThe same S-series switch models and CPU-protection features (HOSTCAR included) behind Case 3 above are exactly what this design has to account for.

Five Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

What's actually different about one-arm echo versus normal two-way BFD?

Normal BFD is a real two-way protocol — both sides run BFD, exchange control packets, and independently track session state. One-arm echo isn't a negotiation at all: only the local device runs BFD; it sends a UDP packet addressed to its own interface's IP and simply expects the peer to forward it straight back, unmodified. It exists specifically for peers that don't support BFD, or haven't enabled it.

source-ip is listed as optional in the command syntax — do I actually need to configure it?

Yes, always. It's optional only in the sense that the command will accept omitting it — in practice, omitting it means the source IP defaults to the destination IP, which is exactly the same-source-same-destination shape that gets dropped on a confirmed list of switch models. Always configure source-ip explicitly to a different address, ideally a Loopback.

My peer actually does support BFD — should I still use one-arm echo?

No. One-arm echo is a workaround for peers that can't run real BFD. If both sides support it, configure a standard two-way BFD session (asynchronous mode, with or without echo function) instead — it gives you genuine bidirectional detection rather than a one-sided loopback test.

A session came back Up on its own, but flapped without any real link event — what's the checklist?

Check display arp for the peer's entry first — if it aged out right before the Down event, something briefly broke Layer 2 reachability. Then check the logs around that exact timestamp for HOSTCAR_DROPPKT or similar CPU-protection drop events; a burst of some other protocol from the same source MAC tripping a rate limiter is a common cause that has nothing to do with BFD or the physical link itself.

Why did it take about 10 seconds for BFD to come back Up after a brief Down?

This is expected, not a fault. When a BFD session goes Down, if the far end sends a BFD packet reporting Up before it has received the local side's Down notification, the local side deliberately ignores that stale Up report and stays Down rather than re-establishing on it immediately — this avoids state oscillation. The extra delay is that safety margin, not a malfunction.

Honest Limits of This Note

Honest Limits of This Note

This note is built around Huawei S-series switch and NE-series router one-arm echo BFD deployments, using the display bfd session / display arp commands shown above. The confirmed model list and drop behavior reflect V200R022C00-era testing — always verify same-source-same-destination handling directly on your own firmware version and model, since Huawei's compatibility list can change across releases. It doesn't cover BFD for VXLAN/EVPN underlay scenarios, or multi-hop BFD in depth.

One-arm echo session stuck Down, or flapping for no obvious reason?

Tell us the switch model and your bfd bind command, plus display bfd session / display arp output, and we'll help you read it.

WhatsApp an engineer →

Related Reading

OSPF Neighbor Stuck or Route Flapping? Reading the State Machine to Find the FaultBFD is usually paired with OSPF for fast convergence — the same discipline of reading state before changing configuration applies here too. Devices Can't Get an IP Address? DHCP Failure Troubleshooting on SwitchesThe DHCPv6 Relay traffic behind Case 3's HOSTCAR trigger — worth reading if the same interface is also handling DHCP for endpoints. Switch CPU Utilization High: Finding What's Eating the Control PlaneHOSTCAR and the other CPU-protection rate limiters behind Case 3 — see the full picture of what's competing for the control plane.