Configure and Verify BFD on Nexus 9000: Step-by-Step

Bidirectional Forwarding Detection (BFD) is the difference between a routing protocol converging in seconds and failing over in milliseconds, but getting the session parameters and verification right on NX-OS requires more than flipping a feature switch. This guide follows Cisco TAC's official procedure to enable BFD globally, tune timers, bind it to OSPF/EIGRP/BGP, and — most importantly — verify the sessions with the correct show commands, counters and packet captures. The examples are based on NX-OS 10.3(4a) on Nexus 9000 switches, and the same flow applies to other NX-OS data center platforms.

What BFD Actually Does

BFD is a lightweight, protocol-independent hello mechanism with a single job: detect a forwarding-path failure between two nodes faster than any routing protocol can on its own. It carries no routes and elects no master — it simply tells the routing protocol that registered with it whether the neighbour is still reachable, and lets that protocol react on its own terms. On a Nexus 9000 in a leaf-spine fabric, that is what turns a 40-second OSPF dead interval into a sub-second reconvergence event.

Two modes matter in practice:

• Asynchronous mode — both endpoints send BFD Control packets at a negotiated transmit interval over UDP port 3785, and each side declares the session down when no packet arrives within the detection time (multiplier × the negotiated receive interval). This is the default and the mode covered throughout this article.
• Echo mode — the local router sends echo packets that the remote system reflects back through its own forwarding path. Echo packets are never processed by the far-end control plane, so less state is required, but echo demands that the neighbour support it and is a very common source of false session-down events when the returned packet is dropped in the forwarding path.

BFD also splits sessions into single-hop (directly connected peers, control packets sent with TTL 255) and multihop (peers reachable through one or more routers, TTL 254, requires the multihop keyword). Classifying the session incorrectly is the single most common reason a session sticks in Down state forever while both routers insist the configuration is correct.

Detection Time Math

Three knobs — interval (min_tx), min_rx and multiplier — combine into the detection time. Both neighbours advertise their own values and the slower side wins, so the effective detection time is always the worse of the two ends, not the one you typed on the local router.

Tightening timers is not free: every 50 ms session consumes a session slot and packets per direction from the supervisor or line-card ASIC, and oversubscribed hardware BFD tables drop sessions silently. Cisco's guidance is to start at 500 × 500 with multiplier 3 and only tighten once you have confirmed the platform supports the scale you intend to run.

Enable the BFD Feature

BFD must be enabled before it can be configured on interfaces and protocols:

SW1(config)# feature bfd

Skip this and the bfd keywords under an interface or routing protocol are simply rejected, usually with a cryptic parse message. Confirm the feature actually took hold before going further:

SW1(config)# show running-config | include "feature bfd"
SW1# show feature | include bfd

Configure Global and Interface BFD Timers

Global parameters are inherited by all sessions; per-interface settings override them:

SW1(config)# bfd interval 500 min_rx 500 multiplier 3
SW1(config)# interface vlan 20
SW1(config-if)# bfd interval 500 min_rx 500 multiplier 3
SW1(config-if)# no ip redirects
SW1(config-if)# no ipv6 redirects

The min_tx and msec range is 50–999 ms (default 50), and the multiplier ranges from 1 to 50 (default 3). Always disable ICMP redirects on BFD-enabled interfaces.

Two further knobs are worth knowing about. bfd echo-interface loopback30 pins the source address of echo packets to a stable interface, and bfd slow-timer 2000 sets a separate, much slower timer used while a session is administratively down or transitioning, so a flapping link cannot hammer the supervisor CPU. The slow timer has no effect on a healthy session's detection time.

Bind BFD to Routing Protocols

BFD on OSPF

SW1(config)# router ospf 1
SW1(config-router)# bfd
SW1(config)# interface vlan 10
SW1(config-if)# ip ospf bfd

The protocol-level bfd command enables BFD support for that process; the interface-level command opts the interface in. Both are required — a very common half-configuration leaves the router-wide knob enabled and the interface silent, and the session never forms.

BFD on EIGRP

SW1(config)# router eigrp 2
SW1(config-router)# bfd
SW1(config)# interface vlan 20
SW1(config-if)# ip eigrp 2 bfd

BFD on BGP (Multihop)

SW1(config)# router bgp 65001
SW1(config-router)# address-family ipv4 unicast
SW1(config-router)# neighbor 192.168.3.1
SW1(config-router-neighbor)# bfd multihop
SW1(config-router-neighbor)# update-source loopback30

Specifying multihop or singlehop determines the session type; without a keyword, directly connected peers default to singlehop. For a multihop session over loopbacks, the update-source matters as much as the BFD keyword: the session is sourced from the interface you name, and if both ends pick different addresses the session never leaves Down.

Verify BFD Sessions

Confirm neighbors are automatically detected and inspect session state:

show bfd neighbors
show bfd neighbors interface lo30 details

Details show the registered protocol, echo function usage, holdown timers, and RX/TX counters. Use show bfd clients to list which protocols registered sessions, and show system internal bfd sess-store interface vlan 10 for session store details.

Reading the Session Detail Output

Knowing which field to look at saves an escalation. In show bfd neighbors details:

• OurAddr / NeighAddr — the source and destination of the BFD control packets. These must be the two loopbacks you expect for a multihop session.
• LD/RD — the local and remote discriminator. A zero RD means the far end has never replied, so the problem is one-way reachability or a mismatched session type, not timers.
• Holdown (ms) — the agreed detection time. If this reads far higher than the value you configured, the neighbour's multiplier or interval is larger than yours and the slower side won.
• Type — SH (single-hop) or MH (multihop). A mismatch here is fatal and silent.
• State — Up, Init, Down. Init means one direction of control packets is being received but the far end is not acknowledging.
• TX/RX counters — non-zero and roughly equal in both directions on a healthy session. A session that is Up with a frozen RX counter is about to go Down.

Understanding BFD Down Reasons

Syslog reasons tell you exactly why a session dropped:

%BFD-5-SESSION_STATE_DOWN: BFD session ... Reason: Path Down.
... Reason: Echo Function Failed.
... Reason: Neighbor Signaled Session Down.
... Reason: Control Detection Time Expired.

An Echo Function Failed with the echo function enabled, for example, points to the forwarding path rather than the control plane. The other three map cleanly onto distinct failure domains:

• Path Down — the local interface or the protocol that owns the session went away. Look at the interface counters first.
• Neighbor Signaled Session Down — the far end decided to tear the session down, usually because its own routing protocol instance was removed or administratively disabled.
• Control Detection Time Expired — packets stopped arriving within the holdown window. The control plane is fine locally, so the culprit is queuing, a microburst on the path, a policer, or a genuinely silent neighbour.

Packet-Level Verification with Ethanalyzer

Capture BFD control and echo traffic on the inband interface (UDP port 3785):

SW1# ethanalyzer local interface inband display-filter "udp.port==3785" limit-captured-frames 0

For a BGP multihop session, filter on the loopback IPs and look for BFD Control packets alternating between both neighbors every ~250 ms. On a healthy multihop session you should see both source addresses in the capture; if only one appears, the return path is being filtered — often by a control-plane policing policy or an ACL that forgot to allow UDP 3785.

Remember that ethanalyzer captures on the supervisor's inband interface, so hardware-offloaded BFD sessions may not show up at all. If the capture is empty but the session is Up, the session is being handled in hardware and there is nothing on the CPU path to see.

Platform and Scale Notes

Hardware-offloaded BFD sessions are what make tight timers viable at scale, and the limits are not uniform across the Nexus 9000 family. A 9300-class leaf may support several hundred hardware sessions while the fixed-form 9200 series is tighter; a session that cannot be offloaded either falls back to the supervisor CPU or fails to establish, and there is no error unless you go looking for one. Before standardising on 50 ms timers across a fabric, count the potential sessions per device — protocol neighbours multiplied by participating interfaces — and compare that against the platform's documented hardware BFD limit. When in doubt, 300–500 ms is the right answer. The operational difference between a 150 ms and a 1.5 s detection time is rarely visible to an application; the difference between 300 sessions and 2000 sessions definitely is.

Common Failure Modes

• Feature not enabled — configuration is accepted in some contexts but no session ever forms. Always check show feature | include bfd.
• Protocol knob missing — bfd under the router process without the interface opt-in, or vice versa.
• Session type mismatch — one end single-hop, the other multihop.
• Asymmetric source addresses — multihop sessions sourced from different loopbacks.
• Echo mismatch — one peer sending echo while the other does not support it, producing intermittent Echo Function Failed events. Disable echo on one side while you isolate the number of variables.
• Hardware session exhaustion — hundreds of tight-timer sessions on a platform with a limited hardware BFD table. Sessions silently fall back or fail; check platform scale documentation.

Design Guidance for a Fabric

In a Nexus 9000 leaf-spine fabric, BFD belongs on the underlay routing protocol neighbours — the leaf-to-spine links — where a sub-second detection time lets the fabric withdraw a failed path before any application notices. It is less useful on host-facing ports: a server NIC going down is already signalled by link state, and BFD only adds overhead. Pair BFD with maximum-paths so the surviving equal-cost paths absorb the traffic immediately, and verify convergence with a real traffic test rather than trusting the routing table alone.

For related NX-OS/IOS XR practice, check our guides on troubleshooting input drops in Cisco IOS XR and interface CRC error troubleshooting, plus the OSPF side of NX-OS in Cisco Nexus NX-OS OSPF configuration examples, the Junos equivalent in Junos BFD liveness detection and MC-LAG integration, and the IP SLA alternative where BFD is not supported end to end in Cisco IOS IP SLA with track objects.

原文链接：https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/221944-configure-and-verify-bfd-on-nexus-9000-s.html