Upstream FRR items this task depends on:
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Today
PR for it is @ https://github.com/vyos/vyos.vyos/pull/512
Yesterday
Sat, Oct 31
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.
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).
Fri, Oct 30
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
Side note: the vyos/vyos-build:current container has an APT source packages.vyos.net/repositories/current that answers 404 now
The actual container is vyos/vyos-build:rolling
ollowing the discussion here I looked at the patch route for Kea 3.0.3.
I'd start with patches this time; this way, we can backport it to the LTS without additional changes or potential new risks.
Then, when we are ready, bump the KEA version for the rolling.
Testing confirmed two ways to fix the duplicate DHCPOFFER from the VLAN parent:
Thu, Oct 29
PR superseded by
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.