IP : サービス保証エージェント(SAA)

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

2016 年 3 月 19 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2003 年 2 月 27 日) | 英語版 (2016 年 2 月 29 日) | フィードバック


目次


概要

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

注: Cisco IOS の Cisco SAA 機能性か。 ソフトウェアは Response Time Reporter (RTR)として以前知られていました。

大規模VOIPネットワークを管理しているとき、ネットワークの音声クオリティで客観的に監視し、報告します必要なツールがなければなりません。 それはそれが頻繁に主観的、不完全であるので単独でユーザ フィードバックに頼ることは実行不可能です。 一般に、音声品質の問題はネットワーク QoS の問題から生じます。 このように音声クオリティ問題を識別するとき、秒ツールがネットワーク QoS を管理し、監察することを必要とします。 この資料の例は Cisco SAA および IPM をこのために使用します。

Telemate.net と Cisco Voice Manager (CVM)が音声クオリティを管理するのに使用されています。 それは各コールのための Cisco IOSゲートウェイによって計算される Calculated Planning Impairment Factor (ICPIF)/障害によって呼び出しの音声クオリティで報告します。 ネットワーク管理者はこれを利用して、音声品質の悪いサイトを特定できます。 詳細については Cisco Voice Manager(CVM)および Telemate を使用した音声品質の管理を参照して下さい。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

この資料は特定のソフトウェアまたはハードウェア バージョンに制限 されませんが、この資料の例はこれらのソフトウェア および ハードウェア バージョンを使用します:

  • Cisco IOS ソフトウェア リリース 12.1(4)

  • Windows NT のための IPM 2.5

  • Catalyst 4500 シリーズ スイッチ

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

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

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

  • パケット損失

  • 過度の遅延

  • 過度のジッタ

パケット交換サービスが WAN で利用される場合これらの図を常時監視することは特に重要です、(たとえば、ATM、フレーム リレー、または IP 仮想 な プライベート ネットワーク)。 搬送ネットワークの輻輳、エッジ デバイスの不適切に設定されたトラフィック シェーピング、またはキャリア側の不適切に設定されたポリシングがパケットロスか過剰なバッファリングを引き起こす場合がある多数のシナリオがあります。 キャリアがパケットを廃棄しているとき、エッジ デバイスに明らかな 証拠がありません。 従って、入力のトラフィックをインジェクトできる必要とし、出力で正常な着信を検証します Cisco SAA のようなエンドツーエンド ツールを。

Cisco SAA および IPM の QoS の管理

3 つの Cisco SAA および IPM コンポーネントがあります:

  • RTR プローブ

  • RTR レスポンダ

  • IPM コンソール

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

IPM コンソールは QOS モニタリングを制御します。 それは簡易ネットワーク管理プロトコル(SNMP)によって関連情報を用いる RTR プローブをプログラムします。 また、SNMP 経由で結果を収集します。 RTR プローブでコマンドラインインターフェイス Cisco IOSコンフィギュレーションが必要となりません。

RTR レスポンダーを手動で設定する rtr responder グローバル 設定 コマンドを、発行して下さい。

RTR プローブおよび応答機は Cisco IOS ソフトウェア リリース 12.0(5)T またはそれ以降を実行する必要があります。 12.1 メインストリームの最新のメンテナンス リリースが推奨されます。 この資料の例の RTR プローブおよびレスポンダーはリリース 12.1(4) を実行しています。 使用中の IPM バージョンは Windows NT のための IPM 2.5 です。 パッチはこのバージョンに Cisco.com で利用できます。 このパッチはそれとして重要、解決します IPM が不正確な IP 優先順位設定(Cisco バグ ID CSCds02402登録ユーザのみ))で RTR プローブを設定する問題をです。

設計

Cisco SAA および IPM ソリューションを展開する前に、心のこれらの考慮事項を使用します設計をして下さい:

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

  • プローブから応答側に送られるトラフィックタイプ

プローブおよびレスポンダーの配置について決定するとき考慮に入れるべきいくつかの事柄があります。 まず、QOS 測定は問題のあるサイトだけでなく、すべてのサイトを対象にする必要があります。 これは他のサイトと比較されたときある特定のサイトのための IPM レポートが同じネットワークで役立つこと遅延 および ジッター数という理由によります。 従って、よい QoS および悪い QoS のサイトを測定したいと思います。 また、十分実行サイトはトラフィックパターンまたはネットワーク変更の変更が明日低実行サイト、原因になるかもしれません。 音声クオリティに影響を及ぼし、ユーザによって報告される前にこれを検出するたいと思います。

次に、CPU 使用率が重要です。 RTR コンポーネントをタイムリーに保守既にビジー状態のルータはできこれは結果をスキューイングするかもしれません。 またどれも前に存在 しなかったのにあらゆるシングル ルータに余りにも多くのプローブ 例を置けば、CPU使用率が高い状態問題を引き起こすかもしれません。 この資料のネットワーク例(およびこれのためにほとんどのネットワークではたらくべきです)採用されるアプローチはリモート/ブランチルータに RTR プローブを置くことです。 一般に、これらのルータは単一の LAN を比較的低速な WAN サービスに接続します。 そのため、ブランチ ルータは CPU 使用率が低いことが多く、RTR に容易に対処できます。 この設計の他の利点はできるだけ多くのルータを渡るロードを分散させることです。 プローブがある程度の 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

/image/gif/paws/13938/csaaipm1.gif

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

この例では、200 のリモートサイトおよび 4 つのコア/配布 サイトがあります。 各配布サイトの Catalyst 4500 は専用 Rtr responder として機能します。 200 のリモートルータのそれぞれは RTR プローブとして機能します。 各プローブは応答側を目標とします直接接続された配布サイトにある。

プローブからレスポンダに送信されるトラフィックのバーストは、ネットワークによって、音声に与えられたものと同じ QOS レベルを与えられる必要があります。 これは RTR プローブからのトラフィックが完全優先 キューイングに応じてあるように低遅延キューイング(LLQ)またはルータの Routing Table Protocol (RTP)プライオリティコンフィギュレーションを調整しなければならないことを意味するかもしれません。 RTP パケットのためのプローブを設定している時、宛先 User Datagram Protocol (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 アクセス リストにこれらの分類行があります:

  • deny ip any any フラグメント

    レイヤ4 アクセス リスト割り当てとして IP断片を、これら暗黙のうちに否定して下さい。

  • 割り当て UDP (ユーザ・データグラム・プロトコル) 10.0.16.0 0.255.239.255 範囲 16384 重要な 32768 10.0.16.0 0.255.239.255 範囲 16384 32768 優位

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

  • 割り当て UDP (ユーザ・データグラム・プロトコル)重要な eq 20000 優位

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

  • 割り当て UDP (ユーザ・データグラム・プロトコル) eq 20000 重要な優位

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

RTR トラフィックの付加により LLQ キューはオーバーサブスクライブされ、実質音声パケットを廃棄しませんこと注意して下さい。 標準 Default60ByteVoice IPM オペレーションはこれらのパラメータの RTP パケットのバーストを送信 します:

  • 要求 ペイロード: 60 バイト

    注: これは RTP ヘッダおよび音声です。 L3 Datagram size を得るために 28 バイト(IP/UDP)を追加して下さい。

  • 間隔: 20 ms

  • パケットの数: 10

これは、バーストの間に、RTR が LLQ 帯域幅の 35.2 Kbs を消費することを意味します。 LLQ 用に十分な帯域幅がない場合は、新しい IPM 操作を作成し、パケット間隔を増やします。 この IPM コンフィギュレーションウィンドウで表示されてパラメータがバーストは 1 だけキロビットの広帯域/秒を消費します:

/image/gif/paws/13938/csaaipm2.gif

結果

このセクションの表は IPM レポートの例です。 このレポートには、RTR プローブの 3 つのインスタンスが含まれています。 1 物理的 な プローブが異なるレスポンダーをターゲットとするか、または異なるペイロードを使用する複数の RTR プローブ 例で設定されるかもしれないことに留意して下さい。

/image/gif/paws/13938/csaaipm3.gif

これらはカラムのそれぞれの意味です:

Avg:

IPM は 1 時間のサンプリングごとに平均を算出します。 これらの毎時平均はさらに長い時間にわたって平均化され、日次、週次、または月次の平均が算出されます。 すなわち、日報のために、IPM は過去 24 時間の毎時間平均を計算します。 それはこの 24 の平均の平均としてそれから毎日の平均を計算します。

Avg 最大値:

この値は図の毎日、週および月のすべての一時間毎最大の平均です。 すなわち、日報のために、IPM は過去 24 時間のそれぞれの内で報告される最も大きいサンプルを奪取 します。 それはこの 24 のサンプルの平均としてそれから毎日最大 平均を計算します。

%に:

これは収集装置のための設定された閾値にあったサンプルのパーセントです。

エラー%:

これは、エラーが発生したパケットのパーセンテージです。 ジッタ プローブはエラーの複数の型を報告します:

  • SD パケットロス—送信元および宛先間の Packets Lost

  • DS パケットロス—宛先とソース間の Packets Lost

  • Busies —前の RTT オペレーションが完了しなかったので Round-Trip Time (RTT) オペレーションが開始できなかった場合の機会の数

  • シーケンス—予想外シーケンス 識別子と受け取った RTT オペレーション 完了の数。 これらはこれがなぜ発生するかもしれませんかいくつかの考えられる原因です:

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

    • 応答はタイムアウトした後受け取られました。

    • 破損パケットは受信され、検出する。

  • ドロップ—これらのどちらかが発生した場合の機会の数:

    • RTT オペレーションは必要な内部リソースが利用できなかったので開始できませんでした(たとえば、メモリまたはシステム ネットワーク アーキテクチャ[SNA]サブシステム)

    • オペレーション 完了は認識できませんでした。

  • MIA (戦闘間の行方不明者) —パケットの数失われる方向が判別することができない。

  • 遅く—タイムアウトの後で着いたパケットの数。

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

実行可能な遅延とジッタの値を取得する最適な方法は、同じネットワーク内にある類似したサイトと比較することです。 192 の Kbps -接続 サイトすべてしかし 1 つのレポート ジッタ 値がおよそ 50 ms、および残りのサイト レポート 100 ms ジッタ、それからそこに問題なら、平常値に関係なく。 IPM はネットワーク全体に進行中の 24x7 遅延 および ジッター測定単位を提供遅延 および ジッター比較に基準として使用するためにベースラインを提供できます。

しかしエラーは異なっています。 原則的には、ゼロ以外のどのエラー パーセントでも赤旗です。 RTR パケットには音声パケットと同じ QoS 処理が行われます。 ネットワーク QoS とコール アドミッション制御が強固であれば、どのようなレベルの輻輳が生じても、音声または RTR パケットについてパケット損失や過度の遅延が起こることはありません。 従って、ゼロ才であると IPM エラーカウントが期待できます。 「標準」とみなすことができる唯一のエラーは巡回冗長検査(CRC)エラー、これら品質 インフラストラクチャでまれであるはずですでありではない。 頻繁である場合、音声クオリティにリスクを構成します。

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

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


関連情報


Document ID: 13938