Bidirectional Forwarding Detection Overview

Fast failure detection is a high priority feature for any network element. Some media, like Ethernet, do not provide remote end failure. Networks must often rely on internal gateway protocol (IGP) hello messages to detect any failure and, in some cases (for example, static routes), even these hello messages are not used.

IGP hellos have their own limitations—it often takes one second or more to detect a remote end failure and processing IGP hello messages takes precious processing time. BFD overcomes IGP detection time and processing limitations in detecting any data path failures.

When configured for various protocols like OSPF and IS-IS, BFD employs rapid, periodic and inexpensive hello messages to detect path activity. You can also configure BFD to function with static routes, combining with the BFD poll bit to detect path activity.

You can also configure a BFD session with a BGP neighbor or peer group to determine relatively quickly whether the neighbor or peer group is reachable. For information 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.

Each pair of peers negotiates acceptable transmit and receive intervals for BFD packets. These values can be different on each peer.

The negotiated transmit interval for a peer is the interval between the BFD packets that it sends to its peers. The receive interval for a peer is the minimum time that it requires between packets sent from its peer; the receive interval is not negotiated between peers.

To determine the transmit interval, each peer compares its configured minimum transmit interval with its peer's minimum receive interval. The larger of the two numbers is accepted as the transmit interval for that peer.

Consider the following example. Router A and Router B are peers, with the following BFD liveness detection values configured.


Configured Transmit Interval (ms)

Configured Receive Interval (ms)







The liveness detection interval is the period a peer waits for a BFD packet from its peer before declaring the BFD session to be down. The detection interval is determined independently by each peer and can be different for each. The detection interval for the local peer is calculated as the remote peer's negotiated transmit interval times the detection multiplier value configured on the remote peer.


Negotiated Transmit Interval (ms)

Detection Multiplier

Liveness Detection Interval (ms)









If Router A fails to receive a BFD packet from Router B within 1500 milliseconds, Router A declares the BFD session to be down. Similarly, if Router B fails to receive a BFD packet from Router A within 900 milliseconds, Router B declares the BFD session to be down. In either case, all routes learned from the failed peer are purged immediately.

Note: Before the router can use any bfd-liveness-detection command, you must specify a BFD license key. To view an already configured license, use the show license bfd command.

Note: During a stateful SRP switchover, the BFD transmit interval is set to 1000 ms with a detection multiplier of 3. These values result in a liveness detection interval of 3000 ms. This longer interval helps prevent a BFD timeout during the switchover. BFD negotiates the interval with the remote peer before applying the temporary change. The BFD timers revert back to the configured values after 15 minutes (the maximum duration for graceful restart completion).