Which VyOS CLI command enables LRO?

Hi, I have tried these set of configuration and the openvpn connection was up and working fine.

I would like to solve this in the next way. I will:

1. Add verification to our config module to avoid impossible configurations.
2. Add IPv6 gateway processing (how could I miss this? Cannot imagine...).

I saw multiple times configs with a firewall section that contains about a thousand lines, so I do not think that DNS records are something size-critical that deserves additional config files.
I believe that keeping config parts outside the config.boot is a bad idea in general that against our main benefit - single config for everything.

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?

I just tried to set up a new router using /31 transfer networks and this also fails with the same error (no BGP unnumbered).

@ernstjo I can't reproduce it in VyOS 1.4-rolling-202102190541

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

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

Template generate wrong value
https://github.com/vyos/vyos-1x/blob/current/data/templates/frr/bgp.frr.tmpl#L112

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

I can confirm it is broken for

reset vpn ipsec-peer XXX

too when you run policy-based VPNs.
Peer reset log:

Sure thing:

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.

Thanks a lot @jestabro ! I'll give it a go with the latest version(s).

Oh, actually I just noticed this was a duplicate of T562, I should have posted there. Sorry about that :-(

In T3338#87652, @zsdc wrote:

Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?

I believe this is the behavior in 1.2.6 aswell?
And I think its not even possible to reset one peer?
So, reset vpn ipsec-peer XXX is broken
as well as reset vpn ipsec-peer XXX tunnel YYY

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

Can you share details about your hypervisor and datasource? Also as the full Cloud-init log (/var/log/cloud-init.log)?
Either datasource generates a wrong config, either the format is not well described in the Cloud-init documentation - there noted that: "gateway: IPv4 address of the default gateway for this subnet". I more believe in the wrong documentation, but would be better to check.
Independently of this all, the situation is not good, because we need to verify values that put into config. So, this will be fixed in one or another way (proper adding or drop), when we figure out details.

So I'm unsure how to rewrite that in a clean way, and I would appreciate your and @c-po's opinions on the subject

dhcp-helper is working perfectly fine with GRE tunnels, see my feature request https://phabricator.vyos.net/T3340

Keep in mind you cannot run dhcp-helper and ISC DHCP server at the same time on a single router. The Vyos CLI should not allow this.

Well, they do work together.

In T2898#87573, @jack9603301 wrote:

@wsapplegate Have you finished a patch yet?

@c-po What do you think?

In T2898#80264, @c-po wrote:

That we can deal with later on when it‘s needed

Yep, got bitten by that too. It's due to some interface types being absent from src/validators/interface-name. Luckily, the solution is pretty easy, here's a patch which adds l2tpeth and friends to that validator:

@pasik I should have a fix committed soon; thanks for the report !

Good job debugging the issue @varesa and @jestabro ! It looks like the actual cause for the deadlock was found already..