Considerations for Configuring BFD for Layer 3 Protocols

There are several points to consider when configuring BFD for Layer 3 protocols.

• BFD supports single-hop and multihop sessions.
• For single-hop sessions, the IP address that matches the subnet of the destination IP address is always used as the source IP address of the BFD control packet. If the source IP address is changed, the session is brought down unless another corresponding address with the same subnet is available.
• For single-hop sessions, an IPv6 address that matches the prefix and scope of the destination IPv6 address is used as the source IPv6 address of the BFD control packet.
• For multihop sessions, BFD clients provide the source IP address and the Layer 3 protocol is notified of any change to the source IP address of the BFD control packet.
• Multicast or anycast address IP addresses cannot be used as source IP addresses.
• BFD establishes only one BFD session per data protocol path (IPv4 or IPv6) regardless of the number of protocols that want to use it.
• If a Layer 3 interface is configured, BFD is enabled by default on the interface (IPv4 or IPv6 ).
• Registration is global across all VRFs, even if a neighbor does not support BFD.
• Inactive sessions are created when BFD is not enabled on a remote device that contains the destination IP address. These sessions are in the Admin Down state and are transmitted at a slower rate than configured values.
• BFD sessions can be established on link-local IPv6 addresses.
• Changing the BFD parameters does not reset the current BFD session.
• When BFD notifies BGP or OSPF that a session has transitioned from up to down, the protocol does not immediately bring down the session if the holdover timer is configured. The protocol waits until the holdover interval expires. If BFD declares a session up before this interval expires, no action is taken by the protocol.
• If you unconfigure a BFD session that is in the up state, OSPF or BGP tells BFD to delete the session and set the reason as Admin Down. Upon receiving this notification, BFD deletes the session and communicates this change to the remote BFD peer. The remote BFD neighbor keeps the session in the down state and propagates a Remote Admin Down event to the routing protocols.