Beware of the details (and VLANs)

A friend today challenged me with this problem on an Ubuntu box:

auto eth2
iface eth2 inet static
    address 10.23.0.32
    netmask 31

auto eth2.210
iface eth2.210 inet static
    address 10.42.0.32
    netmask 31

root@box:~# ifup eth2.210
Cannot find device "eth2.210"
Failed to bring up eth2.210.

The first thing coming to mind is “package vlan missing?”, which it was. After installing it, it got more interesting:

root@box:~# ifup eth2.210
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
ifup: recursion detected for interface eth2 in parent-lock phase
ERROR: trying to add VLAN #210 to IF -:eth2:-  error: File exists
Cannot find device "eth2.210"
Failed to bring up eth2.210

A little poking around showed, that there’s no interface eth2.210 present in the system, but

root@box:~# cat /proc/net/vlan/config 
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
rename10       | 210  | eth2

root@box:~# ip l
[...]
10: rename10@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether DE:AD:BE:EF:23:42 brd ff:ff:ff:ff:ff:ff
[...]

Deleting the renameNN interface an running ifup again, just created a renameNN+1 interface with kernel log entries like

[7366672.699018] rename14: renamed from eth2.210

I suspected some bugs in /etc/network/if-{,pre-}up.d/ but this even happend, when manually running

ip link add link eth2 name eth2.210 type vlan id 210

or

ip link add link eth2 name vlan210 type vlan id 210

Dafuq?

Being confused about this problem, my money was on udev being involved in this situation, which turned out to be right. There were some autogenerated rules by some deployment tool, which seemed a bit short:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:00", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:11", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="DE:AD:BE:EF:23:42", NAME="eth2"
[...]

Comparing these with the autogenerated udev rules on one of my systems which successfully use lots of VLANs, confirmed that the lines contain more attributes:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:15:23:42:47:11", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Adding those attributes to the file above, solved the issue. Now what’s the important part?

Digging through the sysfs information of physical and VLAN interfaces present on my home server and fiddling around with udevadm info showed that all the attributes are the same of the master and VLAN interfaces:

KERNEL=="eno1"
ATTR{address}=="08:15:23:42:47:11"
ATTR{dev_id}=="0x0"
ATTR{type}=="1"
KERNEL=="vlan42"
ATTR{address}=="08:15:23:42:47:11"
ATTR{dev_id}=="0x0"
ATTR{type}=="1

The only difference is the value of the KERNEL variable, but I would assume, that at the time, the udev rules are applied the interface would be called eth*, at least in the case of a new device eth2.210.

Can anyone shed light more on what makes the difference here?

Leave a Reply