Cosa significa eno nel nome dell'interfaccia di rete 'eno16777736' per CentOS 7 o RHEL 7?

In base allo schema di denominazione dei dispositivi di rete coerente, cosa significa "eno" nel nome dell'interfaccia di rete eno16777736per CentOS 7 o RHEL 7?

Si tratta di nomi di dispositivi di interfaccia di rete prevedibili in azione.

• en è per Ethernet
• o è per a bordo
• Il numero è un indice fornito dal firmware / BIOS.

Maggiori dettagli nella fonte di udev-builtin-net_id.c

Hmmm. Più che "en" e "o", sarei più preoccupato per il "16777736".

A meno che, per caso, non ti sia capitato di imbatterti in Google e ti sei trovato seduto su un server con un'architettura PCI personalizzata, non vedo davvero come 16777736 possa essere un valore possibile. Questo potrebbe essere un suggerimento per un problema più serio.

Secondo lo schema attuale, un sistema non sarebbe in grado di indirizzare più di 256 bus PCI (con 32 dispositivi sotto ciascun bus e un massimo di 8 funzioni sotto ciascun dispositivo). Questo è noto anche come Bus: indirizzamento Device.Function. I sistemi moderni utilizzano Domain: Bus: Device.Function per superare la limitazione di 256 Bus. Comunque, tornando al tuo problema ...

Puoi fare un:

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

Se vedi qualcosa di molto simile a:

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

Quindi ti suggerisco di correre veloce prima che Google ti sorprenda a giocare con i loro server.

Il /(0000:1000208:01.0)/ sopra è il dominio: bus: indirizzo Device.Function con il valore del bus "1000208", che è la rappresentazione esadecimale di 16777736. Tuttavia, "0x100" (256) dovrebbe essere il valore massimo che puoi avere per "Bus".

D'altra parte se si ottiene un valore inferiore a 0x100 per il "Bus", ad esempio:

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

Quindi, penso che il problema sarebbe legato al modo in cui il BIOS / firmware sta inviando informazioni a udev (systemd) all'avvio. Per capire la potenziale causa, controlla innanzitutto i valori che udev viene restituito ad essa.

Normalmente ci sono tre posizioni in cui udev richiede di creare il PIN (Predictable Interface Name)

1. ACPI_DSM
2. Tabella SMBIOS [in particolare record di tipo "slot" [9] e tipo 41]
3. Tabella di routing PCI IRQ

[in questo ordine]

Possiamo testare (1) con:

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

Se questo ti dà 16777736, molto probabilmente il tuo sistema non supporta la specifica del firmware PCI 3.1 che è necessaria per supportare ACPI_DSM

Quindi ora dobbiamo testare (2). Quindi controlliamo prima il tipo di record 41 nella tabella SMBIOS (il tipo 41 è il più rilevante):

dmidecode -t 41 | more

Se non viene visualizzato nulla o la versione di SMBIOS è inferiore a "2.62", ciò significa che udev farà affidamento sulla tabella di routing PCI IRQ per creare il PIN.

Quindi dovremmo controllare (3)

biosdecode

Prestare molta attenzione alla voce di slot massima ... dovrebbe essere nel formato:

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

Se X è 25, per l'argomento, la scheda NIC dovrebbe trovarsi su uno slot inferiore o uguale a 25. In caso contrario, udev continuerà a fare riferimento al valore di segnaposto di 16777736.

Nella maggior parte dei casi, puoi controllare il numero di slot del tuo nic da:

lspci -bv | grep -i -A10 ether

E ancora Nella maggior parte dei casi, nel BDF (Bus: Device.Function), il dispositivo dovrebbe essere uguale al numero di porta fisica (dopo averlo convertito da esadecimale a decimale). In altri casi (dove non lo è), lspci elencherà lo slot fisico su una riga separata nell'output dell'esecuzione del comando lspci sopra.

Quindi, se il numero di slot fisico elencato è maggiore di X (il numero massimo che abbiamo trovato nella nostra tabella di routing PCI IRQ) molto probabilmente abbiamo isolato il problema.

Ci sono 5 possibili soluzioni a cui riesco a pensare in questo caso ...

1. Hacker del kernel ... Ricrea il kernel con una nuova tabella di routing PCI IRQ. Dai un'occhiata a /arch/x86/pci/irq.c

[Questa è la soluzione i-need-to-find-better-of-my-time]

2. Mappa il dispositivo con un nome diverso creando una nuova regola

di:

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

quindi aggiungere quanto segue:

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

[La chiamo la soluzione per farci ignorare-il-problema-e-solo-rendere-cose-carina]

3. È possibile aggiungere net.ifnames = 0 alle opzioni di avvio del kernel per disabilitare del tutto la funzionalità

[Questa è ovviamente la soluzione if-it-is-broke-turn-it-off-and-cry-in-solitude] (non proprio una soluzione) ...

4. E se ti capita di eseguire una VM ... VMWare / VirtualBox, ecc ... apri il file di configurazione e modifica "pciSlotNumber" su qualcosa sotto X.

[ma questa è una soluzione temporanea di hacking fino a quando il mio software non viene aggiornato]

5. Acquista un nuovo computer. [e infine la soluzione if-you-impossibile-beat-them-join-them]

Solo per aggiungere dettagli alle risposte precedenti:

Due prefissi di caratteri in base al tipo di interfaccia:

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

Tipo di nomi:

*   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

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