web-dev-qa-db-ja.com

CentOS 7またはRHEL 7のネットワークインターフェース名「eno16777736」でenoは何を意味しますか？

一貫したネットワークデバイスの名前付けスキームでは、「eno」はネットワークインターフェース名で何を表しますかeno16777736 CentOS 7またはRHEL 7の場合？

rhelnetwork-interfacecentos
17
Andy Huang

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

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

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

23
garethTheRed

うーん。 「en」や「o」よりも「16777736」の方が気になります。

誤ってGoogleにアクセスして、カスタムPCIアーキテクチャのサーバーに座っているのでない限り、16777736がどのように考えられるかはわかりません。これは、より深刻な問題のヒントになる可能性があります。

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

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

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

次に、問題は、起動時にBios/Firmwareがudev（systemd）に情報を送信する方法に関連していると思います。考えられる原因を解明するには、最初にudevが返されている値を確認します。

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

  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をご覧ください

[これは、私の時間解決策を見つけるために必要なものです]

  1. 新しいルールを作成して、デバイスを別の名前にマップします

沿って：

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ソリューションと呼びます]

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

[これはもちろん、もしそれが壊れた場合は、単独で解決する]（実際には解決策ではありません）...

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

[しかし、これは一時的なハックで、my-software-gets-updatedソリューションになります]

  1. 新しいコンピュータを購入します。 [そして最後に、あなたがそれらを打ち負かすことができない場合の解決策]
19
Dominic Williams

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

インターフェイスのタイプに基づく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

14
sumid