This is part two of a series of articles looking into the new udev “predictable” names. Part one is here and talks about the path-based names.
As Steve also asked on the comments from last post, isn’t it possible to just use the MAC address of an interface to point at it? Sure it’s possible! You just need to enable the mac-based name generator. But what does that mean? It means that your new interface names will be enx0026b9d7bf1f and wlx0023148f1cc8 — do you see yourself typing them?
Myself, I’m not going to type them. My favourite suggestion to solve the issue is to rely on rules similar to the previous persistent naming, but not re-using the eth prefix to avoid collisions (which will no longer be resolved by future versions of udev). I instead use the names wan0 and lan0 (and so on), when the two interfaces sit straddling between a private and a public network. How do I achieve that? Simple:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:17:31:c6:4a:ca", NAME="lan0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:07:e9:12:07:36", NAME="wan0"
Yes these simple rules are doing all the work you need if you just want to make sure not to mix the two interfaces by mistake. If your server or vserver only has one interface, and you want to have it as wan0 no matter what its mac address is (easier to clone, for instance), then you can go for
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="*", NAME="wan0"
As long as you only have a single network interface, that will work just fine. For those who use Puppet, I also published a module that you can use to create the file, and ensure that the other methods to achieve “sticky” names are not present.
My reasoning to actually using this kind of names is relatively simple: the rare places where I do need to specify the interface name are usually in ACLs, the firewall, and so on. In these, the most important part to me is knowing whether the interface is public or not, so the wan/lan distinction is the most useful. I don’t intend trying to remember whether enp5s24k1f345totheright4nextothebaker is the public or private interface.
Speaking about which, one of the things that appears obvious even from Lennart’s comment to the previous post, is that there is no real assurance that the names are set in stone — he says that an udev upgrade won’t change them, but I guess most people would be sceptic, remembering the track record that udev and systemd has had over the past few months alone. In this situation my personal, informed opinion is that all this work on “predictable” names is a huge waste of time for almost everybody.
If you do care about stable interface names, you most definitely expect them to be more meaningful than 10-digits strings of paths or mac addresses, so you almost certainly want to go through with custom naming, so that at least you attach some sense into the names themselves.
On the other hand, if you do not care about interface names themselves, for instance because instead of running commands or scripts, you just use NetworkManager… well what the heck are you doing playing around with paths? If it doesn’t bother you that the interface for an USB device changes considerably between one port and another, how can it matter to you whether it’s called wwan0 or wwan123? And if the name of the interface does not matter to you, why are you spending useless time trying to get these “predictable” names working?
All in all, I think this is just an useless nice trick, that will only cause more headaches than it can possibly solve. Bahumbug!
Oh, didn’t know the ethMAC thingy was possible. But yes, it comes with a price. That said, it might be possible to reuse the last chars, like git does ?(Yes, I know. But we also know that the beginning of a MAC addr isnt a very idea)
@Steve: yes, the beginning of the MAC isn’t a very good idea if you have multiple cards from the same manufacturer 😉 [as it’s the case for my servers]@Diego: I like your approach with the lan0, … as MAC filtering seems the best way to go for my purposes. [I was already using it].In order to achieve it [sorry for the possibly dumb/noob question], do I just need to erase the contents of the fake 80-net-name-slot.rules and put rules like the ones you posted in it, then delete the old 70-persistent-net.rules wich contained my old rules [which the new udev ignored and rebooted my server with eth0 and eth1 swapped… yeah… “lan0” and “wan0” swapped… no wonder I had no internet connection at home…]
If you check the udevnet Puppet module, it’s actually relatively straight forward: * link @/etc/udev/rules.d/80-net-name-slot.rules@ to @/dev/null@, so that the new naming scheme won’t be used; * remove @70-persistent-net.rules@ as they will only make a mess; * add your rules to @70-my-network.rules@ or something like that; the module uses @70puppet-net.rules@ (yes I forgot a dash…).That would do it just fine.
I think this is all about defaults for sysadmins who can’t be bothered to think about the names.I agree, if you care you should really manually set names with the information that matters.ethDSL, pppDSL, ethLAN, tunFOO, tunBAR, etc are names that would make sense. Maybe using eth is not too smart, but as the kernel only uses numbers after the eth it seems safe enough.An then, when you start manuelly naming it’s nice to have the option to bind these names based on mac (easy before too) or device path (now much easier). I believe in a smartly managed datacenter path based binding (with notice before hardware changes that might switch slots) can be a lot easier. And with binding you can just add rules for both slots so a change can be made smoothly.But that’s all a bit more than many admins/users are going to do. And in that case the system needs safe defaults. using the device path doesn’t seem like such a bad idea there.
Would be nice if network devices supported alias names. That way you could have a primary name for the device based on hardware location to be used by the system, and then user defined aliases set according to MAC address (or whatever other criteria you desire).Would allow having conventional (and human readable) handles for devices regardless of the hardware, while keeping the system happy.
I never could follow the argument about “predictable” names. I remember the first time I booted a Fedora live USB and saw a truly funky interface name (I don’t know it it was exactly of the form “wlp3s0”, but I do remember that it looked like a random function generated it.)I agree: the only viable use case I can think of for their new-style interface renaming is that LAN-WAN distinction–and you could have done the very thing in udev from many versions ago.There’s a really troublesome aspect about this new setup: as I understand, its interface renaming works only for devices whose drivers are loaded as modules. If you have your network drivers compiled into the kernel, as I do, and as I think that most Gentoo people do, the new udev won’t do the renaming for it. Is this the correct understanding? Are people with in-kernel network drivers really left up to the vagaries of device probing? Old udev, at least, would work for in-kernel drivers too.By the way, thank you for covering this on my birthday.
“All in all, I think this is just an useless nice trick, that will only cause more headaches than it can possibly solve.”AMEN!Although, I suppose that the more something like this occupies Lennart’s time, the fewer opportunities he has to screw up more important things.”as I understand, its interface renaming works only for devices whose drivers are loaded as modules.”I have read that and it is not true. I have all needed drivers built in to the kernel, and the renaming works as described (I almost with it didn’t).
I’ve been running Linux on my own machines exclusively for ten or twelveyears now, and I’ve never had a problem with eth0; the only snags werewhen I changed PCMCIA wireless cards on older machines, and udev recognisedthe changed MAC and upped eth1 to eth2However, these were all desktops and laptops; I can see that servers mighthave a problem, and unfortunately RedHat is a server-based company, so thechanges make sense to them. The rest of us just have to put up with it.I think Diego’s got the right solution in tying port renaming to MACaddresses; certainly that’s what I’ll do with my own machines, as longas udev is available. The problem, of course, comes when working onother people’s machines; eth0 was standard, but the first question nowon a new machine is going to be “What is eth0 called today?”Will
While renaming interfaces according to their MAC (or even *using* it directly through e.g enxdeadbeef) might sound like nifty idea – but will again leave you without a network if you’ll have to replace the [i.e. possibly broken] NIC… (just like it is in Windows ever since – have to replace the NIC, you’ll have a new unconfigured network adapter – defaulting to DHCP… doh)On the other hand – if you have to exchange a card (for reasons of 10/100 vs. GBit, 1 Port vs. 4 Ports, … YMMV) which will also imply a change from e.g. PCI to PCI-E, then *both* ways will fail as both MAC and Bus-Id will change…However, I’ve learnt to love the concept when I first played with VF on igbvf/ixgbevf.. if you only have a two physical ports NIC bus see like 16 network interfaces, you *definitely* want to know which NIC got “enumerated” on which physical port..Oh, last but not least: when working with (some modes in) the bonding driver, don’t use MAC based renaming – as some modes “duplicate/copy” the MAC of the active card over to the passive card which then will trigger udev/systemd….
I run mostly servers – most of them xen-machines. They usually have around 4-9 NIC’s installed. The old eth[0-10] naming-scheme always was a big hassle – especially after replacing a broken NIC.So from my daily business even the mac-based naming scheme is something that won’t make me happy because it also requires fiddling out the new proper name-mapping.The new udev-scheme does in these situations a good job and after a first shock when it arrived me I soon saw the advantages. In all cases (server related) network-interface-names stay persistent – even after replacing a NIC with some hardware from a different vendor / model. So as a result it makes my daily server-life alot easier.For desktops and laptops with usb-NIC’s ok …. this is another game. But as you said -> Networkmanager does the job for you.Finally there is no ideal solution for that NIC-naming stuff available that meets all scenarios – the new udev-scheme isn’t ideal … selfbuild udev-rules aren’t ideal either in all cases …. the old eth-schema was daily trouble. So I think one should pick up the solution that fits best the needs of a certain situation. The new udev-scheme is just another new opportunity that works well at least in some scenarios.Just my 2 cents 🙂
Seems to me that the old rules would always work if you just put them in descending order.eg: rule ending in eth2rule ending in eth1rule ending in eth0So that if the first one found was supposed to be eth2, it would be renamed without conflict. Would the next one still be called eth0 or would it come up as eth1 even though eth0 was now eth2? Maybe it doesn’t work at all, I never checked this out. I just went with net0, net1, net2 on my server and all is well (at least it is after changing the rest of my conf.d files and firewall rules to match).I did really like the fact that everyone’s ethernet card was eth0 (1 nic machines) now who knows what it will be?Servers with multiple nics are always going to require some extra setup anyway. The overhead of checking out the MAC and renaming to suit was very small on gentoo with the auto generated rule supplying everything for you but the desired x in “ethx”. I found the new way quite odd and quite disconcerting because there is no nic name I can guarantee when I come to a new machine. Can’t imagine how horrible this would make remote/phone support!