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

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

eno16777736一貫したネットワークデバイスの命名方式では、CentOS 7またはRHEL 7のネットワークインターフェイス名で「eno」とはどういう意味ですか?

答え1

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

  • enイーサネット用
  • oボートで使用するために
  • これはファームウェア/ BIOSによって提供されるインデックスです。

詳細はソースからudev-組み込み-net_id.c

答え2

まあ。 「en」と「o」より「16777736」に興味があります。

誤ってGoogleにアクセスしてカスタムPCIアーキテクチャを持つサーバーに座っていない限り、16777736は可能な値であることを本当に理解していません。これはより深刻な問題を暗示するかもしれません。

現在のアーキテクチャでは、システムは256以上のPCIバス(バスあたり32デバイス、デバイスあたり最大8つの機能)を処理できません。これをバス:装置、機能アドレス指定ともいいます。最新システムは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)/ は Domain:Bus:Device.Function アドレスであり、バス値は "1000208" で 16777736 を 16 進数で表現したものです。ただし、「0x100」(256)は「バス」で使用できる最大値でなければなりません。

一方、「bus」の値が0x100より小さい場合、たとえば、次のようになります。

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

もしそうなら、問題はBIOS /ファームウェアが起動時に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 を引き続き参照します。

ほとんどの場合、次の方法でネットワークカードのスロット番号を確認できます。

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

[私はこれを問題を無視してきれいに見せる解決策と呼びます。]

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

[もちろん「故障したら電源を切って一人で泣きなさい」という解決策だ](実際の解決策ではない)…

  1. VM ... VMWare / VirtualBoxなどを実行している場合は、構成ファイルを開き、「pciSlotNumber」をXより低い値に変更してください。

[しかし、これは私のソフトウェアがソリューションにアップデートされるまで一時的なハッキングです。]

  1. 新しいコンピュータを購入してください。 【最後に「勝てないなら参加する」ソリューション】

答え3

前の回答に詳細を追加するには:

インターフェイスの種類に応じた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

関連情報