Hello, Community!
This update covers the changes that landed in Rolling in September and October, and looking back, the month has a theme that nobody planned.
A commit is a promise: change what I asked for, and leave everything else alone. This month, we found several places where VyOS broke that promise. With certain routing options set, a commit that only touched a route-map description could reset BGP sessions or OSPF adjacencies. Elsewhere, configurations committed without complaint and then quietly did something else. Much of this post is about closing those gaps, and about the community members who found several of them on their own routers.
There is new ground too: MPLS Inter-AS label switching, BGP-LS for SRv6, a VXLAN extension that carries firewall marks, and updates to DHCP, VPP, and OpenVPN. Please read the security section before you upgrade.
Several routing additions this month started the same way: someone needed a capability that FRR or the kernel already had, and described in a feature request exactly the CLI command they wanted.
For Inter-AS option B (RFC 4364), an autonomous system border router has to re-advertise labeled L3VPN routes with its own labels and swap labels on the way through. FRR does this per interface, and you can now enable it from the CLI (T9338):
set protocols mpls interface eth1
set protocols bgp interface eth1 mpls l3vpn-multi-domain-switching
Rolling now contains FRR 10.7.1, which a community member had been waiting for since August (T9454). With SRv6 in use, IS-IS can now hand its link information to BGP-LS (T9227):
set protocols isis distribute link-state
The same contributor fixed SRv6-only IS-IS, which quietly switched on SR-MPLS as well. If the zebra kept logging label installation failures on every adjacency change, this is why. SR-MPLS is now enabled only when one of its own options is set (T9485).
EVPN users with one anycast gateway per VLAN, all sharing a MAC address on a VLAN-aware bridge, saw a second gateway fail to commit, and after a reboot, only one gateway came up, and the rest of the boot configuration was not applied. This is fixed (T9253).
Finally, VXLAN-GBP carries a firewall mark across a tunnel: the sending VTEP copies the packet mark into the VXLAN header, and the receiving VTEP restores it for its own firewall rules (T9319).
set interfaces vxlan vxlan100 gbp
Pay attention - the GBP field is not authenticated, and anything on the underlay can change it. Use it only where you trust the underlay.
On every commit that touches routing, policy, or static routes, VyOS renders the complete FRR configuration and compares it line by line with what FRR is running. For some options, FRR supports multiple variants, and if we write an option in a different form from the one FRR prints back, FRR receives it again on every commit: removed, then re-added. For five options, that was disruptive, even when the commit only changed a route-map description:
All five are now written in the way FRR stores them. One of them changes your configuration on upgrade: protocols ospf parameters opaque-lsa migrates to protocols ospf capability opaque, and is removed from VRF instances, where FRR never accepted it.
Large configurations also commit faster. A duplicate save of the FRR configuration cost almost two minutes per commit in one test, and a double read in the post-commit hook cost 77 to 78 s with a 10,000-rule prefix-list. Both are gone, and the prefix-list duplicate check no longer slows down with the square of the list size (T9377, T9399, T9379).
We also owe you a follow-up on last month's post. The change that updates FRR on every DHCP lease event, which landed on 2026-09-08, brought a race of its own: a lease event colliding with a commit could make the commit skip the FRR reload, or apply the routing configuration from before the commit. A static route with dhcp-interface might never appear, and a DHCP interface moved into a VRF could leave the VRF without its default route. Lease events now wait for a running commit to finish (T9368). The PPPoE IPv6 default route also no longer disappears on an FRR reload (T9395).
One change prevents a bad day. Deleting an interface that other parts of the configuration still refer to - OSPF, QoS, or NTP, for example, used to commit fine and break the next boot. The commit now stops and tells you what still needs the interface (T7886). The idea came from a community member.
Time is hard to get right in a firewall, because nftables thinks in UTC, and most people do not. A time window crossing midnight in UTC never matched (like 22:00-06:00), failed everywhere; and after a daylight saving or time zone change, every window was off until the next firewall commit. Both are fixed (T9474).
A few more fixes, briefly: fragment match-frag now works alongside packet marks; a failed commit or a hand-removed nftables table no longer makes every following firewall or NAT commit fail until reboot; and a GeoIP rule that matches both source and destination no longer silently checks both against the same country list (T9474, T9475, T9332).
NAT load-balancing weights are now shares of their sum, so if your weights do not add up to 100, expect the traffic distribution to change after upgrading. Load-balanced destination NAT with a translation port now commits, and translation to an address prefix keeps its port range (T9475).
DHCP
DHCP server client classes can now match on the hostname a client sends (option 12) or its vendor class identifier (option 60), exactly or as a case-insensitive substring, and hand out their own DHCP options (T9267). The request came from someone provisioning several IP phone models on one subnet:
set service dhcp-server client-class <name> hostname substring value <text>
A subnet accepts one client class, so give each class its own address range.
On the client side, a renewal stuck on a server that had lost its session could leave IPv4 down for hours while IPv6 kept working. A watchdog contributed by the reporter now restarts the client when a renewal is more than 15 minutes overdue (T9108).
VPP
On an interface bound to VPP, an MTU larger than the NIC supports is now rejected at commit, instead of the dataplane quietly running at the NIC maximum. VLAN sub-interfaces get their MTU in the dataplane too (T9161).
VPP also receives each frame into a single buffer whenever the configured MTUs allow it (T9146). In the test that prompted the change, with 64-byte packets on 100G ConnectX-6 NICs, this raised forwarding from 84 to 140 Mpps. Jumbo frames keep working.
Two validation checks now do their job. Every GRE member of a VPP bridge is checked for tunnel-type teb, not just the last one (T9300). And IKE and ESP algorithms that VPP IPsec acceleration cannot handle are rejected again - that check had stopped working when the setting was renamed on 2026-02-15 (T9303).
OpenVPN
The upstream OpenVPN developer behind last month's Data Channel Offload work followed up this month. With DCO, the tunnel MTU now defaults to 1420 through a new mtu node, because the kernel module does not clamp TCP MSS, and full-sized packets were fragmented (T9364). ChaCha20-Poly1305 joins AES-GCM as a cipher that works with DCO (T9370):
set interfaces openvpn vtun0 encryption data-ciphers chacha20poly1305
In site-to-site mode, the keepalive timeout is now the interval multiplied by the failure count (600 s instead of 60 s with the defaults), and keep-alive interval 0 really turns keepalive off, instead of restarting an idle tunnel about once a minute (T9363, T9337).
We need to be upfront about the first one. The OIDC authentication for the API, described last month, did not check the token audience when none was configured. A router with oidc issuer set and no audience accepted any valid token from that identity provider, including tokens issued for other applications - with full API privileges. This affected Rolling builds between 2026-09-02 and 2026-09-29. OIDC was never in an LTS release, so LTS users are not affected. The audience is now required, and a configuration without it will not commit until you add it (T8989):
set service https api rest authentication oidc audience <txt>
The PPTP server ignored the configured MPPE policy, so mppe require did not stop unencrypted clients. It does now, which means such clients will be refused after upgrading (T9462).
The Blast-RADIUS attack (CVE-2024-3596) lets an attacker between a RADIUS client and server forge an Access-Accept. The PPPoE, IPoE, L2TP, PPTP, and SSTP servers can now send and require the Message-Authenticator attribute that defends against it (T9351). Make sure your RADIUS server supports the attribute before you require it:
set service pppoe-server authentication radius message-authenticator include-access-request
set service pppoe-server authentication radius message-authenticator require-access-response
reset connection is replaced by reconnect interface <ifname>, which runs detached from your session (T9354). Reconnecting the link you are logged in through no longer kills the command halfway and leaves the router offline. No alias is kept, so update your scripts. In the API, the old reset path is now /reconnect.
The commit archive now takes a named location per destination, with protocol, server, path, and credentials as separate nodes instead of one URL (T6304):
set system config-management commit-archive location <name> sftp server <host>
set system config-management commit-archive location <name> sftp path <path>
Existing locations migrate automatically, but a URL with an unsupported scheme is dropped with a warning, so check the result after upgrading.
IKEv1 is on its way out: strongSwan 6.1.0 disables it by default and plans to remove it in a future release. A commit now warns about IKE groups that use IKEv1, or that set no key exchange and therefore still accept it (T9320).
The DNS forwarder no longer sends PowerDNS security status queries by default, since their result was discarded anyway (T9175). You can opt back in with set service dns forwarding options security-status-poll-domain secpoll.powerdns.com.
Around a third of this period's changes came from outside the core team. Four of them make good stories.
Many items above came from the community as well, including the OpenVPN follow-ups, the IS-IS and VXLAN-GBP work, the GeoIP and PPTP fixes, the DHCP client classes, and several of the smaller conveniences.
Thank you to everyone who contributed this period, the code, the reports, and the careful reproductions behind them. See you next month!