Page MenuHomeVyOS Platform

Add VRF support
Closed, ResolvedPublicFEATURE REQUEST

Assigned To
Authored By
Unknown Object (User)
Mar 31 2016, 5:23 PM
Referenced Files
"Like" token, awarded by Lillecarl."Like" token, awarded by Raeven."Like" token, awarded by xzjt."Like" token, awarded by hard."Like" token, awarded by Maltahl."Like" token, awarded by rherold."Like" token, awarded by isithran."Like" token, awarded by m.cremers."100" token, awarded by mrciarano.



Difficulty level
Hard (possibly days)
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I think we should make somewhere a list of services and which level of vrf support they have.
Openssh for example has build in support for vrf

And we should declare which services should be available in the management vrf.
From my point of view:

  • ssh
  • ntp
  • syslog
  • snmp
  • API

Why do we need to explicitly create the routing table? why not name the routing table entry like the VRFs name? We should try to keep the CLI as minimal as possible. More CLI nodes, more headache.

When I think about the the Cisco VRF implementation I ise I just create it with a name and refer to it. It creates a routing table for me and I do not care. When adding routes to the table I refer to the VRF name and not an arbitrary number.

Downside of the explicit table number is a user now needs to remember the VRF and table mapping.

We could indeed create the VRF as we parse interfaces, and auto-allocate the VRF number, removing this control from the user.

I would have to move the VRF creation code within the Interface class and any typo on names would create two VRF as there would be no sanitisation, but auto-completion could be done via /etc/iproutes/rt_tables

I am not aware of any "end of configuration check" hook which could be used to parse all the interfaces and notice that a VRF is not used anymore and remove it.
This would have to be run when ALL the configuration has been parsed and acted upon as VRF can be used in different interfaces, which have different handlers.
If we do not, we would end up leaking resources.

Auto completion should be done on a per CLI path:

  <path>vrf name</path>

Assuming the VRFs name will be set using set vrf name 'red'

Adding interfaces to VRFs seems to be a bit of a hazzle:

  • set vrf name <name> member <interface>
    • + has the advantage of having everything in one place
    • - routes could leak during system boot between VRFs until interfaces are properly enslaved to a VRF
  • set interfaces <type> <interface> vrf <name>
    • + has the advantage of knowing the right per interface priority
    • - vrf configuration is split accross different sections

Pondering pro and con I go with option #2 now

Adding a dummy interface to VRF:

VRF foo

vyos@vyos# show interfaces dummy dum1
 vrf foo
vyos@vyos# sudo ip vrf exec foo ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from icmp_seq=3 ttl=64 time=0.070 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 30ms
rtt min/avg/max/mdev = 0.070/0.075/0.082/0.005 ms

VRF default

vyos@vyos# ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=59 time=7.92 ms

see the latency

c-po changed the task status from Open to In progress.Mar 4 2020, 9:15 PM
c-po claimed this task.
c-po set Is it a breaking change? to Unspecified (possibly destroys the router).
c-po changed the task status from In progress to Needs testing.Mar 6 2020, 6:38 PM
c-po changed Difficulty level from Easy (less than an hour) to Hard (possibly days).
c-po moved this task from Need Triage to In Progress on the VyOS 1.3 Equuleus board.

VRF route leaking needs to be added to CLI. Routes can be leaked using:

FRR vtysh: ip route vrf red nexthop-vrf default

This will add a routing table entry into VRF red for destination going via the default VRF

vyos# show ip route vrf red
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

VRF red:
K [255/8192] unreachable (ICMP unreachable), 00:33:44
S>* [1/0] via, eth0.204(vrf default), 00:01:01
c-po changed the status of subtask T2111: VRF add route leaking support from Open to In progress.
erkin set Issue type to Feature (new functionality).Sep 1 2021, 10:56 AM