Page MenuHomeVyOS Platform

Per VRF dynamic routing support
Closed, ResolvedPublic

Description

This is one of the long awaited features in VRF terms. Support for per VRF routing should be added for:

  • BGP
  • OSPF
  • OSPFv3
  • IS-IS

This task is dedicated as an umbrella task for all forther actions and mainly used to discuss the CLI design.

CLI Options

Option 1

Use the routing protocol below the VRF tree

  • set protocols vrf <vrf> ospf
  • set protocols vrf <vrf> ospfv3
  • set protocols vrf <vrf> bgp <asn>

PROS:

  • matches the current CLI design for static routing
  • all contained under one, per vrf tagNode

CONS:

  • Adjustment of XML and Python helpers required - make entire protocols re-includable

Option 2

Make the VRF inline of the current routing protocol

  • set protocols ospf vrf <vrf> default-information
  • set protocols ospf vrf <vrf> area
  • set protocols ospf vrf <vrf> ...
  • set protocols ospfv3 vrf <vrf> default-information
  • set protocols ospfv3 vrf <vrf> area
  • set protocols ospfv3 vrf <vrf> ...
  • set protocols bgp <asn> vrf <vrf> neighbor x.x.x.x
  • set protocols bgp <asn> vrf <vrf> address-family ipv4-unicast ...

PROS:

  • matches the current CLI design for dynamic routing
  • all contained under one, per protocol node

CONS:

  • to many nesting levels

Option 3

No per VRF dynamic routing

Just kidding - this is no option at all!

Summary

From a programmers point of view option 2 should be preferred as it's less invasive. Given the fact that this will happen on the 1.4 current unstable branch invasive changes are totally fine given the current level of smoketests available.

From a user point of view I feel option 1 should be the option of choice.

Please comment and help with the CLI design and wishes. Given the fact that now all protocols are in good XML/Python shape implementation is rather easy now.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)

Related Objects

Event Timeline

c-po changed the task status from Open to In progress.Feb 21 2021, 8:46 AM
c-po triaged this task as Normal priority.
c-po created this task.
c-po created this object in space S1 VyOS Public.

I prefer more option2

set protocols bgp <asn> vrf 
set protocols bgp local-as 65001
set protocols bgp vrf foo local-as 65001
set protocols bgp vrf foo neighbor x.x.x.x

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.

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

The next question is if we are going to allow multiple ospf processes in global or a vrf at some point in time. when that happens using set protocols ospf vrf ... makes it harder for us to differentiate each 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

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

It was copy-paste from the original post :)

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

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

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)

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

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

ip vrf Kumquat

rd some:tag

!
router bgp XXX

yada yada
!
address-family ipv4 unicast vrf Kumquat
!

So maybe you need BOTH styles....like BFD.

OTOH, I liked the transition from:

set interfaces ethX vrrp vrrp-group 1 virtual-address A.B.C.D/X

to

set high-availability vrrp group ethX-1 virtual-address A.B.C.D./X

so I'm open to new things....having different ASNs per VRF would be a huge win so I'd probably lean more towards a style that allowed that.

I vote for option 1.

In Juniper (which is most close to VyOS syntax) you do similar
"set routing-instance XXX protocols ospf ..."
"set routing-instance XXX instance-type <vrf | vpls | l2vpn > ..."
etc

https://www.juniper.net/documentation/en_US/junos/topics/concept/routing-instances-overview.html
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/configuring-ospf-routing-instances.html