O que significa eno no nome da interface de rede 'eno16777736' para o CentOS 7 ou RHEL 7?

Question

Em esquema de nomenclatura de dispositivo de rede consistente, o que 'eno' representa no nome da interface de rede eno16777736 para o CentOS 7 ou RHEL 7?

    

Answer 1

Isso é Nomes de dispositivos de interface de rede previsíveis em ação.

• en é para Ethernet
• o é para on-board
• O número é um índice fornecido pelo firmware / BIOS.

Mais detalhes na fonte de udev-builtin-net_id .c

    

Answer 2

Hmmm. Mais do que "en" e "o", eu estaria mais preocupado com o "16777736".

A menos que você acidentalmente tenha entrado no Google e tenha se encontrado em um servidor com uma arquitetura PCI personalizada, não vejo realmente como o 16777736 poderia ser um valor possível. Isso pode ser uma sugestão para um problema mais sério.

No esquema atual, um sistema não seria capaz de endereçar mais de 256 barramentos PCI (com 32 dispositivos em cada barramento e um máximo de 8 funções em cada dispositivo). Isso também é conhecido como endereçamento Bus: Device.Function. Os sistemas modernos usam Domain: Bus: Device.Function para superar a limitação de 256 barramento. Mas de qualquer maneira, voltando ao seu problema ...

Você pode fazer um:

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

Se você vir algo muito semelhante a:

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

Então, sugiro que você corra rápido antes que o Google o pegue brincando com seus servidores.

O /(0000:1000208:01.0)/ acima é o endereço: Bus: Device.Function endereço com o valor de barramento, "1000208", sendo a representação hexadecimal de 16777736. No entanto, "0x100" (256) deve ser o valor máximo que você pode ter para "Bus".

Por outro lado, se você obtiver um valor abaixo de 0x100 para o "Barramento", como:

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

Então, acho que o problema estaria relacionado a como seu Bios / Firmware está enviando informações para o udev (systemd) na inicialização. Para descobrir a causa potencial, primeiro verifique os valores que o udev está retornando para ele.

Normalmente, existem três consultas udev para criar o PIN (Nome da Interface Previsível)

1. ACPI_DSM
2. Tabela SMBIOS [especificamente gravar tipo "slots" [9] e digite 41]
3. Tabela de roteamento PCI IRQ

[nessa ordem]

Podemos testar (1) por:

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

Se isso lhe der 16777736, provavelmente o seu sistema não suporta a especificação de firmware 3.1 do PCI, que é necessária para suportar ACPI_DSM

Então temos que testar agora (2). Então, vamos verificar primeiro o tipo de registro 41 na tabela SMBIOS (o tipo 41 é o mais relevante):

dmidecode -t 41 | more

Se nada aparecer, ou se a versão do SMBIOS for menor que "2.62", significa que o udev dependerá da tabela de roteamento PCI IRQ para criar o PIN.

Então devemos verificar (3)

biosdecode

Preste muita atenção à sua entrada máxima no slot ... deve ser da seguinte forma:

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

Se X for 25, para justificar o argumento, sua NIC deve estar em um slot menor ou igual a 25. Se não, o udev continuará a referenciar o valor de espaço reservado de 16777736.

Na maioria dos casos, você pode verificar o número do slot do seu nic:

lspci -bv | grep -i -A10 ether

E novamente Na maioria dos casos, no BDF (Bus: Device.Function), o dispositivo deve ser igual ao número da porta física (depois de convertê-lo de hexadecimal em decimal). Em outros casos (onde isso não acontece), o lspci listará o slot físico em uma linha separada na saída da execução do comando lspci acima.

Portanto, se o número do Slot Físico listado for maior que X (o número máximo que encontramos em nossa tabela de Roteamento PCI IRQ), provavelmente, isolamos o problema.

Existem 5 soluções possíveis que posso pensar neste caso ...

1. Kernel hacking ... Reconstrua o kernel com uma nova tabela de roteamento PCI IRQ. Dê uma olhada em /arch/x86/pci/irq.c

[Esta é a solução que eu preciso encontrar melhor uso da minha hora]

2. Mapeie o dispositivo para um nome diferente criando uma nova regra

por:

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

adicione o seguinte:

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

[Eu chamo isso de a solução deixar-nos-ignorar-o-problema-e-apenas-fazer-coisas-bonita]

3. Você pode adicionar net.ifnames = 0 às opções de inicialização do kernel para desativar completamente o recurso

[Esta é, naturalmente, a solução se-é-quebrada-desligada-e-solitária] (não é realmente uma solução) ...

4. E se você estiver executando uma VM ... VMWare / VirtualBox, etc ... abra o arquivo de configuração e modifique o "pciSlotNumber" para algo abaixo de X.

[mas esta é uma solução temporária-hack-until-my-software-gets-updated]

5. Compre um novo computador. [e finalmente a solução if-you-can't-beat-them-join-them]

Answer 3

Apenas para adicionar detalhes às respostas anteriores:

Two character prefixes based on the type of interface:

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

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>][..]1[i<interface>]
                                          -- USB port number chain

Fonte: link