[RFE] add support for VRF devices

Bug #1773522 reported by Dmitrii Shcherbakov
74
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Netplan
Fix Released
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 Schwimer (gschwim) 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
Revision history for this message
sascha arthur (sarthur) wrote :

+1 :(

Revision history for this message
Anthony (atimmins) wrote :

I have filed a PR that adds VRF support here: https://github.com/canonical/netplan/pull/272

Lukas Märdian (slyon)
Changed in netplan:
status: Confirmed → In Progress
Revision history for this message
Lukas Märdian (slyon) wrote :

Basic support for VRF landed in netplan v0.105: https://github.com/canonical/netplan/pull/285

Changed in netplan:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.