From: [email protected] <[email protected]> on behalf of Inder via lists.fd.io <[email protected]> Date: Thursday, 23 April 2026 at 9:06 pm To: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [vpp-dev] IPv6 mFIB specific entries missing interfaces — ND broken due to Multicast RPF check failure Hi,
We're seeing an issue where IPv6 Neighbor Discovery is completely broken on certain VPP sub-interfaces because the IPv6 mFIB specific entries (ff02::1/128, ff02::2/128, ff02::16/128, ff02::1:ff00:0/104) created by the ND subsystem under the "Special" source do not include all IPv6-enabled interfaces in the VRF. VPP version: v25.10-release built on SUSE SETUP ----- Two servers connected back-to-back via 10G Intel X710 NICs with SR-IOV. VPP binds to a VF (iavf driver) on each server for the direct link. Each server also has a PF (i40e driver) connected to an upstream router. Both the VF sub-interface and PF sub-interface are in the same IPv6 VRF (table 2). OSPFv3 runs on the VF sub-interface between the servers (PtP link). Multiple servers deployed with identical VPP version and configuration. Interfaces per server in VRF table 2: - GigE-PF.200 — PF sub-interface (i40e), upstream router, IPv6 2001:db8:1::1/64 - TenG-VF.4091 — VF sub-interface (iavf), server-to-server direct, IPv6 fd00:ab:cd::1/125 - TenG-VF.4092 — VF sub-interface (iavf), additional link, IPv6 fd00:ab:cd::19/125 - host-internal.4091 — internal af_packet, IPv6 fd00:ab:cd::9/125 PROBLEM ------- IPv6 ping between servers on TenG-VF.4091 fails with 100% loss. IPv4 on the same interface works fine. OSPFv3 neighbor is Full (uses ff02::5 multicast which is unaffected). The issue is that incoming Neighbor Solicitation multicast packets on TenG-VF.4091 are dropped by VPP with "Multicast RPF check failed" because TenG-VF.4091 is missing from the specific mFIB entries. The general ff00::/8 entry correctly includes all 4 interfaces. But the specific entries only include GigE-PF.200. Since specific entries win via longest-prefix-match, the RPF check fails for any interface not listed in them. This is not consistent across servers — with identical VPP version and config, some servers have all 4 interfaces in the specific entries (working), others have only 1 or 2 (broken). The issue is deterministic per server and survives VPP restart. WHAT WE TRIED (none fixed the mFIB) ------------------------------------ 1. ip mroute add/del via CLI — silently ignored, cannot modify "Special" source entries 2. ip mroute add with Accept-all-itf flag — added as CLI source but Special source takes precedence 3. Removing and re-adding IPv6 addresses on affected interface — re-joins ff00::/8 but not specific entries 4. Removing IPv6 from ALL interfaces and re-adding — specific entries persist with empty lists, only one interface gets re-added 5. Interface admin down/up — no effect on mFIB 6. VPP restart — reproduces same broken state 7. Static IPv6 neighbors (bypassing ND) — unicast IPv6 works perfectly, confirming data plane is fine QUESTIONS --------- 1. Is there a known issue with the ND subsystem not adding interfaces to existing specific mFIB entries when they join the same multicast group? Nope. Given it works on some of your servers but not others, if there is a bug it depends on the differences between your servers. Perhaps in the order the config was entered? Do the interfaces’ addresses appear in a different [incorrect] table (i.e. they weren’t correctly moved when the interface was added to a VRF). 2. Is there a way to force the Special source to re-evaluate interface membership at runtime? nope 3. Is there a startup config option that controls this behavior? Nope /neale Detailed logs and mFIB dumps from both working and broken servers are in the attached file. Thanks for any guidance.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26998): https://lists.fd.io/g/vpp-dev/message/26998 Mute This Topic: https://lists.fd.io/mt/118969596/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
