¿Por qué mi eth0 se llama eno16777736?

27

He visto http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ , que describe la justificación de los nombres de dispositivos consistentes / predecibles, y luego las reglas por las cuales se generan los nombres de los dispositivos :

 * Two character prefixes based on the type of interface:
 *   en -- ethernet
 *   sl -- serial line IP (slip)
 *   wl -- wlan
 *   ww -- wwan
 *
 * 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>][..][c<config>][i<interface>]
 *                                         -- USB port number chain

Digamos que tengo un dispositivo eno16777736: ¿por qué se llama así? Es una tarjeta ethernet, lo tengo. Pero, ¿cómo puedo volver al resto del nombre de esta interfaz?

Examiné /sys/class/net/eno16777736y vi:

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

Tampoco estoy seguro de cómo interpretar esto, o si puedo usar esta información para llegar eno16777736.

Actualizar

Entonces el 16777736es el dispositivo acpi_index. Por https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-pci :

What:       /sys/bus/pci/devices/.../acpi_index
Date:       July 2010
Contact:    Narendra K <[email protected]>, [email protected]
Description:
        Reading this attribute will provide the firmware
        given instance (ACPI _DSM instance number) of the PCI device.
        The attribute will be created only if the firmware has given
        an instance number to the PCI device. ACPI _DSM instance number
        will be given priority if the system firmware provides SMBIOS
        type 41 device type instance also.

Y de hecho:

core@localhost /sys/devices/pci0000:00/0000:00:11.0/0000:02:01.0 $ find . -type f | xargs grep 1677 2> /dev/null
./net/eno16777736/uevent:INTERFACE=eno16777736
./acpi_index:16777736

Además, para conciliar la salida de ifconfigo ip linky sus dispositivos en lspci:

$ ifconfig
eno16777736: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.37  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::20c:29ff:fe70:c039  prefixlen 64  scopeid 0x20<link>
        inet6 2601:a:7c0:66:20c:29ff:fe70:c039  prefixlen 64  scopeid 0x0<global>
        ether 00:0c:29:70:c0:39  txqueuelen 1000  (Ethernet)
        RX packets 326  bytes 37358 (36.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 172  bytes 45999 (44.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 19  base 0x2000

Observe la "interrupción de dispositivo 19". Y de lspci -v, que tiene "IRQ 19":

02:01.0 Ethernet controller: Advanced Micro Devices, Inc. [AMD] 79c970 [PCnet32 LANCE] (rev 10)
        Subsystem: Advanced Micro Devices, Inc. [AMD] PCnet - Fast 79C971
        Physical Slot: 33
        Flags: bus master, medium devsel, latency 64, IRQ 19
        I/O ports at 2000 [size=128]
        [virtual] Expansion ROM at fd500000 [disabled] [size=64K]
        Kernel driver in use: pcnet32

Aquí también se ve "Phyiscal Slot 33", y de hecho, a veces VMWare arranca las máquinas virtuales que se obtienen ens33como nombre de la interfaz. Entonces, no está claro por qué otras veces elige eno16777736. Pero el 16777736 proviene del acpi_index, y el 33 proviene de la ranura PCI.

linux networking udev Dmitry Minkovsky
fuente
Parece que Red Hat arregló su lado en RHEL7.3: redhat.com/en/about/blog/…
Stefan Lasiewski

Respuestas:

30

en para Ethernet

o para a bordo

16777736es el índice del dispositivo provisto por el firmware (BIOS / EFI). Hubiera sido lógico iniciar el índice en 1. ¡O eso, o tienes un firmware sensible y más de 16 millones de dispositivos integrados! Pero lo más probable es que esté viendo el problema planteado (pero no respondido) en VMware Community : parece que el número proviene de un posible desbordamiento negativo acpi_index.

Puede ver información similar de udevsu sistema con:

udevadm info --name=/dev/eno16777736 --attribute-walk
garethTheRed
fuente
Jaja interesante. Entonces mi BIOS es VMWare. Lo extraño es que a veces VMWare hace eno16777736 y a veces ens33. Entonces, ¿a veces está "a bordo" y otras veces "conectado en caliente"? Extraño. 16777736 está muy cerca de 4096 ^ 2
Dmitry Minkovsky
O, eh, 2 ^ 24. Entonces tal vez comience desde allí ...
Dmitry Minkovsky
2
AHH así que es el "índice_pipi". Muchas gracias. ¡Realmente quería ver ese número en algún lugar en alguna salida! Es una pena que el OP en esa publicación no muestre el comando que emitió, pero estoy seguro de que puedo buscarlo en Google. Gracias
Dmitry Minkovsky
9

¿Usando VMware?

El sitio Unix Stackexchange tenía una pregunta y una respuesta sobre esto. Parece que el BIOS proporciona información sobre la NIC.

Si desea cambiarlo a eth0(o algún otro nombre) puede usar udev para hacerlo. Aquí hay una guía práctica para hacerlo.

Gene
fuente
Sí VMWare Y gracias, ¡revisaré tus enlaces! No necesito cambiarlo a eth0 tanto como quiero que este sistema sea realmente predecible para mí: D. También tuve ens33, por ejemplo, el uso de VMWare. Realmente quiero saber cómo selecciona esos valores, y cómo puedo volver a ellos yo mismo.
Dmitry Minkovsky