Explains core BFD operating behavior, including packet timing, failure detection, priority handling, bundle operation, dampening, hardware offload, and multipath support.
This topic introduces BFD and summarizes how it works in the network.
BFD packet intervals on physical interfaces
This topic explains the BFD control packet transmission behavior on physical interfaces when echo mode is enabled.
BFD packet transmission behavior
When BFD is running over physical interfaces, echo mode is used only if the configured interval is less than two seconds.
When BFD is running over physical interfaces, the system manages packet intervals to prevent redundant high-frequency control packet processing.
These conditions apply to BFD sessions on physical interfaces:
-
Fast rate control packet duplication is unnecessary because echo packets provide the required fast-rate failure detection.
-
Failure detection is triggered when echo packets are not received within the echo failure detection time.
Control packet failure detection in asynchronous mode
Control packet failure detection in asynchronous mode is a detection process that
-
identifies neighbor connectivity loss by monitoring the receipt of valid control packets within a calculated time interval
-
uses the minimum interval as the configured time between control packets, and
-
uses the multiplier to determine the failure detection time.
-
Minimum interval: The configured time duration between control packets, defined by bfd minimum-interval or bfd address-family ipv4 minimum-interval .
-
Multiplier: The factor used to determine the failure detection time, defined by bfd multiplier or bfd address-family ipv4 multiplier .
Failure detection logic
The system calculates the failure detection timer based on the formula ( I x M ), where I is the negotiated interval and M is the multiplier provided by the remote neighbor. The local multiplier value is communicated to the neighbor to facilitate this calculation.
The detection process uses these steps:
-
The system starts a failure detection timer based on the product of the negotiated interval and the remote multiplier.
-
The system resets the timer whenever a valid control packet is received from the neighbor.
-
The system declares the neighbor down if no valid control packet is received before the timer expires.
Priority settings for BFD packets
Priority settings for BFD packets are QoS-related settings that
-
assign internal priority to remote BFD Echo packets
-
configure explicit CoS values in egress QoS service policies, and
-
protect BFD Echo packet replies from other traffic in intermediate switches.
BFD packet priority configuration requirements
Because CoS values in ethernet headers may not be retained in Echo messages, you must explicitly configure these values to maintain traffic prioritization.
Use set cos command to manage CoS values for BFD packets attached to a traffic class.
For more information on configuring class-based unconditional packet marking, see Modular QoS Configuration Guide for Cisco 8000 Series Routers.
BFD dampening
BFD dampening is a configurable exponential delay mechanism that
-
suppresses BFD notifications until the monitored session stabilizes
-
reduces processing resource consumption on network devices, and
-
improves convergence time and overall network stability.
BFD dampening prevents excessive notification to BFD clients when a remote node reachability event flaps.
| Feature Name |
Release |
Description |
|---|---|---|
| BFD dampening |
Release 25.4.1 | Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*) |
| BFD dampening |
Release 25.1.1 | Introduced in this release on: Fixed Systems ( 8010 [ASIC: A100]) |
| BFD dampening |
Release 24.4.1 | Introduced in this release on: Fixed Systems( 8700) (select variants only*). |
| BFD dampening |
Release 24.2.11 | Introduced in this release on: Modular Systems (8800 [LC ASIC: P100]) (select variants only*). |
Bidirectional Forwarding Detection (BFD) helps routing protocols detect reachability failures quickly and notify neighboring devices immediately. When BFD detects a reachability change for a client, it notifies the client neighbors at once.
In some cases, you might need to minimize routing table changes during a microfailure to avoid affecting convergence. An unstable link that flaps repeatedly can cause other devices in the network to use significant processing resources. This condition can also cause routing protocols to lose synchronization with the state of the flapping link.
BFD dampening uses a configurable exponential delay mechanism to reduce the effects of repeated remote-node reachability flaps. It lets the network operator automatically dampen a BFD session and reduce excessive notifications to BFD clients. This behavior helps prevent unnecessary network instability. Dampening suppresses BFD notifications until the monitored session stops flapping and becomes stable.
BFD session dampening configuration
Configure BFD dampening, especially on a high-speed interface with routing clients, to improve convergence and network stability. BFD dampening applies to all BFD session types, including IPv4 single-hop, Multiprotocol Label Switching Transport Profile (MPLS-TP), and pseudowire (PW) Virtual Circuit Connection Verification (VCCV).
Configure BFD dampening at the single-hop BFD template level. Dampening applies to every session that uses that template. If you do not want dampening on a session, use a different template without dampening. By default, templates do not enable dampening.
Configure BFD dampening
The dampening values can be defined for bundle member interfaces and for the non-bundle interfaces.
Procedure
| 1. | Configure the initial and maximum delay for BFD session startup on BFD bundle members. Example: |
|
| 2. | Change the default initial-wait and maximum-wait for BFD on a non-bundle interface. Example:Specifies delays in milliseconds for BFD session startup to control flapping. The value for maximum-wait should be greater than the value for initial-wait . |
BFD multipath sessions
BFD multipath sessions are BFD sessions that
-
run over virtual interfaces such as GRE tunnel interfaces, PWHE interfaces, or interfaces that are multiple hops away
-
support connectivity monitoring across multiple underlying paths, and
-
can migrate when a hosting line card is removed or enters maintenance mode.
BFD multipath session characteristics
These events can affect BFD multipath session stability, depending on the negotiated interval and forwarding-plane convergence time:
-
Failure of a path
-
Online insertion or removal (OIR) of a line card which hosts one or more paths
-
Removal of a link (by configuration) which constitutes a path
-
Shutdown of a link which constitutes a path
| Feature Name |
Release |
Description |
|---|---|---|
| BFD multipath sessions |
Release 25.4.1 |
Introduced in this release on: Fixed Systems (8700 [ASIC: K100])(select variants only*) *This feature is supported on Cisco 8711-48Z-M routers. |
| BFD multipath sessions |
Release 25.1.1 |
Introduced in this release on: Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100])(select variants only*) *This feature is supported on: 8712-MOD-M, 8011-4G24Y4H-I |
| BFD multipath sessions |
Release 24.4.1 |
Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only*); Modular Systems (8800 [LC ASIC: P100])(select variants only*) *This feature is supported on: 8212-48FH-M, 8711-32FH-M, 88-LC1-36EH, 88-LC1-12TH24FH-E, 88-LC1-52Y8H-EM |
Configuration guidelines for BFD multipath sessions
-
Configure the bfd mutlipath include location location-id command on at least one line card. This line card sends and receives packets for BFD multipath sessions.
-
If you remove a line card that hosts a BFD multipath session, BFD tries to move the session to another line card. During the move, static routes are removed from the RIB. BFD then reestablishes the session and adds it back to the RIB.
-
If BFD packets need priority handling, configure a QoS policy across the entire path, including ingress and egress interfaces. Classify BFD packets into priority level 1 or priority level 2 queues.
-
For centralized platforms, use only MPA locations, such as 0/1, for BFD multipath configuration. Do not use line card locations, such as 0/1/CPU0, because BFD multipath does not support them.
IPv4 multihop BFD
IPv4 multihop BFD is a BFD session that
-
is established between two addresses across two nodes over paths that span multiple network hops
-
supports subsecond failure detection for destinations up to
255hops away, and -
integrates with external and internal BGP applications.
You can configure the bfd multihop ttl-drop-threshold command to drop packets from neighbors that exceed a specified hop count.
| Feature Name |
Release |
Description |
|---|---|---|
| IPv4 multihop BFD |
Release 25.4.1 |
Introduced in this release on Fixed Systems (8700 [ASIC: K100], 8010 [ASIC: A100]). |
| IPv4 multihop BFD |
Release 24.2.11 |
Introduced in this release on Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100]) and Modular Systems (8800 [LC ASIC: P100]). |
IPv4 multihop BFD establishes a BFD session between two addresses on different nodes. You can use it for a BFD session between PE and CE loopback addresses or between routers that are several TTL hops apart.
Configure IPv4 multihop BFD
Procedure
| 1. | Configure the BFD multihop parameters and BGP neighbor settings for the platform. Example: |
|
| 2. | Configure the BFD multihop parameters for centralized platforms if required. Example: |
|
| 3. | Verify the configuration details and status of IPv4 multihop BFD using the show tech-support bfdhwoff command. Example: |