ケーブルを疑う前にパケット損失をどう読むか

長い ping の実行で二パーセントの損失が出ると、対処できる数字のように思えますが、実際にそうであることはまれです。返答がどこで失われたのか、まとめて失われたのか、特定のアプリケーションがその区間をどう経験したのかは分かりません。一分間に均等に散った損失と、一回のやり取りの中で固まって起きた損失は、同じ割合でもまったく違う結果を生みます。

一つを信じるのではなく、プローブが見たもの、インターフェースのカウンターが示したもの、そしてアプリケーションが実際に待っていたものという三つの測定を比べてください。

ping の割合は実際に何を測るのか

エコープローブは、一つのプロトコルの一方向を、一つのパケットサイズで、選んだ任意のレートで試します。大きなアップロードを運ぶトンネルはまったく別のことをしており、小さなプローブを落とすリンクが転送を害しているリンクとは限りません。割合はさらに、一度に失われた十件の返答と一時間離れて失われた十件の返答が同じではないため、最も重要なタイミングの情報を押しつぶします。トンネルのどちら側が何かを落としたのかも分かりません。

プローブの結果は経路についての手がかりとして残してください。そのうえで、それを生んだタイミングと境界を探します。

生涯の合計ではなく、カウンターの差分を比べる

症状が現れた時間帯の前と後に、両端と、管理しているスイッチポートのそれぞれで、時刻付きの読み取りを行います。何か月もかけて積み上がったゼロでない合計はこの障害ではなく履歴を表すため、エラー、破棄、リンク状態の変化とあわせて通信量を記録してください。停止中に三だけ動いたカウンターは、三千を示して一度も変わらなかったカウンターとは別の観察です。

ip -s link show dev eth0
nstat -az TcpRetransSegs TcpExtTCPTimeouts
date -u +%Y-%m-%dT%H:%M:%SZ

受信エラーで破棄されたパケットと、それ以外の理由で破棄されたパケットは別のカウンターにあり、この区別が次の手順を変えます。エラーのカウンターは物理層やドライバー層を指し、キューの圧迫やポリシーによる破棄はその上のどこかを指します。上りリンクの受信エラー増加とトンネルのパケットカウンターは置き換えられないため、方向とインターフェース名も残してください。

ドライバーが詳細な物理カウンターを公開している場合は、そのアダプターの資料に沿って読んでください。二つのベンダーで「drop」という名前のすべての項目に一つの意味を当てはめることが、普通の会計上の癖をハードウェアの診断に変える道です。

失われたセグメントが長い待ち時間になるまで

アプリケーションは、セグメントを失ってから一往復よりはるかに長く待つことがあります。TCP は往復時間を見積もり、その見積もりから再送タイマーを計算し、再送も失敗すると待ち時間を延ばすため、まずい瞬間に失われた一つのセグメントが要求を目立つ間隔で止めえます。この仕組みは RFC 6298 で規定されており、取るに足らないように見える損失率がなお体感される理由を説明します。

ただし、すべての停止が再送タイムアウトではありません。同じ待ちは、名前解決、遅いサーバー、失敗後に自分の要求を再試行するアプリケーションからも来ます。失敗した処理を転送の観察とトンネル自身のセッションイベントにそろえて、それらを切り分けてください。再接続を伴わないデータ経路の中断は、新たなハンドシェイクと資格情報の交換とは別の出来事です。

キャプチャが許されている場所では、範囲を狭く保ってください。必要なのは、期待したパケットや確認応答が特定の境界で止まるかどうかであり、混雑したトレースのどこかに再送があるという事実ではありません。

他を動かさずに一つの境界を変える

証拠がローカルのリンクを指しているなら、管理された比較として承認済みのケーブルやポートに交換し、ほかはそのままにします。端点、アプリケーション、作業量を比較できる状態に保ち、試行ごとにちょうど一つの境界だけを変えます。有線のノート PC と無線のものを比べながら出口やプロトコルも変えると、原因に帰せられることは何も分かりません。

きれいなローカルカウンターは経路の残りを保証しません。見える範囲を区切るだけで、正直な報告はどの境界を観察し、どれを観察しなかったかを述べます。最後に欲しいのは、一つの介入で一つの観察が変わったという記述であり、悪いケーブルを普遍的な規則に高めた逸話ではありません。