Summary

  • BFD is a fast, protocol-independent liveness test for one provisioned data-protocol path; the session is bound to its endpoints, encapsulation and parameters.
  • An Up state does not show that every ECMP member, address family, route, MTU or application transaction follows the same working path.
  • A service claim needs a joined receipt: BFD identity and timers, route and FIB state, member coverage, bidirectional service-sized probes and an application result.

The green signal and the black-holed flow

Imagine a maintenance window ending with every routing adjacency restored. The dashboard shows BFD Up on the customer-facing next hop, so the change is closed. Minutes later, large customer transfers still stall. Small probes hash onto one healthy member of a bundle; some production flows select a different member whose forwarding entry or MTU handling is wrong.

Nothing in that scene makes BFD dishonest. The mistake is expanding the scope of its observation. The green state belongs to a particular session and the path exercised by its packets. “The service is reachable” is a larger claim about routes, forwarding choices, both directions, packet sizes and the application itself.

RFC 5880 gives BFD a deliberately narrow job: detect faults in the bidirectional path between two forwarding engines, including links and, where possible, the forwarding engines. It operates independently of the media and routing protocol. That independence makes it fast and reusable, but it also means operators must record which client and which path the session is advising.

The binding matters. BFD has no discovery mechanism. An application decides that a session is needed and supplies its addresses and parameters. The standard creates a separate session for each communications path and data protocol. A tunnel, an MPLS LSP, a physical link and a multihop route can each carry BFD, but the meaning of a result stays attached to that encapsulation.

What Up actually records

In asynchronous mode, systems send BFD Control packets periodically. Missing enough packets drives a failure decision. In demand mode, periodic control exchange can stop because another mechanism is expected to verify connectivity; an explicit Poll sequence can request a check. The optional Echo function sends packets that the far system loops through its forwarding path.

Those modes do not produce interchangeable evidence. Echo can expose some forwarding failures that a control exchange misses. A demand-mode session depends on an independent verification mechanism. A control-plane implementation may share fate with routing processes, while a forwarding-plane implementation can advertise that it is control-plane independent through the C bit. An operator who stores only state=Up discards the facts needed to interpret the state.

The timers are part of the claim as well. Desired transmit interval, required receive interval and detection multiplier determine how quickly absence becomes Down in asynchronous mode. Up at 10:00 says that the negotiated state machine had not declared failure then. It does not promise that a fault cannot occur at 10:00:01, nor that a client protocol has installed the intended response.

RFC 5881 makes the scope concrete for single-hop IPv4 and IPv6. The session is bound to a remote system, interface and protocol. IPv4 and IPv6 on the same link require separate sessions. Multiple sessions protect distinct network-layer paths; duplicating a session over the same path adds no new path evidence.

The same document calls BFD an operations, administration and maintenance mechanism for network connectivity and connection verification. It also states that ordinary BFD is not an application-to-application failure detector across the Internet. Its traffic lacks the congestion behaviour required for that role. A BFD packet reaching a neighbor is not a checkout, DNS lookup or file transfer completing for a user.

The client decides what the signal changes

RFC 5882 describes BFD as advisory. Routing and other clients receive state and use their own mechanisms to react. BFD does not carry application-specific information. A transition may cause a route to be withdrawn quickly, but the client still owns adjacency, topology and forwarding decisions.

Even the event history may be filtered. An implementation may hide a rapid Up/Down/Up transition from clients through hysteresis. AdminDown communicates administrative intent and is not, by itself, a statement that the data path failed. Current state, transition history, notification policy and the client action are therefore separate records.

This is why end-to-end verification cannot be inferred from one dashboard cell. ECMP can send BFD and user flows to different members. A small control packet may pass where a service-sized packet is dropped by an MTU or encapsulation error. The reverse path can fail independently. A route may exist in the RIB but not the intended FIB, or an application may reject traffic after the network delivers it.

Sources