When "Predictable" Network Interface Names Aren't

[John R. Graham]

I bought a dual-NIC PCIe card for one of my infrastructure machines to start using it as a VPN gateway. Prior to installing the new NIC, my existing NIC was here according to lspci:

Code: Select all

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 05)

but after installing the new NIC, it moved. Showing all NICs for clarity:

Code: Select all

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 07)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 07)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller (rev 05)

Of course, given that, the network interface name changed from enp3s0 to enp7s0. But the bus address of the existing NIC changed? I didn't think that was even possible.

- John

[eccerr0r]

Firmware on motherboard might have been responsible for that. I was never certain what motherboards would do when they have pcie lanes that could be used to two different slots (like a x16 broken down to two x8's or 4 x4x or 16 x1's) and what happens if you plug in another card that requires the board to reconfigure the lanes.

[John R. Graham]

"...could be used by two different slots..."? That's a new one on me. Seems like a bad thing to do (from a motherboard design perspective).

- John

[Banana]

yeah it is annoying, but who does really always need all the slots? So they made them dynamic.

But maybe some setting in the BIOS can help you.

[NeddySeagoon]

John R. Graham,

A long time ago udev named interfaces from the MAC address.
You can still do that if you write the udev rules.
Don't use kernel assigned device names though.

[Anon-E-moose]

I like having consistent names so

Code: Select all

 cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x10ec:0x8125 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="58:47:ca:75:1c:25", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x2725 (iwlwifi)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="c8:15:4e:6c:6c:0e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Yeah, yeah, I know kernel assigned names, but I've never had a problem setting things this way, well over 10 years now doing it this way.

[zen_desu]

I skip all this trouble and let udev set interface names to friendly things like "fiber1" or "wireless" based on the device MAC.

Code: Select all

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="ethernet"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="wireless"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="78:9a:18:b6:6b:a2", NAME="lan"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="78:9a:18:b6:6b:a4", NAME="management"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="78:9a:18:b6:6b:a6", NAME="router6"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="78:9a:18:b6:6b:a8", NAME="router"

[John R. Graham]

yeah it is annoying, but who does really always need all the slots? So they made them dynamic.

But maybe some setting in the BIOS can help you.

Been reading up on "PCIe bifurcation". I contend it's rare, at least on the high end, which is what I've almost always used. This machine is awful in several ways.

- John

[eccerr0r]

Definitely not rare on consumer level equipment, most of my motherboards short of my X58 and X79 (prosumer/server class) do this if they have more than one full length pcie slot, and split the x16 to two x8's when you plug in two GPUs. One of my S775 boards you need to set jumpers to split one x16 slot to two x16 slots that are converted to x8's. The X58 and X79 machines have plenty of pcie lanes to not need to do this I think but haven't really worked with them much...

[Zucca]

You can still do that if you write the udev rules.

This is exactly what I still do when I need to have consistent interface naming.

Laptops with only wifi, I normally don't bother. But sometimes I've seen some very odd behavior* from NetworkManager, so if you use it, then maybe it's best to "statically" rename interfaces via udev rules in any cases.

*) NetworkManager not recognizing interface all the sudden and automatically creating a new connection for the "newly discovered" interface.

[pa4wdh]

I always disable the renaming stuff because i don't like them. To me that's an ugly solution searching for a problem.

Don't use kernel assigned device names though.

So far this works 100% right for me on all my multi-nic setups, so it's actually what i use .

I've had one system where i didn't disable it, and at some random point it broke because the "predictable" name was not predictable anymore, so i disabled it there too, problem solved .

[lost+found]

My small hack...
If 2 compiled-in NIC drivers compete for eth0/eth1, making one a module solves it.
The NIC with the module will always be slower, and gets eth1.

[NeddySeagoon]

Anon-E-moose,

That works as those names are already assigned to those devices.
It's the same as setting net.ifnames=0 on the kernel command line.
Then you don't need udev rules at all.

If you had several interfaces of the same type, you would see the problem of using kernel names for yourself. :)

[John R. Graham]

It seems that this is more common than I had thought: it happened to me again! On one of my dual CPU workstations, I had a CPU go flaky. The motherboard is one of the older ones where all of the PCIe slots and devices are connected to the North Bridge, not directly to any CPU, so I didn't have to juggle the peripherals around the slots in any way. When I removed the 2nd CPU the machine became stable...and the network naming changed!

So, I thought, enough is enough. I went through all of the machines in my lab and created UDEV rules to stabilize the names. Sheesh!

- John

[Zucca]

I went through all of the machines in my lab and created UDEV rules to stabilize the names. Sheesh!

Been there, done that.
I sometimes setup udev rules to match the MAC address and then rename the interface to something like ethMB, ethPCI, etc etc etc...

[saellaven]

I was against the "predictable" names from the beginning, as the "design" is anything BUT predictable and will bite you when you least expect it.

Matching against MAC addresses is so much better (barring broken hardware where they reuse MAC addresses). It also results in more predictable interface names - I know my primary ethernet is always going to be at eth1, regardless of which system I'm at. Is the network device in this system enp7s0 or enp3s0?

If I'm physically changing my ethernet card, I know to update my MAC address at that time.

I could get into an entire rant about the lack of design from the people responsible, which has resulted in de facto standards that are more broken than what they were replacing (usrmerge being another), but I'll digress.

[John R. Graham]

...Is the network device in this system enp7s0 or enp3s0?

The motherboard NIC was enp3s0 until I added the new dual-NIC PCIe card; then it became enp7s0.

- John

[b11n]

I was against the "predictable" names from the beginning, as the "design" is anything BUT predictable and will bite you when you least expect it.

Matching against MAC addresses is so much better (barring broken hardware where they reuse MAC addresses).

Hindsight is 20/20. I'm sure the reasoning is discussed in some mailing list post from around 2012 that could be found with half a day of googling, but I wonder if NICs with dodgy MACs was the reason for choosing bus topology as a default. And without numbers on just how many chipsets actually change how the topology is presented, it's hard to know whether it was the lesser of two evils.

[saellaven]

...Is the network device in this system enp7s0 or enp3s0?

The motherboard NIC was enp3s0 until I added the new dual-NIC PCIe card; then it became enp7s0.

- John

I was simply speculating on two different random machines that I might sit down at, not the system in the original post. ALL of my systems point the primary interface at eth0, so that I always know where my primary NIC is when I need to handle admin stuff.

I was against the "predictable" names from the beginning, as the "design" is anything BUT predictable and will bite you when you least expect it.

Matching against MAC addresses is so much better (barring broken hardware where they reuse MAC addresses).

Hindsight is 20/20. I'm sure the reasoning is discussed in some mailing list post from around 2012 that could be found with half a day of googling, but I wonder if NICs with dodgy MACs was the reason for choosing bus topology as a default. And without numbers on just how many chipsets actually change how the topology is presented, it's hard to know whether it was the lesser of two evils.

I don't know how much discussion went into it... I have a feeling it was more "I already implemented this idea based on my biases without consulting others", just like the decision to put stuff required at boot in /usr even though it might not be mounted at boot (because the use case of a network mounted /usr or a read only /usr also wasn't considered, because they felt their way was the one true way).

To reply to your sig, THAT is where we were hurt - all of these arbitrary decisions that were forced on us as a de facto standard with no discussion and no consideration for ANY other use cases. Everything is WILLNOTFIX NOTABUG and the hubris that everyone else needs to follow their dictates. It isn't a matter of hindsight, it was the total lack of discussion or consideration outside of the way one guy thought things should work in complete defiance of decades of reasons to do things otherwise.

[pa4wdh]

because they felt their way was the one true way

I think this is the real problem with poeteringware in general. I mean, why wouldn't udev let you choose between different naming schemes? One based on mac, one based on hardware topology, or even something user defined?

If i remember correctly the problem with the mac-based interface renaming was that there was a slight possibility for a race condition:
- Interface with kernel interface name eth0 becomes available, udev rules dictate this should actually be eth1
- Before udev could actually do the rename a new interface becomes available with kernel name eth1
- udev tries to rename and fails because eth1 already exists ...

I think the main problem is that they stayed within the ethX namespace, if they used a different prefix which is not used by kernel devices the race condition wouldn't exist.

Sidenote: There is actually a page on freedesktop.org about these (un)predictable interface names, it also describes some problems with other naming scemes they tried:
https://www.freedesktop.org/wiki/Softwa ... faceNames/

[b11n]

I have a feeling it was more "I already implemented this idea based on my biases without consulting others"
…
It isn't a matter of hindsight, it was the total lack of discussion or consideration outside of the way one guy thought things should work in complete defiance of decades of reasons to do things otherwise.

Well, there goes that theory. Maybe the biases are your own?

https://www.freedesktop.org/wiki/Softwa ... faceNames/

[saellaven]

*sigh*

I'm not here to derail this with another systemd fanboy more than a decade after the fact. You're not the first one to just blindly quote that page as your sole rationale, even though the arguments made there are completely wrong, given the fact that the names are NOT predictable based on bus address.

Again, it was one guy pushing the way he thought everything ought to he without any concern for other use cases, not how it would break systems in weird ways, like with this thread. It was done out of arrogance and hubris, and again, was a matter of one guy implementing something and using his position to force it on everyone else.

With that, I'm going to bow out before yet another thread gets locked. Apparently, even after "winning" by brute force, the systemd fans still need to try to stir the pot.

[NeddySeagoon]

Once upon a time, servers in data centres all used plug in NICs.
There were no on board NICs.

Bus names made sense in that use case. Open the server, rip out the dud and put a new NIC back in the same slot.
It all just works.

For other use cases, 'persistent' naming swapped one set of corner cases for another.
Who really wants a USB NIC named after the port its conneced to?
That's not a data centre use case, so NOTABUG, EDONTCARE.

Now, with single NIC on the motherboard, even in a data centre, 'persistent naming' makes no sense whatever, since the NIC on the motherboard is not replaceable anyway.

Persistent naming came in just as is most important use case was going away.

[John R. Graham]

To reply to your sig, ...

For myself—and I'm definitely an OpenRC fan—I find that signature hilarious.

For what it's worth, I've seen bent provide friendly, competent support for openrc networking issues.

- John

[b11n]

Not a systemd fanboy, really. I have OpenRC on two of my machines, and it's fine. I just find the asymmetry how much jank people will tolerate in other FOSS compared to systemd amusing, all the catastrophizing over something that turned out to be good enough for all but three or four distros, just silly really. That's all my sig is about.