skip to content

What does the BFD echo function test that asynchronous BFD Control packets do not, and why can't every link use it?

level: seniorimportance: nice to knowfreq 9%

answer

  1. the peer forwards, it does not answer
  2. Required Min Echo RX Interval
  3. UDP 3785, one hop only
  4. ingress filtering breaks it
  5. slow Control packets alongside

basics

~20 s

BFD echo packets are addressed so the peer simply forwards them back, testing its forwarding path without its BFD process answering; echo needs the peer's consent, works only on single-hop sessions and breaks under ingress filtering.

solid answer

~50 s

In asynchronous mode each router's BFD process must build and receive Control packets, so detection depends on the peer's BFD software keeping up. With the **echo function** a router sends packets to UDP 3785, addressed so the peer's forwarding plane routes them straight back; the peer's BFD process never handles them. That tests the peer's **forwarding path** directly, removes the peer's processing jitter, and lets detection run fast while Control packets drop to a sedate rate (RFC 5880 says at least one second). Limits: the peer must advertise a nonzero `Required Min Echo RX Interval`, echo starts only once the session is Up, it needs twice the packets of pure asynchronous mode for the same detection time, it is forbidden across multiple hops, the sender must be able to send to its own address, and ingress filtering on the interface must be relaxed for it.

go deeper

for a junior

Recall that echo packets are bounced back by the peer's forwarding path rather than answered by its BFD process.

for a middle

Explain the consent field, the UDP port and why Control packets slow to a second or more once echo is active.

for a senior

Diagnose why echo fails to come up or flaps: ingress filtering, redirects, address choice, multihop paths, and a peer that advertises a zero echo interval.

for a principal

Decide when echo's independence from the peer's CPU is worth the extra packets, the filtering exceptions and the single-hop restriction across a whole estate.

## What asynchronous mode actually measures In **asynchronous mode** (RFC 5880) both routers send BFD Control packets and each one's BFD implementation must receive and process the other's. A session that stays Up therefore proves that the path works *and* that the remote BFD process is producing packets on time. If that process stalls (a busy control-plane CPU, for instance), packets stop even though the peer may still forward traffic perfectly. ## How the echo function works The **echo function** is an adjunct to either mode, not a separate session type: 1. The session is brought Up with ordinary Control packets. Echo packets MUST NOT be sent unless the session is Up. 2. The peer signals that it is willing to loop echoes by advertising a **nonzero `Required Min Echo RX Interval`**; zero means it will not. Echo is enabled per direction, and only when the looping system allows it and the sending system wants it. 3. The sender transmits echo packets to UDP port **3785** (RFC 5881), addressed so that the peer's ordinary forwarding returns them; in practice the destination is the sender's own address, and the frame is addressed to the peer's link-layer address so the peer actually receives it. 4. The peer forwards each packet back like any transit packet. Its BFD process is not involved, and the payload is a local matter for the sender. 5. If enough echo packets fail to return, the sender declares the session Down with diagnostic code 2, **Echo Function Failed**. How many count as "enough" is left to the implementation. While echo is active a system SHOULD set its `Required Min RX Interval` to at least one second, keeping Control traffic negligible because the echoes now do the detecting. ## What echo gives you | Property | Asynchronous Control packets | Echo function | |---|---|---| | Who handles packets on the peer | The peer's BFD implementation | The peer's forwarding path only | | Tests | Path plus peer's BFD process | Path through the peer's forwarding plane | | Packets for a given detection time | Baseline | About twice as many (each echo crosses the link twice) | | Hops | Single hop or multihop | Single hop only | | Consent needed | No | Peer must advertise nonzero `Required Min Echo RX Interval` | RFC 5880 lists the benefits: echo truly tests only the remote forwarding path, which may reduce round-trip jitter and allow more aggressive detection times, and it can catch some failures that Control packets miss, such as a forwarding plane that has stopped while the control plane still answers. ## Why echo is not always available - **Ingress filtering.** An echo packet arrives back carrying the sender's own address as the destination and a source chosen by the sender. RFC 5881 says ingress filtering in the BCP 38 sense is incompatible with this and MUST be disabled on that interface or must exempt echo packets. - **Redirects.** The source address must be chosen so the peer does not send ICMP or Neighbor Discovery Redirects; RFC 5881 says it SHOULD NOT be in the interface's own subnet and SHOULD NOT be an IPv6 link-local address unless the peer is known not to send Redirects. - **Host APIs.** The sender must be able to transmit packets to its own address, bypassing the normal forwarding lookup, which some systems cannot do. - **Multihop.** RFC 5883 forbids echo across hops: the first router would return the packet and the rest of the path would go untested. - **Bundles.** RFC 7130 micro-BFD on link-bundle members considers only asynchronous mode and leaves echo out of scope. - **Packet cost.** For the same detection time, pure asynchronous mode needs half as many packets. ## Echo and Demand mode RFC 5880 pairs echo with **Demand mode**: once both sides are Up, a system may set the Demand (D) bit so the peer stops periodic Control packets, and echo (or another mechanism such as observed traffic) proves liveness. RFC 5880 warns that Demand mode's detection time then depends on implementation heuristics rather than the protocol. ## When engineers pick echo - The peer's BFD runs in software on a busy control-plane CPU, but its forwarding plane is robust: echo moves the timing burden to the sender. - The goal is to verify forwarding through the neighbour, not just that its control plane is alive. - Both ends sit on a single routed hop with no strict ingress filtering, or the filtering can exempt echo.

  • With echo active, why does a BFD router keep sending Control packets at all?
    The Control session carries state and parameters: Up, Down and AdminDown, the diagnostic code, each side's intervals and whether echo is still allowed. It also confirms the peer's BFD implementation is alive. Echo only replaces the fast liveness check, so RFC 5880 has Control traffic drop to a sedate rate, at least one second, rather than stop.
  • Can one side run echo while the other uses fast Control packets?
    Yes. Echo is enabled independently in each direction, and the system looping echoes is not even told that echoes are being sent. RFC 5880 notes that the side not using echo will then want fairly rapid Control packets to reach its own detection time, which BFD allows because each direction negotiates its own rate.

saying these in an interview costs you the question

  • Echo packets are answered by the peer's BFD process like Control packets.
  • A router may start sending echoes as soon as it configures BFD.
  • Echo halves the packets needed for a given detection time.
  • Echo is the best way to test a multihop path end to end.
  • Strict ingress filtering on the interface has no effect on echo packets.