# Predictable network names?

## innerhippy

When gentoo switched to use the "predictable network names" a while ago, I was sceptical as to why this was necessary. After all, what's wrong with good old eth0 and eth1? - they're a damn sight more memorable than enp2s0 and enp4s2. But I trusted the view that "predictable" was better than "unpredictable", so went along with the utter ball-ache of making the change.

All seemed ok, even though I still preferred the "memorable" to "predictable".

And then I added a new SATA disk to extend my raid array, and guess what, after a reboot I was no longer able to access my (headlesss) raid server, And why? - the wonderfully predictable network name enp4s2 is now called enp5s2.

I'd really like to revert back to the old (more predictable) network naming convention, is there a definitive guide to do this? I see a whole bunch of noise on this topic on the forum, but no clear instructions. I guess I start with net.ifnames=0 in the kernel?

----------

## s4e8

touch /etc/udev/rules.d/80-net-name-slot.rules

touch /etc/udev/rules.d/80-net-setup-link.rules

 *innerhippy wrote:*   

> When gentoo switched to use the "predictable network names" a while ago, I was sceptical as to why this was necessary. After all, what's wrong with good old eth0 and eth1? - they're a damn sight more memorable than enp2s0 and enp4s2. But I trusted the view that "predictable" was better than "unpredictable", so went along with the utter ball-ache of making the change.
> 
> All seemed ok, even though I still preferred the "memorable" to "predictable".
> 
> And then I added a new SATA disk to extend my raid array, and guess what, after a reboot I was no longer able to access my (headlesss) raid server, And why? - the wonderfully predictable network name enp4s2 is now called enp5s2.
> ...

 

----------

## luismw

The udev developers like to change every now and then the method to keep "classical" names, for no good reason. For instance, s4e8's suggestion doesn't work since udev-210. 

Anyway, according to a news item (back in 2014-02-25): "the most reliable way (...) is still the kernel parameter net.ifnames=0". That's what I currently use and it works.

----------

## szatox

I suppose to make those names truly predictable you should define your own naming rules and have udev rename interface to something you can easily remember, based on MAC or something else that doesn't change.

----------

## Aiken

 *szatox wrote:*   

> I suppose to make those names truly predictable you should define your own naming rules and have udev rename interface to something you can easily remember, based on MAC or something else that doesn't change.

 

At least for eth0 and eth0 + wlan0 machines the easiest would be if udev did not screw with the names at all. I am assuming udev renaming was implemented for a reason and not just because someone thought it was a good idea in search of a problem.

I am still of the opinion of leave the names alone. Use mac -> name mapping if there is a problem.

----------

## pidsley

 *Aiken wrote:*   

> I am assuming udev renaming was implemented for a reason and not just because someone thought it was a good idea in search of a problem.

 

Believe it or not, there was a reason for the change to persistent device names. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

I don't really understand why people are so bent about this -- there was a reason for the change, and if you don't like it you can override it (or just avoid udev and use mdev or static dev).

----------

## Hu

People are bent about it because it is on-by-default, requires local configuration changes to switch between using memorable names versus udev mangled names, and is only helpful in scenarios where you have at least two devices that would otherwise race for the kernel style name.  If you have a single NIC machine, then the kernel name is both memorable and predictable for as long as it remains a single NIC machine.

----------

## khayyam

 *pidsley wrote:*   

>  *Aiken wrote:*   I am assuming udev renaming was implemented for a reason and not just because someone thought it was a good idea in search of a problem. 
> 
> Believe it or not, there was a reason for the change to persistent device names. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

 

pidsley ... you left out the line before in the above quote from Aiken, "for eth0 and eth0 + wlan0 machines [...]". So, note how the document you provided mentions nothing of the many machines that only have one ethernet or one ethernet and one wireless interface. That was Aiken's point, for most use cases the race condition was non-existant. So, believe it or not? ... not.

 *pidsley wrote:*   

> I don't really understand why people are so bent about this -- there was a reason for the change, and if you don't like it you can override it (or just avoid udev and use mdev or static dev).

 

I don't feel you have the right to provide the standard freedeskop disclaimer: "if [they] don't like it". Anyone has a perfect right to comment on the "reasons" involved, particularly if the reasons are askew.

best ... khay

----------

## pidsley

Sorry about that -- I just see many people complaining about this, when to me there are plenty of ways to avoid it. I will STFU now, and bow to the greater wisdom of those who have so much more experience than I do. I honestly thought I had the "right" to express a different viewpoint. Thanks for clarifying that.

----------

## khayyam

 *pidsley wrote:*   

> Sorry about that -- I just see many people complaining about this, when to me there are plenty of ways to avoid it. I will STFU now, and bow to the greater wisdom of those who have so much more experience than I do. I honestly thought I had the "right" to express a different viewpoint. Thanks for clarifying that.

 

pidsley ... if you are going to use sarcasm as a form of argument then you show yourself as either immature, or incapable of providing proper reasoning for your views. You didn't come "expressing viewpoints" but presented the "reasons" why things are as they are. Those reasons now having been made suspect you want to assert your "right" to express them as though the truth of them is besides the point. This is made all the worse by the use of "sorry", "bow to greater wisdom", "thanks for clarifying that" ... which is little other than a tactic to make it seem as though you were put upon for merely having a "viewpoint" ... which simply isn't the case.

So, if you have something to counter what I said then present it, otherwise keep the sarcasm to yourself.

best ... khay

----------

## saellaven

 *pidsley wrote:*   

> Sorry about that -- I just see many people complaining about this, when to me there are plenty of ways to avoid it. I will STFU now, and bow to the greater wisdom of those who have so much more experience than I do. I honestly thought I had the "right" to express a different viewpoint. Thanks for clarifying that.

 

Like most of the stuff regularly linked to at freedesktop.org used as justification for whatever their changing whims are, they largely set up strawmen and spread FUD... people take the time to deconstruct them, thoroughly explaining why the fdo people are wrong, only for the issue to rise up again a few weeks/months later. The "persistent" and "predictable" naming schemes are neither and they are prone to cause breakage when you least expect it, as what happened in the original poster's situation.

In short, their articles are meant to be propaganda for evangelism... and those of us that were content to let fdo do whatever it is they wanted so long as it didn't affect us, have gotten sick of having to constantly rehash the same old arguments, solely to keep their insanity from spreading to our systems.

You're free to have your view... or, in this case, to simply echo the view of someone else. If you really want to educate yourself so you can actually post your own thoughts, read through this thread (for one, it's come up multiple times but that thread was pretty good) and/or what flameeyes wrote.

----------

## pidsley

That simply happened to be the first topic I found in a web search. I do have my own opinion, thank you, but it is obviously not welcome here. I will keep my opinions and my sarcasm to myself, as khay suggests.

----------

## steveL

 *pidsley wrote:*   

> That simply happened to be the first topic I found in a web search. I do have my own opinion, thank you, but it is obviously not welcome here. I will keep my opinions and my sarcasm to myself, as khay suggests.

 

As usual the conflation of one point with another to make an emotive plea to avoid reason.

Khay suggested you present reasoning instead of sarcasm, not that you have no right to express an opinion (which you know, I'm sure.)

Yet here you are, apparently playing the victim. Again.

What next, that anyone who disagrees with you are all "haters"? You seem to be implying it pretty damn broadly already.

----------

## albright

the reason for losing memorable names kind of reminds of this

classic:

http://xkcd.com/619/

----------

## pa1983

I liked the old way better. Easier to remember and worked better from a user point of view. Not like I dont care what dev thinks, they know a lot more, not like I dont appreciate what they do. BUT if the users dont like the software its pretty pointless change in my book.

I never had any of the "problems" sad to exist with the old systems for the past 14 years using linux.

Whit the old system at worst you had to remove the mac address associated with a network card if you replaced your nic.

Now days all you need to do is Move your nic, install a new peace of hardware and the system breaks, no nic because now its called enp5s0 instead of enp4s0 or something.

I was recently installing gentoo on my Dec Alpha and was experimenting with the PCI slot and PCI cards, there are some issues on those old system, especially with GFX cards. Yea its so FUN when you cant SSH to the box as soon as you add, remove or move a PCI card. Every time I moved the my Matrox G450 the dam Nic changed name!

New system dont bother me once everything is set up but atm it can cause extra work the old system never caused when doing hardware upgrades and changes.

So from a "normal" users point of view the new system is a pain and its broken. Rely dont care what the devs think. Some of my vital systems are reconfigured to use the old system tough since I cant be bothered with crap issues like this.

----------

## szatox

The oldest "predictable" NIC names I remember were eth0 for ethernet integrated on mobo, eth1 for the lowest occupied slot, wlan0 for wifi in lowest occupied slot, wlan1 in second-lowest....

I guess you get the point.

And really, I have never seen anything wrong with it as I could look at the back of my case and I'd knew the one on mobo is eth0, and in slots wlan0 is above wlan1, and if I ever wanted to add eth2 it would be under eth1.

Well, that was predictable for years, over 4 distributions, perhaps 30 kernels, and many udev versions, until some day eth0 and eth1 got reversed. Quite oddly, it was around the time predictable device names were pushed to tests, so you could opt-in.

So, if someone says renaming eth0 to enp3s4 is a heroic solution to a problem that doesn't exist outside of udev... Well, that's pretty much how it looks like.

I'm really curious what is the true reason behind that behaviour though. "Race condition" is not an acceptable answer. I've had multiple ethernet devices for ages, and no problems with names until udev-187 or something like that. Something must have changed. Question is.... what and why. (and is speeding up boot by 0.001s initializing several devices in parallel worth all this mess?)

Well, I can live with new names. It seems to be over-engineered though. Oh, and new names are not predictable. Before I run udev, I don't know how it will name interfaces. They are only persistent, and not being predictable means generic scripts related to networking are more messy as they have to find out what are interfaces names instead of calling hardcoded eth0.

----------

## NeddySeagoon

Both ways have corner cases where they fail.

Breaking everyones setup to swich from one set of corner case issues to another is just poor systems design.

Now, if you have a USB WiFi stick, it gets a different name if you plug it into a different USB port. 

I like tho old kernel names, so I've stuck with them, but then, I don't have *dev to cause this issue in the first place.

----------

## Aiken

 *NeddySeagoon wrote:*   

> Both ways have corner cases where they fail.
> 
> Breaking everyones setup to swich from one set of corner case issues to another is just poor systems design.
> 
> Now, if you have a USB WiFi stick, it gets a different name if you plug it into a different USB port. 
> ...

 

Pat of the problem is the page linked above (which I have read before) touts benefits that I currently enjoy without the renaming. Easy to remember stable names.

You just hit the killer for me. With normal network names I grab any of my supply of usb wifi adaptors, pick a usb port and get wlan0. With the renaming this computer has a choice of 10 names, the computer acting as the main access point 8 names, the computer acting as the secondary access point 8 names. Add a hub, there is another set of possible names. The desktop with only 2 usb ports connected is easier. With the standard kernel names I can use the same scripts and configuration files across multiple machines without any extra stuffing around.

To retain the same functionality I have now without having to reconfigure wicd, hostapd, firewall rules and being able to use what ever free usb port the best I have come up with is to map all usb wifi adaptors to the same name. Which does not strike me as a good idea. The times I want to use 2 wifi adaptors in the same machine would have udev trying to rename both to the same name. Easier to disable renaming and stay with old faithful wlan0 and occasionally wlan1.

As the 1st way I knew of stopping the renaming has already been changed so had to deal with it again I now have udev > 208 masked and use a custom ebuild that rm -f the offending net rename rule at install time.

----------

## depontius

The new names are only predictable for those who fully understand their PCI and USB enumeration.

They are persistent only until there is a hardware change that causes re-enumeration.

If you really want a predictable, persistent network name the only option is the MAC.  Even at that, it's only predictable when it's printed on the box or manual, which is usually is.  However in the face of mac-changer, you could have an interface name determined by the true MAC, with a different MAC assigned to it by mac-changer.  No problem, just funny and potentially a source of information leakage about the fact that you're using mac-changer, and the identity of your true MAC.

I've been just as happy with eth0.  I was bit only once over ten years ago on a dual-homed server.  Some kernel change swapped eth0 and eth1.  The symptoms were horrible to debug, but it taught me about layer-2 networking before I figured it out.

----------

