VPNゲートウェイのポートにおけるデュプレックス不整合：両端を読む

トンネル経由のファイルコピーが一秒ほど止まり、再開し、VPNのログには何も残らない。アプリケーションはネットワークを責め、ネットワークはアプリケーションを責め、スイッチポートは十一ヶ月間稼働している。この手順はその停止から始まり、物理リンクへと外側に進む。ポートが実際に何をしているのか、対向側が何をしているのか、そして見ている間にカウンタがどう動いたのかを確かめる。誰かがデュプレックス設定に触れる前にやっておく価値がある。

ポートではなく停止から始める

症状は検証できる形で書く。一括転送中に約一秒止まるのは、接続がリセットされるのとは別の問題であり、一時間に一度の停止は数秒ごとの停止とも違う。ワークロード、方向、およその間隔を記録する。

次に、インターフェースを見ながら再現する。物理的な問題は、該当するワークロード中にカウンタが動く形で現れる。そしてカウンタがまったく動かない問題は、リンク層より上にある可能性が高い。一秒ではなく一分間観察する。こうした障害は、現れる前に持続的なトラフィックを必要とすることが多い。アイドル状態の監視は、負荷時だけ不調になるリンクについて何も証明しない。

これが重要なのは、デュプレックス不整合には署名があるからだ。負荷時にだけ、トラフィックの方向にだけエラーが出て、小さなpingや対話的なセッションは完璧なままである。アイドル時のトラフィックでも失敗するなら、まず別の場所を探すべきだ。

両端で動作モードを読む

保存された設定は動作状態ではない。ポートはオートネゴシエーション用に設定されていても半二重に落ち着くことがあり、相手が決して同意していない固定速度に設定されていることもある。リンクが今どちらの側で何をしているのかを読む。

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

速度、デュプレックス、オートネゴシエーションの有無を記録し、隣接するスイッチまたはプロバイダ側ポートから同じ三つの事実を取る。片側だけでは何も分からない。不整合は設定ではなく関係だからだ。両方の行を時刻とともにチケットに並べて書く。この作業の価値の半分は、二つの読み取りが一か所に揃うことにある。

対向側を読めないなら、これを診断することはできない。所有者に動作モードとカウンタを尋ねるか、自分の側を変える前にアクセスを手配する。

10/100の半二重のケースはどう見えるか

10/100の銅線リンクでは、オートネゴシエーションする側が、固定設定された相手の速度を検出できても、そのデュプレックス設定を学習できない。パラレル検出は信号から速度を決め、デュプレックスはネゴシエートされずに仮定される。そのため一方が半二重のまま、他方が全二重で動くことがある。

Ciscoのオートネゴシエーションのガイドラインがその特定のケースを説明している。これはどこでもネゴシエーションを無効にせよという主張ではなく、ギガビット銅線については何も有用なことを言っていない。そこではデュプレックスは固定で、リンクを立ち上げるにはオートネゴシエーションが必須だからだ。

観察できる証拠は、一方向にしか存在しないエラーの混合だ。全二重側のFCSまたはCRCエラー、半二重側の衝突または遅延衝突、そして負荷時に崩壊するスループットであり、アイドル時にはレイテンシは正常のままである。この非対称性が署名だ。単に過剰申告されたリンクは、両方向で、常に劣化する。

両端を一緒に変える。戻り道を用意して

デュプレックスの修正は、局所的な変更ではなく調整された変更だ。対向側の合意なしに自分の側を固定するのは、動いているリンクを壊す方法であり、CLIがコマンドを受け付けたことは構文が正しかったことしか証明しない。

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

そのようなものを実行する前に、プラットフォームがその組み合わせをサポートしていること、そして同じ時間枠で対向側も変更されることを確認する。デバイスを管理する独立した経路を確保しておく。変更しようとしているポートが、自分の管理セッションを運んでいるポートかもしれないからだ。

多くの現代的なリンクでは、何かを固定するのではなく、両端でオートネゴシエーションを有効のままにするのが正解だ。固定は特定技術の特定の不整合に対する治療であり、一般的な改善ではない。特にギガビット銅線はリンクを立ち上げるのにオートネゴシエーションを必要とするので、10/100の助言はそのまま移せない。

カウンタが良い方向に動いたことを確認する

変更後、両端で動作状態を読み直し、一致していることを確認する。次に、停止を引き起こしたのと同じワークロードを実行し、生涯の合計ではなくカウンタの差分を比較する。一年間積み上がった合計では、直近の十分間に何が起きたかは分からないからだ。

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

同じ負荷で新しいエラーが出ないリンクこそ、欠けていた証拠だ。まだエラーが出るリンク、あるいはカウンタが最初からまったく動かなかったリンクは、デュプレックスの議論を深めるのではなく、次の境界へと導く。どちらの結果も前進であり、設定ファイルが与えられるものより大きい。最初の読み取りが正しく見えたからといって、二度目の読み取りを飛ばしてはいけない。

変更前と変更後の数値を、時刻とともにチケットに書く。その記録が「VPNの調子が良くなった」を、次のエンジニアが土台にできる何かに変える。