tcpdump が 64 KB のパケットを表示する：オフロードとキャプチャ位置

ホスト上でキャプチャすると、MTU が 1420 のインターフェースで 64 KB のパケットが見えることがあり、明らかな結論はトンネルがサイズ制限を無視したというものです。その結論はたいてい誤りです。ホスト上のキャプチャ位置は処理経路の内側にあり、セグメンテーション、集約、チェックサムの処理がまだ行われていないことがあります。パケットのサイズを読む前に、観測者の位置を読んでください。

キャプチャする場所が、見えるものを変える

送信オフロードでは、スタックが大きな単位をネットワークデバイスに渡し、デバイスが後でそれをワイヤサイズの断片に分割します。受信集約は逆に、入力側でセグメントを結合してからホスト側の観測者に見せます。したがってキャプチャは、その地点でのホスト内部の見え方を記録するのであり、リンク上のフレームとは限りません。どちらの仕組みもデバイスと経路に依存します。

ethtool -k eth0 | grep -E 'tso|gso|gro'

サイズを障害とみなす前に、二つ目の地点、できれば独立した受信機やミラーでキャプチャしてください。大きな単位が送信側ホストにだけ現れるなら、ワイヤがそれを運んでいない可能性があります。二つの観測地点は一つのファイルより強く、とくに問いが「実際に何がマシンを出たか」である場合に有効です。

内側と外側のインターフェースを分ける

トンネルは独自のインターフェースを追加し、外側と内側の見え方はカプセル化と処理で異なります。トンネルデバイスでのキャプチャは内側のパケットを示し、物理アダプターでのキャプチャは外側のパケットを示します。サイズ、アドレス、チェックサムの状態は、障害とは無関係な理由で両者の間で異なることがあります。

どのインターフェースが各ファイルを生成したかを記録してください。トンネルデバイスで見えたサイズは内側のパケットを表し、アダプターが最終的に送ったフレームではありません。両者を一つの分析で混ぜると、通常のカプセル化の違いが謎になります。

チェックサムの警告も位置に依存する

送信側のキャプチャでは、ハードウェアが埋める前のチェックサムフィールドが見えることがあり、どの受信機も見ない警告が生じます。これは、遠隔ホストが破損パケットを拒否する証拠とは異なります。方向とキャプチャ位置が、どちらなのかを決めます。

実際の転送が失敗したら、受信機または経路上の別の地点での観測と比較してください。それらがないスクリーンショットは後から解釈できないため、方向、インターフェース、カプセル化層を記録と一緒に残してください。

オフロードは管理されたテストとしてのみ無効にする

オフロードを切ると性能とパケット処理が変わるため、奇妙なサイズ表示への最初の対応ではありません。試す場合は設定を一つだけ変え、先に基準を記録してください。MTU、ファイアウォール規則、クライアントプロファイルも変える実行では、結果をオフロードに帰することはできません。後で設定を戻してください。

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

大きな転送の本当の停止は、経路 MTU とアプリケーションが受け取るフィードバックに関する別の問いです。ホストの集約された単位は下流のサイズ制限を証明も反証もせず、低い CPU 使用率はオフロードを原因と特定しません。

有用な成果は、説明されたキャプチャ位置と再現可能なアプリケーションの観測です。これらを分ければ、MTU の変更は内部バッファーの形ではなく実際の制約を狙えます。