CentOS 7またはRHEL 7のネットワークインターフェイス名 'eno16777736'のenoはどういう意味ですか？

一貫性のあるネットワークデバイスの命名スキームではeno16777736、CentOS 7またはRHEL 7のネットワークインターフェイス名で「eno」は何を表していますか？

これは、動作中の予測可能なネットワークインターフェイスデバイス名です。

• en イーサネット用
• o オンボード用です
• 番号は、ファームウェア/ BIOSが提供するインデックスです。

udev-builtin-net_id.cのソースの詳細

うーん。「en」や「o」よりも、「16777736」の方が心配です。

誤ってGoogleに迷い込んで、カスタムPCIアーキテクチャを備えたサーバーに座っていることに気づかない限り、16777736がどのように可能な値であるかはわかりません。これは、より深刻な問題のヒントかもしれません。

現在のスキーマでは、システムは256個を超えるPCIバス（各バスの下に32個のデバイス、各デバイスの下に最大8個の機能）をアドレスできません。これはBus：Device.Functionアドレス指定とも呼ばれます。最新のシステムでは、Domain：Bus：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)/は、16777736の16進表現であるバス値「1000208」を持つDomain：Bus：Device.Functionアドレスです。ただし、「0x100」（256）は最大値である必要があります「バス」に使用できるもの。

一方、「バス」の値が0x100未満の場合、次のようになります。

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

次に、問題は、起動時にBios / Firmwareがudev（systemd）に情報を送信する方法に関連すると思います。潜在的な原因を特定するには、最初にudevが返される値を確認します。

通常、PIN（予測可能なインターフェース名）を作成するためにudevクエリが3つの場所にあります

1. ACPI_DSM
2. SMBIOSテーブル[具体的には、レコードタイプ "スロット" [9]、およびタイプ41]
3. PCI IRQルーティングテーブル

[その順序で]

（1）を次の方法でテストできます。

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

これにより16777736が提供される場合、システムはACPI_DSMをサポートするために必要なPCIファームウェア仕様3.1をサポートしていない可能性が高い

そのため、テストする必要があります（2）。したがって、最初にSMBIOSテーブルのレコードタイプ41を確認してください（タイプ41が最も関連性が高い）。

dmidecode -t 41 | more

何も表示されない場合、またはSMBIOSバージョンが「2.62」より小さい場合、udevはPCI IRQルーティングテーブルに依存してPINを作成することを意味します。

確認する必要があります（3）

biosdecode

最大スロットエントリに細心の注意を払ってください。形式は次のとおりです。

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

Xが25の場合、引数のために、NICは25以下のスロットにある必要があります。そうでない場合、udevは16777736のプレースホルダー値を引き続き参照します。

ほとんどの場合、次の方法でnicのスロット番号を確認できます。

lspci -bv | grep -i -A10 ether

また、ほとんどの場合、BDF（Bus：Device.Function）では、デバイスは（16進数から10進数に変換した後）物理ポート番号に等しくなければなりません。それ以外の場合（そうでない場合）、lspciは、上記のlspciコマンドを実行した出力の別の行に物理スロットをリストします。

そのため、リストされている物理スロット番号がX（PCI IRQルーティングテーブルで見つかった最大数）よりも大きい場合、問題を特定している可能性が高いです。

この場合、考えられる解決策は5つあります...

1. カーネルハッキング...新しいPCI IRQルーティングテーブルを使用してカーネルを再構築します。/arch/x86/pci/irq.cをご覧ください

[これは、マイタイムを見つけるためのi-need-need-to-better-uses-of-my-timeソリューションです]

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}" 

[これをlet-us-ignore-the-problem-and-just-make-things-look-pretty-solutionと呼ぶ]

3. net.ifnames = 0をカーネルブートオプションに追加して、この機能を完全に無効にすることができます

[これは、もちろん、if-it-is-broke-it-off-and-cry-in-solitudeソリューションです]（実際にはソリューションではありません）...

4. VMを実行している場合は... VMWare / VirtualBoxなど...構成ファイルを開き、「pciSlotNumber」をXの下に変更します。

[ただし、これは一時的なハックまで、私のソフトウェアが更新されるまでのソリューションです]

5. 新しいコンピューターを購入します。[そして最後に、もしあなたがそれらを結合することができないなら、それらのソリューション]

前の回答に詳細を追加するだけです：

インターフェイスのタイプに基づいた2つの文字プレフィックス：

*   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