What is BFD?

Bidirectional Forwarding Detection (BFD) is a lightweight protocol that detects failures on the link or path between two directly connected or logically adjacent devices, typically within milliseconds. Routing protocols such as BGP, OSPF, RIP, and IS-IS use BFD as a fast failure-detection mechanism, reacting to a lost neighbor far sooner than their own hello or dead timers allow.

Key takeaways

• BFD detects link and path failures in milliseconds, not seconds.
• IGPs and BGP act as BFD clients; one session can serve several protocols.
• VOS supports BFD with BGP, OSPF, OSPFv3, RIP, RIPng, IS-IS, and static routes.
• Static routes use BFD as a liveness monitor alongside ICMP-based checks.
• Versa recommends BFD on the LAN side, not inside the SD-WAN overlay itself.

On this page: Why it matters · How it works · Types · BFD & Versa · FAQ

Why is BFD important?

Routing protocols were not designed to notice a dead neighbor quickly. OSPF’s default dead interval and BGP’s default hold timer both run into tens of seconds – long enough for traffic to keep flowing into a black hole after a link fails. Layer 2 link-down events help on a directly wired connection, but are useless when the path crosses a switched network or a data-center device with no physical link-down signal.

BFD closes that gap. It runs an independent, protocol-agnostic heartbeat between two endpoints and reports failure in milliseconds, so the protocol above it reacts immediately instead of waiting out its own timers. One BFD session can back multiple clients – OSPF, BGP, and a static route at once – delivering consistent detection without tuning every protocol’s timers individually.

What is BFD?

BFD works by having two endpoints exchange simple control packets at a negotiated interval. Each side advertises how often it sends packets and how many consecutive packets its peer may miss – the multiplier – before declaring the session down. Miss that many in a row and BFD immediately notifies every registered client, without waiting for a hello timeout or a protocol-specific dead interval.

BFD does not replace a routing protocol; it rides alongside one as a shared liveness check. A router can run BFD once between two neighbors and let BGP, OSPF, and a static route to that neighbor subscribe to the same session’s up/down state – one session, multiple clients, low overhead as more protocols share a link. Parameters are configured per instance or interface, so neighbors can run at different speeds.

Types of BFD

BFD is not tied to one routing protocol – the differences are in which client uses it and how the session is set up. Static-route BFD monitors a configured next hop, alongside or instead of ICMP-based monitoring, and withdraws the route if the session fails. IGP BFD covers OSPF, OSPFv3, RIP, RIPng, and IS-IS: when the session to a neighbor drops, the adjacency goes down immediately rather than waiting for the protocol’s dead timer. BGP BFD ties a peering session’s liveness to BFD state with that same neighbor.

A further distinction is single-hop versus multihop BFD: single-hop sessions run between directly connected interfaces, while multihop sessions tolerate routed hops between endpoints. IS-IS adds a strict-mode option, where an adjacency forms only once BFD confirms the neighbor.

BFD & Versa

VOS edge devices support BFD as a liveness monitor across the routing stack: static routes can enable BFD alongside ICMP and other monitor objects, and BFD can be enabled for BGP, OSPF, OSPFv3, RIP, RIPng, and IS-IS instances, each with its own intervals and multiplier. IS-IS interfaces additionally support independent IPv4 and IPv6 BFD with a strict mode that withholds the adjacency until BFD confirms the neighbor.

The Versa SD-WAN design guide recommends enabling BFD on the LAN side of a VOS CPE – toward customer-owned Layer 3 devices and data-center service VNFs – for millisecond detection ahead of BGP or OSPF convergence, but against layering it onto the SD-WAN overlay itself, since the overlay’s fast-convergence and headless-operation design already handles path failures.

Frequently asked questions

What does BFD stand for?

BFD stands for Bidirectional Forwarding Detection: a protocol that verifies, in both directions between two endpoints, that the forwarding path between them is still working – hence “bidirectional.” Each side sends and expects control packets, so either endpoint can independently notice when the path has failed and act on it.

How is BFD different from a routing protocol’s own hello timers?

Hello and dead timers are built into each routing protocol and typically take seconds to tens of seconds to notice a lost neighbor. BFD is a separate, lightweight heartbeat that multiple protocols can share at once, detecting a failed neighbor in milliseconds instead of waiting out those native timers.

Can one BFD session support more than one routing protocol?

Yes. A single BFD session between two neighbors can be registered by several clients at once – for example OSPF, BGP, and a static route to the same next hop – so all of them learn about a failure from the same fast session.

What is the difference between single-hop and multihop BFD?

Single-hop BFD runs between directly connected interfaces on the same subnet, typically with sub-second timers. Multihop BFD tolerates one or more routed hops between the two endpoints, which suits neighbors reached through an intermediate router rather than a direct link.

Should BFD be enabled on a Versa SD-WAN overlay?

Versa’s guidance is to enable BFD on the LAN side, toward third-party routers and data-center devices, rather than inside the SD-WAN overlay itself, where the overlay’s own fast-convergence and headless-operation mechanisms already provide failure detection without needing added BFD timers there.

More on BFD

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about BFD, these are worth looking at next.