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 BFD tracked static routes. 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. The closest alternative to BFD, in conventional 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 Interior Gateway Protocol (IGP) protocols such as IS-IS or OSPF, they 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. How to Configure Bidirectional Forwarding Detection The following sections provide configurational information about bidirectional forwarding detection. Configuring Bidirectional Forwarding Detection Benefits of Using BFD for Failure Detection Configuring Bidirectional Forwarding Detection 5