ON THIS PAGE
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.
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.
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 Firewalls. This field is applicable only for the static routes.
In Junos OS Release 9.1 and later, the BFD protocol is supported for IPv6 static routes. Global unicast and link-local IPv6 addresses are supported for static routes. The BFD protocol is not supported on multicast or anycast IPv6 addresses. For IPv6, the BFD protocol supports only static routes and only in Junos OS Release 9.3 and later. IPv6 for BFD is also supported for the eBGP protocol.
To configure the BFD protocol for IPv6 static routes, include the
bfd-liveness-detection statement at the [edit
routing-options rib inet6.0 static route
destination-prefix] hierarchy level.
In Junos OS Release 8.5 and later, you can configure a hold-down interval to specify how long the BFD session must remain up before a state change notification is sent.
To specify the hold-down interval, include the holddown-interval
statement in the BFD configuration. You can configure a number in the range from 0
through 255,000 milliseconds. The default is 0. If the BFD session goes down and then
comes back up during the hold-down interval, the timer is restarted.
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.
EX4600 switches do not support minimum interval values of less than 1 second.
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
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.
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
set interfaces ge-1/2/0 unit 0 description B->D set interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24 set interfaces lo0 unit 57 family inet address 10.0.0.1/32 set interfaces lo0 unit 57 family inet address 10.0.0.2/32 set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2 set routing-options static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000 set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx set protocols bfd traceoptions file bfd-trace set protocols bfd traceoptions flag all
Device D
set interfaces ge-1/2/0 unit 1 description D->B set interfaces ge-1/2/0 unit 1 family inet address 172.16.1.2/24 set interfaces lo0 unit 2 family inet address 192.168.47.5/32 set interfaces lo0 unit 2 family inet address 192.168.47.6/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1 set routing-options static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 1000 set protocols bfd traceoptions file bfd-trace set protocols bfd traceoptions flag all
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:
On Device B, configure the interfaces.
[edit interfaces] user@B# set ge-1/2/0 unit 0 description B->D user@B# set ge-1/2/0 unit 0 family inet address 172.16.1.1/24 user@B# set lo0 unit 57 family inet address 10.0.0.1/32 user@B# set lo0 unit 57 family inet address 10.0.0.2/32
On Device B, create a static route and set the next-hop address.
[edit routing-options] user@B# set static route 192.168.47.0/24 next-hop 172.16.1.2
On Device B, configure BFD for the static route.
[edit routing-options] user@B# set static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000 set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx
On Device B, configure tracing operations for BFD.
[edit protocols] user@B# set bfd traceoptions file bfd-trace user@B# set bfd traceoptions flag all
If you are done configuring Device B, commit the configuration.
[edit] user@B# commit
On Device D, configure the interfaces.
[edit interfaces] user@D# set ge-1/2/0 unit 1 description D->B user@D# set ge-1/2/0 unit 1 family inet address 172.16.1.2/24 user@D# set lo0 unit 2 family inet address 192.168.47.5/32 user@D# set lo0 unit 2 family inet address 192.168.47.6/32
On Device D, create a static route and set the next-hop address.
[edit routing-options] user@D# set static route 0.0.0.0/0 next-hop 172.16.1.1
On Device D, configure BFD for the static route.
[edit routing-options] user@D# set static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 1000
On Device D, configure tracing operations for BFD.
[edit protocols] user@D# set bfd traceoptions file bfd-trace user@D# set bfd traceoptions flag all
If you are done configuring Device D, commit the configuration.
[edit] user@D# commit
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
user@B# show interfaces
ge-1/2/0 {
unit 0 {
description B->D;
family inet {
address 172.16.1.1/24;
}
}
}
lo0 {
unit 57 {
family inet {
address 10.0.0.1/32;
address 10.0.0.2/32;
}
}
}
user@D# show protocols
bfd {
traceoptions {
file bfd-trace;
flag all;
}
}
user@B# show routing-options
static {
route 192.168.47.0/24 {
next-hop 172.16.1.2;
bfd-liveness-detection {
description Site- xxx;
minimum-interval 1000;
}
}
}
Device D
user@D# show interfaces
ge-1/2/0 {
unit 1 {
description D->B;
family inet {
address 172.16.1.2/24;
}
}
}
lo0 {
unit 2 {
family inet {
address 192.168.47.5/32;
address 192.168.47.6/32;
}
}
}
user@D# show routing-options
static {
route 0.0.0.0/0 {
next-hop 172.16.1.1;
bfd-liveness-detection {
description Site - xxx;
minimum-interval 1000;
}
}
}
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.
user@B> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
172.16.1.2 Up lt-1/2/0.0 3.000 1.000 3
Client Static, description Site-xxx, TX interval 1.000, RX interval 1.000
Session up time 00:14:30
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Replicated, routing table index 172
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 2, remote discriminator 1
Echo mode disabled/inactive
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 ppsThe description Site- <xxx> is supported only on the SRX Series Firewalls.
If each client has more than one description field, then it displays "and more" along with the first description field.
user@D> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
172.16.1.1 Up lt-1/2/0.1 3.000 1.000 3
Client Static, TX interval 1.000, RX interval 1.000
Session up time 00:14:35
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Replicated, routing table index 170
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 1, remote discriminator 2
Echo mode disabled/inactive
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 ppsMeaning
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.
user@B> file show /var/log/bfd-trace Nov 23 14:26:55 Data (9) len 35: (hex) 42 46 44 20 70 65 72 69 6f 64 69 63 20 78 6d 69 74 20 72 Nov 23 14:26:55 PPM Trace: BFD periodic xmit rt tbl index 172 Nov 23 14:26:55 Received Downstream TraceMsg (22) len 108: Nov 23 14:26:55 IfIndex (3) len 4: 0 Nov 23 14:26:55 Protocol (1) len 1: BFD Nov 23 14:26:55 Data (9) len 83: (hex) 70 70 6d 64 5f 62 66 64 5f 73 65 6e 64 6d 73 67 20 3a 20 Nov 23 14:26:55 PPM Trace: ppmd_bfd_sendmsg : socket 12 len 24, ifl 78 src 172.16.1.1 dst 172.16.1.2 errno 65 Nov 23 14:26:55 Received Downstream TraceMsg (22) len 93: Nov 23 14:26:55 IfIndex (3) len 4: 0 Nov 23 14:26:55 Protocol (1) len 1: BFD Nov 23 14:26:55 Data (9) len 68: (hex) 42 46 44 20 70 65 72 69 6f 64 69 63 20 78 6d 69 74 20 74
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.
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.
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.
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.
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:
Specify the BFD authentication algorithm for the static route.
Associate the authentication keychain with the static route.
Configure the related security authentication keychain. This must be configured on the main router.
We recommend that you specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.
[edit] user@host> set routing-options static route ipv4 bfd-liveness-detection authentication loose-check
Figure 2 shows the sample network.
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
set interfaces ge-1/2/0 unit 0 description B->D set interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24 set interfaces lo0 unit 57 family inet address 10.0.0.1/32 set interfaces lo0 unit 57 family inet address 10.0.0.2/32 set routing-options static route 192.168.47.0/24 next-hop 172.16.1.2 set routing-options static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000 set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx set routing-options static route 192.168.47.0/24 bfd-liveness-detection authentication key-chain bfd-kc4 set routing-options static route 192.168.47.0/24 bfd-liveness-detection authentication algorithm keyed-sha-1 set security authentication-key-chains key-chain bfd-kc4 key 5 secret "$ABC123$ABC123$ABC123" set security authentication-key-chains key-chain bfd-kc4 key 5 start-time "2011-1-1.12:00:00 -0800"
Device D
set interfaces ge-1/2/0 unit 1 description D->B set interfaces ge-1/2/0 unit 1 family inet address 172.16.1.2/24 set interfaces lo0 unit 2 family inet address 192.168.47.5/32 set interfaces lo0 unit 2 family inet address 192.168.47.6/32 set routing-options static route 0.0.0.0/0 next-hop 172.16.1.1 set routing-options static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 1000 set routing-options static route 0.0.0.0/0 bfd-liveness-detection authentication key-chain bfd-kc4 set routing-options static route 0.0.0.0/0 bfd-liveness-detection authentication algorithm keyed-sha-1 set security authentication-key-chains key-chain bfd-kc4 key 5 secret "$ABC123$ABC123$ABC123" set security authentication-key-chains key-chain bfd-kc4 key 5 start-time "2011-1-1.12:00:00 -0800"
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:
On Device B, configure the interfaces.
[edit interfaces] user@B# set ge-1/2/0 unit 0 description B->D user@B# set ge-1/2/0 unit 0 family inet address 172.16.1.1/24 user@B# set lo0 unit 57 family inet address 10.0.0.1/32 user@B# set lo0 unit 57 family inet address 10.0.0.2/32
On Device B, create a static route and set the next-hop address.
[edit routing-options] user@B# set static route 192.168.47.0/24 next-hop 172.16.1.2
On Device B, configure BFD for the static route.
[edit routing-options] user@B# set static route 192.168.47.0/24 bfd-liveness-detection minimum-interval 1000 set routing-options static route 192.168.47.0/24 bfd-liveness-detection description Site-xxx
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.
[edit routing-options] user@B# set static route 192.168.47.0/24 bfd-liveness-detection authentication algorithm keyed-sha-1
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.
-
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.[edit routing-options] user@B# set static route 192.168.47.0/24 bfd-liveness-detection authentication key-chain bfd-kc4
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.
[edit security authentication-key-chains key-chain bfd-kc4] user@B# set key 5 secret "$ABC123$ABC123$ABC123" user@B# set key 5 start-time "2011-1-1.12:00:00 -0800"
-
If you are done configuring Device B, commit the configuration.
[edit] user@B# commit
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
user@B# show interfaces
ge-1/2/0 {
unit 0 {
description B->D;
family inet {
address 172.16.1.1/24;
}
}
}
lo0 {
unit 57 {
family inet {
address 10.0.0.1/32;
address 10.0.0.2/32;
}
}
}
user@B# show routing-options
static {
route 192.168.47.0/24 {
next-hop 172.16.1.2;
bfd-liveness-detection {
description Site- xxx;
minimum-interval 1000;
authentication {
key-chain bfd-kc4;
algorithm keyed-sha-1;
}
}
}
}
user@B# show security
authentication-key-chains {
key-chain bfd-kc4 {
key 5 {
secret "$ABC123$ABC123$ABC123"; ## SECRET-DATA
start-time "2011-1-1.12:00:00 -0800";
}
}
}
Verification
Confirm that the configuration is working properly.
- Verifying That BFD Sessions Are Up
- Viewing Details About the BFD Session
- Viewing Extensive BFD Session Information
Verifying That BFD Sessions Are Up
Purpose
Verify that the BFD sessions are up.
Action
From operational mode, enter the show bfd session command.
user@B> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
172.16.1.2 Up ge-1/2/0.0 3.000 1.000 3
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 ppsMeaning
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.
user@B> show bfd session detail
Detect Transmit
Address State Interface Time Interval Multiplier
172.16.1.2 Up ge-1/2/0.0 3.000 1.000 3
Client Static, TX interval 1.000, RX interval 1.000, Authenticate
Session up time 00:53:58
Local diagnostic NbrSignal, remote diagnostic None
Remote state Up, version 1
Logical system 9, routing table index 22
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 ppsMeaning
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.
user@B> show bfd session extensive
Address State Interface Time Interval Multiplier
172.16.1.2 Up ge-1/2/0.0 3.000 1.000 3
Client Static, description Site-xxx, TX interval 1.000, RX interval 1.000, Authenticate
keychain bfd-kc4, algo keyed-sha-1, mode strict
Session up time 01:39:45
Local diagnostic NbrSignal, remote diagnostic None
Remote state Up, version 1
Logical system 9, routing table index 22
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 3, remote discriminator 4
Echo mode disabled/inactive
Authentication enabled/active, keychain bfd-kc4, algo keyed-sha-1, mode strict
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
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.
The description Site- <xxx> is supported only on the SRX Series Firewalls.
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.
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
set interfaces fe-0/1/0 unit 2 description secondary-B->D set interfaces fe-0/1/0 unit 2 family inet address 192.168.2.1/24 set interfaces ge-1/2/0 unit 0 description B->D set interfaces ge-1/2/0 unit 0 family inet address 172.16.1.1/24 set routing-options static route 192.168.47.0/24 qualified-next-hop 192.168.2.2 bfd-liveness-detection minimum-interval 60 set routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2 bfd-liveness-detection minimum-interval 60
Device D
set interfaces fe-0/1/0 unit 3 description secondary-D->B set interfaces fe-0/1/0 unit 3 family inet address 192.168.2.2/24 set interfaces ge-1/2/0 unit 1 description D->B set interfaces ge-1/2/0 unit 1 family inet address 172.16.1.2/24 set routing-options static route 0.0.0.0/0 qualified-next-hop 192.168.2.1 set routing-options static route 0.0.0.0/0 qualified-next-hop 172.16.1.1 set routing-options static route 0.0.0.0/0 bfd-liveness-detection minimum-interval 60
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:
On Device B, configure the interfaces.
[edit interfaces fe-0/1/0] user@B# set unit 2 description secondary-B->D user@B# set unit 2 family inet address 192.168.2.1/24 [edit interfaces ge-1/2/0] user@B# set unit 0 description B->D user@B# set unit 0 family inet address 172.16.1.1/24
On Device B, configure the static route with two next hops, both with BFD enabled.
[edit routing-options static route 192.168.47.0/24] user@B# set qualified-next-hop 192.168.2.2 bfd-liveness-detection minimum-interval 60 user@B# set qualified-next-hop 172.16.1.2 bfd-liveness-detection minimum-interval 60
On Device D, configure the interfaces.
[edit interfaces fe-0/1/0] user@D# set unit 3 description secondary-D->B user@D# set unit 3 family inet address 192.168.2.2/24 [edit interfaces ge-1/2/0] user@D# set unit 1 description D->B user@D# set unit 1 family inet address 172.16.1.2/24
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.
[edit routing-options static route 0.0.0.0/0] user@D# set qualified-next-hop 192.168.2.1 user@D# set qualified-next-hop 172.16.1.1 user@D# set bfd-liveness-detection minimum-interval 60
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.
user@B# show interfaces
fe-0/1/0 {
unit 2 {
description secondary-B->D;
family inet {
address 192.168.2.1/24;
}
}
}
ge-1/2/0 {
unit 0 {
description B->D;
family inet {
address 172.16.1.1/24;
}
}
}
user@B# show routing-options
static {
route 192.168.47.0/24 {
qualified-next-hop 192.168.2.2 {
bfd-liveness-detection {
minimum-interval 60;
}
}
qualified-next-hop 172.16.1.2 {
bfd-liveness-detection {
minimum-interval 60;
}
}
}
}
user@D# show interfaces
fe-0/1/0 {
unit 3 {
description secondary-D->B;
family inet {
address 192.168.2.2/24;
}
}
}
ge-1/2/0 {
unit 1 {
description D->B;
family inet {
address 172.16.1.2/24;
}
}
}
user@D# show routing-options
static {
route 0.0.0.0/0 {
qualified-next-hop 192.168.2.1;
qualified-next-hop 172.16.1.1;
bfd-liveness-detection {
minimum-interval 60;
}
}
}
If you are done configuring the devices, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Checking the Routing Tables
- Verifying the BFD Sessions
- Removing BFD from Device D
- Removing BFD from One Next Hop
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
user@B> show route 192.168.47.0 extensive
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
192.168.47.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 192.168.47.0/24 -> {192.168.2.2}
*Static Preference: 5
Next hop type: Router
Address: 0x9334010
Next-hop reference count: 1
Next hop: 172.16.1.2 via ge-1/2/0.0
Next hop: 192.168.2.2 via fe-0/1/0.2, selected
State: <Active Int Ext>
Age: 9
Task: RT
Announcement bits (1): 3-KRT
AS path: I
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
user@B> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
172.16.1.2 Up ge-1/2/0.0 0.720 0.240 3
192.168.2.2 Up fe-0/1/0.2 0.720 0.240 3
2 sessions, 2 clients
Cumulative transmit rate 8.3 pps, cumulative receive rate 8.3 ppsMeaning
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
Deactivate BFD on Device D.
[edit routing-options static route 0.0.0.0/0] user@D# deactivate bfd-liveness-detection user@D# commit
Rerun the
show bfd sessioncommand on Device B.user@B> show bfd session Detect Transmit Address State Interface Time Interval Multiplier 172.16.1.2 Down ge-1/2/0.0 3.000 1.000 3 192.168.2.2 Down fe-0/1/0.2 3.000 1.000 3 2 sessions, 2 clients Cumulative transmit rate 2.0 pps, cumulative receive rate 2.0 ppsRerun the
show route 192.168.47.0command on Device B.user@B> show route 192.168.47.0
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
If it is not already deactivated, deactivate BFD on Device D.
[edit routing-options static route 0.0.0.0/0] user@D# deactivate bfd-liveness-detection user@D# commit
Deactivate BFD on one of the next hops on Device B.
[edit routing-options static route 192.168.47.0/24 qualified-next-hop 172.16.1.2] user@B# deactivate bfd-liveness-detection user@B# commit
Rerun the
show bfd sessioncommand on Device B.user@B> show bfd session Detect Transmit Address State Interface Time Interval Multiplier 192.168.2.2 Down fe-0/1/0.2 3.000 1.000 3Rerun the
show route 192.168.47.0 extensivecommand on Device B.user@B> show route 192.168.47.0 extensive inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) 192.168.47.0/24 (1 entry, 1 announced) TSI: KRT in-kernel 192.168.47.0/24 -> {172.16.1.2} *Static Preference: 5 Next hop type: Router, Next hop index: 624 Address: 0x92f0178 Next-hop reference count: 3 Next hop: 172.16.1.2 via ge-1/2/0.0, selected State: <Active Int Ext> Age: 2:36 Task: RT Announcement bits (1): 3-KRT AS path: I
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.
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.
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 Firewalls. This field
is applicable only for the static routes.