Que signifie eno dans le nom d'interface réseau «eno16777736» pour CentOS 7 ou RHEL 7?

Dans le cadre d'un schéma de dénomination cohérent des périphériques réseau, que signifie «eno» dans le nom de l'interface réseau eno16777736pour CentOS 7 ou RHEL 7?

rhel network-interface centos

— Andy Huang
source

Il s'agit des noms de périphériques d'interface réseau prévisibles en action.

en est pour Ethernet
o est à bord
Le numéro est un index fourni par le micrologiciel / BIOS.

Plus de détails dans la source de udev-builtin-net_id.c

— garethTheRed
source

Hmmm. Plus que "en" et "o", je serais plus préoccupé par le "16777736".

À moins que vous n'ayez accidentellement erré dans Google et que vous vous soyez retrouvé assis sur un serveur avec une architecture PCI personnalisée, je ne vois pas vraiment comment 16777736 pourrait être une valeur possible. Cela pourrait être un indice d'un problème plus grave.

Dans le schéma actuel, un système ne pourrait pas adresser plus de 256 bus PCI (avec 32 périphériques sous chaque bus et un maximum de 8 fonctions sous chaque périphérique). Ceci est également connu sous le nom de Bus: Device.Function adressing. Les systèmes modernes utilisent Domain: Bus: Device.Function pour dépasser la limitation de 256 bus. Mais quoi qu'il en soit, revenons à votre problème ...

Pouvez-vous faire:

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

Si vous voyez quelque chose de très similaire à:

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

Ensuite, je vous suggère de courir vite avant que Google ne vous surprenne à jouer avec leurs serveurs.

Le /(0000:1000208:01.0)/ ci-dessus est l'adresse Domain: Bus: Device.Function avec la valeur de bus, "1000208", étant la représentation hexadécimale de 16777736. Cependant, "0x100" (256) devrait être la valeur maximale que vous pouvez avoir pour "Bus".

D'un autre côté, si vous obtenez une valeur inférieure à 0x100 pour le "Bus", comme:

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

Ensuite, je pense que le problème serait lié à la façon dont votre Bios / Firmware envoie des informations à udev (systemd) au démarrage. Pour déterminer la cause potentielle, vérifiez d'abord les valeurs auxquelles udev est renvoyé.

Normalement, il existe trois requêtes udev pour créer le code PIN (Predictable Interface Name)

ACPI_DSM
Table SMBIOS [enregistrez spécifiquement le type "slots" [9] et le type 41]
Table de routage PCI IRQ

[dans cet ordre]

Nous pouvons tester (1) par:

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

Si cela vous donne 16777736, votre système ne prend probablement pas en charge la spécification de micrologiciel PCI 3.1 qui est nécessaire pour prendre en charge ACPI_DSM

Nous devons donc maintenant tester (2). Permet donc de vérifier d'abord le type d'enregistrement 41 dans la table SMBIOS (le type 41 est le plus pertinent):

dmidecode -t 41 | more

Si rien ne s'affiche ou si la version SMBIOS est inférieure à "2,62", cela signifie que udev s'appuiera sur la table de routage PCI IRQ pour créer le code PIN.

Nous devons donc vérifier (3)

biosdecode

Portez une attention particulière à votre entrée de slot maximale ... elle devrait être de la forme:

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

Si X vaut 25, pour les besoins de l'argument, votre carte réseau doit se trouver sur un emplacement inférieur ou égal à 25. Sinon, udev continuera de référencer la valeur d'espace réservé de 16777736.

Dans la plupart des cas, vous pouvez vérifier le numéro d'emplacement de votre nic en:

lspci -bv | grep -i -A10 ether

Et encore Dans la plupart des cas, dans le BDF (Bus: Device.Function), le périphérique doit être égal au numéro de port physique (après l'avoir converti de hex en décimal). Dans d'autres cas (où ce n'est pas le cas), lspci listera l'emplacement physique sur une ligne distincte dans la sortie de l'exécution de la commande lspci ci-dessus.

Donc, si le numéro d'emplacement physique répertorié est supérieur à X (le nombre maximal que nous avons trouvé dans notre table de routage PCI IRQ), nous avons très probablement isolé le problème.

Il y a 5 solutions possibles auxquelles je peux penser dans ce cas ...

Piratage du noyau ... Reconstruisez le noyau avec une nouvelle table de routage PCI IRQ. Jetez un œil à /arch/x86/pci/irq.c

[Il s'agit de la solution i-need-to-find-better-uses-of-my-time]

Mappez l'appareil à un nom différent en créant une nouvelle règle

par:

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

puis ajoutez ce qui suit:

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

[J'appelle cela la solution laissez-nous-ignorer-le-problème-et-juste-faire-jolies choses]

Vous pouvez ajouter net.ifnames = 0 aux options de démarrage du noyau pour désactiver complètement la fonctionnalité

[Ceci est bien sûr la solution si-elle-est-cassée-tournez-la-off-and-cry-in-solitude] (pas vraiment une solution) ...

Et si vous utilisez une VM ... VMWare / VirtualBox, etc ... ouvrez le fichier de configuration et modifiez le "pciSlotNumber" en quelque chose en dessous de X.

[mais il s'agit d'une solution de piratage temporaire jusqu'à ce que mon logiciel soit mis à jour]

Achetez un nouvel ordinateur. [et enfin la solution if-you-can't-beat-them-join-them]

— Dominic Williams
source

Je crois que ce nombre étrange correspond au périphérique net dans le BIOS VMWare. Il semble que l'OP utilise des machines virtuelles CentOS 7.

Ce n'est pas toujours la même chose non plus - j'ai eno16780032. Quelle douleur dans le cul.

— Dan Pritts

Cette réponse est si épuisante qu'en répondant à la question du PO, vous avez réussi à produire une référence concise sur la façon d'identifier les appareils par leurs indices.

— Konrads

Ces sortes de noms pour VMware ne sont apparemment pas rares. Par exemple, je nomme mes appareils eno16777732.

— Stefan Lasiewski

Le problème que j'ai rencontré concernant VMWare est qu'il ne semble pas y avoir de moyen d'obtenir l'acpi_index d'une carte réseau donnée à partir de l'API VSphere.

— Danny

Juste pour ajouter des détails aux réponses précédentes:

Deux préfixes de caractères basés sur le type d'interface:

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

Type de noms:

*   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

— somptueux
source