Configuring Bidirectional Forwarding Detection
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 will cause 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 unsupported by BFD, BFD will be in a down state on that interface. The workaround is to shut down the
interface, change to a supported encapsulation type, and then reconfigure BFD.
A single BFD session can be used by an IPv4 static client to track the reachability of next hops through a
specific interface. You can assign a BFD group for a set of BFD-tracked static routes. Each group must have
one active static BFD configuration, one or more passive BFD configurations, and the corresponding static
routes to be BFD-tracked. Nongroup entries are BFD-tracked static routes for which a BFD group is not
assigned. A BFD group must accommodate static BFD configurations that can be part of different VRFs.
Effectively, the passive static BFD configurations need not be in the same VRF as that of the active
configuration.
For each BFD group, there can be only one active static BFD session. You can configure the active BFD
session by adding a static BFD configuration and a corresponding static route that uses the BFD configuration.
The BFD session in a group is created only when there is an active static BFD configuration and the static
route that uses the static BFD configuration. When the active static BFD configuration or the active static
route is removed from a BFD group, all the passive static routes are withdrawn from the RIB. Effectively, all
the passive static routes are inactive until an active static BFD configuration and a static route to be tracked
by the active BFD session are configured in the group.
Similarly, for each BFD group, there can be one or more passive static BFD configurations and their
corresponding static routes to be BFD-tracked. Passive static session routes take effect only when the active
BFD session state is reachable. Though the active BFD session state of the group is reachable, the passive
static route is added to the RIB only if the corresponding interface state is up. When a passive BFD session
is removed from a group, it will not affect the active BFD session if one existed, or the BFD group reachability
status.
Benefits of Using BFD for Failure Detection
When you deploy any feature, it is important to consider all the alternatives and be aware of any trade-offs
being made.
The closest alternative to BFD in conventional EIGRP, IS-IS, and OSPF deployments is the use of modified
failure detection mechanisms for EIGRP, IS-IS, and OSPF routing protocols.
If you set EIGRP hello and hold timers to their absolute minimums, the failure detection rate for EIGRP falls
to within a one- to two-second range.
If you use fast hellos for either IS-IS or OSPF, these Interior Gateway Protocol (IGP) protocols reduce their
failure detection mechanisms to a minimum of one second.
There are several advantages to implementing BFD over reduced timer mechanisms for routing protocols:
• Although reducing the EIGRP, IS-IS, and OSPF timers can result in minimum detection timer of one
to two seconds, BFD can provide failure detection in less than one second.
• Because BFD is not tied to any particular routing protocol, it can be used as a generic and consistent
failure detection mechanism for EIGRP, IS-IS, and OSPF.
• Because some parts of BFD can be distributed to the data plane, it can be less CPU-intensive than the
reduced EIGRP, IS-IS, and OSPF timers, which exist wholly at the control plane.
Routing Configuration Guide, Cisco IOS XE Everest 16.6.x (Catalyst 9500 Switches)
Information About Bidirectional Forwarding Detection
5