ネットワークインターフェースがリンクのアップダウンを繰り返すがdmesgにログが出ないというケースで、ethtoolを用いて物理層のトラブルの兆候を分析できます。
$ ethtool -S <network-interface-name> | grep -E error
rx_crc_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_window_errors: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
qbv_config_change_errors: 0
rx_errors: 0
tx_errors: 0
rx_length_errors: 0
rx_over_errors: 0
rx_frame_errors: 0
rx_fifo_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
インターフェース名は、ip linkコマンドで調べられます。
リンクダウンした際にこれらの値のいずれかがカウントアップしていた場合、ドライバなどソフトウェアの変更では直らない可能性があります。
それぞれの値には固有の意味があるので調べる必要がありますが、たとえばrx_crc_errorsはパケットのチェックサムが一致せず、電気的に異常がある兆候を示しています。
これは、LANケーブルを取り替えると直る可能性がある、という話です。そしてその切り分け方法が一般的でない。
I226-Vのケース
有線LANの物理層エラーはおそらくかなり稀ですが、製品の品質しだいで起き得ます。
Intel I225-Vは動作不良が多いことで知られており、I226-Vは動作不良を引き継いだリブランド品だと言われているようです。
対処方法として省電力機能をオフにするという提案がありますが、結論として今回は単にケーブルの問題でした。
そして、ケーブルが不良なのではなくカテゴリー5eの古いケーブルを使うことが重要だったようです。
新しい規格のLANケーブルはピアの機器にアースをとっていないとノイズが載りやすい傾向があるようで、I226-Vはノイズをパケットデータの解釈に含めることで再現性の高いエラーになる挙動でした。
多くのイーサネットアダプタはそこまでケーブルを選ぶことはないため、I225_V/I226-Vの実装が素朴すぎる問題なのでしょう。
NICの不良は無視しづらい
この原因特定には半年ほどかかりました。
当初は追加のUSBアダプタに切り替えをためしたのですが、Wake on LANできないので組込みのI226-Vを併用する構成になりました。
I226-Vには起動する以外の役割を持たせていないものの、ネットワークスタックが地続きになっており、I226-VのリンクダウンによりUSBアダプタを含むシステムのネットワークが止まる挙動になっていました。
Linuxの構成上、NICについては問題のあるデバイスを直すか除去しない限りシステムが安定しません。
最終的にfirmware更新によるバグ修正で直るのだろうと思っていたので、物理層で対処しなければならないシナリオは盲点でした。
ドライバはその兆候をとらえているので、本来はログ出力があれば対処しやすい事象と言えます。
