BFD Support for Nonbroadcast Media Interfaces Starting from Cisco IOS XE Denali 16.3.1, the BFD feature is supported on routed, SVI, and L3 port channels. The bfd interval command must be configured on the interface to initiate BFD monitoring. BFD Support for Nonstop Forwarding with Stateful Switchover Typically, when a networking device restarts, all routing peers of that device detect that the device went down and then came back up. This transition results in a routing flap, which could spread across multiple routing domains. Routing flaps that are caused by routing restarts create routing instabilities, which are detrimental to the overall network performance.
Nonstop forwarding (NSF) helps to suppress routing flaps in devices enabled with stateful switchover (SSO), thus reducing network instability. NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is restored after a switchover. With NSF, peer networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line cards or dual forwarding processors while the standby RP assumes control from the failed active RP during a switchover. One key to NSF operation is the ability of line cards and forwarding processors to remain up through a switchover.
They remain current with the Forwarding Information Base (FIB) on the active RP. In devices that support dual RPs, SSO establishes one of the RPs as the active processor; the other RP is designated as the standby processor. SSO synchronizes information between the active and standby processor. A switchover from the active to the standby processor occurs when the active RP fails, it is removed from the networking device, or it is manually taken down for maintenance. BFD Support for Stateful Switchover The BFD protocol provides short-duration detection of failures in the path between adjacent forwarding engines.
In network deployments that use dual RP routers or switches (to provide redundancy), the routers have a graceful restart mechanism. This mechanism protects the forwarding state during a switchover between the active RP and the standby RP. The dual RPs have variable switchover times that depend on the ability of the hardware to detect a communication failure. When BFD is running on the RP, some platforms are not able to detect a switchover before the BFD protocol times out. These platforms are referred to as slow switchover platforms. BFD Support for Static Routing Unlike dynamic routing protocols, such as OSPF and BGP, static routing has no method of peer discovery.
Therefore, when BFD is configured, the reachability of the gateway depends on the state of the BFD session to the specified neighbor. Unless the BFD session is up, the gateway for the static route is unreachable, and the affected routes are not installed in the appropriate Routing Information Base (RIB). To successfully establish a BFD session, BFD must be configured on the interface on the peer. There must be a BFD client that is registered on the peer for the address of the BFD neighbor. When an interface is used by dynamic routing protocols, the latter requirement is met by configuring the routing protocol instances on each neighbor for BFD.
When an interface is used exclusively for static routing, this requirement must be met by configuring static routes on the peers. If a BFD configuration is removed from the remote peer while the BFD session is in the up state, the updated state of the BFD session is not signaled to IPv4 static. This causes the static route to remain in the RIB. The only workaround is to remove the IPv4 static BFD neighbor configuration so that the static route no longer tracks BFD session state.
Also, if you change the encapsulation type on a serial interface to one that is Configuring Bidirectional Forwarding Detection BFD Support for Nonbroadcast Media Interfaces Configuring Bidirectional Forwarding Detection 4