Pourquoi mon eth0 s'appelle-t-il eno16777736?

27

J'ai vu http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ , qui décrit la raison d'être des noms d'appareil cohérents / prévisibles, puis les règles de génération des noms d'appareils :

 * 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

Alors disons que j'ai un appareil eno16777736: pourquoi ça s'appelle comme ça? C'est une carte Ethernet, je l'ai. Mais comment puis-je revenir moi-même sur le reste du nom de cette interface?

J'ai examiné /sys/class/net/eno16777736et vu:

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

Je ne sais pas comment interpréter cela non plus, ni si je peux utiliser ces informations pour y accéder eno16777736.

Mise à jour

C'est donc l' 16777736appareil acpi_index. Par 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.

Et en effet:

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

De plus, pour réconcilier la sortie de ifconfigou ip linket de vos appareils dans 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

Remarquez l '"interruption de périphérique 19". Et à partir de lspci -v, qui a "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

Ici, vous voyez également "Phyiscal Slot 33", et en effet, parfois VMWare démarre les machines virtuelles qui deviennent le ens33nom de l'interface. Donc, on ne sait pas pourquoi d'autres fois il choisit eno16777736. Mais le 16777736 vient du acpi_index, et le 33 vient du slot PCI.

linux networking udev Dmitry Minkovsky
la source
On dirait que Red Hat a corrigé son côté dans RHEL7.3: redhat.com/en/about/blog/…
Stefan Lasiewski

Réponses:

30

en pour Ethernet

o à bord

16777736est l'index de l'appareil fourni par le firmware (BIOS / EFI). Il aurait été logique de démarrer l'index à 1. Soit ça, soit vous avez un firmware sensible et plus de 16 millions d'appareils embarqués! Mais plus probablement, vous voyez le problème soulevé (mais sans réponse) sur VMware Community - il semble que le nombre provienne d'un éventuel débordement négatif acpi_index.

Vous pouvez afficher des informations similaires udevpour votre système avec:

udevadm info --name=/dev/eno16777736 --attribute-walk
garethTheRed
la source
Haha intéressant. Mon BIOS est donc VMWare. Ce qui est bizarre, c'est que parfois VMWare fait eno16777736 et parfois ens33. Donc, parfois, c'est «à bord» et parfois «branché à chaud»? Bizarre. 16777736 est très proche de 4096 ^ 2
Dmitry Minkovsky
Ou, euh, 2 ^ 24. Alors peut-être que ça commence à partir de là ...
Dmitry Minkovsky
2
AHH c'est donc le "acpi_index". Merci beaucoup. Je voulais vraiment voir ce nombre quelque part dans une sortie! C'est dommage que l'OP sur ce poste ne montre pas la commande qu'il a émise, mais je suis sûr que je peux Google pour cela. Merci
Dmitry Minkovsky
9

Vous utilisez VMware?

Le site Unix Stackexchange avait une question et une réponse à ce sujet. Il semblerait que les informations sur la carte réseau soient fournies par le BIOS.

Si vous voulez le changer en eth0(ou un autre nom), vous pouvez utiliser udev pour le faire. Voici un guide pratique pour le faire.

Gène
la source
Oui, VMWare. Et merci, je vais vérifier vos liens! Je n'ai pas besoin de le changer en eth0 autant que je veux que ce système soit réellement prévisible pour moi: D. J'ai ens33également utilisé, par exemple, VMWare. Je veux vraiment savoir comment il sélectionne ces valeurs et comment je peux y revenir moi-même.
Dmitry Minkovsky