Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

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. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. 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 is easier, and reconvergence time is consistent and predictable. The main benefit of implementing BFD for BGP is a significantly faster reconvergence time. For internal BGP (iBGP) sessions and external BGP (eBGP) sessions that are either single hop or multihop, BGP can use of the multihop BFD support to help improve the BGP convergence because BFD detection and failure times are faster than the IGP convergence times in most of the network topologies. BGP needs the support of multihop BFD as described in RFC5882, Generic Application of Bidirectional Forwarding Detection (BFD).

BGP by default will purge the routes received from a specific peer when a BFD down event occurs and BFD informs BGP about it. The cBit in BFD determines whether BFD is dependent or independent of the Control Plane. Clients like BGP, whose peers are enabled with fast fall over feature with BFD support, can use this BFD cBit support to provide a more deterministic mechanism to do nonstop forwarding (NSF) when BGP graceful restart is enabled along with BFD fast-fallover support for BGP sessions.

When BGP is using BFD for the fast fallover feature for remote connectivity detection, BFD can detect some of those failures. If BFD is independent of the control plane, a BFD session failure means that data cannot be forwarded anymore (due to link control failures) and so the BGP graceful restart procedures should be aborted to avoid traffic black holes. On the other hand, when BFD is dependent on the control plane, a BFD failure cannot be separated out from the other events taking place in the control plane. When the control plane crashes, a switchover happens and BFD restarts. It is best for the clients (like BGP) to avoid any aborts due to the graceful restart taking place.

The table below describes the handling of BFD down events by BGP.

BGP session establishment works independently from BFD state change, except for fast fall-over detection, that is, inaccessible next-hop and cause best path re-calculation. This means that the BGP session could be established while BFD state is down or dampened, even with neighbor fail-over bfd configured.

From the XE 3.17S release the new optional keyword strict-mode is introduced, which does not allow BGP session to become established, if BFD is in down state. When BFD is dampened or down the routing protocol states or sessions cannot come up.

Before You Begin

Note	The multihop BFD minimum detection time should be higher than IGP convergence times in your network to ensure that down events are not mistakenly identified during reconvergences, causing multihop BGP sessions to flap.

1.    enable


2.    configure terminal


3.    router bgp autonomous-system-number


4.    neighbor ip-address remote-as autonomous-system-number


5.    neighbor ip-address update-source interface-type interface-number


6.    neighbor ip-address remote-as autonomous-system-number


7.    neighbor ip-address ebgp-multihop ttl


8.    neighbor ip-address fall-over bfd [multi-hop|single-hop] [check-control-plane-failure] [ strict-mode]


9.    end

Device> enable

Device# configure terminal

Device(config)# router bgp 50000

Device(config-router)# neighbor 10.0.0.2 remote-as 100

Device(config-router)# neighbor 10.0.0.2 update-source GigabitEthernet 0/0/0

Device(config-router)# neighbor 10.0.0.2 remote-as 100

Device(config-router)# neighbor 10.0.0.2 ebgp-multihop 4

Device(config-router)# neighbor 10.0.0.2 fall-over bfd multi-hop|single-hop check-control-plane-failure strict-mode

Device(config-router)# end

The following examples show how to verify if BFD is enabled on the neighbor, peer-group.

R801-ASBR#sh ip bgp neighbor 11.1.0.2
BGP neighbor is 11.1.0.2,  remote AS 65000, external link
 Fall over configured for session
BFD is configured. BFD peer is Up. Using BFD to detect fast fallover (single-hop) in strict-mode.
  BGP version 4, remote router ID 10.10.10.10
  BGP state = Established, up for 00:04:12
  Last read 00:00:49, last write 00:00:24, hold time is 180, keepalive interval is 60 seconds
…

If BFD is up and running, the following is displayed:

Fall over configured for session
BFD is configured. BFD peer is Up. Using BFD to detect fast fallover (single-hop) in strict-mode (will be verified).
…

If BFD is not up and running, the following is displayed:

Fall over configured for session
 BFD is configured. BFD peer is Down. Using BFD to detect fast fallover (single-hop) in strict-mode.