Customer Service Public - BFD Troubleshooting Guide for Routing Protocols (BGP / OSPF)

BFD Troubleshooting Guide for Routing Protocols

BFD Protocol

BFD (Bidirectional Forwarding Detection), when enabled, detects connectivity failures faster and notifies routing protocols such as BGP, OSPF and static routes so that they can bring down routes faster. BFD runs alongside the routing protocols because the routing protocols themselves take longer to detect that a peer is down. BFD uses aggressive timers to detect link failures quickly.

Problem

The BFD session is not coming up between VOS and peer devices, or routing protocols (BGP/OSPF/static routes) are not reacting to BFD state changes.

General BFD Session Troubleshooting

Check the BFD session state and Rx packet count from the VOS CLI to confirm BFD packets are being received from the peer:

show bfd session detail
Sat Nov 14 12:17:47 PST 2026

Routing Instance: DC-VR
Remote Address: 192.168.100.2      State: up
  Rx Pkts: 504                   Tx Pkts: 502                   Rx PktDrops: 0
  Session up time         : 00:01:29
  Minimum Tx Interval     : 200000
  Minimum Rx Interval     : 200000
  Detect Time Multiplier  : 3
  Session History 1(Most Recent)
  Session Up Time    : 00:00:23()
  Session Down Time  : 00:00:02()
  Session Down Cause : Detection Timer Expired.
  Session History 2:
  Session Up Time    : 00:16:51()
  Session Down Time  : 00:01:02()
  Session Down Cause : Detection Timer Expired.

Verify that the Rx Pkts counter is incrementing. If the Rx counter is zero, BFD packets from the peer are not reaching VOS.

Make sure VOS is sending BFD packets out of the interface. Run VOS tcpdump on the egress interface to confirm that BFD packets (UDP port 3784 for single-hop, 4784 for multi-hop) are leaving VOS:

tcpdump vni-0/0 filter "udp port 3784"
tcpdump vni-0/0 filter "udp port 4784"    (multi-hop BFD)

Sample output:

20:25:29.256493 0c:a9:a5:ae:00:02 > 0c:9f:93:42:00:02, ethertype IPv4 (0x0800), length 66: (tos 0xc0, ttl 255, id 58918, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.100.1.49152 > 192.168.100.2.3784: [udp sum ok] BFDv1, length: 24
	Control, State Up, Flags: [Control Plane Independent], Diagnostic: No Diagnostic (0x00)
	Detection Timer Multiplier: 3 (600 ms Detection time), BFD Length: 24
	My Discriminator: 0x80000013, Your Discriminator: 0x80000012
	  Desired min Tx Interval:     200 ms
	  Required min Rx Interval:    200 ms
	  Required min Echo Interval:    0 ms
20:25:29.384507 0c:9f:93:42:00:02 > 0c:a9:a5:ae:00:02, ethertype IPv4 (0x0800), length 66: (tos 0xc0, ttl 255, id 55500, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.100.2.49152 > 192.168.100.1.3784: [udp sum ok] BFDv1, length: 24
	Control, State Up, Flags: [Control Plane Independent], Diagnostic: No Diagnostic (0x00)
	Detection Timer Multiplier: 3 (600 ms Detection time), BFD Length: 24
	My Discriminator: 0x80000012, Your Discriminator: 0x80000013
	  Desired min Tx Interval:     200 ms
	  Required min Rx Interval:    200 ms
	  Required min Echo Interval:    0 ms
20:25:29.440493 0c:a9:a5:ae:00:02 > 0c:9f:93:42:00:02, ethertype IPv4 (0x0800), length 66: (tos 0xc0, ttl 255, id 58961, offset 0, flags [DF], proto UDP (17), length 52)
    192.168.100.1.49152 > 192.168.100.2.3784: [udp sum ok] BFDv1, length: 24
	Control, State Up, Flags: [Control Plane Independent], Diagnostic: No Diagnostic (0x00)
	Detection Timer Multiplier: 3 (600 ms Detection time), BFD Length: 24
	My Discriminator: 0x80000013, Your Discriminator: 0x80000012
	  Desired min Tx Interval:     200 ms
	  Required min Rx Interval:    200 ms
	  Required min Echo Interval:    0 ms

If VOS is sending BFD packets and the remote device is not replying, troubleshoot the peer device. Make sure the BFD packets sent by VOS reach the BFD module on the peer, using the peer device's debugging/troubleshooting guide.
Check for intermediate devices (firewalls/ACLs) dropping UDP 3784/4784, and confirm TTL = 255 for single-hop BFD (GTSM). Also verify the session is not flapping due to link errors or high CPU.

Understanding BFD Discriminators

BFD runs many sessions over the same IPs and ports, for example one per neighbor, VRF or interface, or multi-hop sessions. The discriminator is how a router tells which session an incoming packet belongs to, without relying on IP addresses alone.

My Discriminator: a unique, non-zero ID the sender picked for its own copy of the session.
Your Discriminator: the sender echoes back the ID it learned from the peer's "My Discriminator". Before it has learned one, it sends 0.

When a packet arrives, the receiver looks up the session by the Your Discriminator field, which is its own local ID.

How the session gets established

Down: each side sends its own My Discriminator with Your Discriminator = 0, because it does not know the peer's ID yet.
Init: each side learns the peer's ID from the received packet and starts echoing it.
Up: both sides send both values, crossed over as shown in the capture above.

When discriminators signal a problem

Your Discriminator stays 0 after the session should be up: that side is not receiving or accepting the peer's packets. Common causes are a one-way path, an ACL or firewall blocking UDP 3784, or a TTL/GTSM mismatch.
Your Discriminator does not match the peer's My Discriminator: the receiver discards the packet. This happens with a stale session after a peer restart, until the session resets and relearns the IDs.
Discriminator changes after a flap: this is normal. A router may pick a new local ID when a session is recreated.

BFD with BGP

Symptoms

The BGP session stays up long after a link failure, BGP flaps whenever BFD flaps, or the BFD session for the BGP neighbor never establishes.

Troubleshooting

Verify that BFD is enabled under the BGP neighbor/peer-group on both VOS and the peer:

set routing-instances DC-VR protocols bgp 1 group DC1-DC2 bfd-liveness-detection
set routing-instances DC-VR protocols bgp 1 group DC1-DC2 bfd-liveness-detection minimum-receive-interval 200
set routing-instances DC-VR protocols bgp 1 group DC1-DC2 bfd-liveness-detection multiplier 3
set routing-instances DC-VR protocols bgp 1 group DC1-DC2 bfd-liveness-detection transmit-interval minimum-interval 200

Confirm that the BGP session itself is Established first. The BFD session for BGP is created only after the BGP session comes up:

BGP instance: 1
Peer: 192.168.100.2+47782 AS 65002     Local: 192.168.100.1+179 AS 65001
 Site Name:
  Type: External    State: Established    Up for: 58s
  Last State: Openconfirm   Last Event: RecvKeepAlive
  Last Error: Cease
  Last Error Node:
  Last Conn up Time Stamp: 20:29:34, PST, 14 November 2026
  Last Conn down Time Stamp: 20:30:23, PST, 14 November 2026
  Last Sent Error: Cease
  Last Sent Error Time: 23:16:28, PST, 12 November 2026
  Last Received Error: Cease
  Last Received Error Time: 02:11:04, PST, 14 November 2026
  History Error: Cease  (History is previous to Last)
  History Error Node: remote
  History Conn up Time Stamp: 12:16:18, PST, 14 November 2026
  History Conn down Time Stamp: 20:29:32, PST, 14 November 2026
  Number of flaps: 28
  Holdtime: 90
  Peer Router ID: 192.168.100.2  Local Router ID: 192.168.100.1
  Keepalive Interval: 30
  BFD: enabled, up
  NLRI advertised by peer: inet-unicast
  NLRI for this session:   inet-unicast
  Peer supports Refresh functionality
  Peer does not support Restarter functionality
  Peer supports 4 byte AS extension (peer-as 65002)
  Peer does not support Outbound Route Filtering functionality
  Peer supports extended message length capability
  Input messages:  Total 267333  Updates 287     Refreshes 0
  Output messages: Total 267279  Updates 281     Refreshes 0

Check that a BFD session exists for the BGP neighbor address and is in the Up state. For eBGP multi-hop neighbors, confirm that multi-hop BFD (UDP 4784) is enabled and supported on both ends.

Verify BFD client registration: BGP should be listed as the client of the BFD session in the show bfd session detail output.

On BFD down, confirm that BGP receives the notification and tears down the session. Check the logs:

routing    bfdNbrStateChange    2026-11-14T11:57:58-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T12:14:50-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T12:15:52-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T12:16:16-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T12:16:19-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T20:29:32-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T20:29:35-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T20:30:23-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T20:30:25-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state

If BGP flaps continuously with BFD enabled, the timers may be too aggressive for the WAN link. Increase the transmit/receive interval or the multiplier on both ends and re-test.

BFD with OSPF

Symptoms

OSPF takes the dead-interval time (default 40 s) to detect a neighbor failure, the OSPF adjacency flaps with BFD, or the BFD session for the OSPF neighbor does not come up.

Troubleshooting

Verify that BFD is enabled under the OSPF interface configuration on both VOS and the peer:

set routing-instances DC-VR protocols ospf 1 area 0 network-name DC1-DC2-P2P bfd-liveness-detection
set routing-instances DC-VR protocols ospf 1 area 0 network-name DC1-DC2-P2P bfd-liveness-detection minimum-receive-interval 200
set routing-instances DC-VR protocols ospf 1 area 0 network-name DC1-DC2-P2P bfd-liveness-detection multiplier 3
set routing-instances DC-VR protocols ospf 1 area 0 network-name DC1-DC2-P2P bfd-liveness-detection transmit-interval minimum-interval 200

Confirm that the OSPF adjacency reaches the Full state first. The BFD session is triggered after the neighbor comes up:

admin@DC1-SVNF-cli> show ospf neighbor extensive
State codes: atmpt - attempt, exchg - exchange, exst - exchange start,
             load  - loading, 2-way - two-way, full - full
Op codes:    gdown - going down, gup - going up

Intf address    Interface    State     Neighbor ID      Pri   Op
------------    ---------    -----     -----------      ---   --
192.168.100.2   vni-0/1.0    full      192.168.100.2    1     up
  Area: 0.0.0.0 DR: none BDR: none
  Admin state: up
  Relationship state with neighbor: full
  Neighbor priority: 1; Options: 0x42; Re-transmission queue length: 0
  Number of neighbor relationship state changes or error: 95
  Permanence: dynamic  Hellos suppressed: no  Requested LSAs: 0
  Dead timer due in: 00:00:35 (hrs:mins:secs:n/a)
  Hitless restart status: not helping
  Remaining hitless restart interval: none
  Hitless restart result: none
[ok][2026-11-14 20:37:14]

Check that a BFD session exists to the OSPF neighbor's interface address and is Up. OSPF uses single-hop BFD, so confirm UDP 3784 and TTL 255:

show bfd session detail
Sat Nov 14 12:17:47 PST 2026

Routing Instance: DC-VR
Remote Address: 192.168.100.2      State: up
  Rx Pkts: 504                   Tx Pkts: 502                   Rx PktDrops: 0
  Session up time         : 00:01:29
  Minimum Tx Interval     : 200000
  Minimum Rx Interval     : 200000
  Detect Time Multiplier  : 3
  Session History 1(Most Recent)
  Session Up Time    : 00:00:23()
  Session Down Time  : 00:00:02()
  Session Down Cause : Detection Timer Expired.
  Session History 2:
  Session Up Time    : 00:16:51()
  Session Down Time  : 00:01:02()
  Session Down Cause : Detection Timer Expired.

On BFD down, confirm that OSPF brings the neighbor down immediately. Check the logs:

routing    bfdNbrStateChange    2026-11-14T12:15:52-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T12:16:16-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T12:16:19-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T20:29:32-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T20:29:35-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state
routing    bfdNbrStateChange    2026-11-14T20:30:23-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Up state to Down state
routing    bfdNbrStateChange    2026-11-14T20:30:25-0800 routing-instance DC-VR: BFD neighbor 192.168.100.2 changed from Init state to Up state

If the adjacency flaps with BFD enabled, check for interface errors, MTU issues, or CPU spikes causing BFD timeouts. Relax the BFD timers if link quality is poor.