How to predict 'predictable network interface names' ?

**doertel** · 17-Dec-2013, 11:36

Hi to all,

openSUSE 13.1 uses the 'predictable network inteface names' (http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) or 'consistent network interface device naming' (https://en.wikipedia.org/wiki/Consistent_Network_Device_Naming).

That is ok..

My problem is that the device naming seems to be a little unpredictable and inconsistent.
In theory (I thought) the utility biosdevname should give me the name which will be used by systemd_udevd.
At my boxes I get for example 'em1' from biosdevname and 'enp0s7' by systemd_udevd.

Why is this a problem:
We (opsi.org) are installing Linux and Windows OS automated based by a linux bootimage.
This linux bootimage is always the same and has the legacy naming convention.
When the opensuse 13.1 installation is finished I can (via chroot) configure the network interfaces via
"yast2 lan add name=eth0 bootproto=dhcp"
After a reboot the interface eth0 is renamed to enp0s7 (for example) and unconfigured again.
But I can configure it while installation via chroot as
"yast2 lan add name=enp0s7 bootproto=dhcp"
and everything is fine. Therefore I need to predict the correct predictable network interface name.
I thought biosdevname should give me this, but it does not work.
You can try this on your opsenSUSE 13.1 calling
"biosdevname -d <your interface name>"
I get for the most internal devices differences.

So has anybody an idea, utility, script, ... which helps to predict 'predictable network interface names' ?

Thanks in advance
d.oertel

**hendwolt** · 17-Dec-2013, 13:30

Hi,

for me biosdevname shows both versions:

Code:

lthendrik:/boot # biosdevname -d 
BIOS device: em1
Kernel name: wlp6s5
Permanent MAC: 00:13:CE:F2:6A:35
Assigned MAC : 00:13:CE:F2:6A:35
ifIndex: 3
Driver: ipw2200
Driver version: 1.2.2kdmprq
Firmware version: ABG:9.0.5.27 (Dec 12 2007)
Bus Info: 0000:06:05.0
PCI name      : 0000:06:05.0
PCI Slot      : embedded
Embedded Index: 1

BIOS device: p2p1
Kernel name: enp2s0
Permanent MAC: 00:0B:5D:C7:3E:B0
Assigned MAC : 00:0B:5D:C7:3E:B0
ifIndex: 2
Driver: tg3
Driver version: 3.133
Firmware version: 5751m-v3.29a
Bus Info: 0000:02:00.0
PCI name      : 0000:02:00.0
PCI Slot      : 2
Index in slot: 1

On my machines systemd uses the "Kernel name"s (wlp6s5 and enp2s0).

Hendrik

**lwfinger** · 17-Dec-2013, 14:10

On 12/17/2013 12:46 PM, doertel wrote:
>
> Hi to all,
>
> openSUSE 13.1 uses the 'predictable network inteface names'
> (http://www.freedesktop.org/wiki/Soft...nterfaceNames/)
> or 'consistent network interface device naming'
> (https://en.wikipedia.org/wiki/Consis..._Device_Naming).
>
> That is ok..
>
> My problem is that the device naming seems to be a little unpredictable
> and inconsistent.
> In theory (I thought) the utility biosdevname should give me the name
> which will be used by systemd_udevd.
> At my boxes I get for example 'em1' from biosdevname and 'enp0s7' by
> systemd_udevd.
>
> Why is this a problem:
> We (opsi.org) are installing Linux and Windows OS automated based by a
> linux bootimage.
> This linux bootimage is always the same and has the legacy naming
> convention.
> When the opensuse 13.1 installation is finished I can (via chroot)
> configure the network interfaces via
> "yast2 lan add name=eth0 bootproto=dhcp"
> After a reboot the interface eth0 is renamed to enp0s7 (for example) and
> unconfigured again.
> But I can configure it while installation via chroot as
> "yast2 lan add name=enp0s7 bootproto=dhcp"
> and everything is fine. Therefore I need to predict the correct
> predictable network interface name.
> I thought biosdevname should give me this, but it does not work.
> You can try this on your opsenSUSE 13.1 calling
> "biosdevname -d <your interface name>"
> I get for the most internal devices differences.
>
> So has anybody an idea, utility, script, ... which helps to predict
> 'predictable network interface names' ?

The new scheme is entirely predictable. The script below will do the conversion:

Code:

#!/usr/bin/perl
$string = `/sbin/lspci | grep Ethernet`;
$bus = hex(substr $string, 0, 2);
$device = hex(substr $string, 3, 2);
print "enp", $bus,"s", $device,"\n";

On my system, bus 00:0a.0 => enp0s10.

**arvidjaar** · 18-Dec-2013, 00:35

Originally Posted by lwfinger

The new scheme is entirely predictable

Please predict what name interface gets on a ... let's say Dell XPS13. Without first booting openSUSE (or any Linux for that matter) on this system.

On my system, bus 00:0a.0 => enp0s10.

The practical problems are

it is not the only possible scheme. It will prefer slot numbers if your system supports it. Now I have NEVER seen this mentioned in any hardware datasheet I met. So you really do not know whether you get enp0s10 or ens3 assuming your controller is in Slot 3. And this may change with BIOS update ... this happened to me just recently with QEMU VM after update of host from 12.3 to 13.1, because new QEMU suddenly started to support slot numbers and interface name changed - without doing anything on VM side.
Information of PCI bus and device numbers is not something that is easily available either.

So while all this sounds very nice in theory, the end result is approximately the same as with traditional ethX - you never know in advance what name your interface gets. In a sense, it became worse - with single interface you at least got predictable eth0 in the past, while now you get completely random name.

And of course for specific projects where hardware was known in advance it was always possible to assign interface names based on PCI topology.

This change was made to make life of developers easier. Not users ...

**deano_ferrari** · 18-Dec-2013, 00:43

Originally Posted by arvidjaar

Please predict what name interface gets on a ... let's say Dell XPS13. Without first booting openSUSE (or any Linux for that matter) on this system.

The practical problems are

it is not the only possible scheme. It will prefer slot numbers if your system supports it. Now I have NEVER seen this mentioned in any hardware datasheet I met. So you really do not know whether you get enp0s10 or ens3 assuming your controller is in Slot 3. And this may change with BIOS update ... this happened to me just recently with QEMU VM after update of host from 12.3 to 13.1, because new QEMU suddenly started to support slot numbers and interface name changed - without doing anything on VM side.
Information of PCI bus and device numbers is not something that is easily available either.

So while all this sounds very nice in theory, the end result is approximately the same as with traditional ethX - you never know in advance what name your interface gets. In a sense, it became worse - with single interface you at least got predictable eth0 in the past, while now you get completely random name.

And of course for specific projects where hardware was known in advance it was always possible to assign interface names based on PCI topology.

This change was made to make life of developers easier. Not users ...

I'm inclined to agree with your reasoning here, but of course it is easy enough to reinstate the persistent naming if preferred.

**deano_ferrari** · 18-Dec-2013, 00:47

Of potential interest

http://wiki.gentoo.org/wiki/Udev/upgrade

Example interface IDs

The default naming precedence rules are these:

Names incorporating Firmware/BIOS provided index numbers for on-board devices (ID_NET_NAME_ONBOARD, example: eno1)
Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (ID_NET_NAME_SLOT, example: ens1)
Names incorporating physical/geographical location of the connector of the hardware (ID_NET_NAME_PATH, example: enp2s0)
Names incorporating the interfaces's MAC address (ID_NET_NAME_MAC, example: enx78e7d1ea46da)
Classic, unpredictable kernel-native ethX naming (example: eth0)

(Rule 4 is disabled by default.) So, if your output is like this:
user $ udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

ID_NET_NAME_MAC=enxd4a8xxxxxxxx
ID_NET_NAME_ONBOARD=eno1
ID_NET_NAME_PATH=enp1s0f1
The interface will be named eno1, because ID_NET_NAME_ONBOARD takes precedence over ID_NET_NAME_PATH.

**robin_listas** · 18-Dec-2013, 07:08

On 2013-12-18 08:36, arvidjaar wrote:
>
> lwfinger;2609312 Wrote:
>>
>> The new scheme is entirely predictable
> Please predict what name interface gets on a ... let's say Dell XPS13.
> Wihtout first booting openSUSE on this system.
>> On my system, bus 00:0a.0 => enp0s10.
>
> The practical problems are
>
> - it is not the only possible scheme. It will prefer slot numbers *if
> your system supports it*. Now I have *NEVER* seen this mentioned in
> any hardware datasheet I met. So you really do not know whether you
> get enp0s10 or ens3 assuming your controller is in Slot 3. And this
> may change with BIOS update ... this happened to me just recently with
> QEMU VM after update of *host* from 12.3 to 13.1, because new QEMU
> suddenly started to support slot numbers and interface name changed -
> without doing *anything* on VM side.
> - Information of PCI bus and device numbers is not something that is
> easily available either.
>
> So while all this sounds very nice in theory, the end result is
> approximately the same as with traditional ethX - you never know in
> advance what name your interface gets. In a sense, it became worse -
> with single interface you at least got predictable eth0 in the past,
> while now you get completely random name.
>
> And of course for specific projects where hardware was known in advance
> it was always possible to assign interface names based on PCI topology.
>
> This change was made to make life of developers easier. Not users ...

I agree...

--
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)

**tsu2** · 18-Dec-2013, 11:27

I just ran into this...
This seems to be specified in

Code:

/etc/sysconfig/network/config

In that file, one of the configurations specifies the allowed network prefix names.
Of course, unless over-written in some way.

TSU

**doertel** · 29-Jul-2014, 07:51

Originally Posted by deano_ferrari

Of potential interest

http://wiki.gentoo.org/wiki/Udev/upgrade

This did the job (for a while)

Code:

OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_ONBOARD`
EXITCODE=$?
if [ $EXITCODE -eq 0 ]; then
    NEWETH0=`echo $OUT | cut -d = -f 2`
else
    OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_SLOT`
    EXITCODE=$?
    if [ $EXITCODE -eq 0 ]; then
        NEWETH0=`echo $OUT | cut -d = -f 2`
    else
        OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_PATH`
        EXITCODE=$?
        if [ $EXITCODE -eq 0 ]; then
            NEWETH0=`echo $OUT | cut -d = -f 2`
        fi
    fi
fi
echo Will configure predicted network interface name $NEWETH0

But now I see that this not works always: The same udevadm version give on the same machine different answers in different environments
On a Ubuntu precise based system with kernel 3.15.1 I get:

Code:

#udevadm --version
208
#udevadm test-builtin net_id /sys/class/net/eth0
calling: test-builtin
=== trie on-disk ===
tool version:          208
file size:         5866515 bytes
header size             80 bytes
strings            1296323 bytes
nodes              4570112 bytes
load module index
ID_NET_NAME_MAC=enx000c29a7b286
ID_OUI_FROM_DATABASE=VMware, Inc.
ID_NET_NAME_PATH=enp2s0
unload module index

So the predicted network interface name is enp2s0

But in fact a suse 13.1 system with kernel 3.11.6-4 renames this interface to ens32:

Code:

 # udevadm --version
208
 # udevadm test-builtin net_id /sys/class/net/ens32
calling: test-builtin
=== trie on-disk ===
tool version:          208
file size:         5866515 bytes
header size             80 bytes
strings            1296323 bytes
nodes              4570112 bytes
load module index
ID_NET_NAME_MAC=enx000c29a7b286
ID_OUI_FROM_DATABASE=VMware, Inc.
ID_NET_NAME_PATH=enp2s0
ID_NET_NAME_SLOT=ens32
unload module index

So again I have the problem to predict the name of the Interface while installing Suse 13.1 from a non Suse bootimage.

Has anybody an Idea how to solve this problem ?

Thanks in advance
d.oertel

**lwfinger** · 29-Jul-2014, 08:20

On 07/29/2014 09:56 AM, doertel wrote:
>
> deano_ferrari;2609420 Wrote:
>> Of potential interest
>>
>> http://wiki.gentoo.org/wiki/Udev/upgrade
>
> This did the job (for a while)
>
> Code:
> --------------------
> OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_ONBOARD`
> EXITCODE=$?
> if [ $EXITCODE -eq 0 ]; then
> NEWETH0=`echo $OUT | cut -d = -f 2`
> else
> OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_SLOT`
> EXITCODE=$?
> if [ $EXITCODE -eq 0 ]; then
> NEWETH0=`echo $OUT | cut -d = -f 2`
> else
> OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null | grep ID_NET_NAME_PATH`
> EXITCODE=$?
> if [ $EXITCODE -eq 0 ]; then
> NEWETH0=`echo $OUT | cut -d = -f 2`
> fi
> fi
> fi
> echo Will configure predicted network interface name $NEWETH0
>
> --------------------
>
>
> But now I see that this not works always: The same udevadm version give
> on the same machine different answers in different environments
> On a Ubuntu precise based system with kernel 3.15.1 I get:
>
> Code:
> --------------------
> #udevadm --version
> 208
> #udevadm test-builtin net_id /sys/class/net/eth0
> calling: test-builtin
> === trie on-disk ===
> tool version: 208
> file size: 5866515 bytes
> header size 80 bytes
> strings 1296323 bytes
> nodes 4570112 bytes
> load module index
> ID_NET_NAME_MAC=enx000c29a7b286
> ID_OUI_FROM_DATABASE=VMware, Inc.
> ID_NET_NAME_PATH=enp2s0
> unload module index
>
> --------------------
>
> So the predicted network interface name is enp2s0
>
> But in fact a suse 13.1 system with kernel 3.11.6-4 renames this
> interface to ens32:
>
> Code:
> --------------------
> # udevadm --version
> 208
> # udevadm test-builtin net_id /sys/class/net/ens32
> calling: test-builtin
> === trie on-disk ===
> tool version: 208
> file size: 5866515 bytes
> header size 80 bytes
> strings 1296323 bytes
> nodes 4570112 bytes
> load module index
> ID_NET_NAME_MAC=enx000c29a7b286
> ID_OUI_FROM_DATABASE=VMware, Inc.
> ID_NET_NAME_PATH=enp2s0
> ID_NET_NAME_SLOT=ens32
> unload module index
> --------------------
>
>
> So again I have the problem to predict the name of the Interface while
> installing Suse 13.1 from a non Suse bootimage.
>
> Has anybody an Idea how to solve this problem ?

If openSUSE 13.1 is getting ens32 rather than enp2s0, then I suspect some file
in /etc/udev/rules.d/ is involved. Of course, that is the case that cannot be
predicted. There should be no difference between kernel 3.11 and kernel 3.15.

On my openSUSE 13.1 system, lspci shows my network devices as follows:

Code:

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)
04:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)

As hexadecimal 19 equals decimal 25, the resulting wired device name is enp0s25
and the wireless device is wlp4s0. Both of these are completely predictable.