FRR bfdd on a VPP-managed interface goes through the LCP punt path. BFD echo mode does not work there (T9548): the returned echo packet (source = destination = own address) is dropped by ip4-local as a spoofed local-address packet.
VPP has its own BFD implementation. I tested it on 2026.10.16-0024-rolling (VPP 25.10.0) against FRR bfdd on a kernel-only peer:
| Case | Result |
|---|---|
| IPv4 single-hop session VPP <-> FRR | Up, stable |
| IPv4 multihop session VPP <-> FRR | Up |
| IPv6 single-hop session VPP <-> FRR | Up |
| Echo mode, VPP as echo sender (bfd udp echo-source set interface <if>) | works, roundtrip about 0.16 ms, bfd-udp-echo4-input counts, no spoof drop |
| Echo reflection by VPP for an FRR peer | works (FRR counted 1508/1508 echo packets) |
Notes from the test:
- The echo source interface needs an address that is not a /32. With 10.9.9.1/32 on the loopback VPP reported "usable as echo source: none", with 10.9.9.1/24 it worked.
- VPP offers authentication and a want_bfd_events API message, so state changes can be delivered to a daemon.
Not tested: VRF, authentication, sub-10 ms timers, how BGP/OSPF/static routes would learn the VPP session state.
Open design point: FRR protocols take BFD state from bfdd via zebra. VPP BFD sessions would need a bridge that creates the sessions in VPP and reports their state to FRR. Until such a feature exists, T9548 could be handled with a verify error or a warning for echo-mode on VPP interfaces.