Start implementing this draft

Hmmm I retract that, apparently not in my configs. But that review indicates that a common pattern is to define the VRF at a global level, then specify an instance at the BGP level...

@c-po not in constrat to other verndors - I know that Juniper ERX allowed for different ASNs if in a VRF. I'll see if I still have some old configs.

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)

Ahh.. yea, i see that now.. i've never done this, so cant say how it work.. but as i can se this is still the same process, so my answer is still the same.... Actually this migth be a good reason for migrating set protocols bgp <asn> to its own local-as <asn> subnode, so the AS is not hardcoded in the configpath

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

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

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:

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

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

Well, they do work together.

In T2898#87573, @jack9603301 wrote:

@wsapplegate Have you finished a patch yet?

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: