IP : IP アプリケーション サービス

シスコ サービス保証エージェントとインターネットワーク パフォーマンス モニタを使用した Voice over IP ネットワークの QOS 管理

2003 年 2 月 27 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 1 月 4 日) | フィードバック

目次

 


概要

この文書では、Cisco Service Assurance Agent(CSAA; シスコ サービス保証エージェント)と Internetwork Performance Monitor(IPM; インターネットワーク パフォーマンス モニタ)を使用して、Voice over IP(VoIP)ネットワークの Quality of Service(QOS)を測定する方法について説明します。この情報は実際の IP テレフォニー プロジェクトに基づいています。この文書では、製品そのものではなく、製品のアプリケーションを中心に扱っています。ここでは、読者がすでに CSAA と IPM について十分理解していて、必要な製品文書を使用できることを前提としています。その他の参考となる文書については、「関連情報 」を参照してください。

注:Cisco IOS ソフトウェアの CSAA 機能は、以前は Response Time Reporter(RTR)という名前でした。

大規模な VoIP ネットワークを管理する際は、ネットワークの音声品質を客観的に監視し、報告するツールが必要です。ユーザからのご意見は主観的かつ不完全であるため、それだけに頼るのは不十分です。一般に、音声品質の問題はネットワーク QoS の問題から生じます。そのため、音声品質の問題を明らかにするには、ネットワークの QOS を管理および監視する第 2 のツールが必要になります。この実装でのクライアントは、この目的で CSAA/IPM を使用しています。

クライアントは Cisco Voice Manager(CVM)と Telemate.net を使用して音声品質を管理します。また、Cisco IOS ゲートウェイによってコールごとに計算された Impairment/Calculated Impairment Planning Factor(Icpif)を使用して、コールの音声品質を報告します。ネットワーク管理者はこれを利用して、音声品質の悪いサイトを特定できます。詳細は、「Cisco Voice Manager(CVM)および Telemate を使用したボイス品質の管理」を参照してください。

VoIP ネットワークでの QOS 問題

パケット化された音声ネットワークでは、次のようないくつかの要因によって音声品質が劣化する可能性があります。

  • パケットの損失

  • 過度の遅延

  • 過度のジッタ

WAN でパケット交換サービス(ATM、フレームリレー、IP VPN など)を使用している場合は、これらの値を継続的に監視することが特に重要です。キャリア ネットワークにおける輻輳、エッジ デバイスでのトラフィック シェーピングの設定ミス、またはキャリア側でのポリシングの設定ミスによってパケット損失や過剰なバッファリングが引き起こされるようなシナリオは数多く存在します。キャリアがパケットを廃棄していたとしても、エッジ デバイスには明白な形跡はありません。そのため、入力時にトラフィックを注入し、出力時にそのトラフィックが正しく到達したかどうかを検証できる、CSAA のようなエンドツーエンドのツールが必要です。

CSAA と IPM を使用した QOS 管理

CSAA/IPM には次の 3 つのコンポーネントがあります。

  • RTR プローブ

  • RTR レスポンダ

  • IPM コンソール

RTR プローブは RTR レスポンダにパケットのバーストを送信します。続いて RTR レスポンダはそれらのパケットを方向転換し、プローブに送り返します。この単純な操作を通じて、プローブはパケット損失と往復の遅延を測定します。ジッタを測定するため、プローブはパケットのバーストを開始する前に、レスポンダに制御パケットを送信します。制御パケットはレスポンダに対して、バースト内の各パケットの間隔が何ミリ秒に想定されているかを通知します。レスポンダはバースト中にパケット間の遅延を測定し、想定されている間隔からのずれがジッタとして記録されます。

IPM コンソールは QOS モニタリングを制御します。IPM コンソールは関連する情報を使用して、SNMP 経由で RTR プローブをプログラムします。また、SNMP 経由で結果を収集します。RTR プローブには、CLI Cisco IOS を設定する必要はありません。

RTR レスポンダは次のグローバル設定コマンドを入力して手動で設定します。

rtr responder

RTR プローブおよびレスポンダには IOS バージョン 12.0(5)T 以降が必要です。12.1 メインストリームの最新のメンテナンス リリースが推奨されます。このクライアントのサイトでは、RTR プローブおよびレスポンダはバージョン 12.1(4)で動作しています。使用している IPM のバージョンは V2.2 for Windows NT です。このバージョンのパッチは CCO から入手できます。このパッチにより、IPM が誤った IP 優先順位設定で RTR プローブを設定する問題(CSCds02402)が修正されるため、このパッチは重要です。

設計

CSAA/IPM ソリューションを導入する前に、設計作業を行う必要があります。次の点について考慮してください。

  • RTR プローブおよびレスポンダの配置

  • プローブからレスポンダに送信されるトラフィック タイプ

プローブおよびレスポンダの配置を決定する際には、考慮すべき事柄が数多くあります。まず、QOS 測定は問題のあるサイトだけでなく、すべてのサイトを対象にする必要があります。これは、IPM によって報告された特定のサイトの遅延とジッタの数は、同じネットワーク内の他のサイトとの比較において最も役立つためです。このため、QoS が良好なサイトと QoS の低いサイトの両方を測定する必要があります。また、パフォーマンスが良好なサイトであっても、トラフィック パターンの変化やネットワークの変更が原因で、次の日にはパフォーマンスが低下する可能性があります。そのような事態は、音声品質に影響が及び、ユーザから報告を受ける前に把握する必要があります。

次に、CPU 使用率が重要です。ルータがすでにビジー状態であれば、RTR コンポーネントの要求にタイムリーに応えられず、正しい結果が得られない場合があります。また、1 台のルータに配置するプローブ インスタンスの数が多すぎると、それ以前は見られなかった CPU 高使用率の問題が生じるおそれがあります。クライアントで選択されたアプローチ(このアプローチはほとんどのネットワークにおいて有効です)は RTR プローブをリモート/ブランチ ルータに配置することです。一般に、これらのルータは単一の LAN を比較的低速な WAN サービスに接続します。そのため、ブランチ ルータは CPU 使用率が低いことが多く、RTR に容易に対処できます。この設計のもう 1 つの利点は、可能な限り多くのルータにわたって負荷が分散する点です。プローブはある程度の量の SNMP ポーリングを処理するため、レスポンダよりもプローブの方が仕事量は多くなります。

この設計では、RTR レスポンダはコアに配置する必要があります。レスポンダは多くのプローブに応答し続けるため、プローブよりもビジーになります。強固な設計にするには、レスポンダとしてのみ動作する専用ルータを配備します。ほとんどの組織では、この機能を実行できるのに、使用していないルータがシェルフ内にあります。イーサネット インターフェイスを備えているすべてのルータを使用できます。その他の方法として、ディストリビューション/コア ルータにレスポンダの役割を与えることも可能です。下記のダイアグラムは両方のシナリオを表しています。

可能な限り多くのルータにわたって負荷を分散した上で、次のコマンドを使用して RTR の CPU 使用状況を監視してください。

Router#show processes cpu | i Rtt|PID
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
67 0 7 0 0.00% 0.00% 0.00% 0 Rtt Responder

プローブとレスポンダを対応させるときは、プローブとレスポンダの間で一貫したトポロジを維持することを推奨します。たとえば、プローブとレスポンダはすべて、同じ数のルータ、スイッチ、および WAN リンクによって区切られていることが望まれます。IPM の結果をサイト間で直接比較できるのは、この条件が満たされる場合に限られます。

このクライアントのケースでは、200 のリモート サイトと 4 つのコア/ディストリビューション サイトがあります。各ディストリビューション サイトに設置されている C4500 が専用の RTR レスポンダとして機能します。200 台のリモート ルータがそれぞれ RTR プローブとして機能します。各プローブは直接接続されたディストリビューション サイトに位置するレスポンダを対象とします。

プローブからレスポンダに送信されるトラフィックのバーストは、ネットワークによって、音声に与えられたものと同じ QOS レベルを与えられる必要があります。この場合、RTR プローブからのトラフィックが、厳格なプライオリティ キューイングに従うようにするため、ルータの LLQ または RTP プライオリティの設定を変更する必要があるかもしれません。RTP パケットに対してプローブを設定している場合は、宛先 UDP ポートのみ制御可能で、送信元 UDP ポートは制御できません。このクライアントの標準的な LLQ ルータの設定には、音声と同じキューに入る RTR パケットを明確に分類するアクセスリストが含まれています。次に例を示します。

class-map VoiceRTP
match access-group name IP-RTP
policy-map 192Kbps_site
class VoiceRTP
priority 110
ip access-list extended IP-RTP
deny ip any any fragments
permit udp 10.0.16.0 0.255.239.255 range 16384 32768 10.0.16.0 0.255.239.255 range 16384 32768 precedence critical
permit udp any any eq 20000 precedence critical
permit udp any eq 20000 any precedence critical

IP-RTP アクセスリストは 4 行で構成されており、それぞれ次の分類を行います。

  • 行 1:IP フラグメントをすべて拒否します。これらはレイヤ 4 アクセスリストによって暗黙的に許可されています。

  • 行 2:音声サブネットからの RTP パケットを許可し、IP 優先順位を 5 に設定します。

  • 行 3:RTR プローブから RTR レスポンダに向かう RTP パケットを許可します。

  • 行 4:RTR レスポンダから RTR プローブに向かう RTP パケットを許可します。

RTR トラフィックを追加しても LLQ キューはオーバー サブスクライブされないので、その結果実際の音声が廃棄される点に注意してください。標準の Default60ByteVoice IPM 操作では、RTP パケットのバーストが次のパラメータで送信されます。

  • ペイロード:60 バイト(注:これは RTP ヘッダーと音声です。L3 データグラムのサイズを得るには、28 バイト(IP/UDP)を加えます。)

  • 間隔:20 ミリ秒

  • パケット カウント:10

これは、バースト中に RTR が 35.2 Kbs の LLQ 帯域幅を使用することを意味します。LLQ 用に十分な帯域幅がない場合は、新しい IPM 操作を作成し、パケット間隔を増やします。次の IPM 設定ウィンドウに示されているパラメータを使用すれば、バーストによる帯域幅の使用量はわずか 1 Kbps になります。

結果

次の表は IPM レポートの例を示しています。このレポートには、RTR プローブの 3 つのインスタンスが含まれています。1 つの物理的プローブに対して複数の RTR プローブ インスタンスを設定し、それぞれ異なるレスポンダを対象としたり、異なるペイロードを使用したりできる点に注意してください。

各カラムの意味は次のとおりです。

Avg:

IPM は 1 時間のサンプリングごとに平均を算出します。これらの毎時平均はさらに長い時間にわたって平均化され、日次、週次、または月次の平均が算出されます。つまり、日報の場合、IPM は過去 24 時間の毎時平均を算出します。続いて、これら 24 の平均値の平均をとって日次平均を算出します。

Avg Max:

この値は、表内の日/週/月ごとの 1 時間内の最大値すべての平均です。つまり、日報の場合、IPM は過去 24 時間の各時間内に報告された最大のサンプルをとります。続いて、これら 24 のサンプルの平均をとって日次最大平均を算出します。

Over %:

これは、収集装置に対して設定されているしきい値を超えたサンプルのパーセンテージです。

Error %:

これは、エラーが発生したパケットのパーセンテージです。ジッタ プローブによって報告されるエラーにはいくつかのタイプがあります。次に簡単な説明を示します。

  • SD パケットの損失:送信元と宛先の間でパケットが失われた。

  • DS パケットの損失:宛先と送信元の間でパケットが失われた。

  • ビジー:前の RTT 操作が完了していないために、次の RTT 操作が開始できなかった回数。

  • シーケンス:予想外のシーケンス識別子とともに受信された RTT 操作完了の数。これが起こった場合は、次のような原因が考えられます。

    • 重複したパケットが受信された。

    • タイムアウトした後に応答が受信された。

    • 受信したパケットが破損しており、それが検出されなかった。

  • 廃棄:必要な内部リソース(メモリや SNA サブシステムなど)が使用できなかった、または処理完了が認識できなかったために、RTT 操作が開始できなかった回数。

  • MIA:処理中に損失:指示を判断できないために失われたパケットの数。

  • 遅延:タイムアウト後に到達したパケットの数。

これらの情報から、VoIP ネットワークではどれくらいの遅延、ジッタ、およびエラーの値が許容されるのかという疑問が生じます。残念ながら、この疑問に対する答えは 1 つではありません。許容される値は、コーデック タイプやジッタ バッファ サイズなどの要因によって異なります。また、これらの変数は相互に依存しています。パケット損失が大きいほど、許容されるジッタは小さくなります。

実行可能な遅延とジッタの値を取得する最適な方法は、同じネットワーク内にある類似したサイトと比較することです。192 Kbps の回線に接続されたサイトのうち、1 つのサイトを除くすべてがジッタ値として 50 ミリ秒前後を報告していて、残りの 1 つのサイトが 100 ミリ秒のジッタを報告している場合は、平常値とは無関係に、問題があることを示しています。IPM は 24 時間、365 日にわたって継続的にネットワーク全体の遅延とジッタを測定し、遅延とジッタを比較するためのベンチマークとして使用されるベースラインを提供することができます。

エラーは別の次元の話です。原則的には、エラーのパーセンテージがゼロでない場合はすべて危険信号を示します。RTR パケットには音声パケットと同じ QoS 処理が行われます。ネットワーク QoS とコール アドミッション制御が強固であれば、どのようなレベルの輻輳が生じても、音声または RTR パケットについてパケット損失や過度の遅延が起こることはありません。したがって、IPM エラーがカウントされる可能性はゼロになります。「正常」と見なされ得る唯一のエラーは CRC エラーですが、質の高いインフラストラクチャでは CRC エラーはほとんど起こりません。CRC が頻繁に発生する場合は、音声品質が低下するおそれがあります。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 13938