IP SLA ICMP ジッター動作では、次の統計情報測定をサポートしています。
IP SLA ICMP ジッターは、2 つの ICMP タイム スタンプ メッセージ、ICMP タイムスタンプ リクエスト(タイプ 13)および ICMP タイムスタンプ応答(タイプ 14)を使用して、ジッター、パケット損失、および遅延を提供します。IP
SLA ICMP ジッター動作は、ICMP エコーは ICMP エコー要求および応答(ping)を使用するという点で、IP SLA ICMP エコー動作と異なります。RFC 792 に完全に準拠しているデバイス、インターネット制御メッセージ プロトコルは、宛先で IP SLA Responder を必要とすることなく、タイム スタンプ メッセージに応答できる必要があります。
(注) |
Cisco IOS デバイスは、RFC 792 のタイムスタンプ要求および応答をサポートしていますが、Cisco IOS-XR デバイスはこれをサポートしていません。
|
ICMP API は、インターフェイスから設定可能な数の要求メッセージ パケットを送信します。要求で受信されたデータ(タイム スタンプ)は、別のタイム スタンプとともに返信メッセージ パケットで返されます。すべてのパケットには、発信(送信)タイムスタンプ、受信タイムスタンプ、および送信(返信)タイプスタンプの
3 つのタイム スタンプが含まれています。
IP SLA は、それらのタイム スタンプを利用して、2 つの連続するパケットの到着間遅延と出発間遅延の差に基づいて、各方向のジッターを計算します。差が正であれば、正のジッターでカウントされます。負の値は、負のジッターでカウントされます。パスは異なるもの(非対称)にできるので、送信元から宛先へ、および宛先から送信元へのデータ
パスの個別の測定を使用して、ネットワークの問題を識別できます。
各 ICMP パケットには、送信者のシーケンスから受信されたパケット数をカウントするために使用されるシーケンス番号がヘッダー内に含まれています。シーケンス番号と受信タイムスタンプはともに、送信元から宛先へのパスでアウトオブシーケンス パケットを計算するために使用できます。パケットの受信タイム
スタンプが次のパケットのタイム スタンプよりも大きい場合は、最初のパケットが送信元から宛先へのパスで不適切に配信されました。宛先から送信元へのパスには、同じ方法を適用できます。送信元から宛先へのパスでパケットに問題がある場合は、宛先から送信元へのパスでも問題がある場合を除き、送信者に正しく返されないことに注意してください。
内部または予期しないエラーが原因でパケットを送信できない場合、またはパケットを含む timerwheel スロットが見つからないため、スキップされたパケットとしてカウントされます。このメトリックは、統計情報が送信されたパケットだけで測定されるため、非常に重要です。
すべてのタイムアウトになったパケットは、パケット損失に考慮されます。連続的なパケット損失は、連続してドロップされたパケットの数をカウントおよび追加することで計算されます。連続的なパケット損失は、最小の連続的なパケット ドロップおよび最大の連続的なパケット
ドロップとして報告されます。
他のすべての統計情報は、UDP ジッター動作と同じロジックを使用して計算されます。