Configuring Bidirectional Forwarding Detection on Cisco IOS XR
Available Languages
Table Of Contents
Configuring Bidirectional Forwarding Detection on Cisco IOS XR Software
Prerequisites for Configuring BFD
Restrictions for Configuring BFD
Differences in BFD in Cisco IOS XR Software and Cisco IOS Software
BFD Source and Destination Ports
BFD Packet Intervals and Failure Detection
Priority Settings for BFD Packets
Enabling BFD on a BGP Neighbor
Enabling BFD for OSPF on an Interface
Enabling BFD on a Static Route
Enabling Echo Mode to Test the Forwarding Path to a BFD Peer
Overriding the Default Echo Packet Source Address
Specifying the Echo Packet Source Address Globally for BFD
Specifying the Echo Packet Source Address on an Individual Interface or Bundle
Configuring BFD Session Teardown Based on Echo Latency Detection
Delaying BFD Session Startup Until Verification of Echo Path and Latency
Disabling Echo Mode on a Router
Disabling Echo Mode on an Individual Interface
Minimizing BFD Session Flapping Using BFD Dampening
Clearing and Displaying BFD Counters
Configuration Examples for Configuring BFD
BFD Over Static Routes: Example
000000000000000000000000 Echo Packet Source Address: Examples
Echo Latency Detection: Examples
Echo Startup Validation: Examples
BFD Echo Mode Disable: Examples
BFD Peers on Routers Running Cisco IOS and Cisco IOS XR Software: Example
Configuring Bidirectional Forwarding Detection on Cisco IOS XR Software
This module describes the configuration of bidirectional forwarding detection (BFD) on the Cisco XR 12000 Series Router.
Bidirectional forwarding detection (BFD) provides low-overhead, short-duration detection of failures in the path between adjacent forwarding engines. BFD allows a single mechanism to be used for failure detection over any media and at any protocol layer, with a wide range of detection times and overhead. The fast detection of failures provides immediate reaction to failure in the event of a failed link or neighbor.
Feature History for Configuring Bidirectional Forwarding Detection on Cisco IOS XR Software
Contents
•
Prerequisites for Configuring BFD
•
•
Prerequisites for Configuring BFD
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
The following prerequisites are required to implement BFD:
•
•
•
–
–
–
•
•
Restrictions for Configuring BFD
The following restrictions apply to BFD:
•
•
–
–
–
•
•
Information About BFD
To configure BFD, you should understand the following concepts:
•
Differences in BFD in Cisco IOS XR Software and Cisco IOS Software
If you are already familiar with BFD configuration in Cisco IOS software, be sure to consider the following differences in BFD configuration in the Cisco IOS XR software implementation:
•
•
•
•
BFD Modes of Operation
Cisco IOS XR software supports the asynchronous mode of operation only, with or without using echo packets. Asynchronous mode without echo will engage various pieces of packet switching paths on local and remote systems. However, asynchronous mode with echo is usually known to provide slightly wider test coverage as echo packets are self-destined packets which traverse same packet switching paths as normal traffic on the remote system.
BFD echo mode is enabled by default for the following interfaces:
•
•
When BFD is running asynchronously without echo packets (Figure 1), the following occurs:
•
•
•
Figure 1 BFD Asynchronous Mode Without Echo Packets
When BFD is running asynchronously with echo packets (Figure 2), the following occurs:
•
•
Figure 2 BFD Asynchronous Mode With Echo Packets
For more information about control and echo packet intervals in asynchronous mode, see the "BFD Packet Intervals and Failure Detection" section.
BFD Packet Information
This section includes the following topics:
•
•
•
BFD Source and Destination Ports
BFD payload control packets are encapsulated in UDP packets, using destination port 3784 and source port 49152. Even on shared media, like Ethernet, BFD control packets are always sent as unicast packets to the BFD peer.
Echo packets are encapsulated in UDP packets, as well, using destination port 3785 and source port 3785.
The BFD over bundle member feature increments each byte of the UDP source port on echo packets with each transmission. UDP source port ranges from 0xC0C0 to 0xFFFF. For example:
1st echo packet: 0xC0C0
2nd echo packet: 0xC1C1
3rd echo packet: 0xC2C2
The UDP source port is incremented so that sequential echo packets are hashed to deviating bundle member.
BFD Packet Intervals and Failure Detection
BFD uses configurable intervals and multipliers to specify the periods at which control and echo packets are sent in asynchronous mode and their corresponding failure detection.
When BFD is running over physical interfaces, echo mode is used only if the configured interval is less than two seconds.
BFD sessions running over physical interfaces when echo mode is enabled send BFD control packets at a slow rate of every two seconds. There is no need to duplicate control packet failure detection at a fast rate because BFD echo packets are already being sent at fast rates and link failures will be detected when echo packets are not received within the echo failure detection time.
Control Packet Failure Detection In Asynchronous Mode
Control packet failure is detected using the values of the minimum interval (bfd minimum-interval) and multiplier (bfd multiplier) commands.
For control packet failure detection, the local multiplier value is sent to the neighbor. A failure detection timer is started based on (I x M), where I is the negotiated interval, and M is the multiplier provided by the remote end.
Whenever a valid control packet is received from the neighbor, the failure detection timer is reset. If a valid control packet is not received from the neighbor within the time period (I x M), then the failure detection timer is triggered, and the neighbor is declared down.
Echo Packet Failure Detection In Asynchronous Mode
The standard echo failure detection scheme on all BFD interfaces is done through a counter that is based on the value of the bfd multiplier command.
This counter is incremented each time the system sends an echo packet, and is reset to zero whenever any echo packet is received, regardless of the order that the packet was sent in the echo packet stream.
Under ideal conditions, this means that BFD generally detects echo failures that exceed the period of time (I x M), where:
•
•
So, if the system transmits one additional echo packet beyond the multiplier count without receipt of any echo packets, echo failure is detected and the neighbor is declared down (See Example 2).
However, this standard echo failure detection does not address latency between transmission and receipt of any specific echo packet, which can build beyond (I x M) over the course of the BFD session. In this case, BFD will not declare a neighbor down as long as any echo packet continues to be received within the multiplier window and resets the counter to zero. Beginning in Cisco IOS XR 4.0.1, you can configure BFD to measure this latency for non-bundle interfaces. For more information, see Example 3 and the "Echo Packet Latency" section.
Echo Failure Detection Examples
This section provides examples of several scenarios of standard echo packet processing and failure detection without configuration of latency detection for non-bundle interfaces. In these examples, consider an interval of 50 ms and a multiplier of 3.
Example 1
The following example shows an ideal case where each echo packet is returned before the next echo is transmitted. In this case, the counter increments to 1 and is returned to 0 before the next echo is sent and no echo failure occurs. As long as the roundtip delay for echo packets in the session is less than the minimum interval, this scenario occurs:
Time (T): Echo#1 TX (count = 1)T + 1 ms: Echo#1 RX (count = 0)T + 50 ms: Echo#2 TX (count = 1)T + 51 ms: Echo#2 RX (count = 0)T + 100 ms: Echo#3 TX (count = 1)T + 101 ms: Echo#3 RX (count = 0)T + 150 ms: Echo#4 TX (count = 1)T + 151 ms: Echo#4 RX (count = 0)Example 2
The following example shows the absence in return of any echo packets. After the transmission of the fourth echo packet, the counter exceeds the multiplier value of 3 and echo failure is detected. In this case, echo failure detection occurs at the 150 ms (I x M) window:
Time (T): Echo#1 TX (count = 1)T + 50 ms: Echo#2 TX (count = 2)T + 100 ms: Echo#3 TX (count = 3)T + 150 ms: Echo#4 TX (count = 4 -> echo failureExample 3
The following example shows an example of how roundtrip latency can build beyond (I x M) for any particular echo packet over the course of a BFD session using the standard echo failure detection, but latency between return of echo packets overall in the session never exceeds the (I x M) window and the counter never exceeds the multiplier, so the neighbor is not declared down.
Note
Time (T): Echo#1 TX (count = 1)T + 1 ms: Echo#1 RX (count = 0)T + 50 ms: Echo#2 TX (count = 1)T + 51 ms: Echo#2 RX (count = 0)T + 100 ms: Echo#3 TX (count = 1)T + 150 ms: Echo#4 TX (count = 2)T + 151 ms: Echo#3 RX (count = 0; ~50 ms roundtrip latency)T + 200 ms: Echo#5 TX (count = 1)T + 250 ms: Echo#6 TX (count = 2)T + 251 ms: Echo#4 RX (count = 0; ~100 ms roundtrip latency)T + 300 ms: Echo#7 TX (count = 1)T + 350 ms: Echo#8 TX (count = 2)T + 351 ms: Echo#5 RX (count = 0; ~150 ms roundtrip latency)T + 451 ms: Echo#6 RX (count = 0; ~200 ms roundtrip latency; no failure detection)T + 501 ms: Echo#7 RX (count = 0; ~200 ms roundtrip latency; no failure detection)T + 551 ms: Echo#8 RX (count = 0; ~200 ms roundtrip latency; no failure detection)Looking at the delay between receipt of echo packets for the BFD session, observe that no latency is beyond the (I x M) window:
Echo#1 RX - Echo#2 RX: 50 msEcho#2 RX - Echo#3 RX: 100msEcho#3 RX - Echo#4 RX: 100msEcho#4 RX - Echo#5 RX: 100msEcho#5 RX - Echo#6 RX: 100msEcho#6 RX - Echo#7 RX: 50msEcho#7 RX - Echo#8 RX: 50msEcho Packet Latency
In Cisco IOS XR software releases prior to Cisco IOS XR 4.0.1, BFD only detects an absence of receipt of echo packets, not a specific delay for TX/RX of a particular echo packet. In some cases, receipt of BFD echo packets in general can be within their overall tolerances for failure detection and packet transmission, but a longer delay might develop over a period of time for any particular roundtrip of an echo packet (See Example 3).
Beginning in Cisco IOS XR 4.0.1, you can configure the router to detect the actual latency between transmitted and received echo packets on non-bundle interfaces and also take down the session when the latency exceeds configured thresholds for that roundtrip latency. For more information, see the "Configuring BFD Session Teardown Based on Echo Latency Detection" section.
In addition, you can verify that the echo packet path is within specified latency tolerances before starting a BFD session. With echo startup validation, an echo packet is periodically transmitted on the link while it is down to verify successful transmission within the configured latency before allowing the BFD session to change state. For more information, see the "Delaying BFD Session Startup Until Verification of Echo Path and Latency" section.
Priority Settings for BFD Packets
For all interfaces under over-subscription, the internal priority needs to be assigned to remote BFD Echo packets, so that these BFD packets are not overwhelmed by other data packets. In addition, CoS values need to be set appropriately, so that in the event of an intermediate switch, the reply back of remote BFD Echo packets are protected from all other packets in the switch.
As configured CoS values in ethernet headers may not be retained in Echo messages, CoS values must be explicitly configured in the appropriate egress QoS service policy. CoS values for BFD packets attached to a traffic class can be set using the set cos command. For more information on configuring class-based unconditional packet marking, see "Configuring Modular QoS Packet Classification" in the Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco XR 12000 Series Router.
BFD for IPv4
Cisco IOS XR software supports bidirectional forwarding detection (BFD) for IPv4.
In BFD for IPv4 single-hop connectivity, Cisco IOS XR software supports both asynchronous mode and echo mode over physical numbered Packet-over-SONET/SDH (POS) and Gigabit Ethernet links, as follows:
•
•
•
Consider the following guidelines when configuring BFD on Cisco IOS XR software:
•
•
–
–
–
–
–
–
–
–
Note
•
–
–
–
–
–
•
•
How to Configure BFD
This section includes the following procedures:
•
•
•
•
•
•
•
•
BFD Configuration Guidelines
Before you configure BFD, consider the following guidelines:
•
•
•
–
•
•
–
–
"; $head.append(linkElement); } if (cdc.eot.isToc && !linkItemsLen) { addNewTocStyleSheet(); } else if (cdc.eot.isEot) { jQuery("#eot-doc-wrapper link[rel='stylesheet']").each(function () { const linkTag = jQuery(this), hrefVal = jQuery(linkTag).attr("href"); if (hrefVal != undefined && hrefVal.indexOf("support-responsive.css") == -1 && hrefVal.indexOf("_responsive.css") == -1) { let fileName = hrefVal.substr(hrefVal.lastIndexOf("/") + 1, hrefVal.length).split(".css")[0]; const filePath = "/etc/designs/cdc/transformation/"; if (fileName == "ccimr") { fileName = "techdocs_responsive"; } else if (fileName == "support-docs") { fileName = "support-responsive"; } else if (fileName == "framework") { fileName = "responsiveframework"; } else if (fileName == "dcmt") { fileName = "wemdcmt_responsive"; } else if (fileName == "techdocs_85_11_word") { fileName = "techdocs_85_11_word"; if (cdc.eot.isToc) { addNewTocStyleSheet(); } } else { fileName += "_responsive"; } jQuery(linkTag).attr("href", filePath + fileName + ".css"); } if (hrefVal.indexOf("support-responsive.css") > -1) { jQuery(linkTag).attr("href", "/etc/designs/cdc/transformation/support-responsive.css"); } }); jQuery("#eot-doc-wrapper > table").wrap(""); jQuery("#eot-doc-wrapper table:not('.olh_note')").parent().css({ overflowX: "auto" }); } });
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)