BFD, bidirectional forwarding detection, is a lightweight protocol whose only job is to notice, very quickly, when the path between two devices has failed.
Two routers or switches set up a BFD session and send small control packets to each other at a steady, fast interval.
If one side stops hearing those packets for a set number of intervals, it declares the path down, in milliseconds rather than the seconds a routing protocol would take. BFD does not route anything itself: it works independently of the media and the routing protocols, and simply tells them the path is gone so they can react.
- BFD detects a failed path between two devices in milliseconds
- Two devices set up a session and exchange small control packets at a fast interval
- A path is declared down when packets stop arriving for a set number of intervals
- BFD is protocol independent: it only detects, it does not route
- Routing protocols like OSPF and BGP use BFD to converge faster
On this page
What it isWhat BFD is
BFD exists to answer one question faster than anything else can: is this path still up.
It is a fault detector, not a router. BFD is a network protocol used to detect faults between two routers or switches connected by a link. It provides low-overhead detection of faults even on physical media that do not support failure detection of their own. It carries no user traffic and makes no routing decisions.
It watches the whole forwarding path. RFC 5880 describes BFD as detecting faults in the bidirectional path between two forwarding engines, including the interfaces, the data links, and as far as possible the forwarding engines themselves. It is not just a cable check; it verifies that traffic can actually pass in both directions.
It is deliberately narrow. BFD does one thing so it can do it fast. By staying a simple hello mechanism with no routing intelligence, it can run at high frequency in the forwarding plane and detect a break in a fraction of the time a full routing protocol would need.
How it worksHow BFD works
The mechanism is a steady heartbeat between two agreed endpoints.
Two devices open a session. BFD has no discovery mechanism; a session must be explicitly configured between the two endpoints. Once it is up, each side knows to expect a stream of packets from the other.
They exchange packets at a set interval. The two systems transmit BFD control packets periodically over the path between them, at an interval they negotiate. As long as the packets keep arriving, the path is considered up.
A miss count declares the failure. If a system stops receiving BFD packets for long enough, some component in that bidirectional path is assumed to have failed.
The threshold is the detect multiplier: the path is declared down after that many expected packets in a row fail to arrive. Detection time is therefore the interval multiplied by the multiplier, which is how BFD reaches millisecond detection.
Why it is fastWhy BFD in networking is so fast
The reason to run BFD in networking at all is speed, and the speed comes from what it does not do.
Routing protocols detect failures slowly. Protocols such as OSPF and EIGRP have their own hello and dead timers, but those are measured in seconds by default and are coarse to tune. Waiting for a routing protocol to notice a dead neighbor can mean seconds of black-holed traffic.
BFD runs faster because it is simpler. With nothing to do but send and count small packets, BFD can use sub-second intervals cheaply, often in the forwarding hardware. It detects the same failure in milliseconds instead of seconds.
It then hands off to the routing protocol. BFD does not reroute anything. When it declares a path down, it signals the routing protocol, which then tears down the neighbor and reconverges. BFD is the fast smoke detector; the routing protocol is what actually puts out the fire.
Who uses itProtocol independence and who uses it
The value of BFD is that one detector serves every protocol on the link.
It works under anything. BFD operates independently of the media, the data protocols, and the routing protocols above it. The same BFD session can protect whatever is running over that path, which is why it is not tied to any one protocol.
Many protocols subscribe to it. OSPF, BGP, EIGRP, IS-IS, HSRP and MPLS can all register with BFD and be told immediately when a path fails, instead of relying on their own timers. One BFD session can drive fast failover for several protocols at once.
It has modes for different needs. The primary mode is asynchronous, where both sides send periodic packets continuously. A demand mode exists where the systems agree to stop sending periodic packets to reduce overhead once the path is known good, and an echo function lets one side loop packets back through the other to test the path.
Session and statesThe BFD session and its states
A session does not simply exist; it comes up through a small handshake and is watched from then on.
A session comes up through a handshake. BFD brings a session up through a small state machine: each side starts Down, moves to Init as it begins hearing the other, and reaches Up once both confirm they can see the other's packets on the interface. Only an established, Up session is trusted to report a fault.
Asynchronous packets are the heartbeat. In the usual asynchronous mode both endpoints send hello-style control packets continuously, and each packet carries the sender's view of the session state. As long as the packets keep arriving, the path stays Up and the network treats it as healthy.
The echo function tests the far end. BFD can also use an echo function, where one system sends packets that the remote system loops back through its own forwarding path. If the echoes stop returning, the path has a fault, and this tests the remote forwarding engine directly rather than just the link.
A lost session triggers convergence. When the session drops from Up, BFD reports the fault to every protocol subscribed to it, and those protocols begin convergence immediately instead of waiting for their own dead timers to expire.
PitfallsWhere people go wrong
Expecting BFD to reroute. It does not. BFD only detects; the routing protocol reacts. If failover is not happening, the routing protocol integration, not BFD itself, is usually where to look.
Setting timers too aggressively. Very short intervals detect faster but risk false failures if a device is briefly busy or a link flaps. Timers have to be fast enough to help and slow enough not to tear down healthy sessions under load.
Forgetting there is no discovery. BFD sessions must be configured on both ends. A one-sided configuration produces a session that never comes up, which is a common first-time mistake.
Running it where the routing timers are already enough. On a stable, well-tuned link BFD adds value; on a link that rarely fails and tolerates a few seconds of detection, it may be complexity without much benefit. It shines where fast failover genuinely matters.
Assuming it checks application health. BFD verifies the forwarding path between two devices, not whether a service beyond them is working. It answers is the path up, not is the application up.
ComparisonBFD next to routing-protocol timers
| Criterion | BFD | Routing-protocol hello timers |
|---|---|---|
| Purpose | Detect a failed path fast | Maintain neighbor relationships |
| Detection speed | Milliseconds | Seconds by default |
| Overhead | Low, small packets | Higher, full protocol messages |
| Protocol scope | Serves many protocols at once | Only its own protocol |
| Reroutes traffic | No, it only signals | Yes, it reconverges |
| Discovery | None, sessions configured | Discovers neighbors |
BFD is the fast detector and the routing protocol is the responder; the table's speed and scope rows are why the two are run together rather than one instead of the other.
FAQFrequently asked questions
What is BFD?
Bidirectional forwarding detection, a lightweight protocol that quickly detects when the forwarding path between two devices has failed. Two devices exchange small control packets in a session, and if the packets stop arriving, the path is declared down in milliseconds.
What does BFD stand for?
Bidirectional Forwarding Detection. The name captures what it does: it checks that traffic can be forwarded in both directions across the path between two devices.
What is BFD in networking used for?
Fast failure detection. It notices a dead path far quicker than a routing protocol's own timers and signals that protocol to reconverge, so traffic is rerouted around the failure in milliseconds rather than seconds.
How does BFD detect a failure?
The two endpoints exchange control packets at a negotiated interval. If a device misses a set number of expected packets in a row, the detect multiplier count, it declares the path down. Detection time is the interval times the multiplier.
Why is BFD faster than OSPF or BGP timers?
Because it does only one thing. With no routing intelligence to run, BFD can send small packets at sub-second intervals cheaply, often in hardware, and detect a break in milliseconds, where routing-protocol dead timers default to seconds.
Does BFD reroute traffic?
No. BFD only detects a failed path and signals the routing protocol. The routing protocol is what tears down the neighbor and reconverges to route around the failure.
Which protocols can use BFD?
OSPF, BGP, EIGRP, IS-IS, HSRP and MPLS, among others. Each can register with a BFD session and be notified immediately of a path failure instead of waiting on its own timers.
Is BFD protocol independent?
Yes. It operates independently of the media, the data protocols, and the routing protocols above it, so a single BFD session can serve whatever is running over the path.
What is the BFD detect multiplier?
The number of consecutive expected packets that must be missed before the path is declared down. Multiplying the transmit interval by the detect multiplier gives the detection time.
What are BFD asynchronous and demand modes?
Asynchronous mode, the primary one, has both sides sending periodic control packets continuously. Demand mode lets them stop the periodic packets once the path is known good to reduce overhead, checking only when needed.
Does BFD need configuration on both ends?
Yes. BFD has no discovery mechanism, so a session must be explicitly configured on both endpoints. A one-sided configuration leaves the session down.
Does BFD check whether an application is working?
No. BFD verifies the forwarding path between two devices, not the health of a service running beyond them. It answers whether the path is up, not whether the application is up.
Keep readingRelated concepts
Read next · Routing OSPF LSA Types, Explained by Who Sends Them and How Far They Flood A routing protocol whose slow dead timer BFD replaces for fast detection. Open this next10 min- Routing · 11 min EIGRP Configuration, and the Feasible Successor Logic That Makes It Work Another routing protocol that leans on BFD for fast failure detection.
- Routing · 11 min HSRP vs VRRP, and What Happens When the Default Gateway Dies First-hop redundancy that can use BFD to fail over faster.