The workaround described above works. Changed it to following line and added few more system-users spotted in the AAA daemon logs:

After discussion with @tfiebig we found https://github.com/FRRouting/frr/issues/7738 and https://github.com/FRRouting/frr/pull/16354. This could fix it

I just bit on this in prod causing one very unhappy IX to write unhappy emails.

the frr issue is fixed for versions 10.1, 10.0, 9.1. It is necessary to retest with the new build

Can't reproduce on my end:

Can you check if changing this line https://github.com/vyos/vyos-1x/blob/current/data/templates/login/tacplus_nss.conf.j2#L33 and adding those user helps?
This file can be changed locally in the router: /usr/share/vyos/templates/login/tacplus_nss.conf.j2
Change line:

exclude_users=root,telegraf,radvd,strongswan,tftp,conservr,frr,ocserv,pdns,_chrony,_lldpd,sshd,openvpn,radius_user,radius_priv_user,*{{ ',' + user | join(',') if user is vyos_defined }}

And change it to something like:

tested with the fixed done by @natali-rs1985 : , works with ports as well :

on latest rolling it's not an issue anymore:

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

The fix is still work in progress, I need to dig deeper into accel-ppp history that predates the github repo. Not sure why some code was commented out over 10 years ago, IPV6CP restart timer is not stopped and disconnects in 3 seconds. Looking at older history in sourceforge but not sure if the answer is even there, sourceforge seems to have lost old history before 2011 (broken links).

@zsdc we need backport for sagitta

reproduced on:
Version: VyOS 1.5-rolling-202409160007
Version: VyOS 1.4-stable-202409170309

do not reproduce on:
Version: VyOS 1.3-stable-202409270542
Version: VyOS 1.4-stable-202409170309
Version: VyOS 1.5-rolling-202409160007

@doctorpangloss I see from the other forum thread:
https://forum.vyos.io/t/something-keeps-adding-offloads-back-to-my-interface-breaking-my-wan/15282/7
that @n.fort has confirmed the persistence of the fix.

i retested this issue
actual for:
Version: VyOS 1.3-stable-202409270542 (DHCP Relay Agent 4.4.1)

What is the approach for preventing offloads from being added back in after boot? I deleting them before upgrading, upgraded to a nightly with this patch, but I observed the offloads returned:

Yes I am overloaded (who isn't), and yes I plan to make a PR but want to test it a bit more first, to be reasonably sure it causes no regression (potential resource leak if something allocated by the incomplete IPv6 configuration is not freed - not sure enough about accel-ppp internals). I'm working to rebuild replacement accel-ppp package (based on the same commit as in equuleus with just my patch applied, no other changes) and run it for a week or two while watching memory usage. Testing a fairly complex config in production environment, so not brave enough to try rolling or even sagitta just yet.

@jmaslak It's been a while since you reported this bug and we've been through multiple FRR updates since then. Could you check if the issue is fixed in the latest nightly build, or attach a config that triggers that behavior if it still exists?

I've merged this into the feature request because the real issue is that we don't have dynamic hairpin NAT yet, while this behavior for "static" NAT is not wrong. We'll get to it.

@marekm Do you plan to make a PR?
If you are overloaded, we can import a patch ourselves, but a PR would be nice.

looks like the problem on the FRR site: https://github.com/FRRouting/frr/issues/16899

I also ran into this issue and lost a couple of hours trying to figure it out.
I stand for the solution purpose by @Viacheslav .

PR ready for review:
https://github.com/vyos/vyos-1x/pull/3876

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

Running smoketests before PR:
https://github.com/jestabro/vyos-1x/tree/configd-err-out

So I investigated further and it is like this in jool:
mark is only used to select between pool4 instances.

I am not yet able to reproduce this in either case. @c-po suggestion of an interaction with the introduction of vyos.utils.configfs is quite reasonable, but I have not reproduced in current rolling or an image earlier than the recent changes (T6633, T6640) to resolve T6639. I've asked the forum user of the second report for further information.

Also reported:
https://forum.vyos.io/t/container-set-by-http-api-failed/15248/2

Yes this is a known, annoying, bug that had not yet been addressed following T6006. One suggestion I have added to your PR is to only set in config in the case of live boot: after installation, activation will not enable against user settings; it will still disable if say, hardware capabilities disappear.

This is a valid point!

we've added this new feature called Server bridge , it's available in 1.5 and backported 1.4: