BFD Explained: The Smoke Detector That Notices a Dead Path in Milliseconds
BFD is a smoke detector for network paths: two routers swap tiny heartbeat packets every few milliseconds, and when three in a row go missing, OSPF, BGP and static routes reroute — detected at 150 ms, not 40 seconds. Timers, session states, the 24-byte packet, variants, and the five mistakes that turn the cure into the outage.
A smoke detector does not fight fires. It sniffs the air constantly, and the moment it smells trouble it screams, so everything else can react in time. BFD is the smoke detector of a network path.
Routers already have a way to notice a dead neighbour: they exchange hellos on a schedule, and declare the neighbour gone only after a long silence. The problem is the schedule.
OSPF (Open Shortest Path First — the routing protocol inside one organisation's network) sends a hello every 10 seconds on a broadcast network and waits a full 40 seconds — its default dead interval — before giving up. BGP (Border Gateway Protocol — how networks swap routes with each other) is slower still: keepalives every 60 seconds, a default hold time of 180 seconds. Three minutes of traffic poured into a dead path before anyone reacts.Worse, sometimes nothing looks dead at all. A path can fail in the middle — an intermediate switch dies, a media converter hangs, one member of a link bundle fails, a fibre fault carries traffic one way only — while your router's interface still reports up/up. The routing protocol watches the wrong thing, on the wrong timescale.
A heartbeat with a single job
BFD is deliberately small. Two ends of a path run a BFD session, swapping tiny control packets over UDP (User Datagram Protocol — the connectionless transport DNS also uses) to destination port 3784. They carry no routes, no topology, nothing except "I am still here." That narrowness is the point: a protocol that does almost nothing can afford to do it every few milliseconds.
An optional echo function goes lighter still: echo packets (UDP port 3785) are looped back by the peer's forwarding plane — its BFD process never handles each one — so the check runs fast with almost no control-plane work.
Four states and a three-way handshake
A BFD session sits in one of four states: Down, Init, Up and AdminDown (deliberately shut down by an operator). It climbs to Up via a three-way handshake carried in the packets themselves.
Each side picks a non-zero My Discriminator — a name tag for the session — and echoes the peer's number back as Your Discriminator.
Until a packet arrives, Your Discriminator is 0: "I have heard from no one."The session moves Down → Init the moment a packet arrives from the peer, and Init → Up when packets show the peer has seen yours — its state field says so, and its Your Discriminator carries your number. Both directions are now proven — exactly what a one-way fibre fault breaks, and exactly what BFD exists to catch.
The timer deal: interval × multiplier = detection time
BFD does not hard-code its speed. Each side advertises three numbers: a Desired Min TX Interval (fastest it wants to send), a Required Min RX Interval (fastest it can receive) and a Detect Multiplier — how many packets in a row may go missing before the path is declared dead. The send interval is negotiated from the two ends' values.
Detection time is plain multiplication: the peer's Detect Multiplier × the negotiated transmit interval. Step by step:
- 50 ms × 3 = 150 ms. Three packets in a row go missing; 150 ms after the last good one, the path is declared dead.
- 100 ms × 3 = 300 ms. Slower packets, same multiplier — gentler on the routers, still far inside a second.
- 3.3 ms × 3 ≈ 10 ms. Hardware platforms can run intervals this fast — always platform-dependent.
Anatomy of a control packet: 24 bytes, nothing spare
Every BFD control packet starts with a mandatory 24-byte section. Expand each field — what a capture shows, and what the timer deal is negotiated with.
Byte 0 — Version and Diagnostic
The protocol version, plus a diagnostic code for why the sender last changed state.
Byte 1 — State and flags
The sender's session state (Down, Init, Up, AdminDown) plus flags: Poll/Final confirm timer changes; Demand marks demand mode.
Byte 2 — Detect Mult
The sender's Detect Multiplier — times the negotiated interval, the detection time the peer applies.
Byte 3 — Length
Total packet length in bytes — 24 with no optional extras.
Bytes 4–7 — My Discriminator
The sender's own non-zero name tag for this session.
Bytes 8–11 — Your Discriminator
The peer's My Discriminator, echoed back. 0 until the first packet arrives; seeing your own number return completes the handshake.
Bytes 12–15 — Desired Min TX Interval
In microseconds: the fastest this sender wants to transmit — one input to the negotiated interval.
Bytes 16–19 — Required Min RX Interval
In microseconds: the fastest this receiver can accept packets. A peer may not send faster.
Bytes 20–23 — Required Min Echo RX Interval
In microseconds: the fastest this receiver can accept echo packets; 0 if echo is not in use.
BFD reroutes nothing — it pulls the fire alarm
Understand what BFD does not do: it computes no routes and moves no traffic. It notifies. Protocols that care about a path — OSPF, IS-IS, BGP, static routes, PIM and MPLS — register as BFD clients; when the alarm sounds, each acts.
OSPF drops the adjacency at once instead of waiting out the dead timer. A static route tied to BFD is withdrawn the moment its session falls, so the backup installs at once — a plain static route has no liveness check of its own; BFD is often the only thing watching it. BGP resets the session, or fast-reroute such as TI-LFA — the precomputed local repair from our segment routing guide — engages while the protocols sort themselves out.
Flavours: single-hop, multihop, LSPs and bundles
The base protocol has standardised variants. Single-hop BFD (RFC 5881) covers directly connected neighbours and checks incoming packets arrive with IP TTL 255 — the GTSM trick (Generalized TTL Security Mechanism): only a truly attached neighbour arrives with TTL 255 untouched — spoofed packets from further away are rejected.
Multihop BFD (RFC 5883) watches paths several hops long — and uses UDP destination port 4784, not 3784. BFD for MPLS LSPs (label-switched paths — MPLS's label tunnels) is RFC 5884. Micro-BFD (RFC 7130) runs a session per member link of a link aggregation group, so one sick member is caught while the bundle stays up.
One more mode, honestly labelled: demand mode. Once a session is Up, either side may stop the periodic packets and lean on the client protocol's own liveness, polling only when it wants proof. It is in RFC 5880 — but plain asynchronous mode is what most networks run.
When the session will not come up
The session state is the troubleshooting map — it tells you which half of the path to interrogate. Two verify commands (generic Cisco style) show it:
show bfd neighbors
show bfd neighbors detailStuck at Down means nothing is arriving: BFD is not configured on the far end; UDP 3784 (or 4784 multihop) is blocked by an ACL or firewall; or the session sits on the wrong interface or VRF.
Stuck at Init is subtler: packets arrive, but the peer never sees yours — its packets never carry your discriminator — so look for a one-way path or a return-path ACL.
Five common mistakes
- Timers faster than the platform can sustain. Run in software on the control-plane CPU, BFD starves under load: packets are missed, healthy paths declared dead — the cure becomes the outage. Hardware-offloaded, distributed BFD makes the fastest timers safe.
- Enabling BFD for one client and forgetting another. OSPF gets sub-second detection while BGP, sharing the same neighbour, still waits out its hold timer.
- Configuring only one side. BFD is a conversation; one-sided config is the classic stuck-at-Down.
- Using the single-hop profile for a multihop session. Wrong destination port — 3784 versus 4784. Match the profile to the path.
- No dampening on a flapping link. Without hold-down, every bounce churns the routing table. Remember: detection is not diagnosis — BFD says the path died, never why.
Try it yourself
The SR-TE / CSPF Path Visualizer shows the backup path that BFD-style fast detection protects — precomputed, waiting for the alarm. Run your BFD session config through the Network Config Verifier first. And in the Wireshark Filter Builder, build the display filter udp.port == 3784 and read a real BFD capture packet by packet.
- BFD (RFC 5880) exists because routing protocols notice failure slowly on their own: OSPF’s default dead interval is 40 s and BGP’s default hold time is 180 s — and a path can be dead while the local interface still shows up/up.
- Two neighbours exchange small UDP control packets (destination port 3784), climb a Down → Init → Up handshake using My/Your Discriminators, and detect failure in the peer’s Detect Multiplier × the negotiated transmit interval — 50 ms × 3 = 150 ms.
- BFD reroutes nothing itself: it notifies its clients — OSPF, IS-IS, BGP, static routes, PIM and MPLS — and each client acts, from dropping an adjacency at once to withdrawing a tracked static route so the backup installs.
- Variants: single-hop BFD is RFC 5881 (IP TTL 255 / GTSM spoofing protection), multihop is RFC 5883 on UDP port 4784, BFD for MPLS LSPs is RFC 5884, and per-member micro-BFD for link bundles is RFC 7130.