Cisco Prime Unified Operations Manager ユーザ ガイド ソフトウェア リリース 9.0 Cisco Unified Communications Management Suite
ノードツーノード テストの使用方法
ノードツーノード テストの使用方法
発行日;2013/03/12 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 13MB) | フィードバック

目次

ノードツーノード テストの使用方法

ノードツーノード テストの使用

使用する前に:Cisco IOS および IP SLA の必要なバージョン

単一のノードツーノード テストの作成

VoIP 用 UDP ジッター

Ping Echo

Ping Path Echo

UDP Echo

Gatekeeper Registration Delay

リアルタイム転送プロトコル

複数のテストのインポート

ノードツーノード テストのインポート ファイルの作成

ノードツーノード テストのインポート ファイルの形式

テストの編集

テストの削除

ノードツーノード テストのイベント

テスト操作の管理

テストのトレンドの表示

テスト情報の表示

テストの詳細の印刷

テストの詳細のエクスポート

テストのステータスの確認

テスト データの使用

ノードツーノード テスト データの格納

ノードツーノード テスト データの保持

別のサーバへのテスト データのコピー

ノードツーノード データの形式

ノードツーノード テストの使用方法

ノードツーノード テストでは、エンドツーエンドとホップバイホップ ベースの両方で、マルチプロトコル ネットワークの応答時間とアベイラビリティを監視します。このデータの収集後は、Prime UOMのグラフ化機能を使用して、ネットワーク パフォーマンス メトリックの変化を検査することができます。

ネットワーク パフォーマンス データをリアルタイムに選択、表示、図化することができます。「テストのトレンドの表示」を参照してください。また、特定のしきい値を超えたときにイベントをトリガーするようにノードツーノード テストを設定することもできます。これらのイベントは、モニタリング ダッシュボードの画面に表示されます。

この項では、Cisco Prime Unified Operations Manager(Prime UOM)でノードツーノード テストを作成、編集、削除、および分析する方法を説明します。

この項では、次のトピックについて取り上げます。

「ノードツーノード テストの使用」

「テスト操作の管理」

「テスト データの使用」

ノードツーノード テストの使用

ノードツーノード テストは、1 つずつ作成するか、ファイルをインポートして一度に複数作成することができます。


) Prime UOM をアンインストールする必要がある場合は、その前に必ずアプリケーションからすべてのノードツーノード テストを削除してください。これらのテストを削除しないと、ルータでテストの実行が続行されます。削除する手順については、「テストの削除」を参照してください。


この項では、次のトピックについて取り上げます。

「使用する前に:Cisco IOS および IP SLA の必要なバージョン」

「単一のノードツーノード テストの作成」

「複数のテストのインポート」

「テストの編集」

「テストの削除」

使用する前に:Cisco IOS および IP SLA の必要なバージョン

ノードツーノード テストは、Cisco IOS IP SLA テクノロジーに依存しています。 表 14-1 に、各タイプのノードツーノード テストを正常に設定および実行するために必要な IP SLA と Cisco IOS のバージョンを示します。

 

表 14-1 各ノードツーノード テストと IP SLA の対応

テスト
必要なバージョン
IP SLA
Cisco IOS

Ping Echo

2.1.0 以降

12.0(5)T、12.1(1)、およびそれ以降

Ping Path Echo

UDP Echo

UDP Jitter for VoIP

ICPIF/MOS 値を使用しません。

UDP Jitter for VoIP

ICPIF/MOS 値を使用します。

2.2.0 以降

12.3(4)T 以降

Gatekeeper Registration Delay

12.3(14)T 以降

リアルタイム転送プロトコル

2.20 以降

タイプ - ds0-group の音声ポート。

タイプ C5510 または C549 の DSP。

12.4(19.12)T 以上の IOS バージョン

ノードツーノード テストがサポートされるデバイス ファミリを確認するには、Cisco.com の『 Supported Devices Table for Cisco Unified Prime UOM 』を参照してください。

単一のノードツーノード テストの作成

テストを作成する前に、Prime UOM で発信元デバイスを監視する必要があります。詳細については、「Device Management の使用方法」を参照してください。


) Connectivity Details View からノードツーノード テストを設定することもできます(「ノードツーノード テスト グラフの設定」を参照してください)。



ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

必要なソフトウェア ライセンスがない場合は、ノードツーノード テストを使用できません。Prime UOM の [Diagnostic] タブは表示されません。

ステップ 2 [Create] をクリックします。

ノードツーノード テストの作成に必要な情報は、テストの操作タイプごとに異なります。詳細については、次の説明を参照してください。

「VoIP 用 UDP ジッター」:模擬的な UDP トラフィックを生成することにより、パケット損失、ラウンドトリップ遅延、および IP ネットワークの遅延の変動(ジッター)を測定します。

「Ping Echo」:発信元デバイスと任意の IP 対応デバイス間のエンドツーエンドの応答時間を測定します。

「Ping Path Echo」:traceroute を使用してパスを検出し、発信元デバイスとパス内の各ホップの間の応答時間を測定することにより、発信元デバイスとネットワーク上の任意の IP デバイス間のホップバイホップの応答時間を測定します。

「UDP Echo」:発信元デバイスと任意の IP 対応デバイス間の UDP 応答時間を測定します。

「Gatekeeper Registration Delay」:ゲートウェイをゲートキーパーに登録するために必要な時間を測定します。

Gatekeeper Registration Delay テストを実行する場合は、発信元ゲートウェイに SIP または H323 が設定されている必要があります。

「リアルタイム転送プロトコル」:DSP ソフトウェアと統合することによって、DSP から DSP への音声品質メトリックを測定します。この操作には、発信元ゲートウェイから宛先へのコール テストの実行、実際の RTP パケットの送信、DSP からの統計情報の収集が含まれます。

リアルタイム転送プロトコル テストの実行については、発信元の DSP モジュール タイプが C5510 または C549 で、音声ポートが ds0-group に設定されている必要があります。


 

VoIP 用 UDP ジッター

このテストでは、UDP プロトコルを使用して、遅延、一方向のジッター、およびパケットのドロップを測定します。ジッターとは、パケット間の遅延です。発信元デバイスは、指定されたパケット間遅延で宛先デバイスに一定数のパケットを送信します。

宛先(IP SLA Responder)は、パケットにタイムスタンプを記録し、パケットを返送します。このデータを使用して、一方向のプラスおよびマイナスのジッター(発信元から宛先およびその逆方向)、パケット損失(発信元から宛先およびその逆方向)、およびラウンドトリップ遅延を調べます。

プラスのジッターは、パケットの一方向の遅延が直前のパケット遅延より長い場合に発生します。マイナスのジッターは、パケットの一方向の遅延が直前のパケット遅延より短い場合に発生します。この連続した数値がばらばらに乱れている場合、テストはエラーを示しています。

遅延、一方向のジッター、およびパケットのドロップを測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[UDP Jitter for VoIP] を選択します。

ステップ 4 [Source] ペインで、次の手順に従います。

デバイス セレクタを使用して発信元デバイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

発信元インターフェイス設定を選択します。[Default] のままにするか、新しい設定を入力できます。

ステップ 5 [Destination] ペインで、次の手順に従います。

デバイス セレクタを使用して宛先デバイスを選択します。

宛先デバイスの UDP ポートを入力します(デフォルト値は 16400)。これが、発信元デバイスがパケットを送信する宛先デバイスのポートになります。

発信元デバイスと宛先デバイスを切り替える場合は、[Swap Source and Destination] ボタンをクリックします。

ステップ 6 [Parameters] ペインで次のパラメータを設定できます。

 

表 14-2 VoIP 用 UDP ジッター テスト パラメータ

パラメータ
デフォルト値
使用可能な値
説明

Codec Type

--

G.711ulaw

G.711alaw

G.729

パケット間隔および要求ペイロードの決定に使用されます。

Call Duration

8

1 ~ 59 秒

コールの時間。

Voice Quality Expectation

Land line

Land line

Wireless campus

Wireless on the move

Multi-hop

Mean Opinion Score(MOS)および Calculated Planning Impairment Factor(ICPIF)の Access Advantage ファクタに対応します。

IP QoS

IP Precedence

IP Precedence

DSCP

IP SLA パケットの Quality of Service ポリシーを定義します。

5

IP Precedence:0(なし)~ 7(高)

DSCP:0(なし)~ 8(CS1)、9、10(AF11)

これは、タイプ オブ サービス(TOS)に変換されてデバイスに設定されます。

ステップ 7 [Threshold] ペインで、次の設定を変更できます。

 

表 14-3 VoIP 用 UDP ジッターしきい値設定

パラメータ
デフォルト値
使用可能な値
説明

Source to Destination

3(パケット損失)
40 msec(ジッター)

正の整数1

パケット損失およびジッターのしきい値設定

Destination to Source

3(パケット損失)
40 msec(ジッター)

1

パケット損失およびジッターのしきい値設定

Average Latency

300 m/sec

1

遅延のしきい値設定

Node-to-Node Quality

Fair

Excellent、Good、Fair、または Poor

テストの品質のしきい値設定。これらの値は MOS スコアに関連付けられます。値と同等の MOS は次のとおりです。

Excellent:5(500)

Good:4(400-499)

Fair:3(300-399)

Poor:2(200-299)

Bad:1(100-199)

1.正の整数は 32 ビットにする必要があります。

ステップ 8 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [schedule] オプション ボタンを選択します。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 9 [OK] をクリックします。


 

トラブルシューティングに関する注意:発信元デバイスの選択

IP SLA 対応デバイスを追加して間もない場合に、[Node-to-Node Test Configuration] ダイアログボックスの [Source] ペインにあるセレクタの [IP SLA Devices] グループにそのデバイスが表示されないときには、デバイス グループのメンバーシップをリフレッシュします。

発信元デバイスを選択するには、次の手順を実行します。


ステップ 1 [Devices] > [Device Groups] を選択します。

[Group Administration and Configuration] ページが表示されます。

ステップ 2 Group Selector で、OM@< server > グループを選択します。<server> は使用しているサーバの名前です。

ステップ 3 [Refresh] ボタンをクリックします。

確認ダイアログボックスが表示されます。

ステップ 4 [Yes] をクリックします。

経過表示バーが表示され、正常終了メッセージが表示されます。

ステップ 5 [OK] をクリックします。

[Node-to-Node Test Configuration] ダイアログボックスが開いている場合は、閉じます。このダイアログボックスをもう一度開くと、[Source] ペインにリフレッシュされたデバイス グループが表示されます。


 

Ping Echo

このテストでは、ICMP を使用してエンドツーエンドの遅延情報を測定します。テストでは、発信元デバイスから宛先デバイスに ICMP パケットを送信し、ラウンドトリップの完了にかかる時間を測定します。

エンドツーエンドの遅延を ICMP を使用して測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[Ping Echo] を選択します。

ステップ 4 [Source] ペインで、次の手順に従います。

a. デバイス セレクタを使用して発信元デバイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

b. 発信元インターフェイス設定を選択します。[Default] のままにするか、新しい設定を入力できます。

ステップ 5 [Destination] ペインのデバイス セレクタを使用して、宛先デバイスを選択します。

発信元デバイスと宛先デバイスを切り替える場合は、[Swap Source and Destination] ボタンをクリックします。

ステップ 6 [Parameters] ペインで次のパラメータを設定できます。

 

表 14-4 Ping Echo テストのパラメータ

パラメータ
デフォルト値
使用可能な値
説明

要求ペイロード

32 バイト

28 ~ 16384 バイト

デフォルト ICMP PING パケットは 32 バイトです。サイズを変えて操作可能です。

IP QoS

IP Precedence

IP Precedence

DSCP

IP SLA パケットの Quality of Service ポリシーを定義します。

0(なし)

IP Precedence:0(なし)~ 7(高)

DSCP:0(なし)~ 8(CS1)、9、10(AF11)

これは TOS に変換されてデバイスに設定されます。

Round-Trip Response Time しきい値を変更する場合は、[Thresholds] ペインのチェックボックスをオンにして、新しい設定を入力します(デフォルトは 300 m/sec)。この設定は正の整数(32 ビット)にする必要があります。

ステップ 7 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [schedule] オプション ボタンを選択します。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 8 [OK] をクリックします。


 

Ping Path Echo

ホップバイホップ遅延情報を ICMP ping と traceroute を使用して測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[Ping Path Echo] を選択します。

ステップ 4 [Source] ペインで、次の手順に従います。

a. デバイス セレクタを使用して発信元デバイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

b. 発信元インターフェイス設定を選択します。[Default] のままにするか、新しい設定を入力できます。

ステップ 5 [Destination] ペインのデバイス セレクタを使用して、宛先デバイスを選択します。

発信元デバイスと宛先デバイスを切り替える場合は、[Swap Source and Destination] ボタンをクリックします。

ステップ 6 [Parameters] ペインで次のパラメータを設定できます。

 

表 14-5 Ping Path Echo テストのパラメータ

パラメータ
デフォルト値
使用可能な値
説明

要求ペイロード

32 バイト

28 ~ 16384 バイト

デフォルト ICMP PING パケットは 32 バイトです。サイズを変えて操作可能です。

IP QoS

IP Precedence

IP Precedence

DSCP

IP SLA パケットの Quality of Service ポリシーを定義します。

0(なし)

IP Precedence:0(なし)~ 7(高)

DSCP:0(なし)~ 8(CS1)、9、10(AF11)

これは TOS に変換されてデバイスに設定されます。

Round-Trip Response Time しきい値を変更する場合は、[Thresholds] ペインのチェックボックスをオンにして、新しい設定を入力します(デフォルトは 300 m/sec)。この設定は正の整数(32 ビット)にする必要があります。

ステップ 7 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [schedule] オプション ボタンを選択します。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 8 [OK] をクリックします。


 

UDP Echo

このテストでは、UDP サーバの遅延を測定します。UDP エコー テストでは、設定された数のバイトからなるパケットを指定されたポート番号の宛先に送信し、応答時間を測定します。

UDP エコー操作には、IP SLA を使用する RTR Responder と IP SLA を使用しない UDP サーバの 2 つの宛先デバイス タイプがあります。

UDP サーバの遅延を測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[UDP Echo] を選択します。

ステップ 4 [Source] ペインで、次の手順に従います。

a. デバイス セレクタを使用して発信元デバイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

b. 発信元インターフェイス設定を選択します。[Default] のままにするか、新しい設定を入力できます。

ステップ 5 [Destination] ペインのデバイス セレクタを使用して、宛先デバイスを選択します。

ステップ 6 応答パケットを送信するときに使用する宛先デバイスの UDP ポート番号(デフォルト値は 7)を入力します。

発信元デバイスと宛先デバイスを切り替える場合は、[Swap Source and Destination] ボタンをクリックします。

ステップ 7 [Parameters] ペインで次のパラメータを設定できます。

 

表 14-6 UDP Echo テストのパラメータ

パラメータ
デフォルト値
使用可能な値
説明

要求ペイロード

16 バイト

4 ~ 1500 バイト

サイズを変えて操作可能です。

IP QoS

IP Precedence

IP Precedence

DSCP

IP SLA パケットの Quality of Service ポリシーを定義します。

0(なし)

IP Precedence:0(なし)~ 7(高)

DSCP:0(なし)~ 8(CS1)、9、10(AF11)

これは TOS に変換されてデバイスに設定されます。

Round-Trip Response Time しきい値を変更する場合は、[Thresholds] ペインのチェックボックスをオンにして、新しい設定を入力します(デフォルトは 300 m/sec)。この設定は正の整数(32 ビット)にする必要があります。

ステップ 8 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [schedule] オプション ボタンを選択します。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 9 [OK] をクリックします。


 

Gatekeeper Registration Delay

このテストでは、H.323 ゲートウェイから H.323 ゲートキーパーに軽量の登録要求(RRQ)を送信し、ゲートキーパーから登録確認(RCF)を受信します。その後、この応答時間が測定されます。


) Gatekeeper Registration Delay テストを実行する場合は、発信元ゲートウェイに SIP または H323 が設定されている必要があります。


応答時間を測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[Gatekeeper Registration Delay] を選択します。

ステップ 4 [Source] ペインのデバイス セレクタを使用して、発信元デバイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

Registration Response Time しきい値を変更する場合は、[Thresholds] ペインのチェックボックスをオンにして、新しい設定を入力します(デフォルトは 300 m/sec)。この設定は正の整数(32 ビット)にする必要があります。

ステップ 5 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [schedule] オプション ボタンを選択します。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 6 [OK] をクリックします。


 

リアルタイム転送プロトコル

このテストでは、DSP ソフトウェアと統合することによって、音声品質メトリックの DSP 間の測定を実行します。コール テストは、発信元ゲートウェイから宛先へのコール テストの実行、実際のリアルタイム プロトコル(RTP)パケットの送信、DSP からの統計情報の収集が含まれます。

一部のネットワークでは、リモート エンドに DSP がない場合があります。このような場合、リアルタイム プロトコル テストではリモート エンド ループを RTP ストリームに戻すことによって、メトリックを測定する必要があります。

リアルタイム転送プロトコル テストには、これらの測定における音声パス(発信元のゲートウェイでのテレフォニー インターフェイスから IP インターフェイスへのパスと、終端ゲートウェイでの IP インターフェイスからテレフォニー インターフェイスへのパス)での遅延が含まれます。

リアルタイム転送プロトコル テストの実行については、発信元の DSP モジュール タイプが C5510 または C549 で、音声ポートが ds0-group に設定されている必要があります。

DSP 間の音声品質メトリックを測定するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Create] をクリックします。

[Node-to-Node Test Configuration] ページが表示されます。

ステップ 3 [Test Type] ドロップダウン メニューで、[Real-time Transport Protocol] を選択します。

ステップ 4 [Source] ペインのデバイス セレクタを使用して、発信元デバイスとインターフェイスを選択します。

最近追加したデバイスを確認できない場合は、デバイス グループをリフレッシュします。「トラブルシューティングに関する注意:発信元デバイスの選択」を参照してください。

ステップ 5 [Destination] ペインのデバイス セレクタを使用して、宛先デバイスとインターフェイスを選択します。

ステップ 6 次の詳細を入力します。

 

フィールド
説明
General Parameters

テストの一般情報。

Codec Type

パケット間隔および要求ペイロードの決定に使用されます。

Call Duration

テストの期間。デフォルトは 20 秒です。

Voice Quality Expectation

Mean Opinion Score(MOS)および Calculated Planning Impairment Factor(CPIF)の Access Advantage ファクタに対応します。

Threshold Parameters

リアルタイム転送プロトコル テストのしきい値設定。

Interarrival Jitter

しきい値設定 宛先から発信元方向での Inter-Arrival ジッター(ミリ秒)メトリクスがサポートされます。

Packet Loss

しきい値設定 宛先から発信元方向での Packet Loss(数値)メトリクスがサポートされます。

R Factor

しきい値設定 遅延、ジッター、パケット損失など、ITU-T 勧告 G.107 によって他の VoIP メトリックから算出される数値スコア。標準範囲は 50 ~ 90 で、80 以上のスコアは、VoIP コール品質が十分であることを示しています。デフォルトは 40 です。

Conversational Quality

しきい値設定 設定(Excellent、Good、Fair、および Poor)に基づいて、通話のオーディオ信号を追跡します。デフォルトは Fair です。

Listening Quality

しきい値設定 設定(Excellent、Good、Fair、および Poor)に基づいて、聴取のオーディオ信号を追跡します。デフォルトは Fair です。

操作固有パラメータ

テスト実行のタイミングと頻度。

Polling Time

24 時間の間にポーリングが発生する回数(分)。

Occurrence Pattern

テストが開始および終了される日付、およびその期間にテストの実行がスケジュールされた時間。テストを毎週実行する場合、スケジュール パラメータにはテストの実行がスケジュールされた曜日が表示されます。

Test Name

ユーザ定義の名前。また、 Prime UOM では、テスト データを格納するフォルダの名前にもこのテスト名が使用されます。この表の Data Directory フィールドの説明を参照してください。

ステップ 7 [Run] ペインでテストの実行タイミングを設定します。

テストを 1 回だけ実行する場合は、[Once] オプション ボタンを選択します。

テストを一定の間隔で実行するようにスケジュールする場合、次の手順に従います。

a. [every X minutes] オプション ボタンを選択します(ここで、X は分の数値です)。

b. テストを実行する頻度を選択します。

c. テストを実行する時刻を入力します。

d. テストを実行する曜日を選択します。

e. テスト名を入力します。

テスト名にタブ、疑問符、引用符、アスタリスク、セミコロン、カンマ、コロン、スラッシュ、縦線、バックスラッシュを入れることはできません。

ステップ 8 [OK] をクリックします。


 

複数のテストのインポート

シード ファイルのインポートにより、Prime UOM でサポート可能な最大数である 64 件までテストをインポートすることができます。

はじめる前に

テストをインポートする前に、発信元デバイスを追加する必要があります。「Prime UOM へのデバイスのインポート」を参照してください。

シード ファイルが正しい形式であることを確認します。詳細については、「ノードツーノード テストのインポート ファイルの作成」を参照してください。

サーバの NMSROOT\ImportFiles ディレクトリにシード ファイルを配置します。

NAT-enabled デバイスのノードツーノード テストを設定するには、インポート ファイルにパブリック/グローバル IP アドレスの代わりに、宛先ルータのプライベート/ローカル IP アドレスが含まれていることを確認します。

NMSROOT は、Cisco Prime Unified Operations Manager がインストールされているシステム上のディレクトリです。インストール時にデフォルト ディレクトリを選択した場合、「C:\Program Files\CSCOpx」または「C:\PROGRA~1\CSCOpx」のように入力されます。

複数のテストをインポートするには、次の手順を実行します。


ステップ 1 [Administration] > [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 [Import] をクリックします。

[Import Node-to-Node Tests] ページが表示されます。

ステップ 3 [Seed Filename] フィールドに、テスト情報を含むシード ファイルの名前を入力します。

たとえば、Node_to_nodetestImport.txt。ファイルは、[Server Path] フィールドの横に表示されているサーバ上のディレクトリに存在している必要があります。

ステップ 4 [OK] をクリックします。

Prime UOM は次のアクションを実行します。

このファイルを以前にインポートしたことがある場合、Prime UOM は、デバイスのいずれかが Prime UOM 内に存在しているかどうかを確認します。インポート ファイルのすべての情報が Prime UOM にすでに存在している情報と同じである場合は、そのことを示すメッセージが表示されます。[OK] をクリックします。

インポート ファイルの形式に問題がある場合、Prime UOM はエラー メッセージを表示します。[OK] をクリックしてファイルを開き、示された問題を修正してください。すべての問題を修正するまでファイルをインポートできません。

エラーがない場合は、確認のダイアログボックスが表示されます。ダイアログボックスには、作成された新しいテストの数と、アップデートされるテストの数が表示されます。[Yes] をクリックします。


 

ノードツーノード テストのインポート ファイルの作成

テストは 64 件までインポートできます。この数は、Prime UOM が同時にサポートできる最大数です。インポート ファイルの例は NMSROOT\Importfiles フォルダにあります。

NMSROOT は、Prime UOM がインストールされているシステム上のディレクトリです。インストール時にデフォルト ディレクトリを選択した場合、「C:\Program Files\CSCOpx」または「C:\PROGRA~1\CSCOpx」のように入力されます。

各操作用のテスト シード ファイルの形式の詳細については、「ノードツーノード テストのインポート ファイルの形式」を参照してください。

すべてのテスト シード ファイルには、次の情報が必要です。

テスト名

操作タイプ

発信元デバイス名

宛先デバイスの情報(NAT-enabled デバイスの場合、デバイスのプライベート IP アドレスが必要です)

操作パラメータ

スケジュール パラメータ

テスト シード ファイルの一般的な形式は、次のとおりです。

インポート ファイルを手動で作成する場合は、インポート ファイルのヘッダーに次のように記述する必要があります。

Cisco Systems Node-to-Node test import, version=3.0;type=CSV;source=manual
 

すべての値をカンマで区切る必要があります。

開始日と終了日は、mm/dd/yyyy の形式になっている必要があります。たとえば、12/01/2004 です。

開始時刻と終了時刻は、24 時間表記の hh:mm 形式である必要があります。たとえば、23:30 です。

発信元 IP アドレスの入力はオプションです。このアドレスは、代替テスト アドレスと同じです。

オプション フィールドに入力するときには、"" のように、二重引用符を付けます。

1 週間のすべての曜日を指定する場合は、1 を入力します。これ以外の場合は 0 を指定する必要があります。1 週間のすべての曜日のエントリが 0 の場合は、該当する曜日を入力する必要があります。曜日は縦棒(|)で区切ります。たとえば、Mon|Tue|Thu|Fri のようになります。

ノードツーノード テストのインポート ファイルの形式

この項の構成は、次のとおりです。

「Ping Echo テスト」

「Ping Path Echo テスト」

「UDP Echo テスト」

「VoIP 用 UDP ジッター テスト」

「VoIP Gatekeeper Registration Delay テスト(毎日のスケジュール)」

Ping Echo テスト

<testName>,Ping-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample-interval>,<IPQosType><IPQosValue>,<request-payload>,<LSRHop1|LSRop2|LSRHop3|LSRHop4|LSRHop5|LSRHop6|LSRHop7|LSRHop8>,<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
echo-import1,Ping-Echo,source-1,"",dest-1,1,DSCP,9,64,lsr-hop1|lsr-hop2,300,09:00,17:00,1
echo-import2,Ping-Echo,source-1,"",dest-1,1,IPPrecedence,4,64,lsr-hop1|lsr-hop2,"",09:00,17:00,0,mon|tue|wed|fri
 

LSRHop<number> はオプションのフィールドです。

Ping Path Echo テスト

<testName>,Ping-Path-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample-
interval>,<IPQosType>,<IPQosValue>,<request-payload>,<completionTimeThreshold or "">
,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,DSCP,10,32,250,17:00,23:00,0,mon|tue|wed|thu|fri
ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,IPPrecedence,5,32,"",17:00,23:00,1
 

UDP Echo テスト

<testName>,UDP-Echo,<source>,<source-ip-address>,<Destination-Name>,<destination-type>,<sample-interval>,<IPQosType>,<IPQosValue>,<destination-port>,<request-payload>,
<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
udp-import1,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,IPPrecedence,4,2001,
32,300,17:00,23:00,0,mon|tue|wed|thu|fri
udp-import2,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,DSCP,48,2001,32,"",
17:00,23:00,1
 

宛先タイプは、UDP-Server または IP SLA-Responder です。

VoIP 用 UDP ジッター テスト

コーデック(ノードツーノード品質)サポートなしの場合

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>,
<IPQosType>,<IPQosValue>,<request-payload>,<inter-packet-interval>,<number-of-packets>,
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">,
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">,
<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
jitter-import1,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,DSCP,24,64,30,20,2002,30,30,25,25,50,17:00,23:00,0,mon|tue|wed|thu|fri
 

コーデック(ノードツーノード品質)サポートありの場合(Cisco IOS バージョン 12.3(4)T 以降で有効)

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>,
<IPQosType>,<IPQosValue>,<codecType>,<voiceQualityBenchMark>,<number-of-packets>,
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">,
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">,
<nodeToNodeQualityThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
jitter-import2,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,IPPrecedence,5,G.711ulaw,LandLine,20,2002,30,30,25,25,50,"",17:00,23:00,1
 

リード(Read)コミュニティ ストリングはオプションのフィールドです。コミュニティ ストリングを指定する場合、Prime UOM は IP SLA Responder を検証します。

VoIP Gatekeeper Registration Delay テスト(毎日のスケジュール)

<testName>,Voip-GKReg-Delay,<source GateWay>,<sample-interval>,
<GatekeeperRegistrationTimeThresholdor "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>
 
gkregdelay-import1,Voip-GKReg-Delay,source-gateway,3,50,17:00,23:00,0,mon|tue|wed|thu|fri
gkregdelay-import2,Voip-GKReg-Delay, source-gateway,5,"",17:00,23:00,1
 

テストの編集

Prime UOM に対してテストを作成した後は、テスト パラメータを変更したり、削除が必要な場合は Prime UOM からテストを削除することができます。

この機能を使用して、既存のテストのパラメータを編集することができます。たとえば、テストの操作パラメータを変更したり、スケジュールを変更することができます。宛先デバイスを変更できません。

テストを編集するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 編集するテストを選択して、[Edit] をクリックします。

[Edit Node-to-Node Test] ページが表示されます。

スケジュールやしきい値の設定をはじめとするテスト パラメータを変更することができます。詳細については、「ノードツーノード テストの使用」を参照してください。

ステップ 3 完了したら [OK] をクリックします。


 

テストの削除

この機能を使用して、1 つ以上のテストを削除することができます。どのような状態のテストでも削除できます。発生しうる状態の詳細については、 表 14-8 を参照してください。

テストを削除するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 削除するテストを選択して、[Delete] をクリックします。

確認ダイアログボックスが表示されます。

ステップ 3 [Yes] をクリックします。

選択したテストが Prime UOM から削除されます。


 

ノードツーノード テストのイベント

ノードツーノード イベントの発生タイミングは、テストの作成時または変更時に設定したしきい値によって決まります。「ノードツーノード テストの使用」を参照してください。

イベントは、発信元デバイスで発生します。3 回のポーリング サイクルで連続してしきい値違反が発生すると、しきい値イベントが生成されます。このイベントは、次のポーリング サイクルで値がしきい値より小さくなるとクリアされます。

次のノードツーノード イベントが生成される可能性があります。

NodeToNodeTestFailed

ノードツーノード テストが失敗した理由とその解決方法については、Cisco.com の IP SLA のドキュメントを参照してください。

RoundTripResponseTime_ThresholdExceeded

RingBackResponseTime_ThresholdExceeded

RegistrationResponseTime_ThresholdExceeded

AverageLatency_ThresholdExceeded

PacketLossSD_ThresholdExceeded

PacketLossDS_ThresholdExceeded

IAJitterDS_ThresholdExceeded

JitterDS_ThresholdExceeded

Quality Dropped Below Threshold

RFactorDS_ThresholdExceeded

MosCQDS_ThresholdExceeded

MosLQDS_ThresholdExceeded

RTPPacketLossDS_ThresholdExceeded

ノードツーノード イベントの詳細については、「処理されるイベント」を参照してください。

テスト操作の管理

ここでは、次の各作業について説明します。

「テストのトレンドの表示」

「テスト情報の表示」

「テストの詳細の印刷」

「テストの詳細のエクスポート」

「テストのステータスの確認」

テストのトレンドの表示

ネットワーク パフォーマンス メトリックでは変更を選択して確認できます。ネットワーク パフォーマンス データをリアルタイムに選択、表示、図化することができます。グラフ化できるメトリックのタイプの詳細は、「グラフに使用できるメトリック」を参照してください。

テストのトレンドを表示するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 トレンドを表示するテストを選択し、[Trend] をクリックします。

VoIP テストの UDP ジッターを選択すると、[Select Metrics] ダイアログボックスが表示されます。

a. グラフ化するメトリックを選択します。メトリックの単位は同じである必要があります。

b. [View Graph] をクリックします。

これ以外のテストを選択した場合、2 番目のダイアログボックスは表示されません。

Node-to-Node Test Trend グラフが表示されます。パフォーマンス グラフの使用方法の詳細については、「パフォーマンス グラフの使用方法」を参照してください。


 

テスト情報の表示

[Test Details] ページでは、特定のテストに関するすべての詳細情報を確認できます。このページから、テスト情報を印刷またはエクスポートすることができます。

テスト情報を表示するには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 表示するテストを選択し、[View] をクリックします。

[Test Details] ウィンドウが開きます。

表 14-7 に、このウィンドウの内容の説明を示します。

 

表 14-7 Test Details

フィールド
説明
General Parameters

テストの一般情報。

Test Name

ユーザ定義の名前。また、 Prime UOM では、テスト データを格納するフォルダの名前にもこのテスト名が使用されます。この表の Data Directory フィールドの説明を参照してください。

Operation Type

テストの操作タイプ。Ping Echo などです。

Source

発信元デバイスの名前または IP アドレス。

Source Interface

発信元デバイスのインターフェイスの IP アドレス。 Default と表示される場合もあります。 Default の場合、発信元デバイスの IP SLA エンジンによって発信元インターフェイスが決定されます。

IP SLA Responder

IP SLA 対応の宛先デバイス名。

Current Status

テストのステータス。発生しうる状態の詳細については、表 14-8 を参照してください。 任意の時点でテストを停止または定義できるかどうかは、このテストの状態によって決まります。また、この状態により、データ収集の状態も決定されます。

ステータスが Config Failed の場合は、障害の原因の説明が表示されます。テストのステータスが Config Failed または Config Pending の場合は、説明が表示されます。

Admin Index

発信元デバイスでのテストの一意な数値識別子。詳細は、この表の後ろにある「 テストが Running 状態の間は、発信元デバイス上でテスト情報を直接確認することができます。発信元デバイスに Telnet して、コマンド show rtr configuration <admin index> を使用してください。」を参照してください。

Data Directory

Prime UOM がテスト データ格納するディレクトリ。Data Directory の名前はテスト名と一致している必要があります。「ノードツーノード テスト データの格納」を参照してください。

Schedule Parameters

テスト実行のタイミングと頻度。

Polling Time

24 時間の間にポーリングが発生する時間数。

Occurrence Pattern

テストが開始および終了される日付、およびその期間にテストの実行がスケジュールされた時間。テストを毎週実行する場合、スケジュール パラメータにはテストの実行がスケジュールされた曜日が表示されます。

操作固有のパラメータ(VoIP の UDP ジッターの場合の例)

テストで実行される特定の種類の操作に関する情報。この表のこれ以降の部分は、 VoIP 用 UDP ジッター テストの操作固有のパラメータの例です。

その他のテスト タイプには、異なる操作固有のパラメータが存在します。その他の操作タイプの操作固有パラメータの詳細については、「単一のノードツーノード テストの作成」を参照してください。

Sample Interval (minutes)

発信元デバイスから宛先デバイス、および Prime UOM から発信元デバイスへのポーリングの頻度。

Duration

テストの期間。

Codec

パケット間隔および要求ペイロードの決定に使用されます。

IP QoS Type

IP SLA パケットの Quality of Service ポリシー。

IP QoS Value

Quality of Service の値。

Voice Quality Expectation

Mean Opinion Score(MOS)および Calculated Planning Impairment Factor(ICPIF)の Access Advantage ファクタに対応します。

Destination Port

デフォルトの宛先ポートは 16400 です。

Threshold Parameters

テストのしきい値設定。

Average Latency

しきい値設定。

Packet Loss Source to Destination

しきい値設定。

Packet Loss Destination to Source

しきい値設定。

Jitter Source to Destination

しきい値設定。

Jitter Destination to Source

しきい値設定。

Node-to-Node Quality

しきい値設定。


テストが Running 状態の間は、発信元デバイス上でテスト情報を直接確認することができます。発信元デバイスに Telnet して、コマンド show rtr configuration <admin index> を使用してください。



 

テストの詳細の印刷

すべてのテストの詳細を印刷するには、[Test Details] ページで、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 表示するテストを選択し、[View] をクリックします。

[Test Details] ウィンドウが開きます。

ステップ 3 ウィンドウの右上隅にあるプリンタ アイコンをクリックします。

レコードが印刷に適した形式に変更されて新しいブラウザ ウィンドウに表示されます。

ステップ 4 ブラウザの印刷機能を使用して表示内容を印刷します。


 

テストの詳細のエクスポート

[Test Details] ページに表示された単一のテストの詳細情報を、設定やステータスも含めてすべてエクスポートし、保存することができます。この操作は、テストで収集されたデータのエクスポートと同じではありません。

テストによって収集されたデータを保存およびエクスポートする方法については、「別のサーバへのテスト データのコピー」を参照してください。

テストの詳細をエクスポートするには、次の手順を実行します。


ステップ 1 [Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。

ステップ 2 必要なテストを選択し、[View] をクリックします。

[Test Details] ウィンドウが開きます。

ステップ 3 ウィンドウの右上隅にあるエクスポート アイコンをクリックします。

ステップ 4 エクスポートの形式として [CSV] または [PDF] のいずれかを選択し、[OK] をクリックします。

CSV を選択した場合は、次の手順を実行します。

a. [File Download] ダイアログボックスが表示されたら、[Save] をクリックします。

b. Windows のフォルダ ウィンドウで、ファイル名とファイルの保存場所を入力します。

c. [Save] をクリックします。

d. [Download Complete] ダイアログボックスで、[Close] をクリックします。

PDF を選択した場合は、次の手順を実行します。

a. セキュリティ情報のダイアログボックスで [Yes] をクリックします。

レコードは PDF 形式で表示されます。

b. PDF の保存機能を使用して、ファイルをシステムに保存します。


 

テストのステータスの確認

テストが実行され、正しく完了したかどうかを確認することができます。また、必要に応じてテストのトラブルシューティングを実行することもできます。

これを行うには、[Diagnostic Tests] > [Node-to-Node Tests] を選択します。

[Node-to-Node Tests] ページが表示されます。このページには、現在のすべてのノードツーノード テストが表示されます。表の最後のカラムに各テストのステータスが表示されます。

 

表 14-8 テストのステータスの定義

テストのステータス
説明

Running

テストはアクティブで、データを収集中です。

Config Pending

デバイスが応答していないか、テストの設定中です。

Delete Pending

テストが削除される前の中間的な状態です。テストにアクションを実行できません。

Suspended

テストは一時停止され、データ収集やポーリングは行われていません。この状態は、デバイスが一時停止されたことによって発生します。

Scheduled

テストの作成またはアップデート後に表示されます。このステータスは、最初のポーリング サイクルで Running に変更されます。

Dormant

テストはアクティブですが、現在データを収集していません。テストは、各ポーリング サイクルの間で Dormant 状態になります。

Config Failed

テストは正しく設定されていません。デバイスのクレデンシャルが間違っているかデバイスのメモリ不足が問題となっている可能性があります。

テスト情報の表示 ページを表示することにより、テストの設定が失敗した原因をより詳細に確認することができます。

テスト データの使用

Prime UOM は、テストによって収集されたデータをディスクに保存します。

次の各項では、データの使用とその安全な維持、および追加テストの実行準備に必要な情報を説明します。

「ノードツーノード テスト データの格納」

「ノードツーノード テスト データの保持」

「別のサーバへのテスト データのコピー」

「ノードツーノード データの形式」

ノードツーノード テスト データの格納

ノードツーノード テストのデータは、Prime UOM サーバの NMSROOT\data\N2Ntests フォルダに格納されます。

NMSROOT は、Prime UOM がインストールされているシステム上のディレクトリです。インストール時にデフォルト ディレクトリを選択した場合、「C:\Program Files\CSCOpx」または「C:\PROGRA~1\CSCOpx」のように入力されます。

表 14-9 に、データ格納ディレクトリに格納される 2 種類のファイルを示します。

 

表 14-9 テスト データ ファイルとログ ファイル

ファイル名
内容

YYYYMMDD.csv

テスト データ。各ファイルには複数のレコードが入っています。各レコードはカンマ区切り形式(CSV)レコードで、ファイルにはポーリング間隔ごとに 1 つのレコードがあります。

StudyInfo.log

ログには、テスト名、説明、ポーリング間隔、デバイス、開始日、終了日、操作タイプ、ポーリング間隔、およびステータスが含まれます。

ノードツーノード テスト データの保持

次の作業をはじめとして、テスト データの保持に関連するすべての作業を実行する必要があります。

テスト データを格納する十分なディスク スペースがあることを確認します。 テストの実行をスケジュールする前に、ディスク スペースを確認します。Prime UOM は、テストのログ ファイルにデータを追加します。テストが実行される場合、 Prime UOM はテストの実行ごとに 1 日につき 1 つのデータ ファイルを作成します。直前のテストで使用されたスペースを算出して、見積もりを出してください。

たとえば、ポーリング サイクルが 16 時間でサンプリング間隔が 1 分のテストでは、1 日におよそ 60 ~100 KB が使用されます。ポーリング サイクルが 16 時間、サンプリング間隔が 1 分、およびホップ数が 12 の Path Echo テストでは、1 日におよそ 1.2 MB が使用されます。

テスト データをエクスポートして保存します。 Prime UOM は、31 日より長く経過したすべてのデータを消去します。31 日より長くデータを保持するには、テストを別のサーバに保存する必要があります。「別のサーバへのテスト データのコピー」を参照してください。

テスト データをバックアップします。 Prime UOM は、[Test Details] ウィンドウに表示された Data Storage Directory にテスト データを書き込みます。ファイルシステムのバックアップと同じ方法を使用して、定期的にバックアップを実行してください。

データを別のサーバにコピーするタイミングを決定します。 テスト データは、別のサーバにコピーしてから検査する必要があります。

データを表示し、使用します。 テストの結果は、テスト データを Microsoft Excel にインポートしてから、またはサードパーティ製のレポート生成ツールを使用して、分析することができます。

テストが Running 状態の間は、テスト データのファイルに対して排他的な読み取り専用ロックするアプリケーションを使用してファイルを開かないでください。テスト データのファイルがロックされると、Prime UOM は出力データを書き込むことができず、ログ ファイルにエラーを書き込みます。

排他ロックするアプリケーションには、Microsoft Excel や Microsoft Word などがあります。テストが実行されていないときには、これらのアプリケーションを使用できます。

別のサーバへのテスト データのコピー

テスト データは、別のサーバにコピーしてから検査する必要があります。また、テスト データの別のサーバへのコピーは、バックアップ手段としても必要になる場合があります。テスト データは ASCII 形式です。別のサーバへのコピーは、SSH やコピー アンド ペーストなど、使用可能な任意の方法で実行することができます。

テスト データのファイルは、Data Storage Directory からコピーします。テスト データは CSV ファイルに書き込まれるため、テスト データ ファイルの名前は末尾が .csv になっています。


) ドラッグ アンド ドロップを使用すると、テスト データがコピーされるのではなく、移動される場合があるので、注意してください。


ノードツーノード データの形式

Prime UOM では、収集されるデータ タイプごとに 1 つのレコード タイプが用意されています。 表 14-10 は、このレコード タイプをまとめたものです。

すべてのエクスポート データの形式の詳細については、「データ ファイル形式」を参照してください。

 

表 14-10 ノードツーノード テストのレコード タイプ

タイプ
定義

200

Echo:このレコード形式は、次のタイプのテストでエンドツーエンドの統計情報を取得します。

ICMP Echo

UDP Echo

Gatekeeper Registration Delay

201

Path Echo:このレコード形式は、ICMP Path Echo テストでホップバイホップの統計情報を取得します。テストでは発信元から宛先へ情報を記録します。

204

Path Echo(宛先ホップ):このレコード形式は、ICMP Path Echo テストでエンドツーエンドの統計情報を取得します。テストは発信元から宛先に対して行われます。

205

VoIP 用の UDP ジッター:このレコード形式は、VoIP 用の UDP(拡張 UDP)テストでエンドツーエンドの統計情報を取得します。テストでは発信元から宛先へ情報を記録します。