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

The issue only occurs when active BGP sessions are present.
If BGP neighbors are administratively shut down before committing the change, the VPP bond subinterfaces remain UP and operate normally after the commit.

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

I believe I am hitting a related PBR/fwmark/container interaction issue on VyOS rolling.

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

Working on this now. Should be a simple change.

I had attempted adding it to the cli and frr template in the 1x package and it worked for adding it but it would not remove it when it was removed from the config due to it being in the global section of the config. I have not gotten back around to figuring that out yet, currently I've been working on SNMP for VPP and trying to figure out an OSPF issue with VPP.

@egoistdream Thanks for the answer.
I close the task.

@ServerForge, any progress?

I found that disabling multicast snooping fixed the issue:

Still fails in the FRR

r14(config)# router eigrp 100
r14(config-router)# 
r14(config-router)# passive-interface eth0
% Configuration failed.

@egoistdream Is this still a problem?

I do not see bugs here
Recreate a bug report if necessary. With a minimal set of commands to reproduce.

Still bug

vyos@r14:~$ vtysh

Still the same bug
https://github.com/vyos/vyos-1x/blob/6fa4967f49e988e4979c611ee9199bb14bef8536/op-mode-definitions/show-configuration.xml.in#L10-L17

root@r14:/home/vyos# diff -u \
  <(cli-shell-api showCfg --show-show-defaults --show-active-only --show-hide-secrets) \
  <(cli-shell-api showCfg --show-active-only --show-hide-secrets)
root@r14:/home/vyos#

Fixed in
https://github.com/FRRouting/frr/commit/7603eca36d7bf7d73f14f46aa5006063214f03e1
https://github.com/FRRouting/frr/pull/15418

@j.vela, this task was closed a year ago.
If you want to change something, you have to add a new task/feature/bug report.

Noticed the charon-logging.conf and charon-systemd.conf affects logs in the system journal logs only. However, as the bug describes, the "set vpn log level 0/1/2" only modifies the charon-systemd.conf, and by default, the value of charon-logging.conf is 1, which leads journald to collect logs at level 1 (includes DPD logs) and not level 0 (only up/down and audit events) as was configured on charon-systemd.conf, by the "set vpn log level 0" command.

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

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

The ID is completely useless for the op-mode and should be removed. It is necessary if we want to extend the output with new fields.

Alternative approach: https://github.com/vyos/vyos-1x/pull/5211

ofc. This is the whole configuration:

I do not see 5 minutes hang, but I see this configuration is incorrect for FRR

set vrf name mgmt table '123'
set interfaces dummy dum0 address '192.0.2.14/24'
set interfaces dummy dum0 vrf 'mgmt'
set interfaces ethernet eth1 address '192.168.122.111/24'
set interfaces ethernet eth1 vrf 'mgmt'

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

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

@pasik I've just tested with 2026.05.19-0047-rolling - it is working fine as well, thanks!.

vyos nightly 2026.05.19-0047-rolling seems to be now available.

It is not expected to be working

I have upgraded all my routers already to 2026-05-16 rolling and the CPU usage problem was fixed.

Rolling release starting from 2026-05-19 will have all necessary fixes inside. I am keen to get the results.

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

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

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

I confirm that in this way the issue is solved. Do you suggest me to leave it like this or to wait for next builds?
It's not a big issue in both ways

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

It will not pass any security audit/certification
I'd double-think about this before implementation.
I understand that we have a lot of issues in different places that should also be limited/hidden from non-admin users.

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

I believe we should better get rid of the default password in the live image and use some auto-login mechanism instead so that if people want to SSH into a system booted from a live CD, they need to set up a user with their own password, rather than create more default credentials.

It will not be implemented.

In T8496#264157, @vvmsq wrote:

This was after building kernel + modules myself - end result was much larger than expected - it's definitely possible/probable I did something wrong and included packages that weren't needed without noticing if regular builds are coming out fine. Apologies for the mistake.

Most likely, it doesn't support the reload-or-restart systemctl option and must be restarted for any authentication change.
https://github.com/vyos/vyos-1x/blob/964a01697f3c2361ce4324fb8333f5fe4d2b0434/src/conf_mode/service_pppoe-server.py#L127-L135
@noc.tlc Can you test it?

sudo nano -c +129 /usr/libexec/vyos/conf_mode/service_pppoe-server.py

And replace the 2 above lines with:

# is_node_changed(conf, base + ['authentication', 'radius', 'dynamic-author']),
# is_node_changed(conf, base + ['authentication', 'mode']),
is_node_changed(conf, base + ['authentication']),