Cisco Bidirectional Forwarding Detection (BFD) Configuration Guide: Enabling Fast Path Failure Detection (EN)

Restrictions for Bidirectional Forwarding Detection

Configuring Bidirectional Forwarding Detection This document describes how to enable the Bidirectional Forwarding Detection (BFD) protocol. BFD is a detection protocol that is designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. BFD provides a consistent failure detection method for network administrators, in addition to fast forwarding path failure detection.

Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates for different routing protocol hello mechanisms, network profiling and planning will be easier, and reconvergence time will be consistent and predictable.

Prerequisites for Bidirectional Forwarding Detection, on page 1 Restrictions for Bidirectional Forwarding Detection, on page 1 Information About Bidirectional Forwarding Detection, on page 2 How to Configure Bidirectional Forwarding Detection, on page 5 Feature History for Configuring Bidirectional Forwarding Detection , on page 22 Prerequisites for Bidirectional Forwarding Detection • All participating switches must enable Cisco Express Forwarding and IP routing. • Before BFD is deployed on a switch, it is necessary to configure one of the IP routing protocols that are supported by BFD. You should implement fast convergence for the routing protocol that you are using.

See IP routing documentation for your version of Cisco IOS software for information on configuring fast convergence. See the "Restrictions for Bidirectional Forwarding Detection" section for more information on BFD routing protocol support in Cisco IOS software. Restrictions for Bidirectional Forwarding Detection • BFD works only for directly connected neighbors. BFD neighbors must be no more than one IP hop away. BFD does not support Multihop configurations. • BFD support is not available for all platforms and interfaces.

To confirm if a specific platform or interface has BFD support and to obtain the most accurate platform and hardware restrictions, see the Cisco IOS software release notes for your software version. • The QoS policy for self-generated packets does not match BFD packets. Configuring Bidirectional Forwarding Detection 1

Стр. 1

Neighbor Relationships

• The class class-default command matches BFD packets. So, you must make sure of the availability of appropriate bandwidth to prevent dropping of BFD packets due to oversubscription. • BFD HA is not supported. • When you use YANG operational models to delete individual BFD interval values, the whole BFD interval configuration gets deleted. Information About Bidirectional Forwarding Detection The following sections provide information about bidirectional forwarding detection. BFD Operation BFD provides a low-overhead, short-duration method of detecting failures in the forwarding path between two adjacent devices. These devices include the interfaces, data links, and forwarding planes.

BFD is a detection protocol that you enable at the interface and routing protocol levels. Cisco supports BFD asynchronous mode. BFD asychronous mode depends on the sending of BFD control packets between two systems to activate and maintain BFD neighbor sessions between devices. Therefore, in order to create a BFD session, you must configure BFD on both systems (or BFD peers). A BFD session is created once BFD is enabled on the interfaces and at the device level for the appropriate routing protocols. BFD timers are negotiated, and the BFD peers begin to send BFD control packets to each other at the negotiated interval.

Neighbor Relationships BFD provides fast BFD peer failure detection times independently. This is independent of all media types, encapsulations, topologies, and routing protocols such as BGP, EIGRP, IS-IS, and OSPF. BFD sends rapid failure detection notices to the routing protocols in the local device to initiate the routing table recalculation process. In this way, BFD contributes to greatly reduced overall network convergence time. The figure below shows a simple network with two devices running OSPF and BFD. When OSPF discovers a neighbor (1), it sends a request to the local BFD process. It initiates a BFD neighbor session with the OSPF neighbor device (2).

The BFD neighbor session with the OSPF neighbor device is established (3). Figure 1: BFD Process on a Network Configured with OSPF The figure below shows what happens when a failure occurs in the network (1). The BFD neighbor session with the OSPF neighbor device is torn down (2). BFD notifies the local OSPF process that the BFD neighbor is no longer reachable (3). The local OSPF process tears down the OSPF neighbor relationship (4). If an alternative path is available, the devices immediately start converging on it. Configuring Bidirectional Forwarding Detection Information About Bidirectional Forwarding Detection Configuring Bidirectional Forwarding Detection 2

Стр. 2

BFD Session Limits

Figure 2: BFD Process During a Network Failure A routing protocol must register with BFD for every neighbor it acquires. Once a neighbor is registered, BFD initiates a session with the neighbor if a session does not already exist. OSPF registers with BFD when: • A neighbor finite state machine (FSM) transitions to full state. • Both OSPF BFD and BFD are enabled. On broadcast interfaces, OSPF establishes a BFD session only with the designated router (DR) and backup designated router (BDR). The session is not established between any two devices in a DROTHER state. BFD Detection of Failures Once a BFD session is established and timer negations are complete, BFD peers send BFD control packets.

The packets act in the same manner as an IGP hello protocol to detect liveliness, except at a more accelerated rate. The following information should be noted: • BFD is a forwarding path failure detection protocol. BFD detects a failure, but the routing protocol must act to bypass a failed peer. • Starting with Cisco IOS XE Denali 16.3.1, Cisco devices support BFD version 0. Devices use one BFD session for multiple client protocols in the implementation. For example, if a network is running OSPF and EIGRP across the same link to the same peer, only one BFD session is established. BFD shares session information with both routing protocols.

BFD Version Interoperability All BFD sessions come up as Version 1 by default and are interoperable with Version 0. The system automatically performs BFD version detection, and BFD sessions between neighbors run in the highest common BFD version between neighbors. For example, if one BFD neighbor is running BFD Version 0 and the other BFD neighbor is running Version 1, the session runs BFD Version 0. The output from the show bfd neighbors [ details ] command verifies which BFD version a BFD neighbor is running. See the "Example Configuring BFD in an EIGRP Network with Echo Mode Enabled by Default" for an example of BFD version detection.

BFD Session Limits Starting with Cisco IOS XE Denali 16.3.1, the number of BFD sessions that can be created has been increased to 100. Configuring Bidirectional Forwarding Detection BFD Detection of Failures Configuring Bidirectional Forwarding Detection 3

Стр. 3

BFD Support for Static Routing

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

Стр. 4