Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Try the Ask AI chatbot for answers to your technical questions about Juniper products and solutions.

close
external-header-nav
keyboard_arrow_up
close
keyboard_arrow_left
BGP User Guide
Table of Contents Expand all
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

BFD for BGP Sessions

date_range 20-Dec-24

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:

EX4600 and QFX5000 Series switches running Junos OS or Junos OS Evolved do not support minimum interval values of less than 1 second in centralized and distributed mode.

Note:

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

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 Firewalls, 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 SessionsTypical 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

content_copy zoom_out_map
set logical-systems A interfaces lt-1/2/0 unit 1 description to-B 
set logical-systems A interfaces lt-1/2/0 unit 1 encapsulation ethernet 
set logical-systems A interfaces lt-1/2/0 unit 1 peer-unit 2 
set logical-systems A interfaces lt-1/2/0 unit 1 family inet address 10.10.10.1/30 
set logical-systems A interfaces lo0 unit 1 family inet address 192.168.6.5/32 
set logical-systems A protocols bgp group internal-peers type internal 
set logical-systems A protocols bgp group internal-peers traceoptions file bgp-bfd 
set logical-systems A protocols bgp group internal-peers traceoptions flag bfd detail 
set logical-systems A protocols bgp group internal-peers local-address 192.168.6.5 
set logical-systems A protocols bgp group internal-peers export send-direct 
set logical-systems A protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000 
set logical-systems A protocols bgp group internal-peers neighbor 192.163.6.4 
set logical-systems A protocols bgp group internal-peers neighbor 192.168.40.4 
set logical-systems A protocols ospf area 0.0.0.0 interface lo0.1 passive 
set logical-systems A protocols ospf area 0.0.0.0 interface lt-1/2/0.1 
set logical-systems A policy-options policy-statement send-direct term 2 from protocol direct 
set logical-systems A policy-options policy-statement send-direct term 2 then accept 
set logical-systems A routing-options router-id 192.168.6.5 
set logical-systems A routing-options autonomous-system 17

Device B

content_copy zoom_out_map
set logical-systems B interfaces lt-1/2/0 unit 2 description to-A
set logical-systems B interfaces lt-1/2/0 unit 2 encapsulation ethernet
set logical-systems B interfaces lt-1/2/0 unit 2 peer-unit 1
set logical-systems B interfaces lt-1/2/0 unit 2 family inet address 10.10.10.2/30
set logical-systems B interfaces lt-1/2/0 unit 5 description to-C
set logical-systems B interfaces lt-1/2/0 unit 5 encapsulation ethernet
set logical-systems B interfaces lt-1/2/0 unit 5 peer-unit 6
set logical-systems B interfaces lt-1/2/0 unit 5 family inet address 10.10.10.5/30
set logical-systems B interfaces lo0 unit 2 family inet address 192.163.6.4/32
set logical-systems B protocols bgp group internal-peers type internal
set logical-systems B protocols bgp group internal-peers local-address 192.163.6.4
set logical-systems B protocols bgp group internal-peers export send-direct
set logical-systems B protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000
set logical-systems B protocols bgp group internal-peers neighbor 192.168.40.4
set logical-systems B protocols bgp group internal-peers neighbor 192.168.6.5
set logical-systems B protocols ospf area 0.0.0.0 interface lo0.2 passive
set logical-systems B protocols ospf area 0.0.0.0 interface lt-1/2/0.2
set logical-systems B protocols ospf area 0.0.0.0 interface lt-1/2/0.5
set logical-systems B policy-options policy-statement send-direct term 2 from protocol direct
set logical-systems B policy-options policy-statement send-direct term 2 then accept
set logical-systems B routing-options router-id 192.163.6.4
set logical-systems B routing-options autonomous-system 17

Device C

content_copy zoom_out_map
set logical-systems C interfaces lt-1/2/0 unit 6 description to-B
set logical-systems C interfaces lt-1/2/0 unit 6 encapsulation ethernet
set logical-systems C interfaces lt-1/2/0 unit 6 peer-unit 5
set logical-systems C interfaces lt-1/2/0 unit 6 family inet address 10.10.10.6/30
set logical-systems C interfaces lo0 unit 3 family inet address 192.168.40.4/32
set logical-systems C protocols bgp group internal-peers type internal
set logical-systems C protocols bgp group internal-peers local-address 192.168.40.4
set logical-systems C protocols bgp group internal-peers export send-direct
set logical-systems C protocols bgp group internal-peers bfd-liveness-detection minimum-interval 1000
set logical-systems C protocols bgp group internal-peers neighbor 192.163.6.4
set logical-systems C protocols bgp group internal-peers neighbor 192.168.6.5
set logical-systems C protocols ospf area 0.0.0.0 interface lo0.3 passive
set logical-systems C protocols ospf area 0.0.0.0 interface lt-1/2/0.6
set logical-systems C policy-options policy-statement send-direct term 2 from protocol direct
set logical-systems C policy-options policy-statement send-direct term 2 then accept
set logical-systems C routing-options router-id 192.168.40.4
set logical-systems C routing-options autonomous-system 17

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.

    content_copy zoom_out_map
    user@host> set cli logical-system A
    
  2. Configure the interfaces.

    content_copy zoom_out_map
    [edit interfaces lt-1/2/0 unit 1]
    user@host:A# set description to-B 
    user@host:A# set encapsulation ethernet 
    user@host:A# set peer-unit 2 
    user@host:A# set family inet address 10.10.10.1/30 
    [edit interfaces lo0 unit 1]
    user@host:A# set family inet address 192.168.6.5/32 
    
  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.

    content_copy zoom_out_map
    [edit protocols bgp group internal-peers]
    user@host:A# set type internal 
    user@host:A# set local-address 192.168.6.5 
    user@host:A# set export send-direct 
    user@host:A# set neighbor 192.163.6.4 
    user@host:A# set neighbor 192.168.40.4 
    
  4. Configure BFD.

    content_copy zoom_out_map
    [edit protocols bgp group internal-peers]
    user@host:A# set bfd-liveness-detection minimum-interval 1000 
    

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

  5. (Optional) Configure BFD tracing.

    content_copy zoom_out_map
    [edit protocols bgp group internal-peers]
    user@host:A# set traceoptions file bgp-bfd 
    user@host:A# set traceoptions flag bfd detail 
    
  6. Configure OSPF.

    content_copy zoom_out_map
    [edit protocols ospf area 0.0.0.0]
    user@host:A# set interface lo0.1 passive 
    user@host:A# set interface lt-1/2/0.1 
    
  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.

    content_copy zoom_out_map
    [edit policy-options policy-statement send-direct term 2]
    user@host:A# set from protocol direct 
    user@host:A# set then accept 
    
  8. Configure the router ID and the autonomous system (AS) number.

    content_copy zoom_out_map
    [edit routing-options]
    user@host:A# set router-id 192.168.6.5 
    user@host:A# set autonomous-system 17
    
  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.

content_copy zoom_out_map
user@host:A# show interfaces
lt-1/2/0 {
    unit 1 {
        description to-B;
        encapsulation ethernet;
        peer-unit 2;
        family inet {
            address 10.10.10.1/30;
        }
    }
}
lo0 {
    unit 1 {
        family inet {
            address 192.168.6.5/32;
        }
    }
}
content_copy zoom_out_map
user@host:A# show policy-options
policy-statement send-direct {
    term 2 {
        from protocol direct;
        then accept;
    }
}
content_copy zoom_out_map
user@host:A# show protocols
bgp {
    group internal-peers {
        type internal;
        traceoptions {
            file bgp-bfd;
            flag bfd detail;
        }
        local-address 192.168.6.5;
        export send-direct;
        bfd-liveness-detection {
            minimum-interval 1000;
        }
        neighbor 192.163.6.4;
        neighbor 192.168.40.4;
    }
}
ospf {
    area 0.0.0.0 {
        interface lo0.1 {
            passive;
        }
        interface lt-1/2/0.1;
    }
}
content_copy zoom_out_map
user@host:A# show routing-options
router-id 192.168.6.5;
autonomous-system 17;

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.

content_copy zoom_out_map
user@host:A> show bgp neighbor | match bfd
Options: <BfdEnabled>
  BFD: enabled, up
  Trace file: /var/log/A/bgp-bfd size 131072 files 10
  Options: <BfdEnabled>
  BFD: enabled, up
  Trace file: /var/log/A/bgp-bfd size 131072 files 10
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.

content_copy zoom_out_map
user@host:A> show bfd session extensive
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
192.163.6.4              Up                       3.000     1.000        3   
 Client BGP, TX interval 1.000, RX interval 1.000
 Session up time 00:54:40
 Local diagnostic None, remote diagnostic None
 Remote state Up, version 1
 Logical system 12, routing table index 25
 Min async interval 1.000, min slow interval 1.000
 Adaptive async TX interval 1.000, RX interval 1.000
 Local min TX interval 1.000, minimum RX interval 1.000, multiplier 3
 Remote min TX interval 1.000, min RX interval 1.000, multiplier 3
 Local discriminator 10, remote discriminator 9
 Echo mode disabled/inactive
 Multi-hop route table 25, local-address 192.168.6.5

                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
192.168.40.4             Up                       3.000     1.000        3   
 Client BGP, TX interval 1.000, RX interval 1.000
 Session up time 00:48:03
 Local diagnostic None, remote diagnostic None
 Remote state Up, version 1
 Logical system 12, routing table index 25
 Min async interval 1.000, min slow interval 1.000
 Adaptive async TX interval 1.000, RX interval 1.000
 Local min TX interval 1.000, minimum RX interval 1.000, multiplier 3
 Remote min TX interval 1.000, min RX interval 1.000, multiplier 3
 Local discriminator 14, remote discriminator 13
 Echo mode disabled/inactive
 Multi-hop route table 25, local-address 192.168.6.5

2 sessions, 2 clients
Cumulative transmit rate 2.0 pps, cumulative receive rate 2.0 pps
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.

content_copy zoom_out_map
user@host:A> file show /var/log/A/bgp-bfd
Aug 15 17:07:25 trace_on: Tracing to "/var/log/A/bgp-bfd" started
Aug 15 17:07:26.492190 bgp_peer_init: BGP peer 192.163.6.4 (Internal AS 17) local address 192.168.6.5 not found.  Leaving peer idled
Aug 15 17:07:26.493176 bgp_peer_init: BGP peer 192.168.40.4 (Internal AS 17) local address 192.168.6.5 not found.  Leaving peer idled
Aug 15 17:07:32.597979 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host
Aug 15 17:07:32.599623 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host
Aug 15 17:07:36.869394 task_connect: task BGP_17.192.168.40.4+179 addr 192.168.40.4+179: No route to host
Aug 15 17:07:36.870624 bgp_connect_start: connect 192.168.40.4 (Internal AS 17): No route to host
Aug 15 17:08:04.599220 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host
Aug 15 17:08:04.601135 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host
Aug 15 17:08:08.869717 task_connect: task BGP_17.192.168.40.4+179 addr 192.168.40.4+179: No route to host
Aug 15 17:08:08.869934 bgp_connect_start: connect 192.168.40.4 (Internal AS 17): No route to host
Aug 15 17:08:36.603544 advertising receiving-speaker only capabilty to neighbor 192.163.6.4 (Internal AS 17)
Aug 15 17:08:36.606726 bgp_read_message: 192.163.6.4 (Internal AS 17): 0 bytes buffered
Aug 15 17:08:36.609119 Initiated BFD session to peer 192.163.6.4 (Internal AS 17): address=192.163.6.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255
Aug 15 17:08:36.734033 advertising receiving-speaker only capabilty to neighbor 192.168.40.4 (Internal AS 17)
Aug 15 17:08:36.738436 Initiated BFD session to peer 192.168.40.4 (Internal AS 17): address=192.168.40.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255
Aug 15 17:08:40.537552 BFD session to peer 192.163.6.4 (Internal AS 17) up
Aug 15 17:08:40.694410 BFD session to peer 192.168.40.4 (Internal AS 17) up
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.

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

    content_copy zoom_out_map
    user@host:A> file show /var/log/A/bgp-bfd
    ...
    Aug 15 17:20:55.995648 bgp_read_v4_message:9747: NOTIFICATION received from 192.163.6.4 (Internal AS 17): code 6 (Cease) subcode 6 (Other Configuration Change)
    Aug 15 17:20:56.004508 Terminated BFD session to peer 192.163.6.4 (Internal AS 17)
    Aug 15 17:21:28.007755 task_connect: task BGP_17.192.163.6.4+179 addr 192.163.6.4+179: No route to host
    Aug 15 17:21:28.008597 bgp_connect_start: connect 192.163.6.4 (Internal AS 17): No route to host
  3. From configuration mode, enter the activate logical-systems B interfaces lo0 unit 2 family inet command.

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

    content_copy zoom_out_map
    user@host:A> file show /var/log/A/bgp-bfd
    ...
    Aug 15 17:25:53.623743 advertising receiving-speaker only capabilty to neighbor 192.163.6.4 (Internal AS 17)
    Aug 15 17:25:53.631314 Initiated BFD session to peer 192.163.6.4 (Internal AS 17): address=192.163.6.4 ifindex=0 ifname=(none) txivl=1000 rxivl=1000 mult=3 ver=255
    Aug 15 17:25:57.570932 BFD session to peer 192.163.6.4 (Internal AS 17) up

Understanding BFD Authentication for BGP

Bidirectional Forwarding Detection protocol (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. 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 BGP. 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.

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 BGP

Beginning with Junos OS Release 9.6, you can configure authentication for BFD sessions running over BGP. Only three steps are needed to configure authentication on a BFD session:

  1. Specify the BFD authentication algorithm for the BGP protocol.

  2. Associate the authentication keychain with the BGP protocol.

  3. Configure the related security authentication keychain.

The following sections provide instructions for configuring and viewing BFD authentication on BGP:

Configuring BFD Authentication Parameters

BFD authentication can be configured for the entire BGP protocol, or a specific BGP group, neighbor, or routing instance.

The following example requires you to 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 authentication:

  1. Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use.
    content_copy zoom_out_map
    [edit]
    user@host# set protocols bgp bfd-liveness-detection authentication algorithm keyed-sha-1
    user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication algorithm keyed-sha-1
    user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication algorithm keyed-sha-1
    
    Note:

    Nonstop active routing 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.

  2. Specify the keychain to be used to associate BFD sessions on BGP with the unique security authentication keychain attributes.

    The keychain name you specify must match a keychain name configured at the [edit security authentication key-chains] hierarchy level.

    content_copy zoom_out_map
    [edit]
    user@host# set protocols bgp bfd-liveness-detection authentication keychain bfd-bgp
    user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication keychain bfd-bgp
    user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication keychain bfd-bgp
    
    Note:

    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.

  3. Specify the unique security authentication information for BFD sessions:
    • The matching keychain name as specified in Step 2.

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

    content_copy zoom_out_map
    [edit security]
    user@host# set authentication-key-chains key-chain bfd-bgp key 53 secret $ABC123$ABC123 start-time 2009-06-14.10:00:00
    
  4. (Optional) Specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.
    content_copy zoom_out_map
    [edit]
    user@host# set protocols bgp bfd-liveness-detection authentication loose-check
    user@host# set protocols bgp group bgp-gr1 bfd-liveness-detection authentication loose-check
    user@host# set protocols bgp group bgp-gr1 neighbor 10.10.10.7 bfd-liveness-detection authentication loose-check
    
  5. (Optional) View your configuration using the show bfd session detail or show bfd session extensive command.
  6. Repeat these steps to configure the other end of the BFD session.
Note:

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.

Viewing Authentication Information for BFD Sessions

You can view the existing BFD authentication configuration using the show bfd session detail and show bfd session extensive commands.

The following example shows BFD authentication configured for the bgp-gr1 BGP group. It specifies the keyed SHA-1 authentication algorithm and a keychain name of bfd-bgp. The authentication keychain is configured with two keys. Key 1 contains the secret data “$ABC123$ABC123” and a start time of June 1, 2009, at 9:46:02 AM PST. Key 2 contains the secret data “$ABC123$ABC123” and a start time of June 1, 2009, at 3:29:20 PM PST.

content_copy zoom_out_map
[edit protocols bgp]
group bgp-gr1 {
    bfd-liveness-detection {
        authentication {
            algorithm keyed-sha-1;
            key-chain bfd-bgp;
        }
    }
}
[edit security]
authentication key-chains {
    key-chain bfd-bgp {
        key 1 {
            secret “$ABC123$ABC123”;
            start-time “2009-6-1.09:46:02 -0700”;
        }
        key 2 {
            secret “$ABC123$ABC123”;
            start-time “2009-6-1.15:29:20 -0700”;
        }
    }
}

If you commit these updates to your configuration, you see output similar to the following. In the output for the show bfd session detail command, Authenticate is displayed to indicate that BFD authentication is configured. For more information about the configuration, use the show bfd session extensive command. The output for this command provides the keychain name, the authentication algorithm and mode for each client in the session, and the overall BFD authentication configuration status, keychain name, and authentication algorithm and mode.

show bfd session detail

content_copy zoom_out_map
user@host# show bfd session detail 

                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
192.0.2.2                 Up        ge-0/1/5.0     0.900     0.300        3   
 Client BGP, TX interval 0.300, RX interval 0.300, Authenticate 
 Session up time 3d 00:34
 Local diagnostic None, remote diagnostic NbrSignal
 Remote state Up, version 1
 Replicated 

show bfd session extensive

content_copy zoom_out_map
user@host# show bfd session extensive    
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
192.0.2.2                 Up        ge-0/1/5.0     0.900     0.300        3   
 Client BGP, TX interval 0.300, RX interval 0.300, Authenticate   
        keychain bfd-bgp, algo keyed-sha-1, mode strict   
 Session up time 00:04:42
 Local diagnostic None, remote diagnostic NbrSignal
 Remote state Up, version 1
 Replicated 
 Min async interval 0.300, min slow interval 1.000
 Adaptive async TX interval 0.300, RX interval 0.300
 Local min TX interval 0.300, minimum RX interval 0.300, multiplier 3
 Remote min TX interval 0.300, min RX interval 0.300, multiplier 3
 Local discriminator 2, remote discriminator 2
 Echo mode disabled/inactive
 Authentication enabled/active, keychain bfd-bgp, algo keyed-sha-1, mode strict  

Change History Table

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

Release
Description
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.
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.
external-footer-nav