Understanding How BFD Detects Network Failures

The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. A pair of routing devices exchange BFD packets. The devices send hello packets at a specified, regular interval. The device detects a neighbor failure when the routing device stops receiving a reply after a specified interval.

• Benefits
• Types of BFD Sessions
• Single-Hop and Multihop BFD

Starting in Junos OS Release 24.3R1, we’ve introduced distributed mode for BFD (Bidirectional Forwarding Detection) failure detection on vSRX 3.0. With this support, we've also added the dedicated offload CPU feature on vSRX 3.0. The dedicated offload CPU feature reschedules a flow thread and uses the DPDK flow filters on the NIC to move high priority packets (BGP, RIPv2, OSPF, PIM, Multicast, IGMP, Single-Hop BFD, and Multihop BFD) onto the dedicated flow thread. With this, feature packets are processed by their own dedicated flow thread or queue, even in cases where the forwarding plane is oversubscribed and dropping packets.

Because an entire flow thread is removed from forwarding traffic, you might observe a reduction in packet throughput and this performance impact is more pronounced in smaller vSRX 3.0 deployments.

To enable the dedicated offload CPU feature on vSRX 3.0, run the set security forwarding-options dedicated-offload-cpu command.

When you configure this feature, the following warning message is displayed in the syslog output: Warning, you have enabled dedicated-offload-cpu, this will have a performance impact.

Without a dedicated offload CPU, in cases of oversubscription, where either memory or CPU thresholds are reached on the Packet Forwarding Engine and packets are being dropped, the Fast BFD packets might also be dropped, leading to BFD flapping.

To view the Packet Forwarding Engine’s current dedicated offload CPU status use the show security forward-options dedicated-offload-cpu command. This command displays whether the Packet Forwarding Engine has dedicated offload CPU feature enabled or disabled.

• Benefits
• Dedicated Offload CPU Limitations for vSRX 3.0
• Distributed Configuration and Support

We support two types of inline BFD: inline BFD and hardware-assisted inline BFD. Inline BFD sessions run on the FPC software. Hardware-assisted inline BFD sessions run on the ASIC firmware. Support depends on your device and software version.

• Benefits
• Inline BFD
• Hardware-Assisted Inline BFD
• Configuration

BFD session damping lets you prevent excess BFD flap notifications by damping BFD session state changes for a configured time period if defined thresholds are exceeded.

• Benefits
• Overview
• Configuration

The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. BFD works with a wide variety of network environments and topologies. A pair of routing devices exchanges BFD packets. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. The BFD failure detection timers have shorter time limits than the static route failure detection mechanisms, so they provide faster detection.

The BFD failure detection timers can be adjusted to be faster or slower. The lower the BFD failure detection timer value, the faster the failure detection and vice versa. For example, the timers can adapt to a higher value if the adjacency fails (that is, the timer detects failures more slowly). Or a neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (Rx) interval by two if the local BFD instance is the reason for the session flap. The transmission (Tx) interval is increased by two if the remote BFD instance is the reason for the session flap. You can use the clear bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on the routing device.

By default, BFD is supported on single-hop static routes.

To enable failure detection, include the bfd-liveness-detection statement in the static route configuration.

In Junos OS Release 9.1 and later, the BFD protocol is supported for IPv6 static routes. Global unicast and link-local IPv6 addresses are supported for static routes. The BFD protocol is not supported on multicast or anycast IPv6 addresses. For IPv6, the BFD protocol supports only static routes and only in Junos OS Release 9.3 and later. IPv6 for BFD is also supported for the eBGP protocol.

To configure the BFD protocol for IPv6 static routes, include the bfd-liveness-detection statement at the [edit routing-options rib inet6.0 static route destination-prefix] hierarchy level.

In Junos OS Release 8.5 and later, you can configure a hold-down interval to specify how long the BFD session must remain up before a state change notification is sent.

To specify the hold-down interval, include the holddown-interval statement in the BFD configuration. You can configure a number in the range from 0 through 255,000 milliseconds. The default is 0. If the BFD session goes down and then comes back up during the hold-down interval, the timer is restarted.

To specify the minimum transmit and receive intervals for failure detection, include the minimum-interval statement in the BFD configuration.

This value represents both the minimum interval after which the local routing device transmits hello packets and the minimum interval after which the routing device expects to receive a reply from the neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. Optionally, instead of using this statement, you can configure the minimum transmit and receive intervals separately using the transmit-interval minimum-interval and minimum-receive-interval statements.

To specify the minimum receive interval for failure detection, include the minimum-receive-interval statement in the BFD configuration. This value represents the minimum interval after which the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number in the range from 1 through 255,000 milliseconds. Optionally, instead of using this statement, you can configure the minimum receive interval using the minimum-interval statement at the [edit routing-options static route destination-prefix bfd-liveness-detection] hierarchy level.

To specify the number of hello packets not received by the neighbor that causes the originating interface to be declared down, include the multiplier statement in the BFD configuration. The default value is 3. You can configure a number in the range from 1 through 255.

To specify a threshold for detecting the adaptation of the detection time, include the threshold statement in the BFD configuration.

When the BFD session detection time adapts to a value equal to or higher than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the minimum-interval or the minimum-receive-interval value. The threshold must be a higher value than the multiplier for either of these configured values. For example if the minimum-receive-interval is 300 ms and the multiplier is 3, the total detection time is 900 ms. Therefore, the detection time threshold must have a value higher than 900.

To specify the minimum transmit interval for failure detection, include the transmit-interval minimum-interval statement in the BFD configuration.

This value represents the minimum interval after which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can configure a value in the range from 1 through 255,000 milliseconds. Optionally, instead of using this statement, you can configure the minimum transmit interval using the minimum-interval statement at the [edit routing-options static route destination-prefix bfd-liveness-detection] hierarchy level.

To specify the threshold for the adaptation of the transmit interval, include the transmit-interval threshold statement in the BFD configuration.

The threshold value must be greater than the transmit interval. When the BFD session transmit time adapts to a value greater than the threshold, a single trap and a system log message are sent. The detection time is based on the multiplier of the value for the minimum-interval or the minimum-receive-interval statement at the [edit routing-options static route destination-prefix bfd-liveness-detection] hierarchy level. The threshold must be a higher value than the multiplier for either of these configured values.

To specify the BFD version, include the version statement in the BFD configuration. The default is to have the version detected automatically.

To include an IP address for the next hop of the BFD session, include the neighbor statement in the BFD configuration.

In Junos OS Release 9.0 and later, you can configure BFD sessions not to adapt to changing network conditions. To disable BFD adaptation, include the no-adaptation statement in the BFD configuration.

The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. The failure detection timers for BFD have shorter time limits than default failure detection mechanisms for BGP, so they provide faster detection.

The BFD failure detection timers can be adjusted to be faster or slower. The lower the BFD failure detection timer value, the faster the failure detection and vice versa. For example, the timers can adapt to a higher value if the adjacency fails (that is, the timer detects failures more slowly). Or a neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap occurs more than three times in a span of 15 seconds (15000 milliseconds). A back-off algorithm increases the receive (Rx) interval by two if the local BFD instance is the reason for the session flap. The transmission (Tx) interval is increased by two if the remote BFD instance is the reason for the session flap. You can use the clear bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on the routing device.

In Junos OS Release 8.3 and later, BFD is supported on internal BGP (IBGP) and multihop external BGP (EBGP) sessions as well as on single-hop EBGP sessions. In Junos OS Release 9.1 through Junos OS Release 11.1, BFD supports IPv6 interfaces in static routes only. In Junos OS Release 11.2 and later, BFD supports IPv6 interfaces with BGP.

The Bidirectional Forwarding Detection (BFD) protocol is a simple hello mechanism that detects failures in a network. BFD works with a wide variety of network environments and topologies. A pair of routing devices exchange BFD packets. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. The BFD failure detection timers have shorter time limits than the OSPF failure detection mechanisms, so they provide faster detection.

The BFD failure detection timers are adaptive and can be adjusted to be faster or slower. The lower the BFD failure detection timer value, the faster the failure detection and vice versa. For example, the timers can adapt to a higher value if the adjacency fails (that is, the timer detects failures more slowly). Or a neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (Rx) interval by two if the local BFD instance is the reason for the session flap. The transmission (Tx) interval is increased by two if the remote BFD instance is the reason for the session flap. You can use the clear bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on the routing device.

You can configure the following BFD protocol settings:

• detection-time threshold—Threshold for the adaptation of the detection time. When the BFD session detection time adapts to a value equal to or greater than the configured threshold, a single trap and a single system log message are sent.

• full-neighbors-only—Ability to establish BFD sessions only for OSPF neighbors with full neighbor adjacency. The default behavior is to establish BFD sessions for all OSPF neighbors. This setting is available in Junos OS Release 9.5 and later.

• minimum-interval—Minimum transmit and receive interval for failure detection. This setting configures both the minimum interval after which the local routing device transmits hello packets and the minimum interval after which the routing device expects to receive a reply from the neighbor with which it has established a BFD session. Both intervals are in milliseconds. You can also specify the minimum transmit and receive intervals separately using the transmit-interval minimum-interval and minimum-receive-interval statements.

  Note:

  BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD of less than 100 ms for Routing Engine-based sessions and 10 ms for distributed BFD sessions can cause undesired BFD flapping.

  Depending on your network environment, the following may apply:

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of no less than 500 ms. An interval of 1000 ms is recommended to avoid any instability issues.

  • For BFD sessions to remain up during a Routing Engine switchover event when nonstop active routing (NSR) is configured, specify a minimum interval of 2500 ms for Routing Engine-based sessions. Without NSR, Routing Engine-based sessions can have a minimum interval of 100 ms.

  • For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

  • Junos OS 21.2R1 and later support distributed OSPFv3 and ISIS BFD sessions with IPv6 link local addresses on MX series routers running MPCs 1 through 9 (it is not supported on MPC 10 or MPC 11). The default for IPv6 link local BFD is inline mode.

  • BFD is not distributed prior to Junos 21.2 (because for OSPFv3, BFD is based in the Routing Engine).

  • On a single QFX5100 switch, when you add a QFX-EM-4Q expansion module, specify a minimum interval higher than 1000 ms.

• minimum-receive-interval—Minimum receive interval for failure detection. This setting configures the minimum receive interval, in milliseconds, after which the routing device expects to receive a hello packet from a neighbor with which it has established a BFD session. You can also specify the minimum receive interval using the minimum-interval statement.

• multiplier—Multiplier for hello packets. This setting configures the number of hello packets that are not received by a neighbor, which causes the originating interface to be declared down. By default, three missed hello packets cause the originating interface to be declared down.

• no-adaptation—Disables BFD adaption. This setting disables BFD sessions from adapting to changing network conditions. This setting is available in Junos OS Release 9.0 and later.

  Note:

  We recommend that you do not disable BFD adaptation unless it is preferable not to have BFD adaptation in your network.

• transmit-interval minimum-interval—Minimum transmit interval for failure detection. This setting configures the minimum transmit interval, in milliseconds, at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can also specify the minimum transmit interval using the minimum-interval statement.

• transmit-interval threshold—Threshold for the adaptation of the BFD session transmit interval. When the transmit interval adapts to a value greater than the threshold, a single trap and a single system log message are sent. The threshold value must be greater than the minimum transmit interval. If you attempt to commit a configuration with a threshold value less than the minimum transmit interval, the routing device displays an error and does not accept the configuration.

• version—BFD version. This setting configures the BFD version used for detection. You can explicitly configure BFD version 1, or the routing device can automatically detect the BFD version. By default, the routing device automatically detects the BFD version automatically, which is either 0 or 1.

You can also trace BFD operations for troubleshooting purposes.

The BFD failure detection timers are adaptive and can be adjusted to be faster or slower. For example, the timers can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (RX) interval by two if the local BFD instance is the reason for the session flap. The transmission (TX) interval is increased by two if the remote BFD instance is the reason for the session flap.

You can use the clear bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation command is hitless, meaning that the command does not affect traffic flow on the routing device.

To detect failures in the network, the set of statements in Table 2 are used in the configuration.

For a list of hierarchy levels at which you can include these statements, see the statement summary sections for these statements.

BFD enables quick failover between a primary and a secondary routed path. The protocol tests the operational status of the interface multiple times per second. BFD provides for configuration timers and thresholds for failure detection. For example, if the minimum interval is set for 50 milliseconds and the threshold uses the default value of three missed messages, a failure is detected on an interface within 200 milliseconds of the failure.

Intervening devices (for example, an Ethernet LAN switch) hide link-layer failures from routing protocol peers, such as when two routers are connected by way of a LAN switch, where the local interface status remains up even when a physical fault happens on the remote link. Link-layer failure detection times vary, depending on the physical media and the Layer 2 encapsulation. BFD can provide fast failure detection times for all media types, encapsulations, topologies, and routing protocols.

To enable BFD for RIP, both sides of the connection must receive an update message from the peer. By default, RIP does not export any routes. Therefore, you must enable update messages to be sent by configuring an export policy for routes before a BFD session is triggered.

When you configure micro-BFD sessions on every member link in a LAG bundle, each individual session determines the Layer 2 and Layer 3 connectivity of each member link in a LAG.

After the individual session is established on a particular link, member links are attached to the LAG and then load balanced by either one of the following:

• Static configuration—The device control process acts as the client to the micro-BFD session.

• Link Aggregation Control Protocol (LACP)—LACP acts as the client to the micro-BFD session.

When the micro-BFD session is up, a LAG link is established and data is transmitted over that LAG link. If the micro-BFD session on a member link is down, that particular member link is removed from the load balancer, and the LAG managers stop directing traffic to that link. These micro-BFD sessions are independent of each other despite having a single client that manages the LAG interface.

Micro-BFD sessions run in the following modes:

• Distribution mode—In this mode, the Packet Forwarding Engine (PFE) sends and receives the packets at Layer 3. By default, micro-BFD sessions are distributed at Layer 3.

• Non-distribution mode—In this mode, the Routing Engine sends and receives the packets at Layer 2. You can configure the BFD session to run in this mode by including the no-delegate-processing statement under periodic packet management (PPM).

A pair of routing devices in a LAG exchange BFD packets at a specified, regular interval. The routing device detects a neighbor failure when it stops receiving a reply after a specified interval. This allows the quick verification of member link connectivity with or without LACP. A UDP port distinguishes BFD over LAG packets from BFD over single-hop IP packets. The Internet Assigned Numbers Authority (IANA) has allocated 6784 as the UDP destination port for micro-BFD.

Starting from Junos OS 16.1R1 release, you can set the state of static route in BFD Admin Down state by configuring one of the following commands:

• set routing-options static static-route bfd-admin-down active—BFD Admin Down state pulls down the static route.

• set routing-options static static-route bfd-admin-down passive—BFD Admin Down state does not pull down the static route.

Seamless BFD (S-BFD) reduces the time that is required to detect and respond to path failures by speeding up BFD initiation time. Each node in the network is assigned a unique S-BFD discriminator. Nodes operate as either initiators that actively check the reachability of paths, or as responders that listen and respond to reachability requests. When an S-BFD initiator sends a request packet, the responder replies by swapping discriminators and immediately setting the state to UP. This stateless operation allows for the quick establishment of multiple sessions, making it ideal for environments requiring rapid connectivity checks.

To enable sbfd, configure the bfd-liveness-detection sbfd remote-discriminator value statement on initator nodes, and the bfd sbfd local-discriminator value on reponder nodes.

• Benefits of S-BFD
• S-BFD Triggered Fast Re-Route

Starting in Junos OS Release 22.4R1, you can configure BFD to send echo packets back and forth from a neighboring device to ensure that a forwarding path is available. Use the bfd-liveness-detection echo minimum-interval milliseconds configuration statement to enable BFD echo mode and set the minimum interval for echo packets. BFD echo mode only works if the neighboring device supports BFD.

If the neighboring device does not support BFD, you can use BFD echo-lite mode. To enable BFD echo-lite mode, use the bfd-liveness-detection echo-lite minimum-interval milliseconds configuration statement. BFD echo-lite mode performs the same function as BFD echo mode without requiring BFD configuration on the neighbor device.

By default, echo and echo-lite modes only support single-hop sessions in centralized BFD mode. Starting in Junos OS Release 24.2R1, PRPD BFD APIs support echo-lite mode for multihop sessions in distributed and inline BFD modes. For more information about PRPD APIs, see Overview of JET APIs.