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

This actually has nothing to do with the http api, but rather is a deadlock coming from ConfigSession show_config(), namely, the use of Popen.wait() in __run_command().

This issue has been fixed in this commit: https://github.com/vyos/vyos-1x/commit/0fb5cc02c6c16ef410c1b1f746c1fbfbc40a0da0