Follow-up: I filed T9552 for the longer-term direction. VPP has a native BFD implementation, and in my lab it interoperates with FRR bfdd on a kernel-only peer (IPv4 single-hop, multihop and IPv6 sessions came up, and with bfd udp echo-source set interface <if> the echo mode works without the spoofed-address drop described here). What is missing is a bridge that creates the sessions in VPP and reports their state to FRR, see T9552 for the details and the open points.

PR: https://github.com/vyos/vyos-1x/pull/5615

I reproduced this on 2026.10.16-0024-rolling with two VMs (peer A without connection-type, peer B with connection-type none, VTI):

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).

I checked the current state of this on a 2026.10.16 image, because the reverted fix left the original problem open.

I could reproduce this on a 2026.10.16 rolling image (r2 only: VPP, pppoe-server with local users, two clients behind eth0 and eth2). Two findings, one of them different from the description.

I could reproduce this on a 2026.10.16 rolling image (r2 only: VPP, pppoe-server with local users, two clients behind eth0 and eth2). Two findings, one of them different from the description.

Context from the discussion in vyos-1x#5558 (comments of jestabro on 2026-10-27 and 2026-10-29): starting the timer before the commit is intended for the action reboot. A failed partial commit should be rebooted, the reboot into the saved configuration is the safety net. The ticket is the part that was left open there: the API cannot tell a commit that failed before anything was applied from one that failed after some scripts ran.

@Viacheslav I know but I can only do draft pr cause the five pr limit on the repo

ollowing the discussion here I looked at the patch route for Kea 3.0.3.

I could reproduce this on a 2026.10.16 rolling image (two VMs, VPP on eth0, kernel on eth2 of the server, same pppoe-server configuration as in the report, local users). Two sessions come up: rvtest2 on the VPP side (pppoe_session0, 10.255.0.10) and rvtest on the kernel side (ppp0, 10.255.0.11). From the VPP client a ping to the kernel client gets 100% loss, a ping to the gateway 10.255.0.1 as well. The kernel client reaches the gateway.

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).

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

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.

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:

@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.

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

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

I can test and create a PR

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).

Addition on the image side, the rtrlib part is the real blocker.

@saadinnocent909 if NAT44 together with PPPoE crashes again on a build with the current fixes, this is what I need, in this order:

saadinnocent909 thank you, and thanks for the permission: the T9502 pull request (https://github.com/accel-ppp/accel-ppp-ng/pull/46) quotes your v6 results and your comment on T9502 about the second crash.

Quick heads-up: I’ll be attending an event next week (RIPE93 in Sofia) , but I’ll still be working on the tickets as usual, so no worries about any major delays.
On a side note, I’ve been really enjoying our exchanges and would love to learn a bit more about your specific use case outside of this ticket system whenever you have some free time.
If you’re open to a quick off-topic chat, feel free to reach out to me via email at (ruben at insecure . pw)

The fix is open as a pull request: https://github.com/accel-ppp/accel-ppp-ng/pull/45

The change is open as a pull request: https://github.com/accel-ppp/accel-ppp-ng/pull/46

PR: https://github.com/accel-ppp/accel-ppp-ng/pull/45

@saadinnocent909 thank you, this is the most useful test so far: a full day with about 2,000 sessions, the exact comparison of the accounting stop with show interface, and the details on the resets.

@Viacheslav thanks. I do not think the RFC decides this, so let me explain what I mean.

@saadinnocent909 sorry for the confusion with the last build. I described v5 as "v3 plus the review changes", but it was built on a newer accel-ppp-ng base than v3, and I left out the policer change from v4, which is the one you are testing for the SIGBUS. Please use v6 and ignore v5.

@saadinnocent909 there is a new test build, v5: https://cloud.insecure.pw/s/695B3YeXyZWpHn6

PR: https://github.com/vyos/vyos-1x/pull/5590

@saadinnocent909 (a mention subscribes you to this task) for your answers about crashes see https://vyos.dev/T9211, where I ask about the backtrace, the NAT44 output-feature workaround and the policer. The crash of T9501 (NAT44, nat_pre_in2out_output) is a different one from the crash of this task (policer_input_node_fn_hsw). T9211 reports a second VPP restart (14:41:22 UTC) without a cause, which could be either of them. The hook that creates and deletes the session interface is where the policer features are removed here and where marking each pppoe_sessionN as NAT inside (option 1 of T9501) would go, so if that is done the removal has to be the reverse of the setup from the start.

@saadinnocent909 a question for your crash tests, so that the VPP crashes are not mixed up. There are at least two different ones now:

Test result so far: on a VM with three sessions with a RADIUS rate limit (VPP policers in use) and a ping flood on each, ending all sessions and reconnecting 15 times, VPP did not crash with the old order and not with the new order, and no policer was left behind after any round with the new order. With three sessions the window is too small to hit, so this does not show that the new order is the fix, only that it removes the policers cleanly. A build with the change is in the task T9211 for the tester, who has the load for it.

@saadinnocent909 a fourth test build, for the policer crash (https://vyos.dev/T9502). It is the third build plus one change in libvyos_vpp.so, the other two files are the same:

@saadinnocent909 thank you for the detailed test, this is very useful. Going through your points:

New information for the decision between pdns-recursor 4.8.8 (the bridge in vyos-build #1329) and a newer series: PowerDNS published Security Advisory 2026-12 on 21 October (https://blog.powerdns.com/2026/10/21/powerdns-security-advisory-2026-12-for-powerdns-recursor, details in https://doc.powerdns.com/recursor/security-advisories/powerdns-advisory-2026-12.html). Seven CVEs, fixed in 5.3.12 and 5.4.8. The advisory names up to 5.3.11 and 5.4.7 as affected and says nothing about 4.x, which is end of life and not checked.

@saadinnocent909 I could reproduce the reset problem, and it is not caused by the test build. It is a crash that is already in the current rolling image.

PR https://github.com/accel-ppp/accel-ppp-ng/pull/44
@saadinnocent909 If you want test I can give you a new package.

@saadinnocent909 thank you for testing, good to hear that the counters work now and that the usage shows up in the interim updates.

PR https://github.com/vyos/vyos-build/pull/1331 but the fix for T9493 must be merged before. I can't create teh PR in the moment cause the PR number limit.

I reproduced this and tested Kea 3.2.1 on a rolling VM (2026.10.16-0024-rolling).

@saadinnocent909 there is no ISO or rolling image with the fix, the PR (https://github.com/accel-ppp/accel-ppp-ng/pull/42) is still in review. Here is a test build of the three changed files that you can put on an existing rolling system:

I reproduced this on a rolling VM and have a fix. I can not open a pull request for it: GitHub limits me to 5 open pull requests in vyos/vyos-1x and all 5 are in use. The commit is on my fork, anyone can take it as it is or I open the PR as soon as a slot is free:

Two additions: how serious the open CVEs are, and a simpler way to get to 5.x through T7557.

I prepared this as a draft PR so that someone else can continue if needed: https://github.com/vyos/vyos-1x/pull/5585

I implemented option one with PR https://github.com/vyos/vyos-build/pull/1329

Summary of what I found, and a question on the direction.

@Viacheslaw I will take care. Can you assign it to me?

@saadinnocent909 can you test my PR in your environment?

Reproduced on a VM (rolling, kernel 6.18.55-vyos) with the steps from the description:

I reproduced this on a VM with rolling (PowerDNS Recursor 4.8.8, pdns-recursor 4.8.8-1+deb12u1) and the cause is in the recursor, not in vyos-hostsd or the addNTA lines. The addNTA lines only set DNSSEC negative trust anchors, they do not take part in resolving names.

@a.kudientsov thanks for the detailed report and the reproducer. You wrote that you have local patches for both parts (skipping the drain in lcp_nl_pair_add_cb when
there is no socket, and the state sync during the resync window) that remove the stuck state in your tests.

I checked this against current rolling and the description matches what I see in the sources:

Because of that the fix belongs in FRR: batch a hard clear (BGP_CLEAR_SOFT_NONE) also when a family is given. Then clearing a group with a family filter is fast as well.
FRR issue: https://github.com/FRRouting/frr/issues/23771. I also opened a patch with a topotest: https://github.com/FRRouting/frr/pull/23779.

I looked at this in the FRR source (stable/10.5 and master, same code), and the cause is a bit wider than the ip token.

PR: https://github.com/vyos/vyos-1x/pull/5582

With no traffic-selector configured, the template falls back to 0.0.0.0/0,::/0 for both local and remote. That is the same proposal as listing both families explicitly, so the result is identical: the responder narrows the CHILD_SA to IPv4 and IPv6 stays down. The default does not help, because both families are always sent in one CHILD_SA.
The only way to get both families up against this peer is one CHILD_SA per family. That is what the PR does: https://github.com/vyos/vyos-1x/pull/5565. I tested it against a real Sophos Firewall by configuring the two children by hand: both were installed and IPv6 worked, with no change on the Sophos side.

PR: https://github.com/vyos/vyos-1x/pull/5565

Thanks for the capture, that settles it.

PR: https://github.com/vyos/vyos-1x/pull/5563

Thanks for testing, @DuxOv8.

Update: in our case this was not an FRR bug, it was a firewall problem on our side.

@DuxOv8 as you could see on the PR link is it not merged yet.

PR https://github.com/vyos/vyos-1x/pull/5522