BGP Protocol: BFD C Bit Feature

 Today I am going to talk about the use of "C Bit Feature with BGP". The C Bit 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 C Bit support to provide a more deterministic mechanism to do nonstop forwarding (NSF) when BGP graceful restart is enabled along with BFD fast failover support for BGP sessions.

When BGP is using BFD for the fast failover 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. 

Fig 1.1- BFD Sessions

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.

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 re-convergence time is consistent and predictable. 

The Echo function MUST NOT be used over multiple hops. Intermediate hops would route the packets back to the sender, and connectivity through the entire path would not be possible to verify.

Restriction
BGP session attribute for BFD does not change dynamically when BGP session changes from single-hop to multi-hop, hence you need to clear the existing BGP session to re-initiate multi-hop BFD session.

The multi-hop BFD minimum detection time should be higher than IGP convergence times in your network to ensure that down events are not mistakenly identified during re-convergences, causing multi-hop BGP sessions to flap.

For BGP IPv4 and BGP IPv6 peering sessions only, multi-hop BFD support is available for BGP for address-family IPv4 and IPv6 unicast.

For multi-hop BGP sessions using IPv6 Link Local addresses, BFD multi-hop support is not available.

Currently BFD Hardware offload is not supported for multi-hop BFD sessions and so C-bit will not be set for multi-hop sessions.

Multi-hop BFD for IPv6 Virtual Routing and Forwarding (VRF) is not supported. BGP session attribute for BFD does not change dynamically when BGP session changes from single-hop to multi-hop, hence you need to clear the existing BGP session to re-initiate multi-hop BFD session.

Verify : show commands
The client must support multihop. A valid multihop template and map must be configured.Each BFD multihop session must have a unique source-destination address pair.

   Configurations