VRF¶
VRF devices combined with ip rules provides the ability to create virtual routing and forwarding domains (aka VRFs, VRF-lite to be specific) in the Linux network stack. One use case is the multi-tenancy problem where each tenant has their own unique routing tables and in the very least need different default gateways.
Warning
VRFs are an “needs testing” feature. If you think things should be different then they are implemented and handled right now - please feedback via a task created in Phabricator.
Configuration¶
A VRF device is created with an associated route table. Network interfaces are then enslaved to a VRF device.
Configure use routing table <id> used by VRF <name>.
Note
A routing table ID can not be modified once it is assigned. It can only be changed by deleting and re-adding the VRF instance.
By default the scope of the port bindings for unbound sockets is limited to the default VRF. That is, it will not be matched by packets arriving on interfaces enslaved to a VRF and processes may bind to the same port if they bind to a VRF.
TCP & UDP services running in the default VRF context (ie., not bound to any VRF device) can work across all VRF domains by enabling this option.
Interfaces¶
When VRFs are used it is not only mandatory to create a VRF but also the VRF itself needs to be assigned to an interface.
Routing¶
Static¶
Static routes are manually configured routes, which, in general, cannot be updated dynamically from information VyOS learns about the network topology from other routing protocols. However, if a link fails, the router will remove routes, including static routes, from the RIPB that used this interface to reach the next hop. In general, static routes should only be used for very simple network topologies, or to override the behavior of a dynamic routing protocol for a small number of routes. The collection of all routes the router has learned from its configuration or from its dynamic routing protocols is stored in the RIB. Unicast routes are directly used to determine the forwarding table used for unicast packet forwarding.
Static Routes¶
Defines next-hop distance for this route, routes with smaller administrative distance are elected prior those with a higher distance.
Range is 1 to 255, default is 1.
Defines next-hop distance for this route, routes with smaller administrative distance are elected prior those with a higher distance.
Range is 1 to 255, default is 1.
Note
Routes with a distance of 255 are effectively disabled and not installed into the kernel.
Leaking¶
Interface Routes¶
Defines next-hop distance for this route, routes with smaller administrative distance are elected prior those with a higher distance.
Range is 1 to 255, default is 1.
Blackhole¶
Operation¶
It is not sufficient to only configure a VRF but VRFs must be maintained, too. For VR Fmaintenance the followin operational commands are in place.
List VRFs that have been created
vyos@vyos:~$ show vrf
VRF name state mac address flags interfaces
-------- ----- ----------- ----- ----------
blue up 00:53:12:d8:74:24 noarp,master,up,lower_up dum200,eth0.302
red up 00:53:de:02:df:aa noarp,master,up,lower_up dum100,eth0.300,bond0.100,peth0
Note
Command should probably be extended to list also the real interfaces assigned to this one VRF to get a better overview.
vyos@vyos:~$ show vrf name blue
VRF name state mac address flags interfaces
-------- ----- ----------- ----- ----------
blue up 00:53:12:d8:74:24 noarp,master,up,lower_up dum200,eth0.302
Display IPv4 routing table for VRF identified by <name>.
vyos@vyos:~$ show ip route vrf blue
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 blue:
K 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 00:00:50
S>* 172.16.0.0/16 [1/0] via 192.0.2.1, dum1, 00:00:02
C>* 192.0.2.0/24 is directly connected, dum1, 00:00:06
Display IPv6 routing table for VRF identified by <name>.
vyos@vyos:~$ show ipv6 route vrf red
Codes: K - kernel route, C - connected, S - static, R - RIPng,
O - OSPFv3, I - IS-IS, B - BGP, 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 ::/0 [255/8192] unreachable (ICMP unreachable), 00:43:20
C>* 2001:db8::/64 is directly connected, dum1, 00:02:19
C>* fe80::/64 is directly connected, dum1, 00:43:19
K>* ff00::/8 [0/256] is directly connected, dum1, 00:43:19
The ping command is used to test whether a network host is reachable or not.
Ping uses ICMP protocol’s mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (pings) will have an IP and ICMP header, followed by “struct timeval” and an arbitrary number of pad bytes used to fill out the packet.
When doing fault isolation with ping, your should first run it on the local host, to verify that the local network interface is up and running. Then, continue with hosts and gateways further down the road towards your destination. Round-trip times and packet loss statistics are computed.
Duplicate packets are not included in the packet loss calculation, although the round-trip time of these packets is used in calculating the minimum/ average/maximum round-trip time numbers.
Ping command can be interrupted at any given time using <Ctrl>+c- A brief statistic is shown afterwards.
vyos@vyos:~$ ping 192.0.2.1 vrf red
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.070 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.078 ms
^C
--- 192.0.2.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 4ms
rtt min/avg/max/mdev = 0.070/0.074/0.078/0.004 ms