Nuestro team especializado pasados ciertos días de investigación y de recopilar de datos, obtuvieron los datos necesarios, deseamos que resulte de utilidad en tu trabajo.
Solución:
Estos son los nombres de dispositivos de interfaz de red predecibles en acción.
enes para Ethernetoes para a bordo- El número es un índice proporcionado por el firmware / BIOS.
Más detalles en la fuente de udev-builtin-net_id.c
Mmm. Más que “en” y “o”, estaría más preocupado por el “16777736”.
A menos que haya entrado accidentalmente en Google y se haya encontrado 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.
Bajo 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: Device.Function address. Los sistemas modernos utilizan Dominio: Bus: Dispositivo Función para superar la limitación de 256 Bus. Pero de todos modos, volviendo a tu problema …
¿Puedes hacer un:
ls -la /sys/class/net | grep eno16777736
Si ve 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 pille jugando con sus servidores.
La /(0000:1000208:01.0)/ anterior es la dirección Domain: Bus: Device.Function con el valor del bus, “1000208”, siendo la representación hexadecimal de 16777736. Sin embargo, “0x100” (256) debería ser el valor máximo que puede tener para “Bus”.
Por otro lado, si obtiene un valor inferior a 0x100 para el “Bus”, como por ejemplo:
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 envía información a udev (systemd) al inicio. Para averiguar la causa potencial, primero verifique los valores que le devuelven udev.
Normalmente, hay tres lugares para las consultas de udev para crear el PIN (nombre de interfaz predecible)
- ACPI_DSM
- Tabla SMBIOS [specifically record type “slots” [9]y tipo 41]
- Tabla de enrutamiento PCI IRQ
[in that order]
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 admita la Especificación de firmware PCI 3.1, que es necesaria para admitir ACPI_DSM
Así que ahora tenemos que probar (2). Por lo tanto, 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 aparece nada, o si la versión SMBIOS es menor que “2.62”, eso significa que udev se basará en la tabla de enrutamiento PCI IRQ para crear el PIN.
Entonces deberíamos marcar (3)
biosdecode
Preste mucha atención a su entrada máxima de tragamonedas … debe ser de 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 menor o igual a 25. De lo contrario, udev continuará haciendo referencia al valor de marcador de posición de 16777736.
En la mayoría de los casos, puede verificar el número de ranura de su nic de la siguiente manera:
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 listará la ranura física en una línea separada en el resultado de ejecutar el comando lspci anterior.
Entonces, si el número de ranura física 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 …
- Hackeo del kernel … Reconstruya el kernel con una nueva tabla de enrutamiento PCI IRQ. Eche un vistazo a /arch/x86/pci/irq.c
[This is the i-need-to-find-better-uses-of-my-time solution]
- 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", ENVID_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]
- Puede agregar net.ifnames = 0 a las opciones de arranque del kernel para deshabilitar la función por completo
[This is of course the if-it-is-broke-turn-it-off-and-cry-in-solitude solution] (no es realmente una solución) …
- Y si está ejecutando una VM … VMWare / VirtualBox, etc … abra el archivo de configuración y modifique el “pciSlotNumber” a algo debajo de X.
[but this is a-temporary-hack-until-my-software-gets-updated solution]
- Compra una computadora nueva. [and finally the if-you-can’t-beat-them-join-them solution]
Solo para agregar detalles a las respuestas anteriores:
Prefijos de dos caracteres según el tipo de interfaz:
* en -- ethernet * sl -- serial line IP (slip) * wl -- wlan * ww -- wwan * ib -- InfinibandTipo de nombres:
* b-- BCMA bus core number * ccw -- CCW bus group name * o -- on-board device index number * s [f ][d ] -- hotplug slot index number * x -- MAC address * [P ]p s [f ][d ] -- PCI geographical location * [P ]p s [f ][u ][..]1[i ] -- USB port number chain
Fuente: http://ask.xmodulo.com/change-network-interface-name-centos7.html
Te mostramos comentarios y calificaciones
Si posees algún impedimento y capacidad de refinar nuestro división eres capaz de realizar una crítica y con placer lo ojearemos.