¿Qué significa eno en el nombre de interfaz de red 'eno16777736' para CentOS 7 o RHEL 7?

Bajo un esquema consistente de nombres de dispositivos de red, ¿qué significa 'eno' en el nombre de la interfaz de red eno16777736para CentOS 7 o RHEL 7?

Se trata de nombres de dispositivos de interfaz de red predecibles en acción.

• en es para Ethernet
• o es para a bordo
• El número es un índice proporcionado por firmware / BIOS.

Más detalles en la fuente de udev-builtin-net_id.c

Hmmm Más que "en" y "o", estaría más preocupado por el "16777736".

A menos que accidentalmente ingrese a Google y se encuentre sentado en un servidor con una arquitectura PCI personalizada, realmente no veo cómo 16777736 podría ser un valor posible. Esto podría ser un indicio de un problema más grave.

Según el esquema actual, un sistema no podría direccionar más de 256 buses PCI (con 32 dispositivos debajo de cada bus y un máximo de 8 funciones debajo de cada dispositivo). Esto también se conoce como Bus: Dispositivo. Direccionamiento de funciones. Los sistemas modernos usan Domain: Bus: Device.Function para superar la limitación de 256 Bus. Pero de todos modos, volviendo a su problema ...

¿Puedes hacer un:

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

Si ves algo muy similar a:

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

Entonces te sugiero que corras rápido antes de que Google te descubra jugando con sus servidores.

El /(0000:1000208:01.0)/ anterior es el Dominio: Bus: Dispositivo. La dirección de la función con el valor del bus, "1000208", es la representación hexadecimal de 16777736. Sin embargo, "0x100" (256) debe ser el valor máximo que puedes tener para "Bus".

Por otro lado, si obtiene un valor inferior a 0x100 para el "Bus", como:

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

Entonces, creo que el problema estaría relacionado con la forma en que su BIOS / Firmware está enviando información a udev (systemd) al inicio. Para descubrir la causa potencial, primero verifique los valores que udev está devolviendo.

Normalmente hay tres lugares de consultas udev para crear el PIN (Nombre de interfaz predecible)

1. ACPI_DSM
2. Tabla SMBIOS [específicamente tipo de registro "slots" [9], y tipo 41]
3. Tabla de enrutamiento PCI IRQ

[en ese orden]

Podemos probar (1) por:

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

Si esto le da 16777736, lo más probable es que su sistema no sea compatible con la especificación de firmware PCI 3.1 que es necesaria para admitir ACPI_DSM

Así que ahora tenemos que probar (2). Entonces, primero verifiquemos el tipo de registro 41 en la tabla SMBIOS (el tipo 41 es el más relevante):

dmidecode -t 41 | more

Si no se muestra nada, o la versión SMBIOS es menor que "2.62", entonces eso significa que udev dependerá de la Tabla de enrutamiento PCI IRQ para crear el PIN.

Entonces deberíamos verificar (3)

biosdecode

Presta mucha atención a tu entrada máxima de espacio ... debe tener la forma:

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

Si X es 25, por el bien del argumento, su NIC debe estar en una ranura inferior o igual a 25. De lo contrario, udev continuará haciendo referencia al valor del marcador de posición de 16777736.

En la mayoría de los casos, puede verificar el número de ranura de su nic:

lspci -bv | grep -i -A10 ether

Y nuevamente En la mayoría de los casos, en el BDF (Bus: Device.Function), el dispositivo debe ser igual al número de puerto físico (después de convertirlo de hexadecimal a decimal). En otros casos (donde no lo hace), lspci mostrará la ranura física en una línea separada en la salida de la ejecución del comando lspci anterior.

Por lo tanto, si el número de ranuras físicas enumerado es mayor que X (el número máximo que encontramos en nuestra tabla de enrutamiento PCI IRQ), lo más probable es que hayamos aislado el problema.

Hay 5 posibles soluciones en las que puedo pensar en este caso ...

1. Hackeo de kernel ... Reconstruya el kernel con una nueva tabla de enrutamiento PCI IRQ. Echa un vistazo a /arch/x86/pci/irq.c

[Esta es la solución i-need-to-find-better-uses-of-my-time]

2. Asigne el dispositivo a un nombre diferente creando una nueva regla

por:

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

luego agregue lo siguiente:

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

[Yo llamo a esto la solución de dejarnos ignorar el problema y hacer que las cosas se vean bonitas]

3. Puede agregar net.ifnames = 0 a las opciones de arranque del kernel para deshabilitar la función por completo

[Esta es, por supuesto, la solución if-it-is-broke-turn-it-off-and-cry-in-soleitude] (no es realmente una solución) ...

4. Y si está ejecutando una VM ... VMWare / VirtualBox, etc ... abra el archivo de configuración y modifique el "pciSlotNumber" a algo debajo de X.

[pero esta es una solución temporal para hackear hasta que mi software se actualice]

5. Compra una computadora nueva. [y finalmente la solución de si no puedes vencerlos-únete a ellos]

Solo para agregar detalles a las respuestas anteriores:

Dos prefijos de caracteres basados ​​en el tipo de interfaz:

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

Tipo de nombres:

*   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

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