☰

ネットワークがランダムに切断され、接続されている

tag-icon • tag-icon linux network-interface networkmanager
ネットワークがランダムに切断され、接続されている

コンピュータで作業しているときにネットワーク接続が失われ、何度も再接続することがあります。これは時々起こりますが、再現できません。この問題をどのように解決できるかを知っている人はいますか？

ハードウェア情報は次のとおりです。

Network:
  Device-1: Intel Ethernet I219-LM vendor: Holco Enterprise Co /Shuttle
    driver: e1000e v: kernel port: N/A bus-ID: 00:1f.6
  IF: eth1 state: down mac: <filter>
  Device-2: Intel Ethernet I225-V vendor: Holco Enterprise Co /Shuttle
    driver: igc v: kernel port: N/A bus-ID: 01:00.0
  IF: eth0 state: up speed: 2500 Mbps duplex: full mac: <filter>

# nmcli device show
GENERAL.DEVICE:                         eth0
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         80:EE:73:FA:CF:22
GENERAL.MTU:                            1500
GENERAL.STATE:                          100 (connected)
GENERAL.CONNECTION:                     eth0
GENERAL.CON-PATH:                       /org/freedesktop/NetworkManager/ActiveConnecti>
WIRED-PROPERTIES.CARRIER:               on
IP4.ADDRESS[1]:                         192.168.1.106/24
IP4.GATEWAY:                            192.168.1.1
IP4.ROUTE[1]:                           dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.ROUTE[2]:                           dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100
IP4.DNS[1]:                             192.168.1.1
IP4.SEARCHES[1]:                        shuttle
IP6.ADDRESS[1]:                         2a02:1210:7489:a300:2697:710a:426:426d/64
IP6.ADDRESS[2]:                         2a02:1210:7489:a300:e284:205d:22b6:9db1/64
IP6.ADDRESS[3]:                         fe80::1744:cadf:be2:4aee/64
IP6.GATEWAY:                            fe80::a6ce:daff:feb7:b0a0
IP6.ROUTE[1]:                           dst = 2a02:1210:7489:a300::/64, nh = ::, mt = >
IP6.ROUTE[2]:                           dst = fe80::/64, nh = ::, mt = 1024
IP6.ROUTE[3]:                           dst = ::/0, nh = fe80::a6ce:daff:feb7:b0a0, mt>
IP6.DNS[1]:                             2a02:1210:7489:a300::1
IP6.SEARCHES[1]:                        home

GENERAL.DEVICE:                         eth1
GENERAL.TYPE:                           ethernet
GENERAL.HWADDR:                         80:EE:73:FA:CF:21
GENERAL.MTU:                            1500
GENERAL.STATE:                          20 (unavailable)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
WIRED-PROPERTIES.CARRIER:               off
IP4.GATEWAY:                            --
IP6.GATEWAY:                            --

GENERAL.DEVICE:                         lo
GENERAL.TYPE:                           loopback
GENERAL.HWADDR:                         00:00:00:00:00:00
GENERAL.MTU:                            65536
GENERAL.STATE:                          10 (unmanaged)
GENERAL.CONNECTION:                     --
GENERAL.CON-PATH:                       --
IP4.ADDRESS[1]:                         127.0.0.1/8
IP4.GATEWAY:                            --
IP6.ADDRESS[1]:                         ::1/128
IP6.GATEWAY:                            --
IP6.ROUTE[1]:                           dst = ::1/128, nh = ::, mt = 256

ログ出力は次のとおりです。

# journalctl -u NetworkManager -f
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1141] device (eth0): carrier: link connected
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1143] device (eth0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1151] policy: auto-activating connection 'eth0' (7ba00b1d-8cdd-30da-91ad-bb83ed4f7474)
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1156] device (eth0): Activation: starting connection 'eth0' (7ba00b1d-8cdd-30da-91ad-bb83ed4f7474)
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1157] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1158] manager: NetworkManager state is now CONNECTING
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1160] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1356] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.1362] policy: set 'eth0' (eth0) as default for IPv4 routing and DNS
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.2509] device (eth0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.2598] device (eth0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.2600] device (eth0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.2604] manager: NetworkManager state is now CONNECTED_SITE
Dec 06 09:11:46 sh NetworkManager[919]: <info>  [1701850306.2606] device (eth0): Activation: successful, device activated.

これまで私は次のことを試しました。

  • すべてのケーブルの交換
  • スイッチの交換
  • システム全体を再インストール
  • IPV6をオフにしても役に立ちません。

ベストアンサー1

インターフェイスeth0はIntel I225-Vです。 Googleで検索してみると、これについて多くの辛い議論があります。

https://www.intel.com/content/www/us/en/support/articles/000057261/ethernet-products/gigabit-ethernet-controllers-up-to-2-5gbe.html

https://community.intel.com/t5/Ethernet-Products/Intel-I225-V-Drops-Connections/mp/1474748

多くのIntel I225-Vチップにハードウェアバグがあるようです。明らかに、この配置でマザーボードの大部分を受け取ったメーカーはAsusとGigabyteでしたが、他のメーカーもいくつかの欠陥のあるチップを受けた可能性があります。

チップの初期バージョンでは、仕様で許可されている5バイト間隔ではなく、2.5Gレートで8バイトのパケット間の間隔が必要でした。これにより、1 GB レートでパケット損失とリンク再ネゴシエーションが発生します。再ネゴシエーションを繰り返すと、かなりの速度低下が発生する可能性があります。 Intelの公式正誤表を参照してください。https://cdrdv2.intel.com/v1/dl/getContent/621661

その後のリビジョンでは問題を解決しようとしましたが、最初は正しく機能しなかったか、最初の修正によって他の問題が発生しました。

I225-Vは明らかにマザーボードに統合されているので（図を参照vendor: Holco Enterprise Co /Shuttle）、システム/マザーボードベンダーがBIOSアップデートまたは別のNICファームウェアアップデート形式でファームウェアアップデートを提供していることを確認してください。

明らかに、マザーボードモデルに合わせてファームウェアの解決策を調整する必要があるため、通常のファームウェアではなく、特定のマザーボード/システムベンダーのファームウェアを優先する必要があります。

ただし、欠陥のあるチップリビジョンの1つがある場合、ファームウェアの解決策は、信頼性の高い2.5Gリンクを許可せず、代わりにカードをより継続的に1Gリンクに切り替えることを可能にします。これは、ハードウェアの安定した脆弱性に関係なく不可能です。維持する必要があります。

明らかにB3チップバージョンは（ほとんど？）利用可能ですが、以前のバージョンはあらゆる点で問題があります。

おすすめ記事