Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Bidirectional Forwarding Detection for Static Routes

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.

Note:

Inline BFD is supported on PTX5000 routers with third-generation FPCs starting in Junos OS Release 15.1F3 and 16.1R2. Inline BFD is supported on PTX3000 routers with third-generation FPCs starting in Junos OS Release 15.1F6 and 16.1R2.

There are three types of BFD sessions based on the source from which BFD packets are sent to the neighbors. Different types of BFD sessions and their descriptions are:

Type of BFD session

Description

Non-distributed BFD

BFD sessions running completely on the Routing Engine.

Distributed BFD

BFD sessions running completely on the Packet Forwarding Engine.

Inline BFD

Note:

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.

Note:

Starting in Junos OS Release 16.1R1, the inline BFD sessions are supported on integrated routing and bridging (IRB) interfaces.

BFD sessions running on the FPC hardware.

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:

QFX5000 Series switches 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.

Example: Configuring BFD for Static Routes for Faster Network Failure Detection

This example shows how to configure Bidirectional Forwarding Detection (BFD) for static routes.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

There are many practical applications for static routes. Static routing is often used at the network edge to support attachment to stub networks, which, given their single point of entry and egress, are well suited to the simplicity of a static route. In Junos OS, static routes have a global preference of 5. Static routes are activated if the specified next hop is reachable.

In this example, you configure the static route 192.168.47.0/24 from the provider network to the customer network, using the next-hop address of 172.16.1.2. You also configure a static default route of 0.0.0.0/0 from the customer network to the provider network, using a next-hop address of 172.16.1.1.

For demonstration purposes, some loopback interfaces are configured on Device B and Device D. These loopback interfaces provide addresses to ping and thus verify that the static routes are working.

Figure 1 shows the sample network.

Figure 1: Customer Routes Connected to a Service ProviderCustomer Routes Connected to a Service Provider

Topology

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device B

Device D

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure BFD for static routes:

  1. On Device B, configure the interfaces.

  2. On Device B, create a static route and set the next-hop address.

  3. On Device B, configure BFD for the static route.

  4. On Device B, configure tracing operations for BFD.

  5. If you are done configuring Device B, commit the configuration.

  6. On Device D, configure the interfaces.

  7. On Device D, create a static route and set the next-hop address.

  8. On Device D, configure BFD for the static route.

  9. On Device D, configure tracing operations for BFD.

  10. If you are done configuring Device D, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device B

Device D

Verification

Confirm that the configuration is working properly.

Verifying That BFD Sessions Are Up

Purpose

Verify that the BFD sessions are up, and view details about the BFD sessions.

Action

From operational mode, enter the show bfd session extensive command.

Note:

The description Site- <xxx> is supported only on the SRX Series devices.

If each client has more than one description field, then it displays "and more" along with the first description field.

Meaning

The TX interval 1.000, RX interval 1.000 output represents the setting configured with the minimum-interval statement. All of the other output represents the default settings for BFD. To modify the default settings, include the optional statements under the bfd-liveness-detection statement.

Viewing Detailed BFD Events

Purpose

View the contents of the BFD trace file to assist in troubleshooting, if needed.

Action

From operational mode, enter the file show /var/log/bfd-trace command.

Meaning

BFD messages are being written to the trace file.

Understanding BFD Authentication for Static Route Security

Bidirectional Forwarding Detection (BFD) enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when you run BFD over Network Layer protocols, the risk of service attacks can be significant.

Note:

We strongly recommend using authentication if you are running BFD over multiple hops or through insecure tunnels.

Beginning with Junos OS Release 9.6, Junos OS supports authentication for BFD sessions running over IPv4 and IPv6 static routes. BFD authentication is not supported on MPLS OAM sessions. BFD authentication is only supported in the Canada and United States version of the Junos OS image and is not available in the export version.

Note:

EX3300 supports BFD over static routes only.

You authenticate BFD sessions by specifying an authentication algorithm and keychain, and then associating that configuration information with a security authentication keychain using the keychain name.

The following sections describe the supported authentication algorithms, security keychains, and level of authentication that can be configured:

BFD Authentication Algorithms

Junos OS supports the following algorithms for BFD authentication:

  • simple-password—Plain-text password. One to 16 bytes of plain text are used to authenticate the BFD session. One or more passwords can be configured. This method is the least secure and should be used only when BFD sessions are not subject to packet interception.

  • keyed-md5—Keyed Message Digest 5 hash algorithm for sessions with transmit and receive intervals greater than 100 ms. To authenticate the BFD session, keyed MD5 uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than or equal to the last sequence number received. Although more secure than a simple password, this method is vulnerable to replay attacks. Increasing the rate at which the sequence number is updated can reduce this risk.

  • meticulous-keyed-md5—Meticulous keyed Message Digest 5 hash algorithm. This method works in the same manner as keyed MD5, but the sequence number is updated with every packet. Although more secure than keyed MD5 and simple passwords, this method might take additional time to authenticate the session.

  • keyed-sha-1—Keyed Secure Hash Algorithm I for sessions with transmit and receive intervals greater than 100 ms. To authenticate the BFD session, keyed SHA uses one or more secret keys (generated by the algorithm) and a sequence number that is updated periodically. The key is not carried within the packets. With this method, packets are accepted at the receiving end of the session if one of the keys matches and the sequence number is greater than the last sequence number received.

  • meticulous-keyed-sha-1—Meticulous keyed Secure Hash Algorithm I. This method works in the same manner as keyed SHA, but the sequence number is updated with every packet. Although more secure than keyed SHA and simple passwords, this method might take additional time to authenticate the session.

Note:

Nonstop active routing (NSR) is not supported with meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

Note:

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

Security Authentication Keychains

The security authentication keychain defines the authentication attributes used for authentication key updates. When the security authentication keychain is configured and associated with a protocol through the keychain name, authentication key updates can occur without interrupting routing and signaling protocols.

The authentication keychain contains one or more keychains. Each keychain contains one or more keys. Each key holds the secret data and the time at which the key becomes valid. The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created.

BFD allows multiple clients per session, and each client can have its own keychain and algorithm defined. To avoid confusion, we recommend specifying only one security authentication keychain.

Strict Versus Loose Authentication

By default, strict authentication is enabled, and authentication is checked at both ends of each BFD session. Optionally, to smooth migration from nonauthenticated sessions to authenticated sessions, you can configure loose checking. When loose checking is configured, packets are accepted without authentication being checked at each end of the session. This feature is intended for transitional periods only.

Example: Configuring BFD Authentication for Securing Static Routes

This example shows how to configure Bidirectional Forwarding Detection (BFD) authentication for static routes.

Requirements

Junos OS Release 9.6 or later (Canda and United States version).

BFD authentication is only supported in the Canada and United States version of the Junos OS image and is not available in the export version.

Overview

You can configure authentication for BFD sessions running over IPv4 and IPv6 static routes. Routing instances and logical systems are also supported.

The following steps are needed to configure authentication on a BFD session:

  1. Specify the BFD authentication algorithm for the static route.

  2. Associate the authentication keychain with the static route.

  3. Configure the related security authentication keychain. This must be configured on the main router.

Tip:

We recommend that you specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.

Figure 2 shows the sample network.

Figure 2: Customer Routes Connected to a Service ProviderCustomer Routes Connected to a Service Provider

Topology

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device B

Device D

Procedure

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure BFD for static routes:

  1. On Device B, configure the interfaces.

  2. On Device B, create a static route and set the next-hop address.

  3. On Device B, configure BFD for the static route.

  4. On Device B, specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use for BFD authentication on the static route.

    Note:

    Nonstop active routing (NSR) is not supported with the meticulous-keyed-md5 and meticulous-keyed-sha-1 authentication algorithms. BFD sessions using these algorithms might go down after a switchover.

  5. On Device B, specify the keychain to be used to associate BFD sessions on the specified route with the unique security authentication keychain attributes.

    This should match the keychain name configured at the [edit security authentication key-chains] hierarchy level.

  6. On Device B, specify the unique security authentication information for BFD sessions:

    • The matching keychain name as specified in Step 5.

    • At least one key, a unique integer between 0 and 63. Creating multiple keys allows multiple clients to use the BFD session.

    • The secret data used to allow access to the session.

    • The time at which the authentication key becomes active, in the format yyyy-mm-dd.hh:mm:ss.

  7. If you are done configuring Device B, commit the configuration.

  8. Repeat the configuration on Device D.

    The algorithm and keychain must be configured on both ends of the BFD session, and they must match. Any mismatch in configuration prevents the BFD session from being created.

Results

Confirm your configuration by issuing the show interfaces, show routing-options, and show security commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device B

Verification

Confirm that the configuration is working properly.

Verifying That BFD Sessions Are Up

Purpose

Verify that the BFD sessions are up.

Action

From operational mode, enter the show bfd session command.

Meaning

The command output shows that the BFD session is up.

Viewing Details About the BFD Session

Purpose

View details about the BFD sessions and make sure that authentication is configured.

Action

From operational mode, enter the show bfd session detail command.

Meaning

In the command output, Authenticate is displayed to indicate that BFD authentication is configured.

Viewing Extensive BFD Session Information

Purpose

View more detailed information about the BFD sessions.

Action

From operational mode, enter the show bfd session extensive command.

Meaning

In the command output, Authenticate is displayed to indicate that BFD authentication is configured. The output for the extensive command provides the keychain name, the authentication algorithm, and the mode for each client in the session.

Note:

The description Site- <xxx> is supported only on the SRX Series devices.

If each client has more than one description field, then it displays "and more" along with the first description field.

Example: Enabling BFD on Qualified Next Hops in Static Routes for Route Selection

This example shows how to configure a static route with multiple possible next hops. Each next hop has Bidirectional Forwarding Detection (BFD) enabled.

Requirements

In this example, no special configuration beyond device initialization is required.

Overview

In this example, Device B has the static route 192.168.47.0/24 with two possible next hops. The two next hops are defined using two qualified-next-hop statements. Each next hop has BFD enabled.

BFD is also enabled on Device D because BFD must be enabled on both ends of the connection.

A next hop is included in the routing table if the BFD session is up. The next hop is removed from the routing table if the BFD session is down.

See Figure 3.

Figure 3: BFD Enabled on Qualified Next HopsBFD Enabled on Qualified Next Hops

Topology

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device B

Device D

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the Junos OS CLI User Guide.

To configure a static route with two possible next hops, both with BFD enabled:

  1. On Device B, configure the interfaces.

  2. On Device B, configure the static route with two next hops, both with BFD enabled.

  3. On Device D, configure the interfaces.

  4. On Device D, configure a BFD-enabled default static route with two next hops to the provider network.

    In this case, BFD is enabled on the route, not on the next hops.

Results

Confirm your configuration by issuing the show interfaces and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the devices, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Checking the Routing Tables

Purpose

Make sure that the static route appears in the routing table on Device B with two possible next hops.

Action
Meaning

Both next hops are listed. The next hop 192.168.2.2 is the selected route.

Verifying the BFD Sessions

Purpose

Make sure that the BFD sessions are up.

Action
Meaning

The output shows that the BFD sessions are up.

Removing BFD from Device D

Purpose

Demonstrate what happens when the BFD session is down for both next hops.

Action
  1. Deactivate BFD on Device D.

  2. Rerun the show bfd session command on Device B.

  3. Rerun the show route 192.168.47.0 command on Device B.

Meaning

As expected, when the BFD sessions are down, the static route is removed from the routing table.

Removing BFD from One Next Hop

Purpose

Demonstrate what happens when only one next hop has BFD enabled.

Action
  1. If it is not already deactivated, deactivate BFD on Device D.

  2. Deactivate BFD on one of the next hops on Device B.

  3. Rerun the show bfd session command on Device B.

  4. Rerun the show route 192.168.47.0 extensive command on Device B.

Meaning

As expected, the BFD session is down for the 192.168.2.2 next hop. The 172.16.1.2 next hop remains in the routing table, and the route remains active, because BFD is not a condition for this next hop to remain valid.

Release History Table
Release
Description
16.1R1
Starting in Junos OS Release 16.1R1, the inline BFD sessions are supported on integrated routing and bridging (IRB) interfaces.
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.1F6
Inline BFD is supported on PTX3000 routers with third-generation FPCs starting in Junos OS Release 15.1F6 and 16.1R2.
15.1F3
Inline BFD is supported on PTX5000 routers with third-generation FPCs starting in Junos OS Release 15.1F3 and 16.1R2.
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.