Yes, thanks. Just to ensure we are on the same page, I'm talking about communication between two clients, one of which is connected to the VPP second to kernel-based

https://github.com/vyos/vyos-1x/pull/5606

https://github.com/vyos/vyos1x-config/pull/99
https://github.com/vyos/vyos-1x/pull/5586

https://github.com/vyos/vyos-1x/pull/5601

Reproduced on rolling with openvpn 2.7.7, on a lightly loaded lab router in client mode: set interfaces openvpn vtun31 description <x> + commit on a running client gives

It is expected for VPP as it does not add a gateway IP address on its own PPP interfaces
But forwarding traffic should work fine

https://github.com/vyos/vyos-1x/pull/5605

https://github.com/vyos/vyos-1x/pull/5604

https://github.com/vyos/vyos-1x/pull/5603

@rherold

so please confirm that this is the intended behaviour.

https://github.com/vyos/vyos-1x/pull/5602

https://github.com/vyos/vyos-build/pull/1336

A second report of this, with the cause confirmed.

Thanks for the extra data, and the ConnectX-6 Dx result matters: in the DPDK 25.07 feature files mlx5 lists no PPPoE flow item, only the Intel ice driver does. So there is no common NIC feature to rely on, and a solution that spreads the upstream PPPoE traffic in software is the general answer. NIC hashing (E810 with the Comms package) would be an optional addition for one vendor, and VPP would need changes for it as well (no PPPoE entry in its RSS type list, no PPPoE flow type in vnet flow).

As mentioned, VyOS does not ship with testpmd.
This falls outside the scope of what VyOS distributes; hence, I'd prefer VyOS developers' input on what they'd like to do before proceeding.
I'd also like to iterate that the issue is not NIC-specific; VPP never asks the NIC for PPP hashing, hence the issue. I tested with a ConnectX-6 Dx and various other NICs and saw the same thing.

correction to my last comment, after reading the DPDK test plan for the ice driver (ice_advanced_rss_pppoe).

https://github.com/vyos/vyos-1x/pull/5597

Thanks for the details. The loaded package is the OS Default package, and rss active lists only the IP and TCP/UDP types, so nothing on the NIC hashes on the PPPoE header. That fits what you see: all upstream PPPoE ends up on queue 0, and the plain IP downstream is spread.

Hi Ruben,

Two notes from vyos/vyos-1x#5565 (T9468, vpn ipsec site-to-site peer <peer> vti traffic-selector split-by-family), in case it helps the review here.

A note on how this overlaps with T9482 / https://github.com/vyos/vyos-1x/pull/5582, in case someone picks this up.

The PR covers physical VPP interfaces like your eth1 and their VLANs. A VPP loopback, bond or tunnel as MPLS interface is refused for now: after a reboot the entry of such an interface was lost when the saved configuration is loaded, so I did not want to accept it silently. That can follow as a separate change.

PR for Quickfix: https://github.com/vyos/vyos-1x/pull/5596

Hi,
I can fully confirm this analysis. The root cause is a fundamental architectural blind spot in the current integration between the Linux Control Plane (LCP) and VPP.
When Keepalived is configured with rfc3768-compatibility, it dynamically spawns a separate macvlan interface inside the Linux kernel to handle the Virtual MAC (VMAC) and VIP. Because VPP only mirrors interfaces it explicitly owns and initializes, its Netlink listener completely ignores these dynamic sub-interfaces added by external tools. Since VPP acts as the exclusive gatekeeper for the physical hardware interface (eth1), it looks up its local FIB, finds no /32 entry for the VIP, and drops 100% of incoming ARP requests for it before they can ever reach the Linux TAP/Keepalived daemon.
Even workarounds like Keepalived's vmac_xmit_base fail here because they only affect outbound advertisements, leaving inbound ARP resolution completely broken.

@Viacheslav should I try to backport to vyos?

It was merged to frr today: https://github.com/FRRouting/frr/pull/23779.

I looked at the task and at the VPP source. What I can say without an E810 here:

PRs:
https://github.com/vyos/vyos1x-config/pull/100
https://github.com/vyos/vyatta-cfg/pull/158
https://github.com/vyos/vyos-1x/pull/5592

@a.pidnebesny the fix is in the draft PR https://github.com/vyos/vyos-1x/pull/5595. If you want to test it before it is merged, there is no image yet, but you can apply it to a running lab router: the attached T9518-vpp-mpls-enable.patch (three Python files) plus one line in a JSON file, with a backup and a revert. The steps are in the attached T9518-test-instructions.md.

I reproduced this on a lab pair (VPP router plus a kernel router, LDP over eth0). set protocols mpls interface eth0 only sets the kernel side (/proc/sys/net/mpls/conf/eth0/input). In VPP the feature stays at mpls-not-enabled and show errors counts mpls-input: MPLS not enabled.

Thanks team - appreciate the quick turn around! 👍

I have implemented new approach to drive the admin state of VTI interfaces from strongSwan via VICI plugin:

• https://github.com/vyos/vyos-1x/pull/5594

@woodsb02 see the PR mentioned above https://github.com/vyos/vyos-build/pull/1329

PR: https://github.com/vyos/vyos-build/pull/1335

https://github.com/vyos/vyos-1x/pull/5593

Hi Viacheslav - can you please provide a link or description as to how this was resolved?

https://github.com/vyos/vyos-build/pull/1334

To late the build test and pr.is.allready running.

In T9514#283701, @rherold wrote:

I can test and create a PR

I can test and create a PR

We can always use the patched VPP version https://github.com/vyos/vyos-vpp-patches/tree/rolling/patches/vpp
Needs to check if we can apply it to our version (stable/2510).

Update: a fix for the underlying VPP problem is uploaded to Gerrit: https://gerrit.fd.io/r/c/vpp/+/47276 (issue: https://github.com/FDio/vpp/issues/3756). It changes one line in arp_dst_fib_check() and adds a unit test. With a build of VPP master plus this change, the reproducer gets its ARP answer after the takeover (0% packet loss) without any neighbor deletion. The transition-script workaround stays useful until the change is merged and VyOS has a VPP build that contains it.

*Two additions, one correction.

I could reproduce this on a lab VM pair (rolling 2026.10.16-0024, VPP bound to eth0 on the backup node, the master node without VPP, VRRP1 vrid 1, VIP 198.51.100.100/24, priorities 200 / 100).