Next rolling release will carry the revert

Thank you for the feedback! Will incorporate this into the rolling releases. Looks like once again Intel did us a favor.

I have reverted the commit of QAT driver update. can you please try out this image:

@ernstjo yeah we also have this "situation" with wireguard tunnels. Should be fixed in general with the rewrite of tunnel to get_config_dict() which is the second last interface not using this scheme, vti is last.

Usually all of them have a serial failback thus they should work, currently there is only a smakk subset of vyos verified LTE modules as each and every modules comes with its own problems:

Docuemntation from: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-tool_reference-tuned_adm

@lucasec of course this commit could be related and we can try revert back to the old version. Would you be willing in testing a binary for us?

as we rely on OpenNHRP this looks like a dead end as of now. Maybe IPv6 support will get introduced and supported when we can migrate to FRR based NHRP - there is another task about that (T2326).

Your referenced commit is only relevant for validation logic if your hardware supports QAT or not. We now run Kernel 4.19.155 - please retry with the latest rolling release.

@tuxnet maybe this will help: https://docs.vyos.io/en/latest/routing/multicast.html

set interfaces ethernet eth2 dhcp-options no-default-route

Available via set interfaces ethernet eth0 dhcp-options host-name

Problem is the constraint statement in https://github.com/vyos/vyos-1x/blob/current/interface-definitions/include/nat-address.xml.i where ipv4-range returns 0 instead of 1.

See T3051 "OpenVPN: multiple client routes do not work in server mode" for follow up

I want to have native-vlan and allowed-vlan

Perfect! Then please share your full OpenVPN config so the issue can be recreated and fixed properly.

Can you please check if this used to work in older VyOS versions, e.g. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202010151549-amd64.iso or share your config and a network diagram.

Please try again with the next rolling release.

As I'm raised by A vendor starting with C and now switched to another vendor starting with A they both reference the function as native-vlan and allowed-vlan - this makes it easier for users which operate cross-platform.

I really like the idea of this interface and alwaysed watned to implement it - but I lacked of time, so first thank you @jack9603301 for picking this up.

I wonder what happens if I have a eth0.10 bridge member interface? Also what should happen when the user jas eth0 and eth1.10 bridge members? should this feature still work or is it exclusively only for native non vlan interfaces?