Summary

  • RFC 5880 makes BFD a protocol-independent way to detect faults in a bidirectional forwarding path, potentially with very low latency.
  • The signal is not a route-selection policy: applications create and consume sessions, while aggressive timers impose packet, processing and false-positive costs that operators must govern.

A narrow signal with broad consequences

BFD watches the bidirectional path between two forwarding engines. RFC 5880 says that path can include interfaces, data links and, where possible, the forwarding engines themselves. The protocol is deliberately independent of the medium carrying it, the data protocol being forwarded and the routing protocol that may consume its state.

That narrow scope is the source of its value. A routing protocol does not have to wait for its own slower Hello or dead timer before learning that the path used for forwarding has failed. A service can consume the same underlying session state. Yet BFD does not decide which prefix should move, which next hop should win or whether an application should tear down an adjacency. It reports state; the client retains policy authority.

RFC 5882 draws the line sharply. For an application, BFD exists to verify connectivity between a pair of systems for a particular data protocol over a particular path. It is not intended to prove that the control protocol itself is healthy. A BFD Down event can justify a routing reaction, but it is not evidence that every control-plane process failed or that a particular alternative is safe.

Session creation is an authorization decision

BFD has no discovery mechanism. The application supplies the remote address and other parameters needed to create the session. That means coverage is configured, not inferred: a path that was never bound to a session cannot be protected merely because BFD runs elsewhere on the device.

RFC 5882 also says that multiple clients monitoring the same data-protocol path should share one BFD session. The state therefore becomes a common dependency. One owner must decide which applications may consume it, which address family and path the session represents, and how a session change propagates into different control systems.

Single-hop operation makes those boundaries concrete. RFC 5881 requires distinct sessions for IPv4 and IPv6 when both are monitored over the same path. It also requires received single-hop Control packets to carry TTL or Hop Limit 255, constraining acceptance to a directly connected peer. Authentication can protect Control packets, but deployment and key management remain operator responsibilities.

The compatibility rule is equally important. If a neighbor is believed not to support BFD, RFC 5882 says the control-protocol adjacency should not be blocked solely because BFD is unavailable. BFD is an added failure signal, not permission to make basic connectivity depend on an unsupported feature.

Detection time is purchased with capacity

In Asynchronous mode, each system periodically sends Control packets. If the negotiated number is not received within the detection time, the session goes Down. Demand mode can suppress periodic Control packets after the session is Up, but only when another mechanism independently verifies connectivity. An optional Echo function can test the forwarding path by sending packets that the remote system loops back through its forwarding plane.

Shorter intervals do not create free certainty. RFC 5881 requires careful provisioning so BFD traffic does not congest the link, input queues or the processor handling packets. If the monitoring mechanism overloads the path or device, delayed BFD packets can be interpreted as evidence of the failure the monitor itself helped induce. A fast timer can shorten a real black hole; it can also amplify transient congestion into a route withdrawal or service flap.

RFC 7419 reduces interoperability risk by defining a common set of intervals that implementations can support consistently. That solves an interval-negotiation problem, not the capacity decision. A value supported by two devices is not automatically appropriate for every number of sessions, queue design, failure domain or recovery policy.

Up is not the same as stable

The base BFD state machine considers a session Up when enough Control packets arrive inside the detection window. Isolated losses within that window may not change state. RFC 9978, published as an Experimental specification, adds a way to count missing BFD Control packets through meticulous sequence numbers and a YANG model. The aim is to reveal deterioration before it lasts long enough to declare the session Down.

That extension has strict limits. It measures BFD packet loss, not user-data loss or delay. Equal-cost multipath and link aggregation can reorder packets, so a simple sequence comparison can mistake reordering for loss unless the implementation compensates. The evidence can guide further OAM investigation; it does not identify a root cause on its own.

The distinction creates a useful leadership boundary. Session state answers whether the configured detector has crossed its failure threshold. Stability telemetry can indicate that its own packets are being lost. Neither observation alone proves what every customer flow experienced.

Evidence and limits

RFCs 5880, 5881 and 5882 define the base mechanism, single-hop constraints and application relationship. RFC 7419 standardizes common interval support. RFC 9978 adds an experimental stability measurement.

The sources do not provide a universal safe timer, a current deployment census or vendor-specific performance guarantees. They do not establish that BFD state identifies root cause, and they do not choose a surviving route. Those decisions remain with the operator and the consuming application.

Sources