RHEL 7 Changes: Where Did My Network Interface Go?

Ethernet card
Ethernet Card

There are enormous changes when upgrading from RHEL 6 to 7 (Red Hat Enterprise Linux).  It’s not that Red Hat decided to change almost everything. Several different communities working on different projects have independently made significant RHEL 7 changes. These occurred between the release of RHEL 6 in November, 2010, and the release of RHEL 7 in June, 2014.

I have described many different aspects of systemd and the new Linux journal logging system, those are part of the RHEL 6–7 migration. A series of posts describing the Linux booting chain covered UEFI, UEFI – shim, GRUB Loader, the role of the kernel, and how systemd has replaced init.  We also covered how to transition from systemd from init and service controlHow to configure the new journal daemon and how to extract journal entries was also looked at.

This week I’m starting a series of articles on other major changes and new features you will encounter not just in Red Hat but in all other recent distributions.

What Happened To My Network Interfaces in RHEL 7, and Why?

Things used to be so simple. Linux Ethernet interfaces were named eth0, eth1, eth2, and so on.

But then we got the “everything at once” approach of systemd. Couple that with the kernel’s automatic probing and discovery of hardware and we can no longer rely on devices being discovered in the same order every time. Interfaces eth0 and eth1 might swap names after the next reboot.

Where’s the harm? Remember that a network is configured in a file named ifcfg-name in the directory /etc/sysconfig/network-scripts. If they trade names, they trade configurations and each is effectively plugged into the wrong network.

Why Can’t the Driver Name It?

On my OpenBSD laptop where I’m writing this, my wired Ethernet and wireless interfaces are named re0 and run0, respectively. OpenBSD names interfaces by driver and discovery order. The wired Ethernet has a Realtek 8101E chipset recognized by the re kernel module, and the wireless has a Ralink RT3070 chipset recognized by the run kernel module. So, re0 and run0 for the first interfaces detected by those modules. Solaris does something very similar.

However, two Ethernet interfaces on the same system very likely use the same chipset and are recognized by one kernel module, so we’re back to the problem of the race condition. Which is re0 and which is re1?

What About MAC Address?

Red Hat has linked MAC address to IP configuration for some time, leading to untold amounts of frustration over mysterious failures when you replace an Ethernet card with another card of the same model plugged into the same slot.

Their NetworkManager system has used its own database of UUID assignments which seems to be based at least partly on the MAC address and which can be even more mysterious and frustrating. Let’s not go that way.

A Design for Consistent Network Interface Names

A project started by the freedesktop.org group devised a naming system that will be consistent from one boot session to the next. The names all start with en for Ethernet or wl for wireless LAN. These are followed by one of:

  1. Firmware-provided index numbers for on-board devices: eno1 and eno2 for the first and second on-board Ethernet.
  2. Firmware-provided PCI Express hotplug index numbers: ens1 and ens2 for the first and second PCIe hotplug Ethernet.
  3. Physical location: enp2s0 for an Ethernet interface at PCI bus address 02:00.0. That’s bus #2, slot #0, the first (.0) function of the card in that slot.
  4. Chained physical location: Let’s say you plug a wireless LAN interface into a USB slot so it’s device #4 on USB bus 1. Meanwhile the USB controller is at PCI bus address 00:03.0. You get an interface named wlp0s3f1u4. The p0s3 part comes from the PCI address of the USB controller, f1u4 from the USB device addressing.
  5. If you still haven’t found something you like, you can use the MAC address: enx0011951E8EB6 for the device with MAC address 00:11:95:1E:8E:B6.

A Consistent But Not Predictable Naming System

This system provides consistent names. Sure, the names aren’t what we’re used to, but how human-friendly was something like eth2 anyway?

My experience is that I can’t predict whether an interface embedded on the motherboard will get named enoX or enpXsY. And if I plug a card into a PCI slot, I have no idea as to which bus and slot that will be without reading the motherboard documentation. But I can easily figure out either situation with a little observation and experimenting.

We get into this in the newly revised Linux server administration course The new revision of it, based on RHEL 7, will begin running in a few weeks.  Learning Tree has also introduced a new 1-day course you can take on-line entitled Linux Booting & Initialization.

And guess what — all of the network commands have changed, too! I’ll explain that next time, check back then.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.