Routing protocols detect dead neighbors with hello timers measured in tens of seconds. Modern applications notice outages measured in hundreds of milliseconds. BFD (Bidirectional Forwarding Detection) closes that gap: a lightweight, protocol-agnostic liveness check that runs in the forwarding plane and tells OSPF, EIGRP, BGP, and friends about a failure in under a second. In this post we configure BFD on Cisco IOS XE, then race it against default timers with a stopwatch: the same simulated failure takes OSPF 34 seconds to notice on its own and 0.58 seconds with BFD. Real captures, from the same lab as the rest of the IP Routing cluster.
The Problem: Hellos Are Slow and Expensive
When a link fails cleanly (carrier drops), interface-down events notify the routing protocol instantly. The dangerous failures are the dirty ones: a one-way fiber fault, a dead peer behind a healthy switch port, a wedged forwarding plane. The interface stays up, and the protocol only notices when hellos stop arriving. Defaults are generous: OSPF waits a 40 second dead interval on broadcast networks, EIGRP 15 seconds of hold time, BGP a leisurely 180 second hold timer. You can crank protocol timers down, but aggressive hellos are processed in the control plane per protocol, so fast timers multiply CPU load and false positives, once per protocol running on the link.
BFD moves the liveness question out of the protocols entirely. One BFD session per link (or per neighbor pair) does the fast polling in the forwarding plane, and every registered protocol subscribes to its verdict. One detection mechanism, many clients.
Timers and the Arithmetic of Detection
Three knobs, set per interface on IOS XE:
interface Ethernet0/1
bfd interval 300 min_rx 300 multiplier 3interval is how often we send (milliseconds), min_rx the slowest rate we are willing to receive at, and multiplier how many consecutive misses declare death. Detection time is roughly the negotiated interval times the multiplier: here 300 ms times 3, so about 900 ms worst case. Carrier-grade deployments run 50 ms times 3 for 150 ms detection; 300x3 is a sane, conservative starting point for enterprise WAN links and virtual labs alike.
IOS XE also defaults to echo mode: BFD sends echo packets that the neighbor's forwarding plane loops straight back without touching its CPU, which tests the actual data path. The control session then relaxes to a slow 1 second cadence, visible in the captures below.
Tying BFD to OSPF and EIGRP
Each protocol registers as a BFD client with one line. On our lab's R2-R3 boundary link (both protocols run there):
! R2
interface Ethernet0/1
bfd interval 300 min_rx 300 multiplier 3
ip ospf bfd
!
router eigrp PINGLABZ
address-family ipv4 unicast autonomous-system 100
af-interface Ethernet0/1
bfdR3 mirrors the same on its side of the link. OSPF can alternatively enable BFD process-wide with bfd all-interfaces under router ospf, and BGP registers per neighbor with neighbor x.x.x.x fall-over bfd. The mechanics are identical in every case: the protocol keeps its own timers as a backstop and additionally accepts BFD's down verdict immediately.
Reading the Session
R2# show bfd neighbors
NeighAddr LD/RD RH/RS State Int
10.0.23.3 1/1 Up Up Et0/1
R2# show bfd neighbors details | begin OurAddr
OurAddr: 10.0.23.2
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Echo Rx Count: 235, Echo Rx Interval (ms) min/max/avg: 227/304/265 last: 101 ms ago
Registered protocols: EIGRP CEF OSPF
Min Echo interval: 300000Two things to read carefully. The control packet timers show 1000000 microseconds (1 second) because echo mode carries the fast detection; the echo counters underneath show the real 300 ms cadence at work (average 265 ms). And "Registered protocols: EIGRP CEF OSPF" is the money line: both routing protocols are subscribed to this one session. If a protocol you configured is missing from that list, the client registration did not take, and BFD will detect failures nobody reacts to.
The Race: Failure Detection With and Without BFD
To time detection honestly we need a failure the interface cannot report. An inbound deny-everything ACL on R2's boundary interface simulates a one-way path failure: R3's hellos, EIGRP packets, and BFD traffic all stop arriving while carrier stays up. First, the baseline with BFD not yet enabled, marker logged at the moment the ACL goes on:
*16:42:50.487: ... BASELINE-NO-BFD: KILL-LINK ACL applied on Et0/1
*16:43:02.942: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.23.3 (Ethernet0/1)
is down: holding time expired
*16:43:24.528: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Ethernet0/1
from FULL to DOWN, Neighbor Down: Dead timer expiredEIGRP needed 12.5 seconds, OSPF 34 seconds. For 34 seconds, R2 forwarded traffic into a black hole while its routing table swore everything was fine. Now the same failure with BFD tied to both protocols:
*16:45:54.773: ... WITH-BFD: KILL-LINK ACL applied on Et0/1
*16:45:55.355: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Ethernet0/1
from FULL to DOWN, Neighbor Down: BFD node down
*16:45:55.356: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.23.3 (Ethernet0/1)
is down: BFD peer down notified582 milliseconds, and both protocols converged in the same millisecond, from the same BFD verdict. The reason codes in the log tell the story: "Dead timer expired" versus "BFD node down".
OSPF, defaults
Dead interval 40 s on broadcast media. Measured detection: 34.0 s.
EIGRP, defaults
Hold time 15 s. Measured detection: 12.5 s.
Both with BFD 300x3
Measured detection: 0.58 s, both protocols simultaneously. About 58x faster than the OSPF dead timer.
BGP, defaults
Hold timer 180 s. The single biggest BFD win: neighbor x.x.x.x fall-over bfd takes edge failover from minutes to sub-second.
Deployment Notes From the Field
Configure BFD symmetrically; a session forms at the slower side's parameters (timers negotiate down), but mismatched multipliers create asymmetric detection you will chase for hours. On multiaccess segments through a switch, BFD is precisely what saves you from the dead-peer-behind-a-live-port failure, so prioritize it there over point-to-point fiber where carrier loss already signals instantly. Keep protocol timers at their defaults once BFD is on (they are the backstop, and tightening them buys nothing). Echo mode needs no ip redirects on some platforms and does not cross Layer 3 hops; for multihop BGP peerings use the separate BFD multihop template support. And in virtual labs, remember BFD state changes are honest but data-plane timing is virtualized: the 0.58 s measured here is the mechanism working as designed, not a hardware benchmark.
BFD for BGP: The Biggest Single Win
BGP's defaults (60 second keepalives, 180 second hold) made sense for 1990s route servers and make none for a modern dual-homed edge. Registration is per neighbor:
router bgp 65001
neighbor 203.0.113.1 fall-over bfdWith the interface-level BFD timers from earlier, an eBGP session over a direct link now fails over in under a second instead of up to three minutes. Two provisos. Your provider must run BFD on their side (ask; most will), and for multihop eBGP or loopback peerings the single-hop echo machinery does not apply, so IOS XE uses BFD multihop via a template and map:
bfd-template multi-hop PEER-TMPL
interval min-tx 300 min-rx 300 multiplier 3
!
bfd map ipv4 10.99.99.2/32 10.99.99.1/32 PEER-TMPL
!
router bgp 65001
neighbor 10.99.99.2 fall-over bfd multi-hopTemplates for Consistency at Scale
Per-interface bfd interval lines drift apart over years of edits. Single-hop templates centralize the numbers, and interfaces reference the name:
bfd-template single-hop FAST
interval min-tx 300 min-rx 300 multiplier 3
!
interface Ethernet0/1
bfd template FASTChange the template once and every referencing interface follows. On platforms with hardware BFD offload, templates are also where echo mode and authentication knobs live (echo, authentication keyed-sha-1), keeping the security posture uniform. If you operate more than a handful of BFD links, templates are the difference between a design and a collection of exceptions.
Reading a BFD Failure After the Fact
When BFD takes a session down, the diagnostic code in show bfd neighbors details ("Local Diag") and the syslog reason tell you which side declared death and why: "Echo Function Failed" means our echoes stopped coming back (data path problem toward the peer), while "Neighbor Signaled Session Down" means the peer told us first (its problem, or a two-way issue it noticed sooner). Pair that with the registered protocol logs, which name BFD explicitly, as in our capture: "Neighbor Down: BFD node down" versus the timer-based "Dead timer expired". If you see BFD flapping without protocol churn underneath, suspect timer aggression versus platform reality: virtualized or oversubscribed boxes miss 50 ms deadlines under CPU stress, and the cure is 300x3, not disabling BFD.
FAQ
Does BFD replace protocol hello timers?
No, it supplements them. Hellos still handle discovery, parameter negotiation, and slow-path liveness; BFD adds the fast failure verdict. Leave protocol timers at defaults once BFD carries detection.
Echo mode or asynchronous mode?
Echo (the IOS XE default where supported) tests the peer's actual forwarding plane and tolerates a busy peer CPU. Asynchronous control-only mode is the fallback where echo is unsupported (some multihop, some platforms) or where ip redirects interactions forbid it.
Can one BFD session serve multiple protocols?
Yes, and it is the design's whole point. Our lab session lists "Registered protocols: EIGRP CEF OSPF" and both IGPs converged from one verdict in the same millisecond. Any new client (BGP, HSRP, static routes via ip route ... track with BFD tracking) subscribes to the same session.
What timers should I start with?
300 ms x 3 on enterprise WAN and virtualized gear, 50 ms x 3 on dedicated hardware where sub-200 ms failover is a requirement. Tighten only with evidence the platform holds the schedule under load.
Key Takeaways
BFD is a single, cheap, forwarding-plane liveness protocol that any registered routing protocol consumes, replacing per-protocol fast hellos. Detection is interval times multiplier (300 ms x 3 gives sub-second), echo mode tests the real data path, and one session serves OSPF, EIGRP, and BGP at once, which our captures show converging in the same millisecond. Verify with show bfd neighbors details and read the "Registered protocols" line like a contract. For what happens after detection (SPF, DUAL, and BGP best path reacting to the loss), see the OSPF, EIGRP, and BGP pillars, and the rest of the IP Routing cluster for the routing machinery BFD accelerates.
