What does eno mean in network interface name 'eno16777736' for CentOS 7 or RHEL 7?

Question

Under consistent network device naming scheme, what does 'eno' stand for in network interface name eno16777736 for CentOS 7 or RHEL 7?

Solution 1

This is Predictable Network Interface Device Names in action.

• en is for Ethernet
• o is for on-board
• The number is a firmware/BIOS provided index.

More details in the source of udev-builtin-net_id.c

Solution 2

Hmmm. More so than "en" and "o", I would be more concerned about the "16777736".

Unless, you accidentally wandered into Google, and found yourself sitting at a server with a custom PCI architecture, I don't really see how 16777736 could be a possible value. This might be a hint to a more serious problem.

Under the current schema, a system would not be able to address more than 256 PCI buses(with 32 devices under each bus and a maximum of 8 functions under each device). This is also know as Bus:Device.Function addressing. Modern systems use Domain:Bus:Device.Function to get over the 256 Bus limitation. But anyway, getting back to your problem...

Can you do a:

ls -la /sys/class/net | grep eno16777736

If you see something very similar to:

eno16777736 -> ../.../devices/pci0000:00/0000:00:11.0/0000:1000208:01.0/net/eno16777736

Then I suggest you run fast before Google catches you playing around with their servers.

The /(0000:1000208:01.0)/ above is the Domain:Bus:Device.Function address with the bus value, "1000208", being the hexadecimal representation of 16777736. However, "0x100" (256) Should be the maximum value that you can have for "Bus."

On the other hand if you get a value that's below 0x100 for the "Bus", such as:

eno16777736 -> ../.../devices/pci0000:00/0000:00:11.0/0000:1c:01.0/net/eno16777736

Then, I would think the problem would be related to how your Bios/Firmware is sending information to udev(systemd) at startup. To figure out the potential cause, first check the values that udev is getting returned back to it.

Normally there are three places udev queries to create the PIN (Predictable Interface Name)

1. ACPI_DSM
2. SMBIOS Table [specifically record type "slots" [9], and type 41]
3. PCI IRQ Routing Table

[in that order]

We can test (1) by:

udevadm info --path=/sys/class/net/eno16777736 --attribute-walk | grep acpi

If this gives you 16777736 then most likely your system doesn't support PCI Firmware Specification 3.1 which is needed to support ACPI_DSM

So we have to now test (2). So lets check record type 41 in the SMBIOS Table first (type 41 is the most relevant):

dmidecode -t 41 | more

If nothing shows, or the SMBIOS version is less that "2.62" then that means udev will rely on the PCI IRQ Routing Table to create the PIN.

So we should check (3)

biosdecode

Pay close attention to your maximum slot entry... it should be of the form:

Slot Entry X: ID 00:00, (slot number X| status)

If X is 25, for argument's sake, your NIC should be on a slot lower than or equal to 25. If not, udev will continue to reference the placeholder value of 16777736.

In most cases, you can check the slot number of your nic by:

lspci -bv | grep -i -A10 ether

And again In most cases, in the BDF (Bus:Device.Function), the Device should equal the Physical port number (after converting it from hex to decimal). In other cases (where it doesn't), lspci will list the Physical Slot on a separate line in the output of executing the the above lspci command.

So if the listed Physical Slot number is greater than X (the maximum number that we found in our PCI IRQ Routing table) we've most likely isolated the problem.

There are 5 possible solutions that I can think of in this case...

1. Kernel hacking... Rebuild the kernel with a new PCI IRQ Routing table. Have a look at /arch/x86/pci/irq.c

[This is the i-need-to-find-better-uses-of-my-time solution]

2. Map the device to a different name by creating a new rule

by:

vi /etc/udev/rules.d/70-my-net-names.rules

then add the following:

ACTION=="add", SUBSYSTEM=="net", ENV{ID_BUS}=="pci", 
KERNELS=="{Domain:Bus:Device.Function}", NAME="{name: i.e. eno1 or eth0}" 

[I call this the let-us-ignore-the-problem-and-just-make-things-look-pretty solution]

3. You could add net.ifnames=0 to the kernel boot options to disable the feature altogether

[This is of course the if-it-is-broke-turn-it-off-and-cry-in-solitude solution] (not really a solution)...

4. And if you happen to be running a VM... VMWare/VirtualBox, etc... open up the configuration file and modify the "pciSlotNumber" to something below X.

[but this is a-temporary-hack-until-my-software-gets-updated solution]

5. Buy a new computer. [and finally the if-you-can't-beat-them-join-them solution]

Solution 3

Just to add details to previous answers:

Two character prefixes based on the type of interface:

*   en -- ethernet
*   sl -- serial line IP (slip)
*   wl -- wlan
*   ww -- wwan
*   ib -- Infiniband

Type of names:

*   b<number>                             -- BCMA bus core number
*   ccw<name>                             -- CCW bus group name
*   o<index>                              -- on-board device index number
*   s<slot>[f<function>][d<dev_port>]     -- hotplug slot index number
*   x<MAC>                                -- MAC address
*   [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]
                                          -- PCI geographical location
*   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..]1[i<interface>]
                                          -- USB port number chain

Source: http://ask.xmodulo.com/change-network-interface-name-centos7.html

Comments

[Martin]

I believe that odd looking number matches the net device in VMWare BIOS. Looks like the OP is using CentOS 7 VM's.

[Dan Pritts]

It's not always the same, either - I have eno16780032. What a pain in the ass.

[Konrads]

This answer is so exhausting that in answering the OP's question you managed to produce a concise reference on how to identify devices by their indices.

[Mark Norgren]

These sorts of names for VMware are apparently not uncommon. For example, I my devices are named eno16777732.