Hi,
We're hitting a glean adjacency bug on VPP 25.10 (stable/2510, December
2025 build) with the LCP plugin. Hoping someone can confirm if
this is known or point us at the right fix.
Setup:
- VPP handles all dataplane forwarding (VRF tables, sub-interfaces,
ARP/ND)
- LCP plugin creates TAP interface pairs: each VPP sub-interface (e.g.,
eth0.71) gets a corresponding Linux TAP in a dedicated network
namespace (dataplane)
- BIRD runs natively inside the dataplane namespace, managing routes on
the Linux TAPs
- LCP mirrors routes between Linux and VPP bidirectionally — when BIRD
installs a route in Linux, LCP syncs it into the VPP FIB
- A separate controller application programs VPP interface IPs via the
binary API (set interface ip address)
- ~200 VRFs configured, each with a /29 subnet on a VLAN sub-interface
(e.g., .8 = network, .9 = upstream router, .11 = our node IP)
Problem:
VPP builds glean adjacencies for connected /29 subnets using the network
address (e.g., .8) as the ARP source instead of the node's
interface address (e.g., .11). When VPP needs to resolve the upstream
router (.9), it sends:
ARP: Who has 10.168.71.9? Tell 10.168.71.8
The upstream router caches VPP's MAC against .8. Since .8 hits a
connected-drop in VPP (network address), all return traffic to that MAC
is blackholed.
Root Cause — Ordering Race:
1. Controller creates sub-interface, assigns it to a VRF table, enables
LCP on it
2. BIRD (or kernel) installs the /29 connected route on the Linux TAP
3. LCP mirrors that route into VPP FIB → VPP creates a glean adjacency.
Since no host IP exists on the VPP interface yet, it uses the
subnet network address (.8) as the glean source
4. Controller then adds the interface IP via binary API: set interface ip
address eth0.71 10.168.71.11/29
5. VPP creates the /32 host route with provides-glean flag, BUT the
already-existing /29 glean adjacency is never updated with the correct
source address
FIB state confirming the bug:
vppctl> show ip fib table 72 10.168.71.11/32
10.168.71.11/32 entry-flags:connected,local,
src-flags:added,contributing,active,provides-glean
# But /29 glean still uses network address as source — BUG
vppctl> show ip fib table 72 10.168.71.8/29
[@4]: ipv4-glean: [src:10.168.71.8/29] eth0.71
# Expected: ipv4-glean: [src:10.168.71.11/29] eth0.71
Reproduction (minimal):
# Create sub-interface in VRF
vppctl create sub eth0 71
vppctl set interface state eth0.71 up
vppctl set interface ip table eth0.71 72
# Enable LCP (creates Linux TAP)
vppctl lcp create eth0.71 host-if eth0.71
# In Linux, enslave TAP to VRF device
ip netns exec dataplane ip link set eth0.71 master vrf72
# Install connected route from Linux BEFORE VPP has an IP
# (simulates BIRD/kernel winning the race)
ip netns exec dataplane ip route add 10.168.71.8/29 dev eth0.71 table 72
proto static
sleep 1
# Now add interface IP via VPP (after LCP already mirrored the route)
vppctl set interface ip address eth0.71 10.168.71.11/29
sleep 1
# Verify: glean source is wrong
vppctl show ip fib table 72 10.168.71.8/29
# Shows: ipv4-glean: [src:10.168.71.8/29] ← should be 10.168.71.11
# Connectivity broken
vppctl ping 10.168.71.9 source eth0.71 repeat 3
# 100% packet loss
Questions:
1. Is this a known issue? We couldn't find an existing bug report.
2. It seems like ip4_glean_add_or_lock() (or the adjacency update path)
should re-evaluate the glean source when a provides-glean host
route is subsequently added to an interface that already has a glean. Is
that the right place to look?
3. Is there a non-disruptive way to force VPP to rebuild the glean with
the correct source address?
Any pointers appreciated. Happy to test patches.
regards
Inderpal Singh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#27137): https://lists.fd.io/g/vpp-dev/message/27137
Mute This Topic: https://lists.fd.io/mt/120827278/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
