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

Sob um esquema consistente de nomeação de dispositivos de rede, o que significa 'eno' no nome da interface de rede do eno16777736CentOS 7 ou RHEL 7?

Esses são nomes de dispositivos de interface de rede previsíveis em ação.

• en é para Ethernet
• o é para bordo
• O número é um índice fornecido por firmware / BIOS.

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

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

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

Sob o esquema atual, um sistema não seria capaz de endereçar mais de 256 barramentos PCI (com 32 dispositivos em cada barramento e no máximo 8 funções em cada dispositivo). Isso também é conhecido como barramento: endereçamento Device.Function. Os sistemas modernos usam Domain: Bus: Device.Function para superar a limitação de 256 barramentos. Mas, enfim, 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 eu sugiro que você corra rápido antes que o Google o pegue brincando com seus servidores.

O /(0000:1000208:01.0)/ acima é o domínio: 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 "Ônibus".

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, eu acho que o problema estaria relacionado à forma como o Bios / Firmware está enviando informações ao udev (systemd) na inicialização. Para descobrir a causa potencial, verifique primeiro os valores que o udev está retornando a ele.

Normalmente, existem três locais em que o udev realiza consultas para criar o PIN (nome da interface previsível)

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

[naquela ordem]

Podemos testar (1):

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

Se isso fornecer 16777736, provavelmente o seu sistema não suporta a PCI Firmware Specification 3.1, necessária para suportar o ACPI_DSM

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

dmidecode -t 41 | more

Se nada aparecer ou a versão 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 estar no formato:

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

Se X for 25, pelo argumento, sua NIC deve estar em um slot menor ou igual a 25. Caso contrário, o udev continuará referenciando o valor do 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 (após convertê-lo de hexadecimal para decimal). Em outros casos (onde não está), 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 IRQ Routing PCI), provavelmente isolamos o problema.

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

1. Hacking do kernel ... 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 para encontrar melhores usos do meu tempo]

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

por:

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

depois 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 solução, vamos ignorar o problema e fazer a coisa parecer bonita]

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

[Esta é, obviamente, a solução "se for quebrado, desligue e chore na solidão] (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 de hack até que meu software seja atualizado]

5. Compre um novo computador. [e, finalmente, a solução se você não pode vencê-los, une-se a eles]

Apenas para adicionar detalhes às respostas anteriores:

Prefixos de dois caracteres com base no tipo de interface:

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

Tipo de nomes:

*   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