Shorter BFD timers are not automatically more resilient. A timer profile that exceeds forwarding-engine or control-plane capacity can create false failures, route churn, and a larger outage than the slow failure detection it was meant to improve.
\nIETF RFC 5880 defines Bidirectional Forwarding Detection as a protocol for detecting faults in the bidirectional path between two forwarding engines. It is designed to provide potentially low-latency detection independently of a particular media type or routing protocol. BFD peers exchange control packets and use negotiated transmission and detection parameters to decide when a session is no longer operational.
\nThe specification defines asynchronous operation, a demand mode, session state, diagnostic codes, and the relationship between desired transmit intervals, required receive intervals, and detection multipliers. The protocol reports path liveness to its client, such as a routing protocol. It does not itself calculate a new route or prove that an application has recovered.
\nActual timer granularity, session scale, hardware offload, queue treatment, link aggregation behavior, and reaction by routing protocols are implementation-specific. Congestion or a busy control plane can look like a path failure. A BFD session may cover a particular forwarding path while application traffic takes another because of hashing or policy. Authentication and exposure should be assessed for the deployment rather than inferred from the existence of the session.
\nStart with a service recovery objective and work backward through route-convergence time to the needed detection interval. Consult the exact platform’s scale guidance and establish a conservative standard profile for each link class. Avoid one global minimum across branch, campus, data-center, overlay, and carrier paths.
\nIn a controlled environment, test physical loss, one-way impairment, packet loss, delay, congestion, and peer restart. Increase session counts to a representative level while monitoring CPU, forwarding resources, BFD packet loss, and routing churn. Confirm how the routing client responds and whether a backup path is genuinely usable. Document maintenance procedures that prevent intentional work from generating unnecessary instability.
\nKeep the timer rationale, device and software matrix, supported-scale documentation, session inventory, resource telemetry, impairment settings, BFD diagnostics, routing-event timestamps, and application probes. Evidence should separately show detection time, route-selection time, and end-to-end restoration time. Establish alerts for unexpected session flapping and periodically compare deployed profiles with the approved standard.
\n