Present Location: News >> Blog >> Linux VLAN Interface Renaming

Blog

> Linux VLAN Interface Renaming
Posted by prox, from Seattle, on July 10, 2016 at 01:38 local (server) time

Almost as a continuation of Dead RPis and Interface Naming, I've now encountered some systemd/udev-related problems when creating VLAN interfaces on Linux (Debian) on one of my routers after upgrading to bleeding-edge stuff (Linux 4.6.0 and udev/systemd 230):

Say I have one of the following in /etc/network/interfaces:

auto eth1.35
iface eth1.35 inet static
     address 10.3.7.250
     netmask 255.255.255.252

or..

auto vlan35
iface vlan35 inet static
     address 10.3.7.250
     netmask 255.255.255.252
     vlan-raw-device eth1

I'll get this:

(starfire:22:23:PDT)# ifup vlan35
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 35 to IF -:eth1:-
(starfire:22:24:PDT)# ip link show dev vlan35
Device "vlan35" does not exist.
(starfire:22:24:PDT)# ip link|grep rename
61: rename61@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:24:PDT)# 

Obviously, I expected vlan35 to be created, but udev renamed it immediately to rename61.  The only udev rules that are acting on this, from what I can tell, are /etc/udev/rules.d/76-netnames.rules and /lib/udev/rules.d/19-ifrename.rules:

(starfire:22:27:PDT)# cat /lib/udev/rules.d/19-ifrename.rules
# udev rules to properly integrate ifrename.
# Renaming is done using /etc/iftab, with full ifrename functionality.
# Require udev version 107 or later.
# Please double check the path to ifrename, and make sure its available
# when udev runs (i.e. on boot partition).

# Enable this rule to test with udevtest.
#ENV{UDEV_LOG}=="6", SUBSYSTEM=="net", ACTION=="add", IMPORT{program}="/sbin/ifrename -D -V -u -i %k", NAME:="$env{INTERFACE}"

# Main ifrename rule.
# If interface is found in /etc/iftab, subsequent rename rules are bypassed.
# If interface is not found in /etc/iftab, subsequent rename rules applies.
SUBSYSTEM=="net", ACTION=="add", IMPORT{program}="/sbin/ifrename -u -i %k", NAME:="$env{INTERFACE}"
(starfire:22:27:PDT)# cat /etc/udev/rules.d/76-netnames.rules 
# Generated by netnames.sh on Sat Jul  9 19:09:59 PDT 2016
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:08:2b:0a", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:04:23:5f:4c:d9", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:08:2b:0b", NAME="eth2"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:04:23:5f:4c:d8", NAME="eth3"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:08:74:c5:d4:61", NAME="eth4"
(starfire:22:27:PDT)# 

The former comes with the udev package but the latter was created by me since I needed all of the NICs in my router to have consistent and traditional names.  I'd add these VLAN interfaces to 76-netnames.rules but there's nothing unique I can match since the MAC addresses on the VLAN interfaces are copied from the physical interface.

It's pretty obvious that udev is renaming VLAN interfaces and getting in the way.  I should normally be able to hack around this by a pre-up or up directive in /etc/network/interfaces but the renameXX interfaces are not consistent (but predictable:

(starfire:22:31:PDT)# ip link show |grep rename
(starfire:22:31:PDT)# vconfig add eth1 99      
Added VLAN with VID == 99 to IF -:eth1:-
(starfire:22:31:PDT)# ip link show |grep rename
63: rename63@eth1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:31:PDT)# vconfig rem rename63     
Removed VLAN -:rename63:-
(starfire:22:31:PDT)# ip link show |grep rename
(starfire:22:31:PDT)# vconfig add eth1 99      
Added VLAN with VID == 99 to IF -:eth1:-
(starfire:22:31:PDT)# ip link show |grep rename
64: rename64@eth1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
(starfire:22:31:PDT)# 

I suspect adding net.ifnames=0 to the kernel command line will fix things again but that's not a long-term solution.  Right now I'm left with no option but to build these interfaces manually after boot.  I'll update this post when I log a bug against one of the Debian packages involved here.

Update 20160710

I managed to get this to work by sticking the following in my /etc/udev/rules.d/76-netnames.rules:

SUBSYSTEM=="net", KERNEL=="eth*.*" ACTION=="add", NAME="$kernel"
SUBSYSTEM=="net", KERNEL=="vlan*" ACTION=="add", NAME="$kernel"

This causes udev to not touch VLAN interfaces using the naming schemes I care about (DEV_PLUS_VID_NO_PAD and VLAN_PLUS_VID_NO_PAD).

> Add Comment

New comments are currently disabled for this entry.