Unfortunately I can not connect the dots between "still the same process" and set protocols bgp <asn> vs. set protocols vrf <vrf> bgp <asn> (I explicitly left the "move bgp tagNode to node with local-as" topic out of the discussion as this is something different and is addressed via a different task)

FRR actually supports configuring a different ASN per VRF in contrast to other vendors

Which VyOS CLI command enables LRO?

at first glance this looks very interesting. Befor this can be added I would like to give the following comments:

• adding a cli node that passes raw config values from cli to the daemon is bad (we inherited this for dhcp and openvpn and it caused more harm then good in the last 2 years) - is this mandatory?
• even dns using A, AAAA, PTR upper case types we should keep the CLI lowercase - this can be easily handled within the Jinja2 template.
• having > 20 dns records here could really bleow up the CLI, maybe we should thing about loading the zone from a file @zdc @dmbaturin @jestabro?

Thank you for giving out bleeding edge codebase a spin - I will check this out.

Can we also extend the available BGP smoketests to test this?

A verify() step will be added to prevent certain configurations when a specific type of driver is used. In this case if the xen driver is used, and MTU is > 1500 and sg is not set, a ConfigError() will be raised.

If this package supports all existing setups and the GRE usecase I see no reason to not replace it. @basalblas PR is happily accepted.

DHCPd shold be vonsistent for both v4 and v6 - running different daemons is simply bad.

Perfect, thanks

@mathiashedberg could you try and enable RPS set interfaces ethernet eth0 offload rps and see if this does any good on utilisation / drop rate? I had a similar issue with a PPPoE link which behaved super bad under preasure.

@plett VyOS 1.4 now does an automatic fallback to the 1.3 behavior which used FRR 7.3 until we decide how to handle this, w.g. by adding a new CLI option which is added by a migration script to keep older systems running "as is" when upgrading.

Somehow this was lost in translation in my git repo....

Nackported to 1.3 equuleus

With this new information I see little to none reason to keep the key_mangling() workaround. If we manage to transform all nodes into "proper" syntax we can one day drop it.

This actually feels like an FRR bug as this still occurs with the new XML/Python rewrite

This is fixed in 1.4 as proper input validation happens.