Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding How BFD Detects Network Failures

SUMMARY An overview of the Bidirectional Forwarding Detection (BFD) protocol and the different types of BFD sessions.

Understanding BFD

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.

Review the Platform-Specific BFD Behavior section for notes related to your platform.

Benefits

  • Use BFD to check the health of your network.
  • BFD works with a wide variety of network environments and topologies.
  • The BFD failure detection timers have short time limits, so they provide fast failure detection.
  • BFD timers are adaptive. You can adjust them to be more or less aggressive.

Types of BFD Sessions

There are four types of BFD sessions based on the source from which BFD packets are sent to the neighbors. The different types of BFD sessions are:

Type of BFD session

Description

Centralized (or non-distributed) BFD

BFD sessions run completely on the Routing Engine.

Distributed BFD

BFD sessions run completely on the FPC CPU.

Inline BFD

BFD sessions run on the FPC software.

Hardware-assisted inline BFD

BFD sessions run on the ASIC firmware.

Single-hop and Multihop BFD

  • Single-hop BFD—Single-hop BFD in Junos OS runs in centralized mode by default. Single-hop BFD control packets use UDP port 3784.

  • Multihop BFD—One desirable application of BFD is to detect connectivity to routing devices that span multiple network hops and follow unpredictable paths. This is known as a multihop session. Multihop BFD control packets use UDP port 4784.

Consider the following when using multihop BFD:

  • In a multichassis link aggregation group (MC-LAG) setup, Inter-Chassis Control Protocol (ICCP) uses BFD in multihop mode. Multihop BFD runs in centralized mode in this kind of setup.

  • Junos OS does not execute firewall filters that you apply on a loopback interface for a multihop BFD session with a delegated anchor FPC. There is an implicit filter on all ingress FPCs to forward packets to the anchor FPC. Therefore, the firewall filter on the loopback interface is not applied on these packets. If you do not want these packets to be forwarded to the anchor FPC, you can configure the no-delegate-processing option.

Centralized BFD

In centralized BFD mode (also called non-distributed BFD mode), the Routing Engine handles BFD.

For both single-hop BFD and multihop BFD, run BFD in non-distributed mode by enabling routing-options ppm no-delegate-processing and then running the clear bfd session command.

You can see what mode BDF is running in as follows:

Distributed BFD

The term distributed BFD refers to BFD that runs on the FPC CPU. The Routing Engine creates the BFD sessions and the FPC CPU processes them.

Benefits

The benefits of distributed BFD are mainly in the scaling and performance areas. Distributed BFD:

  • Allows for the creation of a larger number of BFD sessions.

  • Runs BFD sessions with a shorter transfer/receive timer interval, which can in turn be used to bring down the overall detection time.

  • Separates the functionality of BFD from that of the Routing Engine.

  • A BFD session can stay up during graceful restart, even with an aggressive interval. The minimum interval for Routing Engine-based BFD sessions to survive graceful Routing Engine switchover is 2500 ms. Distributed BFD sessions have a minimum interval of less than a second.

  • Frees up the Routing Engine CPU, which improves scaling and performance for Routing Engine-based applications.

  • BFD protocol packets flow even when the Routing Engine CPU is congested.

Distributed Configuration and Support

Distributed BFD is not supported for chassis clusters.

To determine if a BFD peer is running distributed BFD, run the show bfd sessions extensive command and look for Remote is control-plane independent in the command output.

For distributed BFD to work, you need to configure the lo0 interface with unit 0 and the appropriate family.

This is true for the following types of BFD sessions:

  • BFD over aggregated Ethernet logical interfaces, both IPv4 and IPv6

  • Multihop BFD, both IPv4 and IPv6

  • BFD over VLAN interfaces in EX Series switches, both IPv4 and IPv6

  • Virtual Circuit Connectivity Verification (VCCV) BFD (Layer 2 circuit, Layer 3 VPN, and VPLS) (MPLS)

Note:

The distribution of adjacency entry (the IP addresses of adjacent routers) and transmit entry (the IP address of transmitting routers) for a BFD session is asymmetric. This is because an adjacency entry that requires rules might or might not be distributed based on the redirect rule, and the distribution of transmit entries is not dependent on the redirect rule.

The term redirect rule here denotes the capability of an interface to send protocol redirect messages. See Disabling the Transmission of Redirect Messages on an Interface.

Timer Guidelines for Centralized and Distributed BFD

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, these additional recommendations might apply:

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

  • For very large-scale network deployments with a large number of BFD sessions, contact Juniper Networks customer support for more information.

  • 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. For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

Inline BFD

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 sessions can have keepalive intervals of less than a second, so you can detect errors in milliseconds.
  • If you are running inline BFD and the Routing Engine crashes, the inline BFD sessions will continue without interruption for 15 seconds.
  • Inline BFD has many of the same benefits as distributed BFD since it also separates the functionality of BFD from the Routing Engine.
  • The Packet Forwarding Engine software and the ASIC firmware process the packets more quickly than the FPC CPU, so inline BFD is faster than distributed BFD.

Inline BFD

Inline BFD sessions run on the FPC software. The Routing Engine creates the BFD sessions and the Packet Forwarding Engine software processes them. Starting in Junos OS Release 16.1R1, integrated routing and bridging (IRB) interfaces support inline BFD sessions.

We support inline BFD sessions for both underlay and overlay. For example, you can run BFD sessions between EVPN overlay BGP peers.

We don’t support inline BFD sessions over VXLAN tunnels. For example, you can’t run inline BFD between BGP peers connected through a VXLAN tunnel. To use BFD sessions over a VXLAN tunnel, you must use either distributed mode or centralized mode.

Hardware-Assisted Inline BFD

Hardware-assisted inline BFD sessions run on the ASIC firmware. Hardware-assisted inline BFD is a hardware implementation of the inline BFD protocol. The Routing Engine creates BFD sessions and passes them to the ASIC firmware for processing. The device uses existing paths to forward any BFD events that need to be processed by protocol processes.

Regular inline BFD is a software approach. In hardware-assisted inline BFD, the firmware handles most of the BFD protocol processing. The ASIC firmware processes the packets more quickly than the software, so hardware-assisted inline BFD is faster than regular inline BFD. We support this feature for single-hop and multihop IPv4 and IPv6 BFD sessions.

We support hardware-assisted inline BFD sessions for both underlay and overlay. For example, you can run BFD sessions between EVPN overlay BGP peers.

We don't support hardware-assisted inline BFD sessions over VXLAN tunnels. For example, you can't run hardware-assisted inline BFD between BGP peers connected through a VXLAN tunnel. To use BFD sessions over a VXLAN tunnel, you must use either distributed mode or centralized mode.

Limitations

If the Packet Forwarding Engine process restarts or the system reboots, the BFD sessions will go down.

Hardware-assisted inline BFD:

  • Does not support micro BFD.
  • Is only supported on standalone devices.
  • Does not support BFD authentication.
  • Does not support IPv6 link local BFD sessions.
  • Cannot be used with VXLAN encapsulation of BFD packets.
  • Cannot be used with LAG.
  • Cannot be used with ECMP on QFX5120 Series devices.
Note:

When using hardware-assisted BFD with ECMP, if hardware recovery takes more time than the BFD timer, it can cause flapping in the BFD session.

Supported Platforms

The following platforms support hardware-assisted inline BFD:

Platforms

First Supported Release

Default Mode

QFX5120-32C

QFX5120-48Y

21.2R1

Hardware-Assisted Inline BFD

QFX-5220-32

QFX-5220-128c

23.2R1

Inline BFD

QFX5130-32CD

QFX5700

23.4R1

Inline BFD

Configuration

Devices support either regular inline BFD or hardware-assisted inline BFD. Use the set routing-options ppm inline-processing-enable command to enable the type of inline BFD that your device supports. To return BFD to the default mode, delete the configuration.

Use the set routing-options ppm no-delegate-processing configuration statement to transition from inline mode to centralized mode. If there is a session over VXLAN tunnel, or any other tunnel, you need to set all BFD sessions to run in distributed mode or centralized mode.

BFD Session Damping Overview

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.

Note:

BFD session damping is currently supported for LACP protocol clients only.

Benefits

  • Improve network stability by damping intermittent BFD session flaps that can disrupt services.
  • Enhance network management by setting thresholds and timers for effective BFD damping control.
  • Speed up convergence times by reducing false positives.

Overview

You can use BFD to quickly detect failures in reachabiltiy between devices. When BFD detects a failure, it sends a notification to relevant client and protocols. If an unstable link goes up and down repeatedly, this can cause excessive BFD notifications. You can use BFD session damping to avoid this by automatically damping BFD notifications for a configured time period when flap detection thresholds are exceeded.

If a BFD session transitions between Up and Down more frequently than the configured flap detection threshold, that session is considered flapping and placed in a dampened state. While dampened, all BFD notifications for that session are suppressed for the duration of the damping timeout period. After the timeout expires, notifications resume for that BFD session. You can configure the flap detection threshold and damping timeout period to suit network your needs. Lower timeout values result in faster restoration of notification for flapping sessions.

Session instablity is measured on a per-BFD-session basis as a value called merit value. Each time a BFD session transitions to a Down state, the merit value for that sessions is increased by a configured increment. When the merit value passes a configured threshold, that BFD session will be dampened.

Configuration

Use the bfd-liveness-detection damping configuration statement at the [edit interfaces name aggregated-ether-option] hierachy level to configure BFD session damping.

You can use a variety of configuration options to set values like the merit threshold for triggering damping,the maximum length of damping time, the value of incremental merit applied after each flap, and more.

BFD session damping happens independently on each router locally, so BFD session configuration values should match on both ends of a BFD session to ensure consistent behavior.

The key configuration options are as follows:

suppress

The merit value above which BFD notifications will be suppressed.

reuse

The merit value below which a suppressed BFD session will start notifications again.

increment

Increments applied to merit value for every flap.

max-suppress-time

The maximum time a BFD session can be suppressed. 

half-life

The time duration in seconds after which the accumulated merit value of a BFD session will be reduced by half.

For more information on the default values and ranges for each option, see damping (BFD Liveness Detection).

Understanding BFD for Static Routes for Faster Network Failure Detection

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.

Note:

If a single BFD session includes multiple static routes, the hold-down interval with the highest value is used.

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.

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, these additional recommendations might apply:

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

  • For very large-scale network deployments with a large number of BFD sessions, contact Juniper Networks customer support for more information.

  • 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. For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

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.

Note:

You must configure the neighbor statement if the next hop specified is an interface name. If you specify an IP address as the next hop, that address is used as the neighbor address for the BFD session.

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.

Note:

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

Note:

If BFD is configured only on one end of a static route, the route is removed from the routing table. BFD establishes a session when BFD is configured on both ends of the static route.

BFD is not supported on ISO address families in static routes. BFD does support IS-IS.

If you configure graceful Routing Engine switchover (GRES) at the same time as BFD, GRES does not preserve the BFD state information during a failover.

Understanding BFD for BGP

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.

Note:

Configuring both BFD and graceful restart for BGP on the same device is counterproductive. When an interface goes down, BFD detects this instantly, stops traffic forwarding and the BGP session goes down whereas graceful restart forwards traffic despite the interface failure, this behavior might cause network issues. Hence we do not recommend configuring both BFD and graceful restart on the same device.

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.

Understanding BFD for OSPF

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.

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

  • 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.

Understanding BFD for IS-IS

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 the failure detection mechanisms of IS-IS, providing faster detection.

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.

Note:

Starting with Junos OS Release 16.1R1, you can configure IS-IS BFD sessions for IPv6 by including the bfd-liveness-detection statement at the [edit protocols isis interface interface-name family inet|inet6] hierarchy level.

  • For interfaces that support both IPv4 and IPv6 routing, the bfd-liveness-detection statement must be configured separately for each inet family.

  • BFD over IPv6 link local address is currently not distributed because IS-IS uses link local addresses for forming adjacencies.

  • BFD sessions over IPv6 must not have the same aggressive detection intervals as IPv4 sessions.

  • BFD IPv6 sessions with detection intervals less than 2.5 seconds are currently not supported when nonstop active routing (NSR) is enabled.

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

Table 1: Configuring BFD for IS-IS

Statement

Description

bfd-liveness-detection

Enable failure detection.

minimum-interval milliseconds

Specify the minimum transmit and receive intervals for failure detection.

This value represents the minimum interval at which the local router transmits hellos packets as well as the minimum interval at which the router expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number from 1 through 255,000 milliseconds. You can also specify the minimum transmit and receive intervals separately.

Note:

BFD is an intensive protocol that consumes system resources. Specifying a minimum interval for BFD 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, these additional recommendations might apply:

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 ms for Routing Engine-based sessions and 100 ms for distributed BFD sessions.

  • For very large-scale network deployments with a large number of BFD sessions, please contact Juniper Networks customer support for more information.

  • 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. For distributed BFD sessions with nonstop active routing configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

minimum-receive-interval milliseconds

Specify only the minimum receive interval for failure detection.

This value represents the minimum interval at which the local router expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a number from 1 through 255,000 milliseconds.

multiplier number

Specify the number of hello packets not received by the neighbor that causes the originating interface to be declared down.

The default is 3, and you can configure a value from 1 through 225.

no-adaptation

Disable BFD adaptation.

In Junos OS Release 9.0 and later, you can specify that the BFD sessions not adapt to changing network conditions.

Note:

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

threshold

Specify the threshold for the following:

  • Adaptation of the detection time

    When the BFD session detection time adapts to a value equal to or greater than the threshold, a single trap and a system log message are sent.

  • Transmit interval

Note:

The threshold value must be greater than the minimum transmit interval multiplied by the multiplier number.

transmit-interval minimum-interval

Specify the minimum transmit interval for failure detection.

This value represents the minimum interval at which the local routing device transmits hello packets to the neighbor with which it has established a BFD session. You can configure a value from 1 through 255,000 milliseconds.

version

Specify the BFD version used for detection.

The default is to have the version detected automatically.

Note:

You can trace BFD operations by including the traceoptions statement at the [edit protocols bfd] hierarchy level.

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

Understanding BFD for RIP

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. BFD failure detection times are shorter than RIP detection times, providing faster reaction times to various kinds of failures in the network. Instead of waiting for the routing protocol neighbor timeout, BFD provides rapid detection of link failures. BFD timers are adaptive and can be adjusted to be more or less aggressive. For example, a timer can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the one configured. Note that the functionality of configuring BFD for RIP described in this topic is not supported in Junos OS Releases 15.1X49, 15.1X49-D30, or 15.1X49-D40.

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.

Understanding Independent Micro BFD Sessions for LAG

The Bidirectional Forwarding Detection (BFD) protocol is a simple detection protocol that quickly detects failures in the forwarding paths. To enable failure detection for aggregated Ethernet interfaces in a LAG, you can configure an independent, asynchronous-mode BFD session on every LAG member link in a LAG bundle. Instead of a single BFD session monitoring the status of the UDP port, independent micro-BFD sessions monitor the status of individual member links.

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.

Benefits

  • Failure detection for LAG—Enables failure detection between devices that are in point-to-point connections.

  • Multiple BFD sessions—Enables you to configure multiple micro-BFD sessions for each member link instead of a single BFD session for the entire bundle.

Configuration Guidelines for Micro-BFD Sessions

Consider the following guidelines as you configure individual micro-BFD sessions on an aggregated Ethernet bundle.

  • This feature works only when both the devices support BFD. If BFD is configured at one end of the LAG, this feature does not work.

  • Starting with Junos OS Release 13.3, IANA has allocated 01-00-5E-90-00-01 as the dedicated MAC address for micro BFD. Dedicated MAC mode is used by default for micro BFD sessions.

  • In Junos OS, micro-BFD control packets are always untagged by default. For Layer 2 aggregated interfaces, the configuration must include vlan-tagging or flexible-vlan-tagging options when you configure Aggregated Ethernet with BFD. Otherwise, the system will throw an error while committing the configuration.

  • When you enable micro-BFD on an aggregated Ethernet interface, the aggregated interface can receive micro-BFD packets. In Junos OS Release 19.3 and later, for MPC10E and MPC11E MPCs, you cannot apply firewall filters on the micro-BFD packets received on the aggregated Ethernet interface. For MPC1E through MPC9E, you can apply firewall filters on the micro-BFD packets received on the aggregated Ethernet interface only if the aggregated Ethernet interface is configured as an untagged interface.

  • Beginning with Release 16.1R2, Junos OS checks and validates the configured micro-BFD local-address against the interface or loopback IP address before the configuration commit. Junos OS performs this check on both IPv4 and IPv6 micro-BFD address configurations, and if they do not match, the commit fails. The configured micro-BFD local address should match with the micro-BFD neighbour address that you have configured on the peer router.

  • For the IPv6 address family, disable duplicate address detection before configuring this feature with aggregated Ethernet interface addresses. To disable duplicate address detection, include the dad-disable statement at the [edit interface aex unit y family inet6] hierarchy level.

CAUTION:

Deactivate bfd-liveness-detection at the [edit interfaces aex aggregated-ether-options] hierarchy level or deactivate the aggregated Ethernet interface before changing the neighbor address from the loopback IP address to the aggregated Ethernet interface IP address. Modifying the local and neighbor address without deactivating bfd-liveness-detection or the aggregated Ethernet interface first might cause micro-BFD sessions failure.

Understanding Static Route State When BFD is in Admin Down State

The Bidirectional Forwarding Detection (BFD) Admin Down state is used to bring down a BFD session administratively (applicable for normal BFD session and micro BFD session), 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 failure.

A BFD session moves to the Admin Down state under the following conditions:

  • If BFD configuration is removed for the last client tied to a BFD session, BFD moves to Admin Down state and communicates the change to the peer, to enable the client protocols without going down.

  • If BFD license is removed on the client, BFD moves to Admin Down state and communicates the change to the remote system to enable the client protocols without going down.

  • When clear bfd session command is executed, the BFD sessions move to Admin Down state before restarting. This clear bfd session command also ensures that the client applications are not impacted.

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.

Understanding BFD Echo and Echo-Lite Modes

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.

Platform-Specific BFD Behavior

Use Feature Explorer to confirm platform and release support for specific features.

Use the following tables to review platform-specific behaviors for your platform:

Platform-Specific Distributed BFD Behavior

Platform Difference

MX Series

  • MX Series routers only support inline BFD if the router is static and has MPCs/MICs with enhanced-ip configured.

PTX Series
  • Flapping occurs during the BFD session when the lo0 interface is not configured on PTX Series routers.

QFX Series
  • QFX5110, QFX5120, QFX5200, and QFX5210 switches support 10 multihop inline BFD sessions. You can configure them with a timer of 150 x 3 milliseconds. Single-hop sessions are also supported.

  • Devices support either regular inline BFD or hardware-assisted inline BFD. Starting in Junos OS Release 21.2R1, QFX5120-32C and QFX5120-48Y switches support hardware-assisted inline BFD. They support a timer of 100 x 3 milliseconds. They can run up to 128 hardware-assisted inline BFD sessions, which can be a mix of single-hop and multihop BFD sessions.

SRX Series
  • Distributed BFD is not supported for chassis clusters. Standalone SRX Series Firewalls support a BFD failure detection time of 3 x 100 ms.

  • Enable distributed mode on the SRX5000 line of devices with SPC3 line cards and SRX1500, SRX4100, SRX4200, and SRX4600 devices by configuring the BFD failure detection time to a value less than 500 ms. SRX1500 devices run in dedicated mode if you've configured set chassis dedicated-ukern-cpu, regardless of the BFD failure detection time. You can enable distributed mode on SRX1500 devices only when dedicated mode is not enabled.

Platform-Specific Inline BFD Behavior

Platform Difference

MX Series

  • MX Series routers only support inline BFD if the router is static and has MPCs/MICs with enhanced-ip configured.

QFX Series
  • QFX5110, QFX5120, QFX5200, and QFX5210 switches support 10 multihop inline BFD sessions. You can configure them with a timer of 150 x 3 milliseconds. Single-hop sessions are also supported.

  • Devices support either regular inline BFD or hardware-assisted inline BFD. Starting in Junos OS Release 21.2R1, QFX5120-32C and QFX5120-48Y switches support hardware-assisted inline BFD. They support a timer of 100 x 3 milliseconds. They can run up to 128 hardware-assisted inline BFD sessions, which can be a mix of single-hop and multihop BFD sessions.

Platform-Specific BFD for Static Routes Behavior

Platform Difference

EX Series

  • EX4600 switches do not support minimum interval values of less than 1 second.

MX Series

  • On MX Series devices, multihop BFD is not supported on a static route if the static route is configured with more than one next hop. It is recommended that you avoid using multiple next hops when a multihop BFD is required for a static route.

SRX Series

  • Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, the bfd-liveness-detection command includes the description field. The description is an attribute under the bfd-liveness-detection object and it is supported only on SRX Series Firewalls. This field is applicable only for the static routes.

Platform-Specific BFD for BGP Behavior

Platform Difference

EX Series

  • EX4600 switches do not support minimum interval values of less than 1 second.

MX Series

  • On MX Series devices, multihop BFD is not supported on a static route if the static route is configured with more than one next hop. It is recommended that you avoid using multiple next hops when a multihop BFD is required for a static route.

QFX Series
  • QFX5110, QFX5120, QFX5200, and QFX5210 switches support multihop Bidirectional Forwarding Detection (BFD) inline keep alive support which will enable sessions to be configured at less than 1 second. Performance may vary depending on the system load. 10 inline BFD sessions are supported and can be configured with a timer of 150 x 3 milliseconds. Single-hop sessions are also supported.

SRX Series

  • On all SRX Series Firewalls that support this feature, high CPU utilization triggered for reasons such as CPU intensive commands and SNMP walks causes the BFD protocol to flap while processing large BGP updates. (Platform support depends on the Junos OS release in your installation.)

  • Starting with Junos OS Release 15.1X49-D100, SRX340, SRX345, and SRX1500 devices support dedicated BFD.

  • Starting with Junos OS Release 15.1X49-D100, SRX300 and SRX320 devices support real-time BFD.

  • Starting with Junos OS Release 15.1X49-D110, SRX550M devices support dedicated BFD.

Platform-Specific BFD for OSPF Behavior

Platform Difference

EX Series

  • EX4600 switches do not support minimum interval values of less than 1 second.

MX Series

  • 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.

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

SRX Series

  • For SRX Series Firewalls that support this feature, we recommend 1000 ms as the minimum keepalive time interval for BFD packets.

Platform-Specific BFD for IS-IS Behavior

Platform Difference

EX Series

  • EX4600 switches do not support minimum interval values of less than 1 second.

Platform-Specific BFD for RIP Behavior

Platform Difference

EX Series

  • EX4600 switches do not support minimum interval values of less than 1 second.

Platform-Specific Micro-BFD Behavior

Platform Difference

MX Series

  • Starting with Junos OS Release 14.1, specify the neighbor in a BFD session. In releases before Junos OS Release 16.1, you must configure the loopback address of the remote destination as the neighbor address. Beginning with Junos OS Release 16.1, you can also configure this feature on MX Series routers that support this feature with aggregated Ethernet interface address of the remote destination as the neighbor address.

PTX Series
  • Starting in Junos OS 21.4R1, LACP minimum link with sync reset and microBFD configuration is supported on PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016 routers.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.3
Starting with Junos OS Release 19.3 and later, for MPC10E and MPC11E MPCs, you cannot apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface. For MPC1E through MPC9E, you can apply firewall filters on the MicroBFD packets received on the aggregated Ethernet Interface only if the aggregated Ethernet Interface is configured as an untagged Interface.
16.1R1
Starting in Junos OS Release 16.1R1, inline BFD sessions are supported on integrated routing and bridging (IRB) interfaces.
16.1
Beginning with Junos OS Release 16.1, you can also configure this feature on MX series routers with aggregated Ethernet interface address of the remote destination as the neighbor address.
16.1
Beginning with Release 16.1R2, Junos OS checks and validates the configured micro BFD local-address against the interface or loopback IP address before the configuration commit.
15.1X49-D100
Starting with Junos OS Release 15.1X49-D100, SRX340, SRX345, and SRX1500 devices support dedicated BFD.
15.1X49-D100
Starting with Junos OS Release 15.1X49-D100, SRX300 and SRX320 devices support real-time BFD.
15.1X49
Note that the functionality of configuring BFD for RIP described in this topic is not supported in Junos OS Releases 15.1X49, 15.1X49-D30, or 15.1X49-D40.
14.1
Starting with Junos OS Release 14.1, specify the neighbor in a BFD session. In releases prior to Junos OS Release 16.1, you must configure the loopback address of the remote destination as the neighbor address.
13.3R5
Starting in Junos OS Release 13.3R5, if you apply a firewall filter on a loopback interface for a multihop BFD session with a delegated anchor FPC, Junos OS does not execute this filter, because there is an implicit filter on all ingress FPCs to forward packets to the anchor FPC.
13.3
Starting in Junos OS Release 13.3, the distribution of adjacency entry (the IP addresses of adjacent routers) and transmit entry (the IP address of transmitting routers) for a BFD session is asymmetric.
13.3
Starting with Junos OS Release 13.3, IANA has allocated 01-00-5E-90-00-01 as the dedicated MAC address for micro BFD.
11.2
In Junos OS Release 11.2 and later, BFD supports IPv6 interfaces with BGP.
9.1
In Junos OS Release 9.1 through Junos OS Release 11.1, BFD supports IPv6 interfaces in static routes only.
8.3
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.