Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring BFD for BGP

 

Understanding BFD for BGP

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

Note

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

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

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.

Example: Configuring BFD on Internal BGP Peer Sessions

This example shows how to configure internal BGP (IBGP) peer sessions with the Bidirectional Forwarding Detection (BFD) protocol to detect failures in a network.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

The minimum configuration to enable BFD on IBGP sessions is to include the bfd-liveness-detection minimum-interval statement in the BGP configuration of all neighbors participating in the BFD session. The minimum-interval statement specifies the minimum transmit and receive intervals for failure detection. Specifically, this value represents the minimum interval after which the local routing device transmits hello packets as well as the minimum interval that the routing device expects to receive a reply from a neighbor with which it has established a BFD session. You can configure a value from 1 through 255,000 milliseconds.

Optionally, you can specify the minimum transmit and receive intervals separately using the transmit-interval minimum-interval and minimum-receive-interval statements. For information about these and other optional BFD configuration statements, see bfd-liveness-detection.

Note

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

Depending on your network environment, these additional recommendations might apply:

  • To prevent BFD flapping during the general Routing Engine switchover event, specify a minimum interval of 5000 milliseconds for Routing Engine-based sessions. This minimum value is required because, during the general Routing Engine switchover event, processes such as RPD, MIBD, and SNMPD utilize CPU resources for more than the specified threshold value. Hence, BFD processing and scheduling is affected because of this lack of CPU resources.

  • For BFD sessions to remain up during the dual chassis cluster control link scenario, when the first control link fails, specify the minimum interval of 6000  milliseconds to prevent the LACP from flapping on the secondary node for Routing Engine-based sessions.

  • For large-scale network deployments with a large number of BFD sessions, specify a minimum interval of 300 milliseconds for Routing Engine-based sessions and 100 milliseconds 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 milliseconds 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.

BFD is supported on the default routing instance (the main router), routing instances, and logical systems. This example shows BFD on logical systems.

Figure 1 shows a typical network with internal peer sessions.

Figure 1: Typical Network with IBGP Sessions
Typical Network with IBGP Sessions

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 A

Device B

Device C

Configuring Device A

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 CLI User Guide.

To configure Device A:

  1. Set the CLI to Logical System A.
  2. Configure the interfaces.
  3. Configure BGP.

    The neighbor statements are included for both Device B and Device C, even though Device A is not directly connected to Device C.

  4. Configure BFD.

    You must configure the same minimum interval on the connecting peer.

  5. (Optional) Configure BFD tracing.
  6. Configure OSPF.
  7. Configure a policy that accepts direct routes.

    Other useful options for this scenario might be to accept routes learned through OSPF or local routes.

  8. Configure the router ID and the autonomous system (AS) number.
  9. If you are done configuring the device, enter commit from configuration mode.

    Repeat these steps to configure Device B and Device C.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, 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.

Verification

Confirm that the configuration is working properly.

Verifying That BFD Is Enabled

Purpose

Verify that BFD is enabled between the IBGP peers.

Action

From operational mode, enter the show bgp neighbor command. You can use the | match bfd filter to narrow the output.

user@host:A> show bgp neighbor | match bfd

Meaning

The output shows that Logical System A has two neighbors with BFD enabled. When BFD is not enabled, the output displays BFD: disabled, down, and the <BfdEnabled> option is absent. If BFD is enabled and the session is down, the output displays BFD: enabled, down. The output also shows that BFD-related events are being written to a log file because trace operations are configured.

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.

user@host:A> show bfd session extensive

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/A/bgp-bfd command.

user@host:A> file show /var/log/A/bgp-bfd

Meaning

Before the routes are established, the No route to host message appears in the output. After the routes are established, the last two lines show that both BFD sessions come up.

Viewing Detailed BFD Events After Deactivating and Reactivating a Loopback Interface

Purpose

Check to see what happens after bringing down a router or switch and then bringing it back up. To simulate bringing down a router or switch, deactivate the loopback interface on Logical System B.

Action

  1. From configuration mode, enter the deactivate logical-systems B interfaces lo0 unit 2 family inet command.

    user@host:A# deactivate logical-systems B interfaces lo0 unit 2 family inet
    user@host:A# commit
  2. From operational mode, enter the file show /var/log/A/bgp-bfd command.

    user@host:A> file show /var/log/A/bgp-bfd
  3. From configuration mode, enter the activate logical-systems B interfaces lo0 unit 2 family inet command.

    user@host:A# activate logical-systems B interfaces lo0 unit 2 family inet
    user@host:A# commit
  4. From operational mode, enter the file show /var/log/A/bgp-bfd command.

    user@host:A> file show /var/log/A/bgp-bfd
Release History Table
Release
Description
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.
In Junos OS Release 11.2 and later, BFD supports IPv6 interfaces with BGP.
In Junos OS Release 9.1 through Junos OS Release 11.1, BFD supports IPv6 interfaces in static routes only.
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.