MTUの不一致、それともパケットロス？大容量転送が停止する原因を特定する

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

MTU Mismatch or Packet Loss? Determining Why Large Transfers Stall - Zima Store Online

do-not-fragment サイズテストとパケットキャプチャを使用して、再現可能なサイズ境界を、ランダムな損失や輻輳から切り分けます。

小さな ping とウェブリクエストは機能する一方で、大きな SMB、バックアップ、または VPN 転送が一時停止またはリセットされる場合、この判断が重要になります。競合する状態は、パス MTU ブラックホールまたは MSS の問題と、通常の損失、輻輳、または不安定なリンクです。保存済みの設定と使い捨てデータから始め、一度に1つの分岐だけを観察し、データ損失、権限、または可用性のリスクが拡大する場合は停止します。

パス MTU ブラックホールまたは MSS の問題を、通常の損失、輻輳、または不安定なリンクから切り分ける

変更する前に、ソフトウェアとファームウェアのバージョン、デバイスの識別情報、マウントまたはネットワークパス、空き容量、権限、観測された症状を記録します。ベースラインには、小さな ping とウェブリクエストは機能する一方で、大きな SMB、バックアップ、または VPN 転送が一時停止またはリセットされる状態を再現するのに十分な詳細を残す必要があります。

最初の候補はパス MTU ブラックホールまたは MSS の問題です。2つ目は通常の損失、輻輳、または不安定なリンクです。現在のパケット化レイヤー PMTU ディスカバリーは、テストで使用する仕組みまたはコマンドの境界を定義しますが、このホームサーバー自体の観測に取って代わるものではありません。

判別テストを実行する前に、受け入れ条件と停止条件を書き出します。合格とは、一方の分岐が予測する証拠が変化し、関係のないサービスは変化しないことです。不合格の場合は、推測に基づく修正を連鎖させるのではなく、システムを保存済みの状態に戻す必要があります。

制御された判別テストを1つ実行する

次の判別テストを使用します。フラグメント化しないサイズを増やしながらプローブし、MSS を制御して iperf を実行し、ICMP の too-big メッセージと再送をキャプチャします。変更した変数に結果を帰属できるよう、ワークロード、クライアント、パス、ファイルセット、タイミングを一定に保ちます。

パス MTU ディスカバリーを使用して、分岐を実際に切り分けられるフィールドを選び、そのタイムスタンプ、終了ステータス、エラーテキスト、デバイスまたはスナップショットの識別情報、レイテンシ、転送バイト数、権限、復旧状態をキャプチャします。識別情報、耐久性、またはアプリケーション状態がテスト対象の主張である場合、コマンドが正常終了しただけでは不十分です。

そのイベントが元の条件の一部である場合は、再起動、再接続、再マウント、またはキャッシュを空にした後に、もう一度テストを繰り返します。最初の実行が破壊的である場合、または環境を復元できない場合は、停止して、代わりに使い捨てコピーで再現します。

ping -M do -s 1472 target
tracepath target
iperf3 -c target --set-mss 1360

証拠がどの分岐を支持するかを解釈する

合格: 障害が安定したパケットサイズで始まり、MTU または MSS によって変化する、または損失がサイズに依存せずバースト状に発生する。結論が普遍的な主張にならず、条件付きのまま維持されるよう、合格した正確なバージョン、識別情報、ワークロードを記録します。

不合格: 異なるルートまたは VPN オーバーヘッドによってしきい値が異なるため、各パスを個別にマッピングします。ネットワーク、メモリ、権限、またはソースの一貫性が両方に影響する可能性がある場合、不合格だけで反対の分岐が証明されるわけではありません。エスカレーションする前に、共通する依存関係を切り分けます。

例外または曖昧な結果: 以降のジャンボフレームテストの前に、インターフェースを1500に戻し、ICMP の処理を復元します。復元可能なコピーが存在するまで、ログを保持し、repair、prune、destroy、repartition、または再帰的な所有権変更コマンドを実行しないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

一致するアクションを適用し、元の障害を再現する

観測された分岐に一致するアクションを適用し、その後、縮小した代替テストではなく元の条件を繰り返します。障害が安定したパケットサイズで始まり、MTU または MSS によって変化する、または損失がサイズに依存せずバースト状に発生する状態が、2サイクル、または関連する再起動、スリープ、割り込み、負荷遷移にわたって確認できる場合にのみ、判断は有効です。

エンドツーエンドの MTU 設定を使用して、最も近い依存ワークフローを確認しますが、元のトリガーは変更しないでください。関係のないデータセット、共有、コンテナ、ユーザー、リカバリポイントは、以前のアクセス状態とタイミングを維持する必要があります。

停止境界は明確です。異なるルートまたは VPN オーバーヘッドによってしきい値が異なる場合は、各パスを個別にマッピングし、最後に検証した設定へ戻し、証拠を保持します。分岐が再現可能な場合にのみ、より深いプラットフォームまたはハードウェアテストへエスカレーションします。

対象の結果が得られたら、トラフィックパスを分離する設定と比較し、修正によって隣接するサービスにリスクが移らないことを確認します。対象テストが成功しても、新たなバックアップ、識別情報、タイムアウト、または可用性の障害が発生した場合、その変更は失敗です。

FAQ

大容量転送の停止を診断する際、残る検索内容は通常、MTU ブラックホール中に小さな ping が成功する理由、Wi-Fi の損失が MTU の問題のように見えるかどうか、MSS クランピングを恒久的な修正にすべきかどうかです。以下の回答では、これらのエッジケースを主要な判断から分離します。

受け入れ境界は変わりません。障害が安定したパケットサイズで始まり、MTU または MSS によって変化する、または損失がサイズに依存せずバースト状に発生することです。後続の条件によってファイルシステム、識別情報、ネットワークパス、またはアプリケーションのバージョンが変わった場合は、その変更の影響を受ける判別テストだけを繰り返します。

異なるルートまたは VPN オーバーヘッドによってしきい値が異なる場合は、実験を広げるのをやめ、各パスを個別にマッピングします。その時点で、以降のジャンボフレームテストの前にインターフェースを1500に戻し、ICMP の処理を復元します。プラットフォーム、ストレージ、またはハードウェアの担当者へエスカレーションする前に、証拠を保持します。

MTU ブラックホール中に小さな ping が成功するのはなぜですか？

制約となる MTU 未満に収まり、欠落している too-big フィードバックを必要としないためです。

Wi-Fi の損失が MTU の問題のように見えることはありますか？

あります。パケットキャプチャとサイズしきい値の反復により、ランダムな再送と決定論的な境界を切り分けられます。

MSS クランピングを恒久的な修正にすべきですか？

ルーティングまたはトンネル設計で必要な場合に限ります。まず、可能であれば MTU と ICMP の処理を正しく設定してください。

同じワークロードによって、証拠がパス MTU ブラックホールまたは MSS の問題、あるいは通常の損失、輻輳、または不安定なリンクのいずれかに沿って変化し、一致するアクションによって新たな障害を生じさせずに元の症状が解消されたとき、診断は完了です。どちらの分岐も再現可能な状態を維持できない場合は、ログと保存済みの状態をそのまま保持してください。不確実性はエスカレーションの理由であり、さらに修正を積み重ねる理由ではありません。