Systemd Solution as of v197

Since the V197 version of systemd, radical changes have been made to deal with the problem by providing predictable network interface names [3]. In a similar approach to biosdevname, NICs obtain their names according to their unique location in the (virtual) hardware (Figure 2).

Figure 2: Naming of network interfaces by systemd.

The name starts with two characters for the type of interface: en for Ethernet, wl for WLAN, ww for WWAN. The type is then distinguished: o<Index> represents an onboard interface with an ordinal number; s<Slot> is a slot card with an ordinal number, and p<Bus>s<Slot> reveals the location of the PCI card. Examples of the results are, say, enp2s0 or enp2s1. This shows just a small part of the naming scheme; more information can be found online [4] [5].

Aftermath

However, some entities have fallen foul of this naming revolution. Programs in the enterprise environment in particular, but also many (installation) scripts, expect a traditional scheme of network names based on a pattern of eth* and thus suddenly fail to work. A proposed solution [3] involves copying 80-net-name-slot.rules

cp /usr/lib/udev/rules.d/80-net-name-slot.rules \
   /etc/udev/rules.d/80-net-name-slot.rules

and editing as shown in Listing 1 so that they assign device names in line with the traditional scheme.

ACTION=="remove", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"
NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_ONBOARD}", NAME="%c"
NAME=="", ENV{ID_NET_NAME_SLOT}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_SLOT}", NAME="%c"
NAME=="", ENV{ID_NET_NAME_PATH}!="", PROGRAM="/usr/bin/name_dev.py $env{ID_NET_NAME_PATH}", NAME="%c"
LABEL="net_name_slot_end"

The PROGRAM directive calls a small Python script that maps to the old names (Listing 2). The script can be adapted to your environment by simply changing the key-value pairs in line 4. The following conditions are now met:

• The network configuration is no longer dependent on chance.
• The traditional naming scheme is maintained.
• Systems can be cloned in the cloud indefinitely.

You can try out this systemd version with Chakra Linux [6] as of version 2013.01; it will take some time for other distributions to catch up. Fedora 19 will also use this version.

01 #!/usr/bin/env python
02 import sys
03
04 dict = {'enp2s0':'eth0', 'enp2s1':'eth1'}
05
06 if sys.argv[1] in dict:
07         print dict[sys.argv[1]]
08 else:
09         print(sys.argv[1])
10 exit(0)

Workaround

Despite renewed efforts, you often have to cope with the generator rules in everyday life (Table 1). Fortunately, the udev ruleset is powerful enough to drag itself out of the dirt. The trick used in Listing 3 relies on the fact that no other applicable rules are executed after assigning a name to a device. Thus, the udev rule simply assigns the name proposed by the kernel (eth*) with the corresponding kernel ordinal number (%n).

Rules for KVM:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:*", KERNEL=="eth*", NAME="eth%n"
Rules for VMware:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:*", KERNEL=="eth*", NAME="eth%n"
Rules for Xen:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:16:3E:*", KERNEL=="eth*", NAME="eth%n"

By setting a MAC address pattern that matches the MAC addresses automatically generated by the hypervisor, you can specify the rule in more detail. If you add appropriate mapping to this rule, it is also possible to use a virtual machine template for a different network configuration than for the clones. Existing persistent net rules are not overwritten by the net generator or by updates.

As you know, there's an exception to every rule, including this one: The udev rules assume that the hypervisor (or hardware) always enables the devices in the configured order and that they are thus known to the kernel in the same order. For KVM and VMware, this assumption works; with Hyper-V, however, it seems not to be the case [7]. The only solution is then the biosdevnames package or manual rework.

These rules work around the generators for persistent net rules and thus remove the disadvantages that accompany them. Another advantage of this approach is that the traditional device names (eth*) are kept; thus, applications and scripts that rely on precisely these names continue to work. However, the problem remains that the kernel assigns device numbers to the devices in the order of their appearance during the boot process. The rules in Listing 3 can therefore only be used successfully in environments in which this order is always the same.