BFD: Bidirectional Forwarding Detection for Fast Failover

The one-sentence mental model

BFD is the neighbor-death detector that routing protocols wish they had. OSPF hello is 10 s, dead 40 s. EIGRP hello 5 s, hold 15 s. BGP keepalive 60 s, hold 180 s. Way too slow for real-time apps. BFD fires 3-per-second (or faster) hellos and detects failure in under a second, then tells the routing protocol to react.

Why not just tighten routing-protocol timers?

You can. But:

• CPU cost. Every neighbor + every protocol multiplies the hello load.
• Not consistent. OSPF, BGP, HSRP, static routes with track. Each has its own timer knobs.
• Not sub-second reliably. Below 1s, timer-based detection gets flaky under load.

BFD solves all three: one lightweight protocol, one detection engine, one config. Every routing protocol just subscribes.

How BFD works

Two neighbors negotiate a session:

1. Discriminator exchange: each side picks a random ID for the session and tells the peer.
2. Timer negotiation: TX interval + detection multiplier. Actual detection time = TX × multiplier.
3. Steady state: both sides fire BFD packets at the TX interval. If N in a row are missed → session down.

Typical numbers: TX 50 ms × multiplier 3 = detection in 150 ms. Compare to OSPF dead-timer 40 seconds. BFD is ~250× faster.

Two flavors:

• BFD Asynchronous: bidirectional constant packet stream. Detects link and peer aliveness. Always runs.
• BFD Echo: one side loops packets back through the other’s data plane. Tests the actual forwarding hardware, not just the control plane. On Cisco IOS, echo mode is on by default on top of the async session (disable with no bfd echo on the interface).

Enabling BFD on Cisco IOS

Enable on the interface first:

interface GigabitEthernet0/1
  bfd interval 100 min_rx 100 multiplier 3

This says: send BFD every 100 ms, expect one every 100 ms, declare dead after 3 misses (300 ms).

Then attach protocols as clients.

OSPF

router ospf 1
  bfd all-interfaces

Or per-interface: ip ospf bfd.

EIGRP

router eigrp 100
  bfd all-interfaces

BGP (per neighbor)

router bgp 65001
  neighbor 203.0.113.1 fall-over bfd

HSRP

interface Vlan10
  bfd interval 100 min_rx 100 multiplier 3
  standby 1 ip 10.10.10.1
  standby bfd

HSRP BFD peering (standby bfd, on by default once BFD is enabled on the interface) lets the Standby detect a dead Active router in about 300 ms. Note that BFD does not change an interface’s line-protocol state, so track ... interface line-protocol gets no benefit from BFD.

Static route with BFD

interface GigabitEthernet0/1
  bfd interval 100 min_rx 100 multiplier 3
!
ip route static bfd GigabitEthernet0/1 203.0.113.1
ip route 10.0.0.0 255.0.0.0 GigabitEthernet0/1 203.0.113.1

If the BFD session to 203.0.113.1 goes down, the static route is withdrawn from the routing table.

Verifying

show bfd neighbors                        ← session state, protocols using it
show bfd neighbors 203.0.113.1 details    ← negotiated timers, drops

Look for State = Up and LD/RD (local/remote discriminator) values. If timers renegotiate to something you didn’t ask for, one side’s config caps the other.

When to use BFD

Use it when:

• Real-time apps (voice, video, financial market data) traverse the link.
• Dual-carrier eBGP peers: you want the “prefer ISP-A unless dead” logic to react in under a second.
• Static routes that need to failover fast without a routing protocol.
• HSRP tracking on WAN interfaces.

Skip it when:

• The link is a low-priority backup (a couple seconds of downtime is fine).
• CPU is a hard constraint on old hardware.
• The routing protocol already has sub-second timers negotiated (rare).

Common exam / real-world mistakes

1. Forgetting to enable BFD on the interface and attach the protocol. Enabling router ospf 1 → bfd all-interfaces without interface Gi0/1 → bfd interval ... does nothing.
2. Asymmetric timer configs. Both sides need compatible intervals. BFD negotiates, but only within the ranges each side allows.
3. Trusting BFD Echo without hardware support. Some older platforms don’t support echo mode. show bfd neighbors details will show echo not supported.
4. Enabling BFD everywhere at 50/3. That’s 20 packets per second in each direction, per neighbor. Across hundreds of sessions on a scale-out core, it’s real CPU. Start with 200 ms × 3 = 600 ms detection on non-critical links.
5. Missing that BGP fall-over bfd still needs BFD enabled on the interface reaching the peer. Symptom: BGP sits with default 180 s hold-timer, BFD session doesn’t exist.

Cheat strip

Job         detect neighbor/link death. Fast. Sub-second.
Numbers     TX × multiplier = detection time. Typical 100×3 = 300ms.
Modes       Async (default)  |  Echo (hardware loop, best detection)

Enable      interface X → bfd interval T min_rx R multiplier M
Attach:
  OSPF      router ospf N → bfd all-interfaces
  EIGRP     router eigrp N → bfd all-interfaces
  BGP       neighbor X fall-over bfd
  HSRP      standby bfd (default on once the interface has BFD)
  static    ip route static bfd <interface> <next-hop>

Verify      show bfd neighbors [details]