Re: how to compute predictable network interface names?

[Christian Seiler <christian@iwakd.de>]

On 02/16/2017 12:24 PM, Harald Dunkel wrote:
> I understand that the predictable nic names can be turned off
> using
> 
> 	net.ifnames=0
> 
> on the kernel command line, but I wonder if there is a shell
> script to actually predict the "enpYsZ" from the old style
> "ethX" initially assigned by the kernel? Something like
> 
> 	% predict_nic eth4
> 	enp12s1

On a system with predictable names running? Or on a system
pre-upgrade?

Because if you have a system that's being upgraded at the
moment, the following command _might_ work _after_ you've
upgraded udev and _before_ you've rebooted the system.

udevadm info /sys/class/net/eth4

Look at ID_NET_NAME there.

Can't really test that though, since I don't have a setup
with the old scheme that I still need to upgrade, so this
might not work at all.

If your system has already switched to the new scheme,
then 'eth4' is meaningless once the devices have been
renamed, so you don't really know.

Also, the reason why the new scheme was introduced is that
on some systems ethX is not reproducible: the order in
which the devices are found by the kernel can change
(especially if you have USB devices, but also in other
cases) so 'eth4' is often ambivalent anyway.

If you have some other information on identifying the
device (such as the device's MAC address), you can identify
it that way by looking for the interface with that MAC and
name it something yourself.

For example, you could create a file [1]
/etc/systemd/network/10-uplink.link
with the following contents:

[Match]
MACAddress=xx:yy:zz:gg:hh:ii

[Link]
Name=uplink

This way the network interface with the specified MAC
address is now called "uplink" instead of "enp12s1" or
whatever it was previously. You can also match by PCI
paths (udevadm info's ID_PATH attribute) and matching
supports wildcards. See the manpage for systemd.link
for further details.

Regards,
Christian

[1] This works even on non-systemd systems with udev because
    *.link files are interpreted by udev's builtin and _not_
    by systemd, so technically the location is a bit
    misleading.