In T3344#87831, @runar wrote:

@Viacheslav in you example, what does set protocols bgp <asn> vrf do? if i'm reading it correctly it makes no sense as you do not start a new process, and the ASN for the vrf will be the asn of the global bgp process

@Viacheslav in you example, what does set protocols bgp <asn> vrf do? if i'm reading it correctly it makes no sense as you do not start a new process, and the ASN for the vrf will be the asn of the global bgp process

using set protocols ospf vrf ... makes it harder to show that this is actually multiple processes that co-exist on the router, but on the other hand if we are thinking about the config scripts that are going to execute all this the syntax set protocols ospf vrf.... makes more sense, because the normal ospf config_mode script can program both "global" and all the vrf's

There are differences on vrf support in ospf,++ and BGP. the largest difference is that in IGP's you start a new process for each and every vrf you use. then the syntax set protocols vrf ospf.... makes kinda sense, but on BGP you are only using ONE process and the vrf is only a address-family inside the current process. and there the syntax set protocols bgp X vrf X makes most sense.

I prefer more option2

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.