トラブルシューティング方法SD-WAN遅延、ジッター、およびパケット損失
39484
Created On 01/20/23 00:01 AM - Last Modified 12/10/25 01:04 AM
Objective
のPAN-OSfirewallSD-WAN機能モニターSD-WAN仮想インターフェイス (両方の物理インターフェイスを含む)ISPインターフェイスおよび/またはVPNトンネル インターフェイス)を使用SD-WANプローブ. これらのプローブでレイテンシ (ミリ秒)、ジッター (ミリ秒)、またはパケット損失 (%) がしきい値パス品質プロファイルで構成されている場合、そのメトリックは異常としてマークされ、その結果、トラフィックが別の道.
このドキュメントでは、影響を受けるリンクを介してネットワークで検出されたこの遅延、ジッター、またはパケット損失の根本原因を絞り込み、検証し、解決するためのネットワーク トラブルシューティング手順を示します。
ヒント:SD-WAN機能は、リンクの遅延、ジッター、およびパケット損失を測定します。ICMP実際のトラフィック パケットの遅延、ジッター、またはパケット損失ではなく、プローブ パケット
心に留めておくことが重要です。firewall実際のトラフィックで遅延、ジッター、またはパケット損失が発生しているかどうかはチェックしません。 代わりに、firewallかどうかをチェックしますSD-WANプローブ パケットは、そのリンク上で遅延、ジッター、またはパケット損失が発生しています (実際のトラフィックも同様です)。 そうしてfirewallこれらの値が、そのアプリケーションのパス品質プロファイルで構成されたしきい値を上回っているか下回っているかを単純にチェックします。
Environment
- PAN-OS
- SD-WAN
Procedure
- 調べるSD-WANリンクで遅延、ジッター、またはパケット損失が発生しており、そのリンクを通過しているどのアプリケーションが、Web を使用しているために設定されたパス品質プロファイルのしきい値を超えているかを特定します。UIと CLI
Panorama > オブジェクト >SD-WANリンク管理 > パス品質プロファイル
のfirewallを測定しますSD-WANレイテンシー、ジッター、またはパケット損失のプローブ。 これらのプローブ パケットで、そのアプリケーションのパス品質プロファイルで設定されたしきい値を超える遅延、ジッター、またはパケット損失の値が発生した場合SD-WAN Policyトラフィックがヒットしているというルールで、そのアプリケーションは異常としてマークされます。 これらのアプリケーションのステータスと、構成されたしきい値を満たしているか超えているかを表示するには、次の方法を使用します。
Panorama >SD-WAN > モニタリング
CLI コマンド
> show sdwan path-monitor stats vif sdwan.1
===slot1 dp0 health_ver:(High sensitive) 15 (Medium sensitive) 11 (Low sensitive) 2 ===
----------------------------------------------------------------
ethernet1/1 idx: 16 Probing: Enabled Monitor-mode: Aggressive
----------------------------------------------------------------
probe-req-send:30920 State: up
probe-reply-recv:30919
packet loss : real-time crt-use change
per 1000 pkt: 0 0 0
latency jitter pkt_loss health_ver
3000ms average
real time: 16 1 0
current use: 0 0 0 2
10000ms average
real time: 16 1 0
current use: 0 1 0 8
25000ms average
real time: 16 1 0
current use: 0 0 0 2
- パスを特定します (およびISP)遅延、ジッター、またはパケット損失が発生しているトラフィックが宛先に到達するまでにかかる時間
案内する監視 > トラフィック ログと使用フィルターソースを決定するIP住所、目的地IPアドレス、およびそのパスを介したこのアプリケーションのトラフィックの出力インターフェイスを確認し、宛先に到達するためにどのパスとリンクを使用しているかを確認します
- あなたの電話ISPレイテンシー、ジッター、またはパケットロスを解決してもらいます
もしそこにあるならではない以外の他のデバイスISP支店とHubfirewall、その後、この遅延、ジッター、またはパケット損失の問題をお客様のデバイスで追跡してくださいISP. 注:ISPパスに遅延、ジッター、またはパケット損失がないと主張している場合は、文書化された証拠を提供するよう依頼してください。firewallのSD-WAN ICMPプローブ(それを横断するISP/VPNトンネル)それは遅延、ジッター、またはパケット損失が発生しています)。
もしそこにあるならそれはこれらのパス内の他のデバイス (ルーター、スイッチなど)SD-WAN以外のプローブISP、以下の手順に進みます。
もしそこにあるならそれはこれらのパス内の他のデバイス (ルーター、スイッチなど)SD-WAN以外のプローブISP、以下の手順に進みます。
- どのデバイスまたはインターフェイスかを特定します (または、ISP ) トラフィックのパスで遅延が発生している
- サードパーティのトラフィックまたはネットワーク監視ツールを確認して、そのトラフィック フローのパスで遅延が発生しているポイントを特定します。
- このトラフィックのパスでネットワークに導入された構成変更または新しいデバイスが、この遅延、ジッター、またはパケット損失を引き起こした可能性があるかどうかを特定します
- トラフィックのパスにあるデバイスにログインしてチェックし、トラフィックの処理に問題の兆候が見られるかどうかを確認します。 このタイプの速度低下を引き起こす可能性が最も高いと思われるデバイス、またはトラフィックが期待どおりに機能していたために導入された新しいデバイスから始めます。 ヒント: そのベンダーの組み込みのトラフィック診断ツール (パケット トレース、パケット キャプチャ、パフォーマンス ログ、トラフィック ログなど) を使用して、そのトラフィック フローの理由を (ソース別に) 診断します。IPと目的地IP) はそのデバイスをゆっくりと通過しています
- このトラフィック フローのパスに沿って、ネットワーク内のさまざまなポイントでパケット キャプチャを取得します。 ネットワーク内のさまざまなポイントでキャプチャされたパケットのタイムスタンプを並べて比較し、どのキャプチャ ポイント (つまり、デバイス) でパケットの到着または入力/出力に時間がかかっているかを特定します。 遅延を直接引き起こしている単一のデバイスまたはネットワークのリンクに絞り込むことができるまでこれを行うと、そのデバイスでトラブルシューティング、解決、または必要な構成変更を行うことができます。
- で確認してくださいISPトラフィックがたどるパスに遅延、パケット損失、またはジッターがないことの証拠/証拠を提供するように依頼します。
- パス内のデバイスまたはリンクの高負荷、使用率、または輻輳を特定して軽減または排除します
ドロップ、エラー、フラッド、またはパケット処理の問題がないか、トラフィックのパスにある各リンクとデバイスの統計/状態を確認します。 これらのタイプの症状により、パケットがデバイスに出入りするのに通常よりも時間がかかる場合があり、その結果、エンド ユーザーがアプリケーションの機能の遅さを報告する原因になります。
一般的な犯人は次のとおりです。
一般的な犯人は次のとおりです。
- あらゆる種類の DDoS 攻撃/トラフィック フラッドにさらされているデバイス
- そのトラフィック フローをリダイレクトまたはプロキシするデバイス
- そのトラフィックを不必要に厳しく検査するデバイス (復号化デバイス)
- 高リソースの問題が発生しているデバイスCPU、メモリ、バッファなど。
- トラフィック パスに沿ってそのトラフィックのパケットに優先順位を付けるために必要なデバイスで QoS を構成します。
このトラフィック フローのパスにある適切なデバイスで QoS を設定します。 その結果、この特定のトラフィック フローは他のトラフィックよりも優先され、このパス内のデバイスによって可能な限り迅速に処理されます。 デバイスで QoS を構成する方法については、それぞれのデバイスのベンダーのドキュメントを参照してください。
- ルーティングとパスを最適化する
トラフィックが目的地に到達するために、最短、最も直接的、かつ最速のルートとリンクを使用するようにします。 パス上のセキュリティ デバイスによって、トラフィックが不必要にリダイレクトまたはプロキシされていないことを確認します。 リダイレクトまたはプロキシを一時的に停止して、それが問題かどうかを判断します。 トラフィックが意図せずにリダイレクトまたはプロキシされた場合は、そのトラフィック フローでリダイレクトまたはプロキシを行わないように、リダイレクトまたはプロキシを実行しているデバイスを再構成します。 次に、問題が解決したかどうか、またはトラフィック パフォーマンス (遅延、ジッター、またはパケット損失) が改善されたかどうかを確認します。
これの一般的な犯人は次のとおりです。
これの一般的な犯人は次のとおりです。
- 厳重な検査を行うファイアウォール
- 復号化デバイス
- プロキシ デバイス
- 不要/準最適VPNトンネル ルーティング
- (オプション) アプリケーション設定を下げるか、軽量で高速なプロトコル/テクノロジーを使用してそのトラフィックを送信します
例:
- ビデオ品質の制限 (4k から 1080p)
- オーディオ品質コーデックの制限 (からG.722 ~G .711 またはG.729)
- 必要に応じて、使用しているプロトコル/アプリケーションのより軽量なバージョンまたは実装があり、帯域幅要件が低いかどうかを評価します
- パケット損失、遅延、またはジッターの要件が緩いパス品質プロファイルを作成する
あなたまたはあなたのISPアプリケーション/パスを現在のパス品質プロファイルで指定したしきい値レベルまで実行できない場合、パス品質プロファイルのパケット損失、遅延、またはジッターしきい値を編集して低いレベルにする必要がある場合があります