Table of Contents
Advertisement
JUNOSe 11.0.x IP Services Configuration Guide
about configuring BFD for EBGP routes, see Configuring BGP Routing in JUNOSe BGP
and MPLS Configuration Guide.
How BFD Works
In a BFD-configured network, when a client launches a BFD session with a peer, BFD
begins sending slow, periodic BFD control packets that contain the interval values
that you specified when you configured the BFD peers. This is known as the
initialization state and BFD does not generate any up or down notifications in this
state.
When another BFD interface acknowledges the BFD control packets, the session
moves into an up state and begins to more rapidly send periodic control packets.
If a data path failure occurs and BFD does not receive a control packet within the
configured amount of time, the data path is declared down and BFD notifies the BFD
client. The BFD client can then perform the necessary actions to reroute traffic. This
process can be different for different BFD clients. All BFD-configured IGP clients (like
IS-IS, OSPF, PIM, and RIP) launch BFD sessions when they detect neighbors through
their own hello protocols. However, a static BFD client launches a BFD session when
it detects that its next hop is resolved.
The BFD Admin Down state is used to bring down a BFD session administratively,
to protect client applications from BFD configuration removal, license issues, and
clearing of BFD sessions. When BFD enters the Admin Down state, BFD notifies the
new state to its peer for a failure detection time and after the time expires, the client
stops transmitting packets. For the Admin Down state to work, the peer, which
receives the Admin Down state notification, must have the capability to distinguish
between administratively down state and real link down. A BFD session moves to
the Admin Down state under the following conditions:
Negotiation of the BFD Liveness Detection Interval
When you issue the appropriate bfd-liveness-detection command on an IS-IS, OSPF,
RIP, or PIM interface, BFD liveness detection is established with all of its BFD-enabled
peers. When an update is received from a peer if BFD is enabled and if the session
is not already present the local peer attempts to create a BFD session to the remote
peer.
114
Bidirectional Forwarding Detection Overview
When a BFD configuration is removed for the last client tied to a BFD session,
BFD moves to the Admin Down state and communicates the change to the peer
to enable the client protocols to handle this in a seamless manner without going
down.
When a BFD license is removed on the client, it moves to the Admin Down state
and communicates the change to the remote system to enable the client protocols
to handle this in a seamless manner without going down.
When the clear bfd session command is executed, the BFD sessions move to
the Admin Down state before restarting the BFD sessions so that the client
applications are not impacted.
Advertisement
Table of Contents
