When using logrotate we can take full owership about the resources that will be used for number of files and its size - so i think this will be the best approach.

Please test and feedback in latest rolling.

Howadays there is the generic vyos.ifconfig Python class which deals with IPV6 dhcp client stuff.

If this is always enabled "hardcoded" and SNMPd is not running the following will happen:

This was only a problem in rolling and is fixed

I like the idea, but unfortunately I do not understand why there needs to be a cancel node? If maintenance mode is not activated shouldnt this be enough?

FRR build triggered, please try next rolli g

As I recently rewrote this part in XML/Python please also check the default values in the Python script

This should be restricted by a regex

Dou can try to play around withe the node.def and interfaces-vxlan.py file and lower the limits to see if it works at all.

Please use service custom

Very Nice!

As I can remember there is no objection about FRR for RAs - its only the CLI structure.

Why not check if radv is running and sent a HUP signal instead?

This is already fixed in latest rolling by T1921 - please recheck ltest rolling

As asked on slack and to be clear. This issue was never present in any of the 1.2 LTS releases (crux branch) - not in 1.2.0, 1.2.1, 1.2.2, 1.2.3 and 1.2.4.

We should inform Debian Team about this error and use a fix provided by them if possible.

As this is on the new XML Python interface this is not a problem in crux

Merging 5.8.1 without the VyOS patches in vyos-strongswan did not work. Site-2-Site tunnels did not get up. Funny thing is that DMVPN was working.

Debian Buster changed a lot in VyOS 1.3. I tried my best to port the settings to VyOS 1.3 in T1921, can someone please verify it is working as expected?

Right now there is also the possibility to enable IPv6 router-advertisments on a PPPoE client interface - this somehow makes no sense at all

1.2.3 to 1.3 rolling worked fine for me with a similar l2tp radius config.