Page MenuHomeVyOS Platform
Create Task
Maniphest T9548

BFD echo-mode over VPP echo packets not return
Open, Requires assessmentPublicBUG
Actions

Description

With echo-mode enabled on a BFD peer reached over a VPP interface, the peer's VPP correctly
reflects the echo packet, but when it comes back to the sender's own VPP, it is dropped as a
"spoofed" local-address packet (source address equals one of the node's own addresses) before it
ever reaches bfdd.

Steps to reproduce

# r1
configure
set vpp settings interface eth1
set interfaces ethernet eth1 address '10.0.0.1/30'
set protocols bfd peer 10.0.0.2 interval transmit '500'
set protocols bfd peer 10.0.0.2 interval receive '500'
set protocols bfd peer 10.0.0.2 interval multiplier '3'
commit
save
# r2
configure
set vpp settings interface eth1
set interfaces ethernet eth1 address '10.0.0.2/30'
set protocols bfd peer 10.0.0.1 interval transmit '500'
set protocols bfd peer 10.0.0.1 interval receive '500'
set protocols bfd peer 10.0.0.1 interval multiplier '3'
commit
save

Confirm the session is up on both

Then enable echo-mode on both:

# r1
configure
set protocols bfd peer 10.0.0.2 echo-mode
set protocols bfd peer 10.0.0.2 interval echo-interval '100'
commit
save
# r2
configure
set protocols bfd peer 10.0.0.1 echo-mode
set protocols bfd peer 10.0.0.1 interval echo-interval '100'
commit
save

Wait a few seconds, then on any node: show bfd peer <oterh side ip> counters.

Expected (?)

echo-packet-input tracks echo-packet-output (every echo sent by this node comes back from the
peer and is counted).

Actual

echo-packet-output ok; echo-packet-input stays at 0.

vyos@vpp1-r1:~$ show bfd peer 10.0.0.2 counters
        peer 10.0.0.2 vrf default
                ID: 1716907203
                Control packet input: 120894 packets
                Control packet output: 122248 packets
                Echo packet input: 0 packets
                Echo packet output: 137477 packets
                Session up events: 34370
                Session down events: 34370
                Zebra notifications: 68740
                RX fail packet: 636


---
vyos@vpp1-r2:~$ show bfd peer 10.0.0.1 counters
        peer 10.0.0.1 vrf default
                ID: 1950781669
                Control packet input: 121166 packets
                Control packet output: 121714 packets
                Echo packet input: 0 packets
                Echo packet output: 137406 packets
                Session up events: 34424
                Session down events: 34424
                Zebra notifications: 68848
                RX fail packet: 656

vppctl show errors - 138197 ip4-local ip4 spoofed local-address packet dr error 

vyos@vpp1-r1:~$ vppctl show errors
   Count                  Node                              Reason               Severity 
       416             arp-reply                       ARP replies sent            info   
       412             arp-reply             ARP request IP4 source address lear   info   
         4             ip6-input                    ip6 source lookup miss         error  
         5        ip6-local-hop-by-hop       Unknown protocol ip6 local h-b-h pa   error  
    138197             ip4-local             ip4 spoofed local-address packet dr   error  
         1           ip6-icmp-input          neighbor solicitations for unknown    error  
         8           ip6-icmp-input           neighbor discovery not configured    error  
      7586             llc-input                    unknown llc ssap/dsap          error  
vyos@vpp1-r1:~$

Details

Version
1.5-rolling-202610191432
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Unspecified (please specify)

Related Objects

Event Timeline

a.pidnebesny created this task.Fri, Oct 30, 1:55 PM
pasik subscribed.Fri, Oct 30, 5:57 PM
rherold subscribed.Sat, Oct 31, 5:50 AM

I reproduced this on 2026.10.16-0024-rolling (VPP 25.10.0, FRR 10.7.1) with two VMs and a direct link. One side runs VPP on the link interface, the other side uses the kernel only (no VPP).

Result with echo-mode on both sides:

  • VPP side: Echo packet input: 0, Echo packet output grows, the session flaps (16 up/down events in about 3 minutes).
  • Kernel side: Echo packet input equals Echo packet output (143/143), no problem on this side.

So the reflecting side does not matter. The loss happens on the VPP node that receives its own echo packet back.

VPP trace and counters on the VPP side:

UDP: 10.0.0.1 -> 10.0.0.1
UDP: 3785 -> 3785
...
10  ip4-local  ip4 spoofed local-address packet drops  error

The returned echo packet has the node's own address as source and destination, and ip4-local drops it before it reaches bfdd. This confirms the description in the task.

Control: with echo-mode removed on both sides the session is stable (no new up events in 40 s, same echo counters).

Notes:

  • VPP has its own BFD implementation. bfd udp echo-source set interface <interface> exists in the VPP CLI (echo source is not set by default). I found no BFD handling in the VyOS VPP code, so VyOS uses FRR bfdd only.
  • I did not test whether a separate echo source address in FRR would avoid the drop. FRR bfdd uses the session's local address.

Possible direction: either reject or warn about echo-mode on peers whose interface is a VPP interface until a fix exists, or look into the VPP side. I can prepare a warning in the BFD verify code if that is wanted.

rherold mentioned this in T9552: VPP: use the native VPP BFD implementation instead of FRR bfdd on VPP interfaces.Sat, Oct 31, 5:52 AM