Linux機器に複数のNICを装備する場合に、特定のNICはLANのみに接続したいケースがあります。たとえば、Wifiインターフェースではインターネット接続したいが、有線イーサネットはLANアクセスのみの構成としたい利用例が考えられます。
Linuxのデフォルト挙動は、すべてのインターフェースにデフォルトゲートウェイを設定し、外部ネットワークに接続しようとします。現在の構成はip [-6|-4] routeで確認できます。
リストのうちdefaultから始まる行が外部にルーティングする設定です。
Netplan on NetworkManagerの場合
近年のDebian系のデスクトップディストリビューションは、config規約に Netplan 、ネットワークデーモンにNetworkManagerを採用しています。
Netplanのconfigは/etc/netplan/にデバイスごとに作成されます。
外部ルーティングをdisableしたいデバイスのconfigの
dhcp4-overwrites
.use-routesの値をfalseに指定すると、デフォルトルートなしの構成になります。IPv6の場合は、dhcp6-overwrites.use-routesです。
どう見てもDHCP用の設定ですが、スタティックにIP設定する場合にも参照されます。ただし、NetworkManagerの特定バージョンの実装がNetplanのconfigをそのように解釈しているだけの可能性が高く、将来別のフィールドが追加されるかもしれません。
Netplanには下層のconfigも書けますが、networkmanager.passthrough.ipv4.ignore-auto-routesという設定はNetworkManagerに直接指定するconfigのようです。
対応するGUI管理ツールも各デバイスのIPv4/IPv6設定の「Routes」などから指定できるケースがありますが、これはツールとバージョンによるでしょう。GUIの出力は/etc/netplan/に保存されるため、各configファイルで確認できます。
NICの物理層エラー切り分け
ネットワークインターフェースがリンクのアップダウンを繰り返すが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更新によるバグ修正で直るのだろうと思っていたので、物理層で対処しなければならないシナリオは盲点でした。
ドライバはその兆候をとらえているので、本来はログ出力があれば対処しやすい事象と言えます。