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

UpNP was removed

Problem was not reproduced

This appears to be a kernel issue.

I think we hit the same issue in 1.4.3. This is reproducible with the following configs:

Tested NTP, setup-delete-setup
First Setup :

Сhecked test all combination :

Have test on VyOS 2025.09.01-0023-rolling

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

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

The VyOS 1.3.x is EOL
for the newest versions fix here https://github.com/vyos/vyos-1x/pull/4663

In this case, can we have a proper error message for unsupported hw?
Also it seems strange that x710 supports VPP/DPDK but lacks TC_SETUP_FT.

@kakurpiel is correct, TC flowtable does not work with Intel cards due to lack of driver support. I suggest this ticket can be closed.

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

the ticket is closed, and

ssh vyos@vyos -- /opt/vyatta/bin/vyatta-op-cmd-wrapper show interfaces

I'm getting this same (or very similar) issue on 1.4.2LTS (running on VEP-4600).

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

PR 4609 submitted to adjust MSS clamping from forward hook to postrouting.

Looking at this again, and it seems like if the nft rule is moved from forward hook to postrouting hook that MSS is adjusted appropriately.

Fix of commit-config after changes: https://github.com/vyos/vyatta-cfg/pull/107

https://github.com/vyos/vyatta-cfg/pull/103

Could be closed

vyos@r14# grep speed /opt/vyatta/etc/config/config.boot
            speed "115200"
[edit]
vyos@r14#

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

I have created a merge request: https://github.com/vyos/vyos-1x/pull/4508

@Viacheslav,
default must have the same ipv4 subnet of "podman" default network, if changed, Podman doesn't detect it (via conf-mode commands).

@covalente, should we disable the name default? Or do you have another idea?

After further debugging, it's the network name that causes the issue with CNI creation (pod-*) and static ip.
Podman overlaps "podman" default network and the user-defined "default" network.
containers get assigned to "podman" default network and CNIs ignored, so causing this primary issue.

@covalente Add a simple set of commands to reproduce, thanks!