[SOLVED] Systemd-netword: Can't create macvlan network

Networking Networking Software
1

Hi all,

So I’m trying to wrap my head around .netdev and .network files, which are ini-style configuration files that tell systemd-networkd how to statically configure the network.

I want to create a few macvlan interfaces off my main physical ethernet interface, but I’ve hit a really stupid issue that I can’t wrap my head around: When I tell systemd-networkd to reconfigure my network by running

$ networkctl reload

I get the following error messages reported by $ networkctl status:

Aug 15 21:28:02 vm-server systemd-networkd[587]:
/etc/systemd/network/10-veth0.netdev:5: Unknown section 'Macvlan'.
Ignoring.
Aug 15 21:28:02 vm-server systemd-networkd[587]:
/etc/systemd/network/10-veth0.netdev:5: Unknown section 'Macvlan'.
Ignoring.

Sounds pretty self-explanatory, right? No such section “Macvlan”.

But there is, damnit! It’s right here, in the official manual:

…

[MACVLAN] SECTION OPTIONS

The [MACVLAN] section only applies for netdevs of kind “macvlan”, and accepts the following key:
…

Below are the two configuration files that I’ve added, where I have triple-checked that I’ve indeed added the Kind=macvlan parameter as the documentation suggest.

/etc/systemd/network/10-veth0.netdev:

[NetDev]
Name=veth0
Kind=macvlan

[MACVLAN]
Mode=bridge

/etc/systemd/network/10-veth0.network:

[Match]
Name=veth0

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=110
UseMTU=true

Any ideas would be much appreciated!

Versions:

  • Running on Ubuntu 20.04

  • $ networkctl --version returns:

    systemd 245 (245.4-4ubuntu3.17)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
1 Like
2

Capitalisation?

Is Just, and Only the M supposed to be capitalised?
Or all caps?

1 Like
3

So here’s the thing: I’ve tried it with [MACVLAN], [Macvlan], [macvlan], they all give the same error (as mentioned in OP.)

I’ve gone ahead and taken a peek at the source code. Now I am very aware that I am using Ubuntu’s build of Systemd, but the base version is 245.4, and if we look at the source code here:

we can see that the [MACVLAN] section appears there. I am ofcourse operating on the assumption that this particular fuzz tester is testing for correct operation rather than checking for errors.

As mentioned, because its an Ubuntu build, I can’t rule out the possibility that Canonical decided the [MACVLAN] implementation in that particular version of Systemd was broken for their purposes, and patched it out… I’ll try to find the source code for my exact version of Systemd.

1 Like
4

You were right fist time, it does specify all caps in the man page.
And the Mode=bridge also matches the docs.
Welp, so much for first line sanity check…

2 Likes
5

I think actually I may have been a massive idiot…

So I was just playing around with different capitalisations, and I just realised that the log printed by networkctl status does not clear every time you run networkctl reload (fair enough.)

But what it means is that, I think this is what happened:

  • The first time I wrote the config file, I used [Macvlan]
  • $ networkctl status then complained that [Macvlan] is not a valid header
  • I went back to change it to [MACVLAN], and hit $ networkctl reload
  • $ networkctl status STILL PRINTS the LATEST log items: which in my case, was the warning about [Macvlan] not being a valid header!
  • I proceeded to go crazy, thinking that the log was cleared each time I ran $ networkctl reload, and consequently thought that those warning messages (which are completely stale by now) corresponded to the changes I had made

Having said all that… I still can’t see my veth0 device…

2 Likes
6

I was gonna say, have you tried saving the files without the 10- and so they just have the same name as the .netdev, and the .network interfaces?
Just looking at real basics…
(Shouldn’t be needed, and I have a couple 10- and 99- .network files. Just chuckin pasta at the walls. Sorry)

7

No change, unfortunately.

I did notice one passage from the systemd.netdev manual:

[MATCH] SECTION OPTIONS

A virtual network device is only created if the [Match] section matches the current environment, or if the section is empty. The following keys are accepted:

To that end I’ve modified veth0.netdev to contain an empty [Match] header as follows:

[Match]

[NetDev]
Name=veth0
Kind=macvlan

[MACVLAN]
Mode=bridge

with also no apparent changes. To clarify, I expect to see veth0 appear in the below command invocation:

$ networkctl list
IDX LINK   TYPE     OPERATIONAL SETUP     
  1 lo     loopback carrier     unmanaged 
  2 enp0s3 ether    routable    configured

2 links listed.
8

Ok… well that renaming of files from 10-veth0.* to veth0.* has created another very interesting systemd “interaction”:

$  sudo networkctl reload
$  sudo networkctl status
...
Aug 16 17:48:25 vm-server systemd-networkd[591]: veth0: The setting Name=veth0 in /etc/systemd/network/veth0.netdev conflicts with the one in /etc/systemd/network/10-veth0.netdev, ignoring
maxim@vm-server:/etc/systemd/network$ ls -a
.  ..  10-netplan-enp0s3.network  veth0.netdev  veth0.network

wtf??? why is it referencing files that don’t even exist anymore?

9

Huh, I thought the .network section needs it, like

[Match]
Name=veth0

As per

Which does look like your setup. Just different names

10

Oh sure, in my *.network I’ve got the [Match] pointing to my veth0 device:

[Match]
Name=veth0

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=110
UseMTU=true
1 Like
11

I found the issue! To cut to the chase, I needed to add one single line:

MACVLAN=veth0

to a file that I didn’t even mention here yet, which is the /etc/systemd/network/10-netplan-enp0s3.network file. It now looks like this:

[Match]
Name=enp0s3

[Network]
DHCP=ipv4
MACVLAN=veth0
LinkLocalAddressing=ipv6

[DHCP]
RouteMetric=100
UseMTU=true

(In my defence, I did not anticipate that a parent device would have to know about a child device - it seemed logical that the parent ethernet interface just does its thing, and all the configuration for any child macvlan interfaces would be completely self-contained within their respective *.network and *.netdev configuration files, but I guess not…)

Now, that file did not exist there by default: I actually just copied it from /run/systemd/network/10-netplan-enp0s3.network, and I’m not sure why it’s there, why Systemd (or whoever else) created it, and under what circumstances it gets created. In any case, I’m glad it’s there because it gave me an initial configuration to work off of for the main enp0s3 interface, but I’m not actually clear on the rules for why that file gets created under the /run directory.

I initially thought that Systemd creates this file at run-time when there is no other configuration present, but now that I do have my own configuration, it still seems to create it (but evidently files in the /etc/systemd/network directory override it.)

Anyway, the way I figured this out is this person trying to do exactly what I’m doing (down to the interface name), except they had a different issue - they weren’t doing something I was, and I wasn’t doing something they were (the one-line discrepancy.)

For future reference, $ networkctl list now shows

$ networkctl list
IDX LINK   TYPE     OPERATIONAL SETUP     
  1 lo     loopback carrier     unmanaged 
  2 enp0s3 ether    routable    configured
  3 veth0  ether    routable    configured

3 links listed.
2 Likes
12

then you just need an additional -enpNsN.network for each additional link you wanna add to the bridge?
nice

1 Like
13

Here’s my networkd setup on my router:

  • I do interface renaming because enpblafoo mean nothing to me… and I want reasonably looking firewall rules; on this machine I have interfaces named lan_physical/lan/wan/… ; on another machine I have them named onboard_physical/nic-bottom/nic-top (in tower orientation, bottom is closer to motherboard)
  • I have lan_physical and lan both, because I want my uncontainerized host software to be able to communicate with docker software running with macvlan containers
tail -n +0 /etc/systemd/network/* 
==> /etc/systemd/network/10-persistent-net-lan_physical.link <==
[Match]
MACAddress=11:22:33:44:55:66
Type=!vlan bridge

[Link]
Name=lan_physical

==> /etc/systemd/network/10-persistent-net-wan.link <==
[Match]
MACAddress=66:55:44:33:22:11

[Link]
Name=wan

==> /etc/systemd/network/guest.netdev <==
[NetDev]
Name=guest
Kind=vlan
MTUBytes=1500

[VLAN]
Id=666
GVRP=no
MVRP=no

==> /etc/systemd/network/guest.network <==
[Match]
Name=guest

[Link]
MTUBytes=1500

[Network]
DHCP=no
IPv6AcceptRA=no
LinkLocalAddressing=no
LLMNR=no
LLDP=no
Address=192.168.66.1/24

==> /etc/systemd/network/lan.netdev <==
[NetDev]
Name=lan
Kind=macvlan

[MACVLAN]
Mode=bridge

==> /etc/systemd/network/lan.network <==
[Match]
Name=lan

[Network]
DHCP=no
LinkLocalAddressing=no
IPv6AcceptRA=no
Address=10.9.8.1/24
DNS=10.9.8.8
Domains=housename.myowndomain.net
LLMNR=no

==> /etc/systemd/network/lan_physical.network <==
[Match]
Name=lan_physical

[Link]
MTUBytes=9000

[Network]
DHCP=no
LinkLocalAddressing=no
IPv6AcceptRA=no
LLMNR=no
MACVLAN=lan
VLAN=guest

==> /etc/systemd/network/wan.network <==
[Match]
Name=wan

[Link]
MTUBytes=1500

[Network]
DHCP=ipv4
LinkLocalAddressing=no
IPv6AcceptRA=no
LLMNR=no

IPMasquerade=ipv4

[DHCPv4]
UseDNS=no
RoutesToDNS=no
UseNTP=no
UseSIP=no
UseMTU=no
SendHostname=no
UseHostname=no
Hostname=level1techs
UseDomains=no
UseRoutes=no
UseGateway=yes
UseTimezone=no
ClientIdentifier=mac
networkctl 
IDX LINK            TYPE     OPERATIONAL SETUP     
  1 lo              loopback carrier     unmanaged
  2 lan_physical    ether    carrier     configured
  3 wan             ether    routable    configured
  4 lan             ether    routable    configured
  9 docker0         bridge   no-carrier  unmanaged
 84 br-53xxxxxxxxa8 bridge   routable    unmanaged
 92 br-cfzzzzzzzz2b bridge   routable    unmanaged
107 tailscale0      none     routable    unmanaged
132 veth7zzzzz3     ether    enslaved    unmanaged
135 guest           vlan     routable    configured
139 veth2zzzzz3     ether    enslaved    unmanaged
144 veth4zzzzzd     ether    enslaved    unmanaged
146 vethdzzzzz0     ether    enslaved    unmanaged

13 links listed.
2 Likes