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 reconvergence
time is consistent and predictable. The main benefit of implementing BFD for
BGP is a significantly faster reconvergence time. For internal BGP (iBGP)
sessions and external BGP (eBGP) sessions that are either single hop or
multihop, BGP can use of the multihop BFD support to help improve the BGP
convergence because BFD detection and failure times are faster than the IGP
convergence times in most of the network topologies. BGP needs the support of
multihop BFD as described in RFC5882,
Generic Application
of Bidirectional Forwarding Detection (BFD).
BGP by default will
purge the routes received from a specific peer when a BFD down event occurs and
BFD informs BGP about it. The cBit 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 cBit support to
provide a more deterministic mechanism to do nonstop forwarding (NSF) when BGP
graceful restart is enabled along with BFD fast-fallover support for BGP
sessions.
When BGP is using BFD
for the fast fallover 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. 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.
The table below
describes the handling of BFD down events by BGP.
Table 1. BGP handling of BFD Down
Event
|
BFD Down Event
|
Failure—Control Plane Independent?
|
BGP Action for
NSF (when GR and BFD are enabled)
|
|
BGP control
plane detection failure enabled
|
Yes
|
Purge Routes
|
|
BGP control
plane detection failure enabled
|
No
|
Carry on NSF
and keep stale routes in Routing Information Base (RIB)
|
|
BGP control
plane detection failure disabled (the default behavior)
|
Yes
|
Purge Routes
|
|
BGP control
plane detection failure disabled (the default behavior)
|
No
|
Purge Routes
|
BGP session establishment works independently from BFD state change,
except for fast fall-over detection, that is, inaccessible next-hop and cause
best path re-calculation. This means that the BGP session could be established
while BFD state is down or dampened, even with
neighbor fail-over bfd configured.
From the XE 3.17S release the new optional keyword
strict-mode is introduced, which does not allow BGP
session to become established, if BFD is in down state. When BFD is dampened or
down the routing protocol states or sessions cannot come up.
Feedback