FRR case where there is a long explanation: https://github.com/FRRouting/frr/issues/15400

Example implementation of such a daemon:
https://github.com/vyos/vyos-1x/pull/4872

This is still a problem. We have found no suitable fixes, and I think we've tried "everything" without avail.

No passthrough.
In general, the configuration looks like this:
HP DL 360G10 Servers
Windows Server 2019 with Hyper-V role
Vyos VMs Generation 2.
NIC ports are grouped at the OS level to Team (like bond in Linux).
After installing a new NIC (HPE P26253-B21, Broadcom BCM57416), we simply changed the members of this Network Team, nothing more.
Up to this point, everything had been working properly for several years.

@lbv2rus Do you passthrough NICs to the VM?

Please share the full configuration. bond0 is not listed in the example above.

I did some deeper debuging:

Yes got the information that the other side is no vyos (sorry didn't expect this) it's an current sophos box with strongswan.
It try to replicate it here between two vyos boxes the next days

@rherold any updates?

We found this Debian bug report, which seems to be somewhat similar: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116074

lsusb @ VyOS 1.4.3:

Tried Debian too (debian-live-13.1.0-amd64-standard.iso). Live-boot 13.1.0 works. Boot from disk/installed Debian 13.1.0 also works.

For the circinus works as expected

vyos@r14:~$ show version 
Version:          VyOS 1.5-stream-202510060458
Release train:    circinus
Release flavor:   generic

Working on the latest rolling (checked VyOS 2025.10.05-0020-rolling)
VyOS config:

set container name radius allow-host-networks
set container name radius image 'dchidell/radius-web'
set container name radius volume accel destination '/usr/share/freeradius/dictionary.accel'
set container name radius volume accel source '/usr/share/accel-ppp/radius/dictionary.accel'
set container name radius volume clients destination '/etc/raddb/clients.conf'
set container name radius volume clients source '/config/containers/radius/clients'
set container name radius volume dictionary destination '/usr/share/freeradius/dictionary'
set container name radius volume dictionary source '/config/containers/radius/dictionary'
set container name radius volume users destination '/etc/raddb/users'
set container name radius volume users source '/config/containers/radius/users'
set service pppoe-server access-concentrator 'ACN'
set service pppoe-server authentication mode 'radius'
set service pppoe-server authentication radius server 192.168.122.14 key 'vyos-secret'
set service pppoe-server client-ip-pool FIRST range '100.64.0.0/18'
set service pppoe-server client-ipv6-pool IPv6-POOL delegate 2001:db8:8003::/48 delegation-prefix '56'
set service pppoe-server client-ipv6-pool IPv6-POOL prefix 2001:db8:8002::/48 mask '64'
set service pppoe-server default-ipv6-pool 'IPv6-POOL'
set service pppoe-server default-pool 'FIRST'
set service pppoe-server gateway-address '100.64.0.1'
set service pppoe-server interface eth1 combined
set service pppoe-server interface eth1.23
set service pppoe-server log level '5'
set service pppoe-server name-server '1.1.1.1'
set service pppoe-server name-server '1.0.0.1'
set service pppoe-server ppp-options disable-ccp
set service pppoe-server ppp-options ipv6 'allow'
set service pppoe-server session-control 'disable'

RADIUS users

client-1	Cleartext-Password := "client-1"
    Service-Type = Framed-User,
    Accel-VRF-Name = "red",
    Framed-IP-Address = 10.0.0.11,
    Stateful-IPv6-Address-Pool = "IPv6-POOL",
    Delegated-IPv6-Prefix-Pool = "IPv6-POOL",
    Framed-Route = "100.64.0.11/32 10.0.0.11 1",
    Framed-Protocol = PPP

@seriv I am unable to reproduce on 1.4.3; for example:

To work around this at present I am setting the following additional configuration to prevent losing IPv6 connectivity frequently:

Sorry, another followup, rather than duplicating the control logic in both interface.py and in vyos-netplug-dhcp-client (and leaving yourself open to another logic divergence in future), you could consider just checking for presence of the config file /var/run/dhcp6c.eth0.conf in vyos-netplug-dhcp-client when determining if the service should restart. That file only exists if dhcp6c is required on that specific interface, and that means the logic for dhcp6c presence is determined only by interface.py and vyos-netplug-dhcp-client just follows its lead.

Relevant section of interface.py: https://github.com/vyos/vyos-1x/blob/5845c4b1c50bc0335284cfb3306e0a91de3efd40/python/vyos/ifconfig/interface.py#L1822-L1824

@rherold I tried to reproduce this behavior using your configuration for VyOS 1.4.2, 1.4.3 and 1.5, but everything works fine in my lab.

I've created: https://github.com/vyos/vyos-1x/pull/4720

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

Added commands:

ip -6 r s ff00::/8
ff00::/8 nhid 19 proto static metric 20 pref medium

nexthop dev tun3 weight 1
nexthop dev tun2 weight 1

Finally VyOS-style static route help:

Both tunnel have multicast enabled:

Manually adding route:
ip -6 r a ff00::/8 dev tun2

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

Will be fixed after migration to the accel-ppp-ng T7744

basically with our test, it's missing a command which enable on the interfaces that can talk lfa with other isis routers, we should add this feature to solve this problmes

some config is missing in FRR when configured from VyOS CLI:

bug case in frr: https://github.com/FRRouting/frr/issues/19431

@Viacheslav
Rolling release isn't affected due to this bit of code and the import of the related signal library: https://github.com/vyos/vyos-1x/blob/69cd4845861c88285ab496339f19103dec7a32b6/src/op_mode/firewall.py#L29

here's the topology and full cofig. running on VyOS 2025.05.29-0019-rolling

Does the rolling release also affected?
If yes, you should add a PR to the “current” branch.
And then it will be tested in the rolling and if works fine, it will be backported to the stable branches.

PR submitted here https://github.com/vyos/vyos-1x/pull/4664 but it was auto-closed as pull-requests on sagitta branch aren't accepted per the Bot (I don't recall this block on past contributions).

Adding (1) and (2) to this bug report:

Could you share the interface configuration or topology and expected entries?
What about the latest rolling?