Cisco Catalyst 9300 BFD Echo Failure: Troubleshooting Session Flaps and Restoring Stability

A physical link can stay up and exchange BFD Control packets while the BFD session flaps because its Echo path fails. In this Catalyst 9300 case, Echo transmit counters increased while receive counters stayed at zero. Disabling Echo on the affected interface restored session stability. The cause of Echo packet loss remained unconfirmed.

Conceptual symptom: BFD Control is received while the Echo return path fails. This diagram does not identify where packets are lost.

Environment

Item	Environment
Platform	Cisco Catalyst 9300
Deployment	Stack
Headquarters IOS XE	17.12.5
Branch IOS XE	17.18.4
Affected function	BFD Echo
Operational workaround	Disable BFD Echo on the affected interface

For a separate guide covering configuration order and verification for Catalyst 9300 BFD deployments, see Cisco Catalyst 9300 HQoS and Static BFD: Configuration Order and Verification.

Observed symptoms

• BFD Control packets were received.
• BFD Echo transmit counters increased.
• BFD Echo receive counters remained at zero.
• The affected session repeatedly transitioned between DOWN, INIT, and UP.
• Diagnostic information included Echo Function Failed.
• Another BFD session between the devices remained stable.

Control reception and Echo forwarding needed separate checks; successful Control exchange did not validate the Echo path.

For an Ethernet example where traffic continued despite a duplex mismatch, see Cisco CDP Duplex Mismatch: FastEthernet Full, GigabitEthernet Half.

What Echo tests

Echo packets test the forwarding path. Check Cisco's release-specific requirements, including ICMP redirect and uRPF interactions, when investigating Echo failures.

Illustrative BFD configuration

This generic Cisco documentation example is separate from the incident's production configuration.

interface GigabitEthernet1/0/1
 no switchport
 ip address 192.0.2.1 255.255.255.252
 no ip redirects
 bfd interval 100 min_rx 100 multiplier 3

The timer values are examples. A supported routing or static-route BFD client must also register; interface timers alone do not configure static-route tracking.

Check the session, compare working and failing paths, check Echo TX/RX, then inspect interface configuration and filtering.

Troubleshooting steps

1. Check the BFD session

show bfd neighbors
show bfd neighbors details

Compare state, diagnostics, negotiated timers, registered clients, and Echo information.

2. Compare a working session with the failing session

Use the working session between the same devices as a baseline. Compare interfaces, forwarding, counters, and captures to identify differences on the failing path.

3. Check Echo TX and RX behavior

Observation	Affected session
Echo TX	Increasing
Echo RX	Zero
BFD Control RX	Received
Session state	Repeated transitions

These counters point to Echo-path failure but do not locate the loss.

Workaround: disable BFD Echo

The workaround applied to the affected interface was:

configure terminal
interface GigabitEthernet1/0/1
 no bfd echo
end

Cisco documents interface-level no bfd echo. Confirm support and behavior for the deployed platform and release. Echo disablement can retain asynchronous Control operation while changing detection behavior. It may renegotiate BFD or transiently change session state. Review convergence requirements and verify the result as an operational change.

After disabling Echo on the affected interface, verify BFD stability, detection parameters, and the dependent routing client. The original root cause remains unconfirmed.

Verification after the change

show bfd neighbors
show bfd neighbors details

Check that the session reaches UP and remains stable, Echo is no longer required on that interface, negotiated detection parameters are acceptable, and the dependent routing client works. The session became stable after disabling Echo. This verifies the workaround's observed result, while leaving the loss mechanism unresolved.

Unconfirmed causes to investigate

Unconfirmed hypotheses for further investigation:

• Forwarding-path differences: interface-specific configuration, forwarding-table programming, or hardware packet handling may differ between the working and failing paths.
• Packet filtering: ACLs or other filtering mechanisms may affect the Echo path and require packet capture and counter verification.
• uRPF interaction: Cisco documents restrictions involving BFD Echo and uRPF. This should be checked if uRPF is configured.
• Software behavior: the devices ran different IOS XE releases, but version difference alone does not establish a software defect. A reproducible test or matching Cisco defect record would be required.

Operational checks

• Separate BFD Control behavior from Echo behavior during troubleshooting.
• Use a working BFD session as a comparison baseline when available.
• Treat Echo Function Failed as a reason to investigate the Echo forwarding path specifically.
• Do not present a successful workaround as a confirmed root cause.
• After disabling Echo, verify that the resulting BFD detection characteristics still meet operational requirements.

Session result

Disabling Echo restored the affected session's stability. The precise cause of the failed Echo return path remained unconfirmed.

Official references

• Cisco, IP Routing Configuration Guide, Cisco IOS XE Dublin 17.12.x (Catalyst 9300 Switches): Configuring Bidirectional Forwarding Detection.
• Cisco, Command Reference, Cisco IOS XE 17.18.x (Catalyst 9300 Switches): bfd echo.