Add support for VRF devices (LP: #1773522)

[slyon]

Description

Adding support for Virtual Routing and Forwarding devices using the sd-networkd and NetworkManager backends.
Any VRF device is linked to a (new) routing table, specified via the table stanza and can define its child interfaces via interfaces: [...]. If any routes: or routing-policy: settings are given, those are implicitly connected to the VRF's routing table.

It builds upon #272 (squashed & rebased), extracted VRF bits.

Example:

network:
  version: 2
  [...]
  vrfs:
    vrf1005:
      table: 1005
      interfaces:
        - br1
        - br1005
      routes:  # uses "table: 1005" implicitly
        - to: default
          via: 10.10.10.4
      routing-policy:
        - from: 10.10.10.42
  bridges:
    br1:
      interfaces: [...]
    br1005:
      interfaces: [...]

Checklist

• Runs make check successfully.
• Retains 100% code coverage (make check-coverage).
• New/changed keys in YAML format are documented.
• (Optional) Adds example YAML for new feature.
• (Optional) Closes an open bug in Launchpad. LP#1773522

[Conan-Kudo]

Can we have NetworkManager supported in this PR (or shortly afterward)?

[slyon]

Can we have NetworkManager supported in this PR (or shortly afterward)?

Yes, I'm working on adding NM support to this PR, too.

[Conan-Kudo]

Awesome!

[slyon]

The new integration tests (routing.test_vrf_basic) are finally passing in CI and the commit history should now be rather clean.
The new YAML schema was pre-approved via an (internal) specification document.

Thank you very much @netdever for the initial implementation.
May I ask you to do a review of the VRF code that I added/adopted on top of yours?

Also, @Conan-Kudo seems to be interested, especially in the NetworkManager part.
May I ask you to do a code-review on this PR as well?

[netdever]

Looks good to me. Thanks!

[schopin-pro]

Looks good, but I'd need confirmation on the revertability issue.

[schopin-pro]

question (blocking): Seeing vrf in this list, how is revertability handled in netplan try?

Does networkd handle it on its own?

[slyon]

This is a very good question! And I needed to do some investigation in order to answer this. But this is working as expected (and similar to vlans): vrfs are cleaned up on netplan apply (if using the --state parameter properly) or on netplan try (using the --config-file parameter). netplan try --state ... still behaves a bit odd, but that's unrelated to this PR.

VRFs are different to bonds/bridges, in that the backend (networkd/NM) does not need to initialize certain parameters, which cannot be changed afterwards and is therefore much more similar to a VLAN interface, which can just be deleted.
So I think this is all fine!

$ cat /etc/netplan/main_test.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: true
$ cat ./test.yaml
network:
  vrfs:
    vrf0:
      table: 1004
      interfaces: [enp0s31f6]
$ sudo LD_LIBRARY_PATH=. PYTHONPATH=. src/netplan.script --config-file=test.yaml try
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 111 seconds

# === meanwhile in another terminal === 
$ ip l show vrf0
110: vrf0: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a2:f7:52:d9:7c:5c brd ff:ff:ff:ff:ff:ff
# === terminal switch ===
^C
Reverting.
$ ip l show vrf0
Device "vrf0" does not exist.

(I actually found a bug/typo while testing this, which I fixed in b39dbea)

[slyon]

Thanks for the quality review @schopin-pro! I think I addressed or replied to all of your remarks.
Additionally, I've added a missing handler for the renderer stanza for VRFs in V2 of 11f9867

Also, I found a bug/typo while re-testing this, which I fixed in b39dbea

[schopin-pro]

LGTM, the netplan get question is not blocking for me.

[slyon]

Thanks for your final review. I've added a debug log about ignoring the redundant table value in V3 of 362b85a to account for that for now.

Merging.