BFD for BGP
BGP periodically sends Keepalive messages to a peer to monitor its status, but this mechanism takes an excessively long time, more than 1 second, to detect a fault. If data is transmitted at Gbit/s rates and a link fault occurs, such a lengthy detection period will result in a large amount of data being lost, making it impossible to meet the high reliability requirements of carrier-grade networks.
To address this issue, BFD for BGP has been introduced. Specifically, BFD is used to quickly detect faults on links between BGP peers (usually within milliseconds) and notify BGP of the faults, thereby accelerating BGP route convergence.
Fundamentals
On the network shown in Figure 1, DeviceA and DeviceB belong to AS 100 and AS 200, respectively. An EBGP connection is established between the two devices.
BFD is used to monitor the BGP peer relationship between DeviceA and DeviceB. If the link between them becomes faulty, BFD can quickly detect the fault and notifies BGP.
On the network shown in 2, indirect multi-hop EBGP connections are established between DeviceA and DeviceC and between DeviceB and DeviceD; a BFD session is established between DeviceA and DeviceC; a BGP peer relationship is established between DeviceA and DeviceB; the bandwidth between DeviceA and DeviceB is low. If the original forwarding path DeviceA->DeviceC goes faulty, traffic that is sent from DeviceE to DeviceA is switched to the path DeviceA->DeviceB->DeviceD->DeviceC. Due to low bandwidth on the link between DeviceA and DeviceB, traffic loss may occur on this path.
BFD for BGP TTL check applies only to the scenario in which DeviceA and DeviceC are indirectly connected EBGP peers.
To prevent this issue, you can set a TTL value on DeviceC for checking the BFD session with DeviceA. If the number of forwarding hops of a BFD packet (TTL value in the packet) is smaller than the TTL value set on DeviceC, the BFD packet is discarded, and BFD detects a session down event and notifies BGP. DeviceA then sends BGP Update messages to DeviceE for route update so that the traffic forwarding path can change to DeviceE->DeviceF->DeviceB->DeviceD->DeviceC. For example, the TTL value for checking the BFD session on DeviceC is set to 254. If the link between DeviceA and DeviceC fails, traffic sent from DeviceE is forwarded through the path DeviceA->DeviceB->DeviceD->DeviceC. In this case, the TTL value in a packet decreases to 252 when the packet reaches DeviceC. Since 252 is smaller than the configured TTL value 254, the BFD packet is discarded, and BFD detects a session down event and notifies BGP. DeviceA then sends BGP Update messages to DeviceE for route update so that the traffic forwarding path can change to DeviceE->DeviceF->DeviceB->DeviceD->DeviceC.