[RFE] add support for VRF devices

Bug #1773522 reported by Dmitrii Shcherbakov
60
This bug affects 12 people
Affects Status Importance Assigned to Milestone
netplan
Wishlist
Unassigned

Bug Description

Initial support for kernel-level VRF functionality is present in 4.4 kernels (since Ubuntu 16.04).

https://www.kernel.org/doc/Documentation/networking/vrf.txt
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian.master/config/config.common.ubuntu?id=2c5158e82d497c5eb90d6e2b8aaf07d36cb175f6#n5172
https://cumulusnetworks.com/blog/vrf-for-linux/

systemd-networkd also supports VRFs: https://www.freedesktop.org/software/systemd/man/systemd.network.html#VRF=

A VRF device acts similarly to a bridge device but for purposes of associating routing table information with an interface (physical, vlan, bridge, bond etc.).

There are several goals to achieve:

* (receiving) connected sockets created out of listening sockets bound to a particular interface address should be associated with a routing table attached to a VRF of a network device;
* (receiving) connected sockets created based on connections accepted on listening sockets bound to INADDR_ANY should be associated with a routing table of an interface the traffic originally came from;
* (sending) when traffic is initiated from a local host, if SO_BINDTODEVICE is used to bind a socket to a given interface address, a routing table associated with that interface's VRF should be used
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);

* (sending) same as above but when an eBPF program is attached to a cgroup via ip vrf exec (http://man7.org/linux/man-pages/man8/ip-vrf.8.html) instead of a socket option being set

Sample configuration via iproute2:

# echo 'net.ipv4.tcp_l3mdev_accept = 1' >> /etc/sysctl.conf
# echo 'net.ipv4.udp_l3mdev_accept = 1' >> /etc/sysctl.conf
# sysctl -p

# # create additional routing tables
# cat >> /etc/iproute2/rt_tables.d/vrf.conf <<EOF
1 mgmt
10 pub
20 storacc
30 storrepl
EOF

# # populate per-routing table default gateways
# ip route add mgmt default via 192.168.0.1
# ip route add pub default via 172.16.0.1
# ip route add storacc default via 10.10.4.1
# ip route add storrepl default via 10.10.5.1

# # add and bring up VRF devices
# ip link add mgmt type vrf table 1 && ip link set dev mgmt up
# ip link add pub type vrf table 10 && ip link set dev pub up
# ip link add storacc type vrf table 20 && ip link set dev storacc up
# ip link add storrepl type vrf table 30 && ip link set dev storrepl up

# # enslave actual devices to VRF devices
# ip link set mgmtbr0 master mgmt
# ip link set pubbr0 master pub
# ip link set storaccbr0 master storacc
# ip link set storreplbr0 master storrepl

The point here is that each routing table will have its own default gateway and there will be no need to run a dynamic routing daemon on an end host, configure static routes or source-based policy routing - any actual routing table management (static or dynamic) can performed on L3 switches or routers where it belongs.

-------

An example from ifupdown2:
https://annex.debconf.org/debconf-share/debconf16/slides/114-ifupdown2-the-ultimate-network-interface-manager--progress-and-status.pdf

auto red
iface red
    vrf-table auto

auto eth0
iface eth0
    vrf red

systemd-networkd:
https://www.freedesktop.org/software/systemd/man/systemd.netdev.html#id-1.24.12
[NetDev]
Name=vrf-test
Kind=vrf

[VRF]
Table=42

systemd-networkd also supports VRFs: https://www.freedesktop.org/software/systemd/man/systemd.network.html#VRF=
[Match]
Name=enp0s31f6

[Network]
Address=192.168.0.1/24
VRF=vrf-test

-------

proposed syntax:

network:
  version: 2
  renderer: networkd
  vrfs:
    vrf-test:
      interfaces:
        - bond0
        - br0
        - br-bond0
        - tun0
      table: auto # or a specific integer

-------

Revision history for this message
james beedy (jamesbeedy) wrote :

+1 bump

Revision history for this message
Sylvain Coutant (kassec) wrote :

Need vrf please ;) networkd-dispatcher scripts are a pain.

Revision history for this message
Gareth Owen (owensteam) wrote :

+1 bump

Revision history for this message
Jeremy (nzlamb) wrote :

+1 bump

tags: added: id-5ec2ab9d5b71a20d224dd5c1
Revision history for this message
Dieter Lievens (dieter-lievens) wrote :

+1, if netplan is virtually mandatory, at least ensure it's got all the reasonable functionality you can expect from a linux-kernel

Revision history for this message
Brian Knight (bknight-nitel) wrote :

+1, vrf support exists in other Ubuntu 20.04 routing tools (BIRD2, iproute2) but not this foundational one.

Revision history for this message
Kenneth Østrup (kennetho) wrote :

+1, would like VRF support in netplan as well.

Revision history for this message
Greg S (gschwimer) wrote :

+1 bump. We're building a greenfield production environment and vrf functionality is required in netplan.

Revision history for this message
Jon N (nistorj) wrote :

+1, would be amazing to see vrf support in netplan -- would simplify a number of start-up scripts.

Lukas Märdian (slyon)
Changed in netplan:
status: New → Confirmed
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers