How to predict 'predictable network interface names' ?

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

Hi,

for me biosdevname shows both versions:

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

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/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’ ?

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


#!/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,"
";

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

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

  1. 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. 1. 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.

Of potential interest

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

Example interface IDs The default naming precedence rules are these:

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (ID_NET_NAME_ONBOARD, example: eno1)
  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (ID_NET_NAME_SLOT, example: ens1)
  3. Names incorporating physical/geographical location of the connector of the hardware (ID_NET_NAME_PATH, example: enp2s0)
  4. Names incorporating the interfaces’s MAC address (ID_NET_NAME_MAC, example: enx78e7d1ea46da)
  5. 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[HR][/HR]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.

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)

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

/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

This did the job (for a while)

OUT=`udevadm test-builtin net_id /sys/class/net/eth0 2&gt; /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&gt; /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&gt; /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:

#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:

 # 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

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:


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.

Please explain how to get this information before system is installed, when you have bare metal box and want to automate interface setup during installation.

Hi,

do you have an idea why udevadm sees ‘ID_NET_NAME_SLOT=ens32’ in one case and not in the other case.?

d.oertel

On 07/29/2014 11:06 AM, arvidjaar wrote:
>
> lwfinger;2656468 Wrote:
>> Both of these are completely predictable.
>
> Please explain how to get this information before system is installed,
> when you have bare metal box and want to automate interface setup during
> installation.

The first thing to determine is why your openSUSE system is getting a strange
result. I just rebooted my system, and found that kernel 3.11, and my regular
3.16-rcX are getting enp0s25.

BTW, I ran the script you posted above, and it fails to get any answer, while my
Perl script posted earlier in this thread gets enp0s25. The reason that your
script fails is that /sys/class/net/eth0 does not exist after the device is
renamed. I made your script work by changing every instance of “eth0” to “e*”.
Of course, that will fail if you have more than one wired interface.

Hi to all,

thank you for your answers.

But I have two remarks @lwfinger that describes why they don’t help me:

lwfinger:
“If openSUSE 13.1 is getting ens32 rather than enp2s0, then I suspect some file
in /etc/udev/rules.d/ is involved.”

"The first thing to determine is why your openSUSE system is getting a strange
result.

As mentioned in the post from deano_ferrari and the Links:

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

The default naming precedence rules are these:

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

(Rule 4 is disabled by default.)

http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  4. Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
  5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

there are more than one rule.

As I posted, my suse box had the udevadm outptut while Suse running “ID_NET_NAME_SLOT=ens32” so the interface name has to be ens32 because rule 2 has a higher priority than rule 3 (which would lead to ‘enp2s0’). So what this suse system does on this ‘Hardware’ is not ‘strange’ at all, but according to the rules.

So at the moment I’m convinced that every solution of this problem hast to implement all these rules.

The perl script posted by lwfinger implements only rule 3 and as far I see the situation that is not enough to predict correctly.

Last not least: My script work properly because it implements the 3 rules and it is designed to run in an a Ubuntu based environment (see my first posting) and there is no use of ‘predictable netweork interface names’ right now - so the use of ‘eth0’ is correct.

So my script would predict correctly the interface names if the output of udevadm would be the same in different environments.
But as my post shows, it isn’t.

So again is my question: What is influencing the output of udevadm on the same machines in different environments.

Thanks in advance
d.oertel

Hi to all,

some experiments (and hours) later:

> What is influencing the output of udevadm on the same machines in different environments.

It seems that my Ubuntu Precise based bootimage is to old for rule 2. In fact has a Ubuntu Precise only udevadm Version 175.
(So even if I chroot to a opsenSuse 13.1 environment I still use a /dev from a to old udev)
Using a Ubuntu Trust Thar (14.04) environment (with udevadm Version 208) gives the same output as booting to openSuse 13.1 or Fedora 20.
So this would be the trick to predict the network interface name correctly …

Thank you to all the People in this Thread.

d.oertel

For the record:

According to this page passing net.ifnames=0 to the kernel (amongst other options) disables this piece of wank.

I haven’t rebooted yet. If I never post back again, you’ll know it didn’t work.