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

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

https://github.com/vyos/vyos-build/pull/1268
https://github.com/vyos/vyos-1x/pull/5405

https://github.com/vyos/vyos-build/pull/1253
https://github.com/vyos/vyos-1x/pull/5350

This issue remains in july 2026 using VyOS Stream 2026.03.

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

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

I found that disabling multicast snooping fixed the issue:

@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

It is not expected to be working

is needed something else to merge this?

If a change is made to remove this, I think it should be safely placed behind an explicit configuration parameter for the vyos_config

I believe the intent of the existing filters is to prevent accidental password changes. For an automation solution, I don't see significant value in changing this behavior, except to remove the plaintext variant as well. The intention here is to prevent accidental overwrite of passwords during the configuration step. The existing vyos_user should be used for handling password changes.

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

In T6545#214868, @ordex wrote:

Hi, I'd like to get back on this task and give it a shot, but I have troubles building and testing images from scratch.
What's the recommended procedure? Installing the latest rolling release and hacking that one?

@natali-rs1985, consider backporting it.

The solution is vyos@r14# set firewall global-options apply-to-bridged-traffic accept-invalid ethernet-type arp
Close this task as duplicate, for reference T7150

@Viacheslav any preference on which syntax?

*Edited to remove an "option" I don't have a way to code.

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

In T8211#248553, @Viacheslav wrote:

Hey @srnoth would you like to create a PR?

Hey @srnoth would you like to create a PR?

This is due to a hardcoded limit on the size of the underlying unionfs file in vyatta-cfg: as the value was set rather arbitrarily, we will increase the limit from 2^18 to 2^20. Note that limit is encountered irrespective of the use of the http api.

I have tested it, and the issue does not reproduce after the fix.
As we have backported it, I propose closing this task as resolved.
Thank you.

Hello, long time no updates.
I have tested it.
Migration to the latest Rolling releases and Stream 2025.11 was successful, interface was added to the new configuration.
Thank you.

In T4001#173519, @Viacheslav wrote:

Needs to re-check for 1.4/1.5

@Apachez , @gaige Hello Guys!
How do we want to continue here, please?

I have tested it in the lab with 1.4.3, but I cannot reproduce it. But during the implementation of OpenVPN for our customer, I met this issue. It happened when the config was too large (around 9K command lines) and the system was overloaded (old servers or GNS3).

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

It is definately related to wide-dhcp-client as it takes upo to 30 seconds for the process to terminate. Root cause still unknown - but I've seen this lately a lot while debugging PPPoE DHCPv6-PD things.

As we moved from pmacct to ipt-netflow it needs to be re-checked

Patch v4 lkml:
https://lkml.org/lkml/2025/10/24/1254

New patch v3 lkml:
https://lkml.org/lkml/2025/10/21/1117

It was investigated - the bug is indeed in the kernel.
Currently, the patch is proposed. But it probably would be refactored in the near future to a patch ver3:

@pr0ton11, do you see the same log? Can you try the latest rolling?

@Giggum Thanks, missed this.

@Viacheslav PR was submitted a year ago is this bug closed?

Fixed, checked in the stream-q2

vyos@r15# run show conf com | match dhcp
set interfaces pppoe pppoe1 dhcpv6-options pd 1 interface dum1
set interfaces pppoe pppoe2 dhcpv6-options pd 1 interface dum2
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 range 0 start '10.0.0.100'
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 range 0 stop '10.0.0.199'
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 static-mapping myPC ip-address '10.0.0.130'
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 static-mapping myPC mac '52:54:00:28:23:f1'
set service dhcp-server shared-network-name LAN subnet 10.0.0.0/24 subnet-id '10'
[edit]
vyos@r15# 
[edit]
vyos@r15# run show dhcp server leases 
IP Address    MAC address        State    Lease start                Lease expiration           Remaining    Pool    Hostname    Origin
------------  -----------------  -------  -------------------------  -------------------------  -----------  ------  ----------  --------
10.0.0.130    52:54:00:28:23:f1  active   2025-09-25 03:47:47+00:00  2025-09-26 03:47:47+00:00  23:59:28     LAN     mypc        local
[edit]
vyos@r15# 
[edit]
vyos@r15# 
[edit]
vyos@r15# run show ver
Version:          VyOS 1.5-stream-2025-Q2
Release train:    circinus
Release flavor:   generic