]> China Mobile

Beijing100053 China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing100053 China duzongpeng@chinamobile.com

Centec

Shanghai201203 China wangjj@centec.com

Centec

Shanghai201203 China chengw@centec.com

Centec

Shanghai201203 China zhanggy@centec.com

Inesa

Shanghai200030 China sunxun@inesa.com

SAIA

Shanghai200125 China chunhao.zhao@sh-aia.com

RTG BFD BFD Bidirectional Forwarding Detection redundant control plane switchover high availability In systems with redundant control plane processors, Bidirectional Forwarding Detection (BFD) sessions are typically managed by a single active processor. When that processor fails and a standby takes over, BFD sessions may be interrupted long enough for remote peers to declare failure, even though the forwarding plane remains operational. This document describes requirements and operational considerations for preserving BFD sessions across control plane switchover events. It discusses how BFD session state can be maintained on a standby processor and how BFD processing can be resumed by the standby within the BFD Detection Time, without requiring cooperation from or signaling to remote BFD peers.

Introduction Bidirectional Forwarding Detection (BFD) provides a low-overhead mechanism for detecting forwarding path failures between adjacent systems. BFD is widely deployed in conjunction with routing protocols such as OSPF, IS-IS, and BGP to trigger rapid convergence upon link or node failure. Many network devices employ redundant control plane architectures to improve availability. Common examples include routers with dual Route Processors (RPs), switch stacking topologies, Virtual Chassis systems, and chassis with redundant Supervisor modules. In these systems, one control plane processor is active while one or more standby processors are available to take over upon failure. In typical deployments, BFD sessions are managed entirely by the active processor: the BFD state machine, timers, and packet processing all reside there. When the active processor fails and control transitions to a standby, BFD sessions must be re-established. This re-establishment time frequently exceeds the BFD Detection Time (the product of the negotiated transmit interval and the detection multiplier, as defined in ), causing the remote BFD peer to declare failure. The result is unnecessary routing reconvergence and transient traffic disruption, even when the forwarding plane remains fully operational. The interactions between BFD and Graceful Restart (GR) described in Section 4.3 of address BFD behavior during control protocol restarts, but rely on explicit signaling by the restarting system and cooperation from remote peers in helper mode. Not all control protocols support planned restart signaling, and GR cannot protect against all unplanned failure scenarios. This document describes an approach in which BFD session state is maintained on the standby processor and BFD processing is resumed there before the remote peer's Detection Time expires. Because this operates entirely within the local system, the remote BFD peer is unaware of the switchover, and no protocol extensions or new BFD packet formats are introduced. This document does not address forwarding plane failures, link-level failures, or data plane issues, which are detected by normal BFD operation as defined in . The considerations in this document are also distinct from Seamless BFD (S-BFD) , which defines an initiator/responder model for unidirectional path monitoring.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms. BFD-specific terms such as Detection Time, Discriminator, and state machine variables are defined in .

Active Processor:

The control plane processor in a redundant system that is currently running the BFD state machine, managing BFD session timers, and processing BFD control packets for all locally-owned sessions.

Standby Processor:

A control plane processor in a redundant system that is available to take over BFD session processing from the active processor. During normal operation, the standby processor does not run BFD timers or generate BFD control packets.

Switchover:

The event in which BFD session processing transitions from the active processor to a standby processor, which then becomes the new active processor. A switchover may be planned (e.g., administrative action) or unplanned (e.g., processor failure).

System Model This document considers systems with the following characteristics:

• Two or more control plane processors, each capable of running BFD.
• A shared forwarding plane that continues to operate during control plane switchover.
• An internal communication path between processors with sufficient bandwidth and reliability to carry BFD session state.

Such systems include routers with redundant Route Processors, switch stacking topologies, Virtual Chassis configurations, and chassis with redundant Supervisor modules. At any point in time, exactly one processor is active for any given BFD session. This invariant MUST be maintained: there MUST NOT be a period during which two processors simultaneously run timers or transmit BFD control packets for the same session.

Maintaining BFD State on the Standby Processor To enable the standby processor to resume BFD processing after switchover, the active processor MUST keep the standby informed of current BFD session state. The following session variables, as defined in Section 6.8.1 of , MUST be available on the standby processor:

• bfd.LocalDiscr and bfd.RemoteDiscr
• bfd.SessionState and bfd.RemoteSessionState
• bfd.LocalDiag
• bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval
• bfd.RemoteMinRxInterval
• bfd.DemandMode and bfd.RemoteDemandMode
• bfd.DetectMult
• bfd.AuthType, and when authentication is enabled, bfd.RcvAuthSeq and bfd.XmitAuthSeq

The state on the standby processor MUST be sufficiently current that BFD processing can be resumed without the remote peer detecting a discontinuity. In particular, the standby's copy of session state MUST NOT lag behind the active processor by more than one BFD transmission interval. The specific method used to keep the standby processor informed is an implementation choice. Possible approaches include shared memory between processors on the same board, inter-processor messaging over a backplane, checkpoint-based periodic synchronization, or any other suitable internal transport. This document does not prescribe a particular method. While the standby processor holds copies of BFD session state, it MUST NOT run BFD state machine timers, transmit BFD control packets, or otherwise actively participate in BFD sessions. The standby MUST be ready to begin active BFD processing at any time upon becoming the active processor.

Switchover Behavior When a switchover occurs (whether planned or due to failure), the system MUST ensure that BFD processing resumes on the newly active processor before the remote peer's Detection Time expires. The following requirements apply.

Packet Delivery Incoming BFD control packets MUST be delivered to the processor that is currently active for the corresponding BFD session. The system MUST be capable of redirecting BFD packet delivery to the newly active processor as part of the switchover. If the system's forwarding plane can receive BFD packets on behalf of multiple processors (e.g., in a stacking topology where different member switches have physical ports), then the system MUST ensure that BFD packets received on any port are delivered to the currently active processor, regardless of which physical member receives the packet.

Resuming BFD Processing Upon becoming the active processor, the newly active processor MUST begin running the BFD state machine for each session using the most recently available session state. Specifically:

• BFD control packets transmitted by the newly active processor MUST use the same bfd.LocalDiscr, bfd.RemoteDiscr, and bfd.SessionState values that were in use by the former active processor. From the remote peer's perspective, there MUST be no observable change in these values.
• The transmit interval MUST be set to the previously negotiated bfd.DesiredMinTxInterval.
• The Detection Time calculation MUST continue using the previously negotiated parameters.
• If BFD authentication is enabled (as specified in Section 6.7 of ), the newly active processor MUST continue the authentication sequence from the values maintained on the standby. For Meticulous Keyed modes, the sequence number used in the first transmitted packet MUST be the successor of the most recently transmitted sequence number.

Former Active Processor If the former active processor is still partially operational during a planned switchover, it MUST cease all BFD timer processing and packet transmission before the newly active processor begins transmitting. This prevents duplicate packets and conflicting state transitions. If the former active processor has failed completely, this condition is inherently satisfied.

Timing Requirements For BFD sessions to survive a switchover, the newly active processor MUST transmit a valid BFD control packet before the remote peer's Detection Time expires. The Detection Time is defined in Section 6.8.4 of as the product of the remote peer's bfd.RequiredMinRxInterval (or the negotiated transmit interval) and bfd.DetectMult. Because BFD transmissions from the local system cease during the switchover interval, and the remote peer's Detection Timer continues to run, the total time consumed by the switchover -- including redirecting packet delivery, loading session state on the new processor, and transmitting the first BFD packet -- MUST be less than the remaining time on the remote peer's Detection Timer. In practice, the switchover time SHOULD be significantly shorter than the Detection Time to account for scheduling variance and processing delays. A switchover that completes within a small fraction of the Detection Time provides adequate margin for reliable operation.

Applicability

BFD Session Types The approach described in this document applies to BFD sessions operating in Asynchronous mode, which is the most widely deployed operational mode. Sessions using Demand mode MAY also benefit, although the timing considerations differ because the remote peer does not maintain a continuous Detection Timer in Demand mode. BFD Echo mode operates in the forwarding plane and is typically unaffected by control plane switchover. The considerations in this document generally do not apply to the Echo function. The approach applies to both single-hop BFD sessions and multihop sessions. The specific BFD encapsulation does not affect the requirements described here. For BFD sessions associated with Link Aggregation Groups as described in , session state for each per-member-link BFD session (micro-BFD session) MUST be individually maintained on the standby. All micro-BFD sessions associated with a LAG MUST be covered by the switchover.

Relationship to BFD Graceful Restart The approach described in this document operates entirely within the local system and does not require remote peer awareness or cooperation. In contrast, the BFD interactions with Graceful Restart described in rely on the remote peer entering helper mode and on control-protocol-level restart signaling. The two approaches are complementary. A system MAY implement both: using standby-based BFD state maintenance for local recovery, while also signaling GR capability for interoperability with peers that support it. When both are present, the local switchover can provide sub-Detection-Time recovery independent of whether the remote peer supports GR. If a system successfully preserves BFD sessions across switchover as described in this document, the Control Plane Independent (C) bit in the BFD control packet (Section 4.3 of ) accurately reflects that BFD is not sharing fate with the control plane, since BFD processing survives the control plane restart.

Manageability Considerations Implementations supporting BFD across redundant control planes SHOULD provide the following operational visibility:

• An indication of whether BFD session state is currently being maintained on the standby processor for each session, and whether the standby state is current.
• Counters tracking the number of switchover events that occurred and whether BFD sessions were preserved during each event.
• Notifications when the state on the standby processor falls behind the active processor by more than a configurable threshold.
• A mechanism to administratively enable or disable BFD state maintenance on the standby, on a per-session or system-wide basis.

Security Considerations Maintaining BFD session state on a standby processor introduces an internal communication path that carries sensitive information including discriminator values and, when authentication is enabled, authentication sequence numbers and keying material. The internal communication path between processors MUST be protected against unauthorized modification. An attacker who can alter session state on the standby could cause BFD sessions to fail upon switchover or could prevent legitimate failure detection by injecting false state. If BFD authentication is in use, compromise of replicated authentication state could enable session spoofing. When the communication path between processors traverses media that may be subject to interception or modification -- for example, a backplane fabric accessible to line cards running third-party software -- the path SHOULD be protected using integrity and confidentiality mechanisms such as MACsec or IPsec . When the path is entirely within a trusted hardware boundary (e.g., shared memory on the same board), hardware-level access controls MAY be sufficient. Switchover is time-critical. If the newly active processor is unable to begin BFD processing promptly -- for instance, due to a denial-of-service condition exhausting CPU resources -- BFD sessions will time out despite having state available. Implementations SHOULD ensure that switchover-related BFD processing is appropriately prioritized and isolated from general-purpose control plane tasks.

IANA Considerations This document has no IANA actions.

IEEE

Acknowledgements The authors would like to thank the members of the BFD Working Group for their review and feedback.