BFD for RIP
Understanding BFD for RIP
The Bidirectional Forwarding Detection (BFD) Protocol is a simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. A neighbor failure is detected when the routing device stops receiving a reply after a specified interval. BFD works with a wide variety of network environments and topologies. BFD failure detection times are shorter than RIP detection times, providing faster reaction times to various kinds of failures in the network. Instead of waiting for the routing protocol neighbor timeout, BFD provides rapid detection of link failures. BFD timers are adaptive and can be adjusted to be more or less aggressive. For example, a timer can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher value for a timer than the one configured. Note that the functionality of configuring BFD for RIP described in this topic is not supported in Junos OS Releases 15.1X49, 15.1X49-D30, or 15.1X49-D40.
EX4600 switches do not support minimum interval values of less than 1 second.
BFD enables quick failover between a primary and a secondary routed path. The protocol tests the operational status of the interface multiple times per second. BFD provides for configuration timers and thresholds for failure detection. For example, if the minimum interval is set for 50 milliseconds and the threshold uses the default value of three missed messages, a failure is detected on an interface within 200 milliseconds of the failure.
Intervening devices (for example, an Ethernet LAN switch) hide link-layer failures from routing protocol peers, such as when two routers are connected by way of a LAN switch, where the local interface status remains up even when a physical fault happens on the remote link. Link-layer failure detection times vary, depending on the physical media and the Layer 2 encapsulation. BFD can provide fast failure detection times for all media types, encapsulations, topologies, and routing protocols.
To enable BFD for RIP, both sides of the connection must receive an update message from the peer. By default, RIP does not export any routes. Therefore, you must enable update messages to be sent by configuring an export policy for routes before a BFD session is triggered.
Example: Configuring BFD for RIP
This example shows how to configure Bidirectional Forwarding Detection (BFD) for a RIP network.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
To enable failure detection, include the bfd-liveness-detection statement:
bfd-liveness-detection { detection-time { threshold milliseconds; } minimum-interval milliseconds; minimum-receive-interval milliseconds; multiplier number; no-adaptation; transmit-interval { threshold milliseconds; minimum-interval milliseconds; } version (1 | automatic); }
Optionally, you can specify the threshold for the adaptation
of the detection time by including the threshold statement.
When the BFD session detection time adapts to a value equal to or
greater than the threshold, a single trap and a system log message
are sent.
To specify the minimum transmit and receive interval for failure
detection, include the minimum-interval statement. This
value represents the minimum interval at which the local routing device
transmits hello packets as well as the minimum interval at which the
routing device expects to receive a reply from a neighbor with which
it has established a BFD session. You can configure a value in the
range from 1 through 255,000 milliseconds. This examples
sets a minimum interval of 600 milliseconds.
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 nonstop active routing configured, the minimum interval recommendations are unchanged and depend only on your network deployment.
You can optionally specify the minimum transmit and receive intervals separately.
To specify only the minimum receive interval for failure detection,
include the minimum-receive-interval statement. This value
represents the minimum interval at which the local routing device
expects to receive a reply from a neighbor with which it has established
a BFD session. You can configure a value in the range from 1
through 255,00 milliseconds.
To specify only the minimum transmit interval for failure detection,
include the transmit-interval minimum-interval statement.
This value represents the minimum interval at which the local routing
device transmits hello packets to the neighbor with which it has established
a BFD session. You can configure a value in the range from 1
through 255,000 milliseconds.
To specify the number of hello packets not received by a neighbor
that causes the originating interface to be declared down, include
the multiplier statement. The default is 3, and you
can configure a value in the range from 1 through 255.
To specify the threshold for detecting the adaptation of the
transmit interval, include the transmit-interval threshold statement. The threshold value must be greater than the transmit
interval.
To specify the BFD version used for detection, include the version statement. The default is to have the version detected
automatically.
You can trace BFD operations by including the traceoptions statement at the [edit protocols bfd] hierarchy level.
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. We recommend
that you not disable BFD adaptation unless it is preferable not to
have BFD adaptation enabled in your network.
Figure 1 shows the topology used in this example.
CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device R1.
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 R1
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set protocols bfd traceoptions file bfd-trace set protocols bfd traceoptions flag all set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.1 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept
Device R2
set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 5 family inet address 10.0.0.5/30 set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.2 set protocols rip group rip-group neighbor fe-1/2/1.5 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept
Device R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.6 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept
Step-by-Step Procedure
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 CLI User Guide.
To configure a BFD for a RIP network:
-
Configure the network interfaces.
[edit interfaces] user@R1# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
-
Create the RIP group and add the interface.
To configure RIP in Junos OS, you must configure a group that contains the interfaces on which RIP is enabled. You do not need to enable RIP on the loopback interface.
[edit protocols rip group rip-group] user@R1# set neighbor fe-1/2/0.1
-
Create the routing policy to advertise both direct and RIP-learned routes.
[edit policy-options policy-statement advertise-routes-through-rip term 1] user@R1# set from protocol direct user@R1# set from protocol rip user@R1# set then accept
-
Apply the routing policy.
In Junos OS, you can only apply RIP export policies at the group level.
[edit protocols rip group rip-group] user@R1# set export advertise-routes-through-rip
-
Enable BFD.
[edit protocols rip group rip-group] user@R1# set bfd-liveness-detection minimum-interval 600
-
Configure tracing operations to track BFD messages.
[edit protocols bfd traceoptions] user@R1# set file bfd-trace user@R1# set flag all
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, and show policy-options commands. If the output does
not display the intended configuration, repeat the configuration instructions
in this example to correct it.
user@R1# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
user@R1# show protocols
bfd {
traceoptions {
file bfd-trace;
flag all;
}
}
rip {
group rip-group {
export advertise-routes-through-rip;
bfd-liveness-detection {
minimum-interval 600;
}
neighbor fe-1/2/0.1;
}
}
user@R1# show policy-options
policy-statement advertise-routes-through-rip {
term 1 {
from protocol [ direct rip ];
then accept;
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying That the BFD Sessions Are Up
Purpose
Make sure that the BFD sessions are operating.
Action
From operational mode, enter the show bfd session command.
user@R1> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
10.0.0.2 Up fe-1/2/0.1 1.800 0.600 3
1 sessions, 1 clients
Cumulative transmit rate 1.7 pps, cumulative receive rate 1.7 ppsMeaning
The output shows that there are no authentication failures.
Checking the BFD Trace File
Purpose
Use tracing operations to verify that BFD packets are being exchanged.
Action
From operational mode, enter the show log command.
user@R1> show log bfd-trace Feb 16 10:26:32 PPM Trace: BFD periodic xmit to 10.0.0.2 (IFL 124, rtbl 53, single-hop port) Feb 16 10:26:32 Received Downstream TraceMsg (24) len 86: Feb 16 10:26:32 IfIndex (3) len 4: 0 Feb 16 10:26:32 Protocol (1) len 1: BFD Feb 16 10:26:32 Data (9) len 61: (hex) 42 46 44 20 70 61 63 6b 65 74 20 66 72 6f 6d 20 31 30 2e Feb 16 10:26:32 PPM Trace: BFD packet from 10.0.0.1 (IFL 73, rtbl 56, ttl 255) absorbed Feb 16 10:26:32 Received Downstream TraceMsg (24) len 60: Feb 16 10:26:32 IfIndex (3) len 4: 0 Feb 16 10:26:32 Protocol (1) len 1: BFD Feb 16 10:26:32 Data (9) len 35: (hex) 42 46 44 20 70 65 72 69 6f 64 69 63 20 78 6d 69 74 20 6f ...
Meaning
The output shows the normal functioning of BFD.
Understanding BFD Authentication for RIP
BFD enables rapid detection of communication failures between adjacent systems. By default, authentication for BFD sessions is disabled. However, when running 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 RIP. BFD authentication is only supported in the domestic image and is not available in the export image.
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 the 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 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.
See Also
Example: Configuring BFD Authentication for RIP
This example shows how to configure Bidirectional Forwarding Detection (BFD) authentication for a RIP network.
Requirements
No special configuration beyond device initialization is required before configuring this example.
The devices must be running Junos OS Release 9.6 or later.
Overview
Only three steps are needed to configure authentication on a BFD session:
Specify the BFD authentication algorithm for the RIP protocol.
Associate the authentication keychain with the RIP protocol.
Configure the related security authentication keychain.
Figure 2 shows the topology used in this example.
CLI Quick Configuration shows the configuration for all of the devices in Figure 2. The section #d45e66__d45e234 describes the steps on Device R1.
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, copy and paste the commands into the CLI
at the [edit] hierarchy level, and then enter commit from configuration mode.
Device R1
set interfaces fe-1/2/0 unit 1 family inet address 10.0.0.1/30 set protocols bfd traceoptions file bfd-trace set protocols bfd traceoptions flag all set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.1 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-rip set protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5 set protocols rip group rip-group bfd-liveness-detection authentication loose-check set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept set security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123 set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"
Device R2
set interfaces fe-1/2/0 unit 2 family inet address 10.0.0.2/30 set interfaces fe-1/2/1 unit 5 family inet address 10.0.0.5/30 set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.2 set protocols rip group rip-group neighbor fe-1/2/1.5 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-rip set protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5 set protocols rip group rip-group bfd-liveness-detection authentication loose-check set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept set security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123 set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"
Device R3
set interfaces fe-1/2/0 unit 6 family inet address 10.0.0.6/30 set protocols rip group rip-group export advertise-routes-through-rip set protocols rip group rip-group neighbor fe-1/2/0.6 set protocols rip group rip-group bfd-liveness-detection minimum-interval 600 set protocols rip group rip-group bfd-liveness-detection authentication key-chain bfd-rip set protocols rip group rip-group bfd-liveness-detection authentication algorithm keyed-md5 set protocols rip group rip-group bfd-liveness-detection authentication loose-check set policy-options policy-statement advertise-routes-through-rip term 1 from protocol direct set policy-options policy-statement advertise-routes-through-rip term 1 from protocol rip set policy-options policy-statement advertise-routes-through-rip term 1 then accept set security authentication-key-chains key-chain bfd-rip key 53 secret $ABC123$ABC123 set security authentication-key-chains key-chain bfd-rip key 53 start-time "2012-2-16.12:00:00 -0800"
Step-by-Step Procedure
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 CLI User Guide.
To configure a BFD authentication:
Configure the network interfaces.
[edit interfaces] user@R1# set fe-1/2/0 unit 1 family inet address 10.0.0.1/30
Create the RIP group and add the interface.
To configure RIP in Junos OS, you must configure a group that contains the interfaces on which RIP is enabled. You do not need to enable RIP on the loopback interface.
[edit protocols rip group rip-group] user@R1# set neighbor fe-1/2/0.1
Create the routing policy to advertise both direct and RIP-learned routes.
[edit policy-options policy-statement advertise-routes-through-rip term 1] user@R1# set from protocol direct user@R1# set from protocol rip user@R1# set then accept
Apply the routing policy.
In Junos OS, you can only apply RIP export policies at the group level.
[edit protocols rip group rip-group] user@R1# set export advertise-routes-through-rip
Enable BFD.
[edit protocols rip group rip-group] user@R1# set bfd-liveness-detection minimum-interval 600
Specify the algorithm (keyed-md5, keyed-sha-1, meticulous-keyed-md5, meticulous-keyed-sha-1, or simple-password) to use.
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.
[edit protocols rip group rip-group] user@R1# set bfd-liveness-detection authentication algorithm keyed-md5
Specify the keychain to be used to associate BFD sessions on RIP with the unique security authentication keychain attributes.
The keychain you specify must match a keychain name configured at the
[edit security authentication key-chains]hierarchy level.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.
[edit protocols rip group rip-group] user@R1# set bfd-liveness-detection authentication key-chain bfd-rip
(Optional) Specify loose authentication checking if you are transitioning from nonauthenticated sessions to authenticated sessions.
[edit protocols rip group rip-group] user@R1# set bfd-liveness-detection authentication loose-check
Specify the unique security authentication information for BFD sessions:
The matching keychain name as specified in Step 7.
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-rip] user@R1# set key 53 secret $ABC123$ABC123 user@R1# set key 53 start-time "2012-2-16.12:00:00 -0800"
Configure tracing operations to track BFD authentication.
[edit protocols bfd traceoptions] user@R1# set file bfd-trace user@R1# set flag all
Results
From configuration mode, confirm your configuration
by entering the show interfaces, show protocols, show policy-options, and show security commands.
If the output does not display the intended configuration, repeat
the configuration instructions in this example to correct it.
user@R1# show interfaces
fe-1/2/0 {
unit 1 {
family inet {
address 10.0.0.1/30;
}
}
}
user@R1# show protocols
bfd {
traceoptions {
file bfd-trace;
flag all;
}
}
rip {
group rip-group {
export advertise-routes-through-rip;
bfd-liveness-detection {
minimum-interval 600;
}
neighbor fe-1/2/0.1;
}
}
user@R1# show policy-options
policy-statement advertise-routes-through-rip {
term 1 {
from protocol [ direct rip ];
then accept;
}
}
user@R1# show security
authentication-key-chains {
key-chain bfd-rip {
key 53 {
secret $ABC123$ABC123
start-time "2012-2-16.12:00:00 -0800";
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
- Verifying That the BFD Sessions Are Authenticated
- Viewing Extensive Information About the BFD Authentication
- Checking the BFD Trace File
Verifying That the BFD Sessions Are Authenticated
Purpose
Make sure that the BFD sessions are authenticated.
Action
From operational mode, enter the show bfd session
detail command.
user@R1> show bfd session detail
Detect Transmit
Address State Interface Time Interval Multiplier
10.0.0.2 Up fe-1/2/0.1 1.800 0.600 3
Client RIP, TX interval 0.600, RX interval 0.600, Authenticate
Session up time 01:39:34
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Logical system 6, routing table index 53
1 sessions, 1 clients
Cumulative transmit rate 1.7 pps, cumulative receive rate 1.7 pps
Meaning
Authenticate is displayed to indicate that BFD authentication is configured.
Viewing Extensive Information About the BFD Authentication
Purpose
View the keychain name, the authentication algorithm and mode for each client in the session, and the BFD authentication configuration status.
Action
From operational mode, enter the show bfd session
extensive command.
user@R1> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
10.0.0.2 Up fe-1/2/0.1 1.800 0.600 3
Client RIP, TX interval 0.600, RX interval 0.600, Authenticate
keychain bfd-rip, algo keyed-md5, mode loose
Session up time 01:46:29
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Logical system 6, routing table index 53
Min async interval 0.600, min slow interval 1.000
Adaptive async TX interval 0.600, RX interval 0.600
Local min TX interval 0.600, minimum RX interval 0.600, multiplier 3
Remote min TX interval 0.600, min RX interval 0.600, multiplier 3
Local discriminator 225, remote discriminator 226
Echo mode disabled/inactive
Authentication enabled/active, keychain bfd-rip, algo keyed-md5, mode loose
Session ID: 0x300501
1 sessions, 1 clients
Cumulative transmit rate 1.7 pps, cumulative receive rate 1.7 ppsMeaning
The output shows the keychain name, the authentication algorithm and mode for the client in the session, and the BFD authentication configuration status.
Checking the BFD Trace File
Purpose
Use tracing operations to verify that BFD packets are being exchanged.
Action
From operational mode, enter the show log command.
user@R1> show log bfd-trace Feb 16 10:26:32 PPM Trace: BFD periodic xmit to 10.0.0.2 (IFL 124, rtbl 53, single-hop port) Feb 16 10:26:32 Received Downstream TraceMsg (24) len 86: Feb 16 10:26:32 IfIndex (3) len 4: 0 Feb 16 10:26:32 Protocol (1) len 1: BFD Feb 16 10:26:32 Data (9) len 61: (hex) 42 46 44 20 70 61 63 6b 65 74 20 66 72 6f 6d 20 31 30 2e Feb 16 10:26:32 PPM Trace: BFD packet from 10.0.0.1 (IFL 73, rtbl 56, ttl 255) absorbed Feb 16 10:26:32 Received Downstream TraceMsg (24) len 60: Feb 16 10:26:32 IfIndex (3) len 4: 0 Feb 16 10:26:32 Protocol (1) len 1: BFD Feb 16 10:26:32 Data (9) len 35: (hex) 42 46 44 20 70 65 72 69 6f 64 69 63 20 78 6d 69 74 20 6f ...
Meaning
The output shows the normal functioning of BFD.
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.