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.
Use Feature Explorer to confirm platform and release support for specific features.
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-processingoption.
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:
user@device> show ppm adjacencies detail Protocol: BFD, Hold time: 6000, IFL-index: 65 Distributed: FALSE BFD discriminator: 18, BFD routing table index: 0
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.
# set interfaces lo0 unit 0 family inet # set interfaces lo0 unit 0 family inet6 # set interfaces lo0 unit 0 family mpls
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)
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.
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.
See Also
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.
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.
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.
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.
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.
We recommend that you not disable BFD adaptation unless it is preferable not to have BFD adaptation in your network.
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.
See Also
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.
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.
See Also
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 thetransmit-interval minimum-intervalandminimum-receive-intervalstatements.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 theminimum-intervalstatement.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 theminimum-intervalstatement.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.
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-detectionstatement 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.
Statement |
Description |
|---|---|
|
Enable failure detection. |
|
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:
|
|
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. |
|
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. |
|
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. |
|
Specify the threshold for the following:
Note:
The threshold value must be greater than the minimum transmit interval multiplied by the multiplier number. |
|
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. |
|
Specify the BFD version used for detection. The default is to have the version detected automatically. |
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.
See Also
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-processingstatement 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-taggingorflexible-vlan-taggingoptions 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-addressagainst 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-disablestatement at the[edit interface aex unit y family inet6]hierarchy level.
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.
See Also
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 sessioncommand is executed, the BFD sessions move to Admin Down state before restarting. Thisclear bfd sessioncommand 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.
See Also
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-Specific Inline BFD Behavior
- Platform-Specific BFD for Static Routes Behavior
- Platform-Specific BFD for BGP Behavior
- Platform-Specific BFD for OSPF Behavior
- Platform-Specific BFD for IS-IS Behavior
- Platform-Specific BFD for RIP Behavior
- Platform-Specific Micro-BFD Behavior
Platform-Specific Distributed BFD Behavior
| Platform | Difference |
|---|---|
|
MX Series |
|
| PTX Series |
|
| QFX Series |
|
| SRX Series |
|
Platform-Specific Inline BFD Behavior
| Platform | Difference |
|---|---|
|
MX Series |
|
| QFX Series |
|
Platform-Specific BFD for Static Routes Behavior
| Platform | Difference |
|---|---|
|
EX Series |
|
|
MX Series |
|
|
SRX Series |
|
Platform-Specific BFD for BGP Behavior
| Platform | Difference |
|---|---|
|
EX Series |
|
|
MX Series |
|
| QFX Series |
|
|
SRX Series |
|
Platform-Specific BFD for OSPF Behavior
| Platform | Difference |
|---|---|
|
EX Series |
|
|
MX Series |
|
| QFX Series |
|
|
SRX Series |
|
Platform-Specific BFD for IS-IS Behavior
| Platform | Difference |
|---|---|
|
EX Series |
|
Platform-Specific BFD for RIP Behavior
| Platform | Difference |
|---|---|
|
EX Series |
|
Platform-Specific Micro-BFD Behavior
| Platform | Difference |
|---|---|
|
MX Series |
|
| PTX Series |
|
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.
local-address against the interface or
loopback IP address before the configuration commit.