Table of Contents
Advertisement
JunosE 11.2.x IP Services Configuration Guide
How BFD Works
Negotiation of the BFD Liveness Detection Interval
108
configuring BFD for EBGP routes, see Configuring BGP Routing in JunosE BGP and MPLS
Configuration Guide.
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:
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.
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.
Each pair of peers negotiates acceptable transmit and receive intervals for BFD packets.
These values can be different on each peer.
Copyright © 2010, Juniper Networks, Inc.
Advertisement
Table of Contents
