Cisco IOS IP SLA

Cisco IOS IP SLA はネットワークにデータを送信し、複数のネットワーク間あるいは複数のネットワーク パス内のパフォーマンスを測定します。ネットワーク データおよび IP サービスをシミュレーションし、ネットワーク パフォーマンス情報をリアル タイムで収集します。Cisco IOS IP SLA は、Cisco IOS デバイス間のトラフィックまたは Cisco IOS デバイスからネットワーク アプリケーション サーバのようなリモート IP デバイスへのトラフィックを生成し、分析します。さまざまな Cisco IOS IP SLA 動作で評価を実行し、トラブルシューティング、問題分析、ネットワーク トポロジの設計に使用します。

Cisco IOS IP SLA 動作に応じてシスコ デバイスのネットワーク パフォーマンス統計情報がモニタリングされ、コマンドライン インターフェイス（CLI）MIB および簡易ネットワーク管理プロトコル（SNMP）MIB に格納されます。IP SLA パケットには設定可能な IP レイヤおよびアプリケーション層のオプションがあります。たとえば、発信元および宛先 IP アドレス、ユーザ データグラム プロトコル（UDP）/TCP ポート番号、タイプ オブ サービス（ToS）バイト（DiffServ コード ポイント（DSCP）および IP プレフィックス ビットを含む）、VPN ルーティング/転送インスタンス（VRF）、URL Web アドレスなどが設定できます。

Cisco IP SLA はレイヤ 2 転送に依存していないので、異なるネットワーク間にエンドツーエンド動作を設定してエンド ユーザが経験しそうなメトリックを最大限に反映させることができます。IP SLA は、次のような一意のパフォーマンス メトリックのサブセットを収集します。

■遅延（往復および一方向）

■ジッター（方向性あり）

■パケット損失（方向性あり）

■パケット シーケンス（パケット順序）

■パス（ホップ単位）

■接続（方向性あり）

■サーバーまたは Web サイトのダウンロード時間

Cisco IP SLA は SNMP によるアクセスが可能なので、Cisco Works Internetwork Performance Monitor（IPM）やサードパーティ製パフォーマンス管理製品などのパフォーマンス モニタリング（PM）アプリケーションでも使用できます。IP SLA を使用すると次のような利点があります。

■SLA モニタリング、評価、検証。

■ネットワーク パフォーマンス モニタリング。

–ネットワーク内のジッタ、遅延、パケット損失が測定できる。

–連続的で信頼性のある確実な評価ができる。

■IP サービス ネットワーク ヘルス アセスメントにより、既存の QoS が新しい IP サービスに適していることを確認できる。

■端末間のネットワーク アベイラビリティをモニタリングして、ネットワーク リソースをあらかじめ検証し接続をテストできる（たとえば、ビジネス上の重要なデータを保存する NFS サーバーのネットワーク アベイラビリティをリモート サイトから確認できる）。

■信頼性の高い評価を連続的に行ってネットワーク動作のトラブルシューティングを行うので、問題をすぐに特定しトラブルシューティングにかかる時間を短縮できる。

■マルチプロトコル ラベル スイッチング（MPLS）パフォーマンス モニタリングとネットワークの検証を行う（MPLS をサポートするスイッチの場合）。

Cisco IOS IP SLA によるネットワーク パフォーマンスの測定

IP SLA を使用して、プローブを物理的に配置せずに、コア、分散、エッジといったネットワーク内の任意のエリア間のパフォーマンスを監視することができます。2 つのネットワーク デバイス間のネットワーク パフォーマンスは、生成トラフィックで測定します。図 108 に、送信元デバイスが宛先デバイスに生成パケットを送信する際に IP SLA が開始される手順を示します。宛先デバイスがパケットを受信すると、IP SLA 動作の種類によって、送信元のタイム スタンプ情報に応じてパフォーマンス メトリックを算出します。IP SLA 動作は、特定のプロトコル（UDP など）を使用してネットワークの送信元から宛先へのネットワーク測定を行います。

図 108 Cisco IOS IP SLA 動作

IP SLA ネットワーク パフォーマンス測定を実施する手順は次のとおりです。

–必要であれば、IP SLA Responder を有効にします。

–必要な IP SLA 動作タイプを設定します。

–指定された動作タイプのオプションを設定します。

–必要であれば、しきい値条件を設定します。

–動作の実行スケジュールを指定し、しばらく動作を実行して統計情報を収集します。

–Cisco IOS CLI を使用するかネットワーク管理システム（NMS）と SNMP を併用して、動作の結果を表示し確認します。

IP SLA Responder と IP SLA コントロール プロトコル

IP SLA Responder は宛先シスコ デバイスに組み込まれたコンポーネントで、システムが IP SLA 要求パケットを予想して応答します。Responder は専用プローブなしで正確な測定を行います。Responder は、受信および応答するポートが通知されるメカニズムを Cisco IOS IP SLA コントロール プロトコルを通じて実現します。Cisco IOS デバイスだけが宛先 IP SLA Responder の送信元になります。

図 108 に、IP ネットワーク内での Cisco IOS IP SLA Responder の配置場所を示します。Responder は、IP SLA 動作から送信されたコントロール プロトコル メッセージを指定されたポートで受信します。コントロール メッセージを受信したら、指定された UDP または TCP ポートを指定された時間だけ有効にします。この間に、レスポンダは要求を受け付け、応答します。Responder は、IP SLA パケットに応答した後または指定の時間が経過したら ポートをディセーブルにします。セキュリティの向上のために、コントロール メッセージでは MD5 認証が利用できます。

すべての IP SLA 動作に対して宛先デバイスの Responder をイネーブルにする必要はありません。たとえば、宛先ルータが提供しているサービス（Telnet や HTTP など）は Responder では必要ありません。他社製のデバイスに IP SLA Responder を設定することはできません。また、Cisco IOS IP SLA はこれらのデバイス固有のサービスに対してだけ動作パケットを送信できます。

IP SLA の応答時間の計算

スイッチとルータは、他のハイ プライオリティ プロセスがあるために、着信パケットの処理に数十ミリ秒かかることがあります。この遅延により応答時間が影響を受けます。テストパケットの応答が処理待ちのキューに入っていることもあるからです。この場合、応答時間は正しいネットワーク遅延を反映しません。IP SLA はソース デバイスとターゲット デバイス（Responder が使用されている場合）の処理遅延を最小化し、正しいラウンドトリップ時間（RTT）を識別します。IP SLA テスト パケットは、タイム スタンプによって処理遅延を最小化します。

IP SLA Responder がイネーブルの場合、パケットが割り込みレベルでインターフェイスに着信した際およびパケットが出て行く際にターゲット デバイスでタイム スタンプを付け、処理時間は含めません。タイム スタンプはサブミリ秒単位で構成されます。

図 109 に、Responder の動作を示します。RTT を算出するためのタイム スタンプが 4 つ付けられます。ターゲット ルータでレスポンダ機能がイネーブルの場合、タイム スタンプ 3（TS3）からタイム スタンプ 2（TS2）を引いてテスト パケットの処理にかかった時間を求め、デルタ（Δ）で表します。次に全体の RTT からこのデルタの値を引きます。IP SLA により、この方法はソース ルータにも適用されます。その場合、着信タイム スタンプ 4（TS4）が割り込みレベルで付けられ、より正確な結果を得ることができます。

図 109 Cisco IOS IP SLA Responder タイム スタンプ

この他にも、ターゲット デバイスに 2 つのタイム スタンプがあれば一方向遅延、ジッター、方向性を持つパケット損失がトラッキングできるという利点があります。大半のネットワーク動作は非同期なので、このような統計情報があるのは問題です。ただし一方向遅延測定を取り込むには、ソース ルータとターゲット ルータの両方にネットワーク タイム プロトコル（NTP）を設定し、両方のルータを同じくロック ソースに同期させる必要があります。一方向ジッター測定にはクロック同期は不要です。

IP SLA 動作のスケジューリング

IP SLA 動作を設定する場合、統計情報の取り込みとエラー情報の収集から開始するように動作のスケジューリングをします。スケジューリングは、すぐに動作を開始する、または特定の月、日、時刻に開始するように設定できます。pending オプションを使用して、後で動作を開始するように設定することもできます。pending オプションは動作の内部状態に関するもので、SNMP で表示できます。トリガーを待機する反応（しきい値）動作の場合も pending オプションを使用します。1 度に 1 つの IP SLA 動作をスケジューリングしたり、グループの動作をスケジューリングすることもできます。

Cisco IOS CLI または CISCO RTTMON-MIB で 1 つのコマンドを使用して、IP サービス イメージを稼働する複数の IP SLA 動作をスケジューリングできます。等間隔で動作を実行するようにスケジューリングすると、IP SLA モニタリング トラフィックの数を制御できます。IP SLA 動作をこのように分散させると CPU 使用率を最小限にとどめ、ネットワーク スケーラビリティを向上させることができます。

IP SLA 動作のしきい値のモニタリング

サービス レベル契約モニタリングを正しくサポートするには、違反が発生した場合にすぐに通知されるメカニズムにする必要があります。IP SLA は SNMP トラップを送信して、次のような場合にイベントをトリガーします。

■接続の損失

■タイムアウト

■RTT しきい値

■平均ジッターしきい値

■一方向パケット損失

■一方向ジッター

■一方向平均オピニオン評点（MOS）

■一方向遅延

IP SLA しきい値違反が発生した場合も、あとで分析するために別の IP SLA 動作がトリガーされます。たとえば、回数を増やしたり、ICMP パス エコーや ICMP パス ジッタ動作を開始してトラブルシューティングを行うことができます。

しきい値タイプとレベル設定の決定は複雑で、ネットワークで使用する IP サービス タイプによって異なります。

UDP ジッター動作を使用した IP サービス レベル

ジッターはパケット間の遅延がばらつくことを指します。発信元から宛先に向かって複数のパケットを 10 ミリ秒遅れで送信した場合、ネットワークが正常に動作していれば宛先でも 10 ミリ秒遅れで受信します。しかし、ネットワーク内に遅延がある場合（キューの発生や別のルータ経由で到着するなど）、パケットの到着遅延が 10 ミリ秒を上回ったり、下回ったりします。正のジッタ値は、パケットの到着が 10 ミリ秒を超えていることを意味します。パケットの到着が 12 ミリ秒の場合のジッター値は +2 ミリ秒（正の値）です。8 ミリ秒で到着する場合は、2 ミリ秒（負の値）です。遅延による影響を受けやすいネットワークの場合、正のジッタ値は望ましくありません。ジッタ値 0 が理想的です。

ジッタのモニタリング以外にも、IP SLA UDP ジッタ動作を多目的データ収集動作に使用できます。パケット IP SLA は搬送パケットを生成し、送信元ターゲットと動作ターゲット間でシーケンス情報の送受信とタイム スタンプの送受信を行います。以上の点に基づき、UDP ジッタ動作は次のデータを測定します。

■方向別ジッター（送信元から宛先へ、宛先から送信元へ）

■方向別パケット損失

■方向別遅延（一方向遅延）

■ラウンドトリップ遅延（平均 RTT）

データを送受信するパスが異なる場合もあるので（非同期）、方向別データを使用すればネットワークで発生している輻輳や他の問題の場所を簡単に突き止めることができます。

UDP ジッター動作では合成（シミュレーション）UDP トラフィックを生成し、送信元ルータからターゲット ルータに多数の UDP パケットを送信します。その際の各パケットのサイズ、パケット同士の間隔、送信間隔は決められています。デフォルトでは、10 バイトのペイロード サイズのパケット フレームを 10 ミリ秒で 10 個生成し、60 秒間隔で送信します。これらのパラメータは、提供する IP サービスを最適にシミュレートするように設定できます。

一方向遅延を正確に測定する場合、NTP などによる送信元デバイスとターゲット デバイス間のクロック同期が必要です。一方向ジッタおよびパケット損失を測定する場合は、クロック同期は不要です。送信元デバイスとターゲット デバイスのクロックが同期されていない場合、一方向ジッタおよびパケット損失データは戻されますが、UDP ジッタ動作による一方向遅延測定の値は 0 で戻ります。

注： 送信元デバイスに UDP ジッター動作を設定する前に、ターゲットデバイス（動作ターゲット）の IP SLA 応答側をイネーブルにしておく必要があります。

ICMP エコー動作を使用した IP サービス レベル

ICMP エコー動作は、シスコ デバイスと IP を使用する任意のデバイスとの間でエンドツーエンド応答時間を測定します。応答時間は、ICMP エコー要求メッセージを宛先に送信して ICMP エコー応答を受信するまでの時間を測定して算出します。大多数のカスタマーが IP SLA ICMP ベース動作、社内 ping テスト、ping ベース専用プローブを使用して、送信元 IP SLA デバイスと宛先 IP デバイス間の応答時間を測定しています。IP SLA ICMP エコー動作は、ICMP ping テストと同じ仕様に準拠しており、どちらの方法でも同じ応答時間が得られます。

注： この動作では、IP SLA 応答側をイネーブルにしておく必要はありません。

IP SLA Responder の設定

はじめる前に

IP SLA Responder が機能するためには、Catalyst 3750 スイッチまたは Catalyst 3560 スイッチのような、IP サービス イメージを実行して IP SLA をすべてサポートしている送信元デバイスを設定する必要があります。送信元デバイスの設定情報については、マニュアルを参照してください。

UDP ジッター動作の設定

はじめる前に

送信元デバイスに UDP ジッター動作を設定する前に、ターゲット デバイス（動作ターゲット）の IP SLA 応答側を有効にしておく必要があります。

ICMP エコー動作を使用した IP サービス レベルの分析

注： この動作では、IP SLA 応答側をイネーブルにしておく必要はありません。

ICMP エコー IP SLA 動作の設定：例

次に、ICMP エコー IP SLA 動作の設定例を示します。

show ip sla コマンドの出力：例

コマンド出力例は次のとおりです。

UDP ジッター IP SLA 動作の Responder の設定：例

次に、デバイスを UDP ジッタ IP SLA 動作の Responder に設定する例を示します。UDP ジッタ IP SLA 動作については次の項で説明します。

UDP ジッター IP SLA 動作の設定：例

次に、UDP ジッタ IP SLA 動作の設定例を示します。

関連ドキュメント

標準

MIB

RFC

シスコのテクニカル サポート