netplan.io autopkgtest failures with NetworkManager 1.44.0

[Jeremy Bícha]

netplan.io's autopkgtests fail with NetworkManager 1.44.0

This happens in both Debian and Ubuntu 23.10

https://autopkgtest.ubuntu.com/packages/netplan.io/mantic/amd64
https://ci.debian.net/packages/n/netplan.io/testing/amd64

autopkgtest log excerpt
----------------

3624s ======================================================================
3624s FAIL: test_vrf_basic (__main__.TestNetworkManager.test_vrf_basic)
3624s ----------------------------------------------------------------------
3624s Traceback (most recent call last):
3624s File "/tmp/autopkgtest-lxc.tzad0mtq/downtmp/build.vhF/src/tests/integration/routing.py", line 316, in test_vrf_basic
3624s self.assertIn('10.10.0.0/16 via 10.10.10.1 dev vrf0', out)
3624s AssertionError: '10.10.0.0/16 via 10.10.10.1 dev vrf0' not found in '10.10.10.0/24 dev eth42 proto kernel scope link src 10.10.10.22 metric 100 \nlocal 10.10.10.22 dev eth42 proto kernel scope host src 10.10.10.22 \nbroadcast 10.10.10.255 dev eth42 proto kernel scope link src 10.10.10.22 \n11.11.11.0/24 via 10.10.10.2 dev eth42 proto static metric 100 \n'
3624s
3624s ----------------------------------------------------------------------
3624s Ran 28 tests in 757.513s
3624s
3624s FAILED (failures=1, skipped=3)
3624s autopkgtest [15:11:48]: test routing: -----------------------]
3624s autopkgtest [15:11:48]: test routing: - - - - - - - - - - results - - - - - - - - - -
3624s routing FAIL non-zero exit status 1

[Danilo Egea Gondolfo (danilogondolfo)]

The new Network Manager is not installing the route for the vrf0 interface.

This change in behavior might be related to this commit https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/dabfa26a41edc7911a45a4689d555e8f055b0373

The interface is not being assigned any IP addresses. And we actually can't add IPs to VRFs in Netplan but we probably should...

Test case:

---
network:
  dummy-devices:
    dummy0:
      renderer: NetworkManager
      addresses: [10.10.10.22/24]
      routes:
      - to: 11.11.11.0/24
        via: 10.10.10.2
        table: 1000
  vrfs:
    vrf0:
      renderer: NetworkManager
      table: 1000
      interfaces: [dummy0]
      routes:
      - to: 10.10.0.0/16
        via: 10.10.10.1
      routing-policy:
      - from: 10.10.10.42
---

The interface is created

# nmcli con show
NAME UUID TYPE DEVICE
netplan-vrf0 be402d13-a9f8-395d-8382-81a1ef0bdd1d vrf vrf0
netplan-enp5s0 e1419a5e-5e1d-3fff-a17c-b2fc6d2cef99 ethernet enp5s0
lo 6c74c0d6-04c6-4ea2-b5e3-b53b579e3adf loopback lo
netplan-dummy0 9c4bae2d-b07e-3aea-965f-76d9e84fa47e dummy dummy0

But will stuck in "activating"

# nmcli -f GENERAL.STATE con show netplan-vrf0
GENERAL.STATE: activating

And the route "10.10.0.0/16 via 10.10.10.1" will not be installed

# ip r show table 1000
10.10.10.0/24 dev dummy0 proto kernel scope link src 10.10.10.22 metric 550
local 10.10.10.22 dev dummy0 proto kernel scope host src 10.10.10.22
broadcast 10.10.10.255 dev dummy0 proto kernel scope link src 10.10.10.22
11.11.11.0/24 via 10.10.10.2 dev dummy0 proto static metric 550

In Lunar, with Network Manager 1.42, the vrf interface will also stuck in activating, but the route will be installed.

Assigning an IP to the vrf interface will make the test pass but Netplan doesn't support it. Adding the IP via networkmanager.passthrough fixes the test for Network Manager but will break networkd.

With networkd, the route is installed even if the interface has no IP addresses.

We could just stop checking for that route to make the test pass but we probably want to rethink our support for VRFs in Netplan.

Lukas, what do you think?

[Lukas Märdian (slyon)]

This seems to be an intentional change on the side of NetworkManager. So yes, we should adopt Netplan accordingly.

I wonder if a simple patch like this will already do the trick?
```diff
diff --git a/src/parse.c b/src/parse.c
index b930b750..a1730e51 100644
--- a/src/parse.c
+++ b/src/parse.c
@@ -2864,6 +2864,7 @@ static const mapping_entry_handler vlan_def_handlers[] = {
 };

 static const mapping_entry_handler vrf_def_handlers[] = {
+ COMMON_LINK_HANDLERS,
     COMMON_BACKEND_HANDLERS,
     {"renderer", YAML_SCALAR_NODE, {.generic=handle_netdef_renderer}, NULL},
     {"interfaces", YAML_SEQUENCE_NODE, {.generic=handle_vrf_interfaces}, NULL},
diff --git a/tests/integration/routing.py b/tests/integration/routing.py
index f29b012b..f63be36f 100644
--- a/tests/integration/routing.py
+++ b/tests/integration/routing.py
@@ -295,6 +295,7 @@ class _CommonTests():
         table: 1000
   vrfs:
     vrf0:
+ addresses: [10.10.10.20/24]
       table: 1000
       interfaces: [%(ec)s]
       routes:
```

[Danilo Egea Gondolfo (danilogondolfo)]

Yes, I think it's the best approach. It will also improve the integration with Network Manager as it supports adding IPs to VRFs but Netplan doesn't.

[Lukas Märdian (slyon)]

https://github.com/canonical/netplan/pull/401

[Launchpad Janitor (janitor)]

This bug was fixed in the package netplan.io - 0.107-2

---------------
netplan.io (0.107-2) unstable; urgency=medium

  * d/control: Add runtime dependency on python3-cffi-backend (LP: #2031962)
  * d/t/control: Enable dummy & veth integration tests
  * Fix NetworkManager 1.44 VRF compatibility (LP: #2031421, Closes: #1049432)
    d/p/0001-parse-allow-COMMON_LINK_HANDLERS-for-VRFs-LP-2031421.patch
  * d/rules: Fix dh_clean to cleanup after tests (Closes: #1046524)
  * Fix OVS tests by avoiding NetworkManager taking control
    d/p/0002-test-ovs-Avoid-NetworkManager-taking-contol-breaking.patch
  * d/t/control: Don't hide real OVS test failures as skippable

 -- Lukas Märdian <email address hidden> Mon, 21 Aug 2023 17:25:33 +0200