Що означає значення назви мережевого інтерфейсу 'eno16777736' для CentOS 7 або RHEL 7?

За послідовною схемою іменування мережевих пристроїв, що означає 'eno' у назві мережевого інтерфейсу eno16777736для CentOS 7 або RHEL 7?

Це передбачувані імена пристроїв мережевого інтерфейсу .

• en призначений для Ethernet
• o призначений для борту
• Номер - це індекс, що надається прошивкою / BIOS.

Більш детально у джерелі udev-buildin-net_id.c

Хммм. Більше, ніж "en" і "o", мене більше турбує "16777736".

Якщо ви випадково не потрапили в Google і не опинилися, що сидите за сервером із власною архітектурою PCI, я насправді не бачу, як 16777736 може бути можливим значенням. Це може бути натяком на більш серйозну проблему.

За чинною схемою система не змогла би адресувати більше 256 шин PCI (з 32 пристроями під кожною шиною та максимум 8 функцій під кожним пристроєм). Це також відомо як Bus: Device.Function addressing. Сучасні системи використовують домен: шина: Device.Function, щоб перейти за обмеження шини 256. Але все одно, повертаючись до своєї проблеми ...

Чи можете ви зробити:

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

Якщо ви бачите щось дуже схоже на:

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

Тоді я пропоную вам швидко бігти до того, як Google застане вас грати зі своїми серверами.

/(0000:1000208:01.0)/ вище - Домен: Шина: Device.Функційна адреса зі значенням шини "1000208", що є шістнадцятковим представленням 16777736. Однак "0x100" (256) має бути максимальним значенням що ви можете мати для "Автобус".

З іншого боку, якщо ви отримаєте значення, що нижче 0x100 для "Шини", наприклад:

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

Тоді я думаю, що проблема буде пов'язана з тим, як ваш Bios / Firmware надсилає інформацію до udev (systemd) при запуску. Щоб з'ясувати потенційну причину, спочатку перевірте значення, які удев повертається до нього.

Зазвичай для запиту PIN-коду (передбачувана назва інтерфейсу) є три місця udev-запитів.

1. ACPI_DSM
2. Таблиця SMBIOS [конкретно записуйте тип "слоти" [9] та тип 41]
3. Таблиця маршрутизації PCI IRQ

[у тому порядку]

Ми можемо протестувати (1):

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

Якщо це дає 16777736, то, швидше за все, ваша система не підтримує специфікацію прошивки PCI 3.1, яка потрібна для підтримки ACPI_DSM

Тож ми маємо зараз протестувати (2). Тож давайте спочатку перевіримо тип запису 41 у таблиці SMBIOS (тип 41 є найбільш релевантним):

dmidecode -t 41 | more

Якщо нічого не відображається, або версія SMBIOS менша, ніж "2,62", то це означає, що udev для створення PIN-коду покладається на таблицю маршрутизації PCI IRQ.

Отже, ми повинні перевірити (3)

biosdecode

Зверніть пильну увагу на ваш максимальний запис у слоті ... він має бути такої форми:

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

Якщо X дорівнює 25, для аргументу ваш NIC повинен бути на прорізі, меншому або рівному 25. Якщо ні, udev продовжить посилатись на значення заповнення 16777736.

У більшості випадків ви можете перевірити номер слота вашого ніка за допомогою:

lspci -bv | grep -i -A10 ether

І знову. У більшості випадків у BDF (Шина: Device.Function) Пристрій повинен дорівнювати номеру фізичного порту (після перетворення його з шестигранної у десяткову). В інших випадках (де цього немає) lspci відобразить фізичний слот на окремому рядку у висновку виконання вищевказаної команди lspci.

Отже, якщо вказаний номер фізичного слота більший за X (максимальна кількість, яку ми знайшли в нашій таблиці маршрутизації PCI IRQ), ми, швидше за все, усунули проблему.

У цьому випадку я можу придумати 5 можливих рішень ...

1. Злом ядра ... Відновіть ядро ​​за допомогою нової таблиці маршрутизації PCI IRQ. Погляньте на /arch/x86/pci/irq.c

[Це рішення "мені потрібно-знайти-краще-використовувати-свого часу"]

2. Позначте пристрій на іншу назву, створивши нове правило

автор:

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

потім додайте наступне:

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

[Я називаю це рішенням "дозвольте нам" ігнорувати "проблему" та "просто зробити речі".

3. Ви можете додати net.ifnames = 0 до параметрів завантаження ядра, щоб повністю відключити функцію

[Це, звичайно, рішення "якщо це - перерва", "вимкнення", "викривлення" та "крик у самоті"] (насправді не рішення) ...

4. І якщо у вас трапляється запуск VM ... VMWare / VirtualBox тощо ... відкрийте файл конфігурації та змініть "pciSlotNumber" на щось нижче X.

[але це тимчасове рішення "hack-till-my-software" отримує оновлення]

5. Купіть новий комп’ютер. [і нарешті рішення, якщо ви не можете перемогти їх, приєднайтесь до них]

Просто для додання деталей до попередніх відповідей:

Два символьні префікси залежно від типу інтерфейсу:

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

Тип імен:

*   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

Джерело: http://ask.xmodulo.com/change-network-interface-name-centos7.html