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.

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 distributed mode by default. The exceptions are OSPFv3 BFD and PIMv6 BFD, which only support non-distributed BFD. 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:

  • Prior to Junos OS Release 12.3, multihop BFD is non-distributed and runs on the Routing Engine. Starting in Junos OS Release 12.3, multihop BFD runs in distributed mode by default.
  • 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.

  • Starting in Junos OS Release 13.3R5, 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, you can run the BFD session in non-distributed mode by configuring set routing-options ppm no-delegate-processing and then running the clear bfd session command.

If the Routing Engine CPU goes too high, there is a chance that BFD will flap. Even in cases where the Routing Engine CPU is normal, smaller values of minimum-interval can lead to BFD packets not being processed if other higher priority tasks are running. You should select the minimum interval value based on proper testing.

For information about troubleshooting BFD, see Juniper Networks Knowledge Base article 26746.

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.

Configuration and Support

SRX Series devices support a BFD failure detection time of 3 x 100 ms. We support this feature for a standalone SRX Series device. It is not supported for chassis clusters.

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.

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:

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

Note:

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

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.

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

QFX5110, QFX5120, QFX5200, and QFX5210 switches support 10 multihop inline BFD sessions. You can configure them with a timer of 150 x 3 milliseconds.

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.

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.

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.
Note:

If you have configured EVPN overlay BGP peerings, do not use hardware-assisted inline BFD. Use distributed BFD instead.

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.

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.

Note:

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.

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

Note:

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 devices. This field is applicable only for the static routes.

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:

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

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.

Note:

QFX5000 Series switches and EX4600 switches do not support minimum interval values of less than 1 second.

Note:

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.

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.

Note:

On all SRX Series devices, 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.

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.

Note:

QFX5000 Series switches and EX4600 switches do not support minimum interval values of less than 1 second.

Note:

BFD is supported for OSPFv3 in Junos OS Release 9.3 and later.

Note:

For branch SRX Series devices, we recommend 1000 ms as the minimum keepalive time interval for BFD packets.

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, these additional recommendations might 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 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. Without NSR, Routing Engine-based sessions can have a minimum interval of 100 ms. In OSPFv3, BFD is always based in the Routing Engine, meaning that BFD is not distributed. For distributed BFD sessions with NSR configured, the minimum interval recommendations are unchanged and depend only on your network deployment.

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

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.

Note:

QFX5000 Series switches and EX4600 switches do not support minimum interval values of less than 1 second.

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.

Note:

QFX5000 Series switches and EX4600 switches do not support minimum interval values of less than 1 second.

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

Starting with Junos OS Release 13.3, this feature is supported on the following PIC/FPC types:

  • PC-1XGE-XENPAK (Type 3 FPC)

  • PD-4XGE-XFP (Type 4 FPC)

  • PD-5-10XGE-SFPP (Type 4 FPC)

  • 24x10GE (LAN/WAN) SFPP, 12x10GE (LAN/WAN) SFPP, 1x100GE Type 5 PICs

  • All MPCs on MX Series with Ethernet MICs

  • FPC-PTX-P1-A on PTX5000 with 10-Gigabit Ethernet interfaces

  • FPC2-PTX-P1A on PTX5000 with 10-Gigabit Ethernet interfaces in Junos OS Release 14.1 and later

  • All FPCs on PTX Series with Ethernet interfaces in Junos OS Release 14.1R3 and later 14.1 releases, and Junos 14.2 and later

Tip:

See PTX Series PIC/FPC Compatibility for a list of PICs that are supported on each PTX Series FPC.

Note:

Micro-BFD configuration with interface addresses is not supported on PTX routers on FPC3 and QFX10000 line of switches.

The Bidirectional Forwarding Detection (BFD) protocol is a simple detection protocol that quickly detects failures in the forwarding paths. A link aggregation group (LAG) combines multiple links between devices that are in point-to-point connections, thereby increasing bandwidth, providing reliability, and allowing load balancing. To run a BFD session on LAG interfaces, 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.

The individual BFD sessions determine the Layer 2 and Layer 3 connectivity of each member link in the LAG. Once a BFD session is established on a particular link, the member links are attached to the LAG and the load balancer either by a static configuration or by the Link Aggregation Control Protocol (LACP). If the member links are attached to the LAG by a static configuration, the device control process acts as the client to the micro BFD session. When member links are attached to the LAG by the LACP, the 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.

Note:
  • 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 accordance with the latest draft for BFD over LAG.

  • In Junos OS, MicroBFD control packets are always untagged by default. For L2 aggregated interfaces, the configuration must include vlan-tagging or flexible-vlan-tagging in the Aggregated Ethernet with BFD. Otherwise, the system will throw error while committing the configuration.

  • When you enable MicroBFD on an aggregated Ethernet Interface, the aggregated Interface can receive MicroBFD packets. 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.

Micro BFD sessions run in the following modes:

  • Distribution Mode—Micro BFD sessions are distributed by default at Layer 3.

  • Non-Distribution Mode—You can configure the BFD session to run in this mode by including the no-delegate-processing statement under periodic packet management (PPM). In this mode, the packets are being sent or received by the Routing Engine at Layer 2.

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.

Note:

IANA has allocated 6784 as the UDP destination port for micro BFD.

To enable failure detection for LAG networks for aggregated Ethernet interfaces:

  • Include the bfd-liveness-detection statement in the configuration.

  • Specify a hold-down interval value to set the minimum time that the BFD session must remain up before a state change notification is sent to the other members in the LAG network.

  • Specify the minimum interval that indicates the time interval for transmitting and receiving data.

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

    Note:

    On T1600 and T4000 routers, you cannot configure the local aggregated Ethernet Interface address of the remote destination as the neighbor address.

    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 loopback IP address to 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.

    Note:

    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.

Note:

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.

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

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.

Release History Table
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-D70
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 devices. This field is applicable only for the static routes.
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 in Junos OS Release 13.3, inline BFD is supported only on static MX Series routers with MPCs/MICs that have configured enhanced-ip.
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.