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?

We never received any info about what the incorrect behavior in question is, and the load balancing subsystem is undergoing a rewrite, so I'm closing this.

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.

@Viacheslav I can try testing this on my test bench as I have a couple of spare ConnectX 4/5 to play around. Is this in 1.5 rolling?

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

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

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

As the message currently states over at https://sourceforge.net/projects/e1000/

PR (Docs): https://github.com/vyos/vyos-documentation/pull/1551

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

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

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

I am currently using 2.18.1 with kernel 6.6.51-vyos

I am currently using 2.18.1 with kernel

This task has been completed with https://github.com/vyos/vyos-documentation/pull/1548

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

Smoketest fails for the wireless interfaces

 DEBUG - ======================================================================
DEBUG - FAIL: test_wireless_add_single_ip_address (__main__.WirelessInterfaceTest.test_wireless_add_single_ip_address)
DEBUG - ----------------------------------------------------------------------
DEBUG - Traceback (most recent call last):
DEBUG -   File "/usr/libexec/vyos/tests/smoke/cli/test_interfaces_wireless.py", line 84, in test_wireless_add_single_ip_address
DEBUG -     self.assertTrue(process_named_running('wpa_supplicant'))
DEBUG - AssertionError: None is not true

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

KVM is a dependency

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

I think, a new command is required for this show integrity or similar. Also a brief status in MOTD and show version.

Do you want some CLI for it? Or just user util?

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 to be 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.

Not sure if still relevant after these years, as hardware has progressed to larger RAM sizes, but Debian x32 port doesn't seem to be very active anymore.