Cisco テクニカル ソリューション シリーズ：IP テレフォニー ソリューション ガイド

QoS の重要性

音声品質に影響を及ぼす要因には、パケットの喪失およびパケットの遅延という 2 つがあります。 パケットの喪失があると、音声にクリッピングとスキップが発生します。 現在の Cisco DSP アルゴリズムでは、喪失音声が 30 msec 以内であれば補正されます。 Cisco VoIP テクノロジでは、VoIP パケット当たり 20 msec サンプルの音声ペイロードを使用します。 したがって、コーデック補正アルゴリズムを有効にするのに許される喪失パケットは、ある時点では 1 パケットだけです。 パケットの遅延は、エンドツーエンド間のボイス遅延による音質品質の劣化原因となり、または遅延が変動する場合はパケットの喪失の原因となります。 エンドツーエンド間のボイス遅延が長くなる（たとえば、250 msec）と、CB ラジオで 2 人が同時に話しているように聞えてきます。 遅延が変動すると、受信側でジッタ バッファのオーバーランが発生することがあります。 IP ネットワークを介してファックスやモデムのトラフィックを含める場合、ドロップや遅延をなくすことが重要であり不可欠です。 パケット喪失や遅延がどのようにして発生するかその原因を検証することにより、サービス品質（QoS）が企業ネットワークのすべての領域で必要な理由を理解できます。

ネットワークの品質

次の場合、音声パケットがドロップする可能性があります。

• ネットワークの品質が低い

• ネットワークが輻輳している

• ネットワーク内で極端な変動遅延が発生している

ネットワークの品質が低いと、物理的あるいは論理的な接続が切断されるためにセッションが頻繁に使用できなくなることがあります。

（注） この項では、VoIP の設計および実装する上で、物理的および論理的ネットワークが定義した音声設計の方法論にしたがっており、きわめて安定していることを想定しているため、ネットワークの品質については説明しません。

ネットワークの輻輳

ネットワークに輻輳があるときは、パケット ドロップや間隔が不定のパケット遅延が発生することがあります。 ネットワーク輻輳により発生する音声パケットのドロップは、通常、ネットワークの出口になっているどこかのインターフェイスに接続しているトランスミット バッファがどれも満杯であることが原因となって発生します。 リンクあるいは接続の使用率が 100 パーセントに近づくと、それらの接続にサービスしているバッファ キューは満杯になります。 キューが満杯になると、満杯になっているキューへ入ろうとするパケットは廃棄されます。 このような現象は、サービス プロバイダのフレームリレー ネットワークでよく発生するように、キャンパス イーサネット スイッチ上でも発生します。

ネットワークの輻輳は、通常、散発的に発生するため、輻輳による遅延幅は、本質的に変動する傾向があります。 出口インターフェイス キュー待ち時間、または大幅なシリアライゼーション遅延があると、このタイプの変動遅延が発生します。 これら 2 つの要因については、次の項で説明します。

遅延とジッタ

遅延とは、パケットが送信エンドポイントから転送されてから、受信エンドポイントに到達するのに要した時間のことです。 この所要時間は、「エンドツーエンド遅延」と呼ばれ、固定ネットワーク遅延と変動ネットワーク遅延の 2 つの領域に分けることができます。 ジッタは、音声フローにある 2 つの音声パケットのエンドツーエンド遅延合計値におけるデルタ、つまり 2 者の遅延値の差異となります。

固定ネットワーク遅延は、VoIP ネットワークを設計するとき最初に検討しておく必要があります。 国際電気通信連合（ITU）の標準 G.114 では、150 msec の単方向遅延バジェットが許容であるとしています。 シスコのテクニカル マーケティングは、200 msec の遅延バジェットで構築されたネットワークを使用した音声比較では、音質スコアーにほとんど差のないことを証明しました。

固定ネットワーク遅延の例として、送信側エンドポイントと受信側エンドポイント間の信号の伝搬遅延、音声符号化遅延、および各種 VoIP コーデックの音声パケット化時間があります。 伝搬遅延計算の結果は、ほぼ 6.3 Usec/km と算定されます。たとえば、G.729A コーデックの遅延値は、25 msec の符号化遅延値（ 2 つの 10 msec フレーム＋ 5 msec 先読み）とさらに 20 msec のパケット化遅延が追加された値となります。

ネットワーク インターフェイス上の輻輳出口キュー、およびシリアライゼーション遅延は、変動パケット遅延の原因となる可能性があります。 優先順位によるキューイングあるいは低遅延キューイング（LLQ）がなければ、キューイング遅延時間は、リンクの使用率が 100 パーセントに近づくと、シリアライゼーション遅延時間と等しくなります。

シリアライゼーション遅延は、リンク速度とパケット サイズの固定関数です。 パケットがより大きく、リンク クロッキング速度が遅いほど、シリアライゼーション遅延は大きくなります。 これは既知の比率ですが、大きなデータ パケットほど、音声パケットの前の出力キューに随時入ることができる、あるいはまったく入ることができないため、一定にならないと考えられます。 音声パケットがデータ パケットのシリアライゼーションを待機する必要がある場合、音声パケットにより被る遅延は、音声パケット自体のシリアライゼーション遅延に、そのパケットの前に入るデータ パケットのシリアライゼーション遅延がプラスされた値となります。

「ワイド エリア ネットワークを使用可能にする」 で説明している Cisco Link Fragmentation and Interleave（LFI）テクノロジーを使用して、シリアライゼーション遅延を固定遅延値に設定できます。

ネットワークの輻輳は、ネットワーク内でポイントで随時発生する可能性があるため、バッファは瞬時に満杯になる可能性があります。 このバッファが満杯になると、同一のボイス ストリーム内にあるパケット間で遅延時間差が生じることがあります。 この遅延差をジッタといい、パケットの到着予測時間とパケットの実際の受信時間との差異を意味します。 会話内の音声パケット間で発生するこれらの遅延変動を補正するために、VoIP エンドポイントでは、ジッタ バッファを使用してこれらの遅延変化を定数値に変え、音声の円滑な再生を行います。 パケット遅延値での変動を除去するために、音声の再生前にジッタ バッファを使用してパケットを一時的に保持します。

Cisco VoIP エンドポイントは、ジッタ バッファを 20 ～ 50 msec の間で適応可能なジッタ バッファを実装する（DSP）アルゴリズムを使用します。 実際のバッファのサイズは、予想される音声パケットのネットワーク遅延に基づいて 20 ～ 50 msec で変化します。 これらのアルゴリズムは、音声パケットのリアルタイム転送プロトコル（RTP）ヘッダーのタイムスタンプを調べ、予測遅延を計算して、その結果に応じてジッタ バッファのサイズを調整します。 この適応ジッタ バッファの設定時に、「余分」な 10 msec のバッファ部分が変動パケット遅延用に設定されます。 たとえば、パケットのストリームがジッタ バッファに入る場合、またそのジッタ バッファの RTP タイムスタンプを使用して 23 msec のネットワーク ジッタが発生したことを示す場合には、VoIP エンドポイントに必要なジッタ バッファのサイズは、最大で 33 msec となります。 パケットのジッタが、前述の 23 msec の予測遅延変動（23 + 10 = 33 msec の動的に割り当てられている適応ジッタ バッファ スペース）より 10 msec 以上大きくなると、パケットはドロップします。

図 4-1 遅延とジッタ

音声品質は、最も脆弱なネットワーク リンクの品質と同等以上にはなりません。 パケット喪失、遅延および遅延変動はすべて、音声品質を低下させる要因となります。 また、瞬間的なバッファの輻輳がネットワークのどの部分でも、いつでも発生する可能性があるため、ネットワーク品質はエンドツーエンドを設計する上で問題となります。 この項全体で説明する QoS ツールとは、データ ネットワーク上で音声の品質を高める一連のメカニズムのことです。この一連のメカニズムは、ネットワークの輻輳時にドロップする音声パケットを減少させ、ある特定の音声接続で発生する固定遅延と変動遅延の両方を最小限に抑えます。

これらの QoS ツールは、次の 3 つのカテゴリに分類されます。

• 分類

• キューイング

• ネットワーク プロビジョニング

この項の記載例で設定されている Cisco QoS ツールは、図 4-2に基づいています。

図 4-2 QoS ネットワーク図

分類

分類とは、パケットあるいはフローに特定の優先順位を付けてマーキングすることを意味します。 このマーキングにより、トラスト境界が設定され、強制的に実行される必要があります。

分類は、ネットワークのエッジ、通常、ワイヤリング クローゼットあるいは IP Phone内、つまり音声エンドポイント自体の内部で実行される必要があります。 パケットには、802.1Q ヘッダーの 802.1p 部分にあるユーザ プライオリティ ビット内のレイヤ 2 クラス オブ サービス（CoS）設定値（図 4-3を参照、または、Ipv4 ヘッダーのタイプ オブ サービス（ToS）バイト内の IP Precedence/DSCP（識別サービス コード ポイント）（ 表 4-2 を参照）を使用して、パケット内の重要のマークを挿入するることができます。

IP Phoneのすべての RTP パケットには、レイヤ 2 802.1p 設定では CoS = 5 の値、レイヤ 3 設定では IP Precedence = 5 の値のタグを付ける必要があります。 さらに、すべての制御パケットには、レイヤ 2 設定で CoS = 3 の値、レイヤ 3 設定で ToS = 3 の値のタグを付ける必要があります。

前述の例では、IP Precedence を使用してトラフィックにマークを付ける方法は、すべての IP デバイスが DiffServe コード ポイントをサポートするまでの移行ステップとして使用されています。 理想としては、Cisco VoIP エンドポイントは、RTP 音声ベアラ フローには明示的転送（EF）の DSCP 値を使用し、VoIP 制御トラフィックには保証転送 31（AF31）に等しい DSCP 値を使用するようになることです。 分類の詳細は、 「IP Phoneの接続」 を参照してください。

図 4-3 分類

キューイング

キューイングとは、ネットワークでの処理が適切に行われるように複数のキューの 1 つに、パケットあるいはフローを分類に基づいて割り当てることを意味します。

データ、音声およびビデオが同じキューに入れられると、パケット喪失および変動遅延はきわめて発生しやすくなります。 出口インターフェイスで複数のキューを使用し、音声パケットをデータ パケットとは別のキューに入れることで、ネットワークの動作ははるかに予測しやすくなります。 バッファがネットワークのどの部分でもキャパシティに到達する可能性があるため、キューイングについては、このマニュアルのすべての項で説明します。

シリアライゼーション遅延への対処は、総合的なキューイング ソリューションの一部と見られています。 シリアライゼーション遅延は、低速リンク上での 1 つの要素でしかないため、その問題については、 「ワイド エリア ネットワークを使用可能にする」 で説明します。

ネットワーク プロビジョニング

ネットワークのプロビジョニングでは、音声会話、すべてのデータ トラフィック、すべてのビデオアプリケーション、およびルーティング プロトコルのような、リンク管理必須オーバーヘッドに必要な必須帯域幅を正確に計算する必要があります。

音声が WAN を通過できるようにするために必要な帯域幅の量を計算するときは、組み合わせたすべてのアプリケーション トラフィック（音声、ビデオおよびデータ）が、設定した帯域幅の 75 パーセント以上にならないようにする必要があります。このことは重要なことなので、この規則を忘れないようにしてください。 残りの 25 パーセントは、オーバーフローおよびルーティング プロトコルのような管理オーバーヘッドに使用します。 VoIP 帯域幅計算、ATM（非同期転送モード）セル オーバーヘッド、およびネットワークのプロビジョニングに関するその他の詳細については、 「ワイド エリア ネットワークを使用可能にする」 で説明します。

IP Phoneの接続

この項での強調または推奨する事項は、次のとおりです。

• ワイヤリング クローゼットのスイッチでのポート設定にオートネゴシエーションを使用する

• IP Phoneを音声専用サブネット上に分類する

• PortFast を使用して IP Phoneのブート時間を短縮させる

• trust-ext コマンドを使用して、分類トラスト境界を電話に拡張する

• PC のアプリケーションが 5 ～ 7 の CoS あるいは ToS 値でトラフィックを送信できないようにする

• レイヤ 3/4 のインテリジェント ワイヤリング クローゼットだけを SoftPhone で使用する

IP Phoneをキャンパス ネットワークに接続するには、次の 4 つの方法があります（図 4-4を参照）。

• 単一ケーブルを使用する

• 複数のケーブルを使用する

• PC 上で動作する SoftPhone アプリケーションを使用する

• 別個のスイッチを使用する

保証音声品質を提供する際には、これらの接続方式にそれぞれに次のような問題があります。

• 電話への接続に使用する速度とデュプレックスの設定値

• 使用する VLAN と IP のアドレッシング方式

• IP Phoneでの分類とキューイングにより VoIP フローを処理する方法

図 4-4 IP Phoneの接続モデル

（注） IP Phoneは、イーサネット ハブのような共有メディア デバイスに接続できません。 この時、IP Phoneはカスケード接続もできません。 IP Phoneを正確に接続することが、企業ネットワークで QoS を使用可能にする最初のステップです。

単一ケーブルによる IP Phoneのインストール

多くの企業が、単一ケーブルによる IP Phoneのインストール モデルを使用して IP テレフォニー ネットワークを配備するには、次の理由があります。

• インストールの容易性

• ケーブル接続に必要なインフラストラクチャにかかるコストの節約

• ワイヤリング クローゼット スイッチ ポートによるコスト節約

これらのコスト節約には、特に QoS が関係する追加スイッチ機能の要件が関係します。 この要件には、たとえば、イーサネット リンク速度およびデュプレックス、レイヤ 2 CoS、および IP Phoneとワイヤリング クローゼット イーサネット スイッチの両方におけるキューイングを正確に設定する必要があります。図 4-5では、QoS が問題となる可能性のある領域を示しています。

図 4-5 可能性のある QoS 問題領域

速度とデュプレックス設定

IP Phoneの 10/100 イーサネット ポートは、ユーザが設定できないスピードとデュプレックスを設定するオートネゴシエーションをサポートしています。 PC のネットワーク インターフェイス カードもオートネゴシエーションを使用しますが、イーサネットのスイッチ ポートが 10BaseT 半二重に対して設定されていると、リンク スピードの不一致により、インターフェイス バッファのオーバフロー状況が発生する可能性があります。 IP Phoneとスイッチの間のこの半二重接続は、通常問題となることはありませんが、100BaseT 全二重から 10BaseT 半二重集束へ集約されるときにバッファの輻輳が発生する可能性があります。 きわめて高速のビデオ ストリームのような激しいトラフィックの期間中、半二重接続では、遅延しているパケットからのパケット喪失を生じる可能性があります。 パケットの遅延は、セグメント上での過度の衝突により発生します。 スイッチと IP Phoneの両方とも、音声に対してプライオリティー キューを使用しますが、常に、音声トラフィックを最初に送信します。 ただし、高速ビデオ ストリームも、できる限り多くのパケットを送信します。 スイッチあるいは電話のいずれか（ビデオ フローの進行方向による）が、音声トラフィックを送信しようとした場合、転送の試行時に音声トラフィックの衝突が発生する可能性があります。 この結果、音声パケットの遅延が発生します。

（注） この多大なトラフィック損失例は、通常の企業環境ではめったに発生しませんが、SmartBits を使用して、MPEG ビデオのストリームをラボラトリでシミュレートすると、その損失例が再現されることがあります。

この問題に対する最善の対処法は、すべての電話接続のオプションについてスイッチ ポートをオートネゴシエーションに設定することです。 ポートが静的に 100BaseT 全二重に設定されている場合、IP Phoneは、自動的にそのポートを 100BaseT 半二重に設定するため、デュプレックスで不一致が発生します。 この問題の説明は、『Configuring and Troubleshooting Ethernet 10/100Mb Half/Full Duplex Auto-negotiation』のテクニカル情報を参照してください。このテクニカル情報は、次のサイトにあります。

http://www.cisco.com/warp/public/473/3.html .

すべてのユーザが NIC 設定を修正して 100BaseT 全二重を使用可能にできるため、この IP テレフォニー 設定には、オート ネゴシエーションの使用をお勧めします。 また、オートネゴシエーションは 100BaseT 全二重のポート スピードをイネーブルにできるため、IP テレフォニー のロールアウトにオートネゴシエーションを実装して、インフラストラクチャが高速ビデオアプリケーションをサポートできるようにします。

また、CatOS PortFast メカニズムを使用して、電話のアクセス ポートを即座に転送状態に移行させるように設定できます。 この設定により IP Phoneのブート時間が短縮されます。 port host コマンドを Catalyst 4000 と Catalyst 6000 に、そして、 spanning-tree portfast コマンドを 2900XL と 3500XL に設定して、DTP と PagP をオフにし、portfast をイネーブルにします。

（注） 電話のブート時間は、電話が常に給電され常時接続されているため、通常、問題になることはありません。

• Catalyst 4000 と Catalyst 6000 ：イーサネット スイッチの Catalyst 4000、2948G、2980G および 6000 の回線上で、ポートを次のように設定できます。

• Catalyst 3500/2900 XL ： Catalyst 3500 と Catalyst 2900 XL のスイッチで、ポートを次のようにして設定できます。

IP アドレッシング

IP Phoneにスピードとデュプレックス設定値を設定したら、IP アドレッシングについて考慮する必要があります。 IP アドレッシングには、次の 3 つのオプションがあります。

• 新しいサブネットを作成し、別の IP アドレス スペース（登録済みあるいは RFC 1918 アドレス スペース）にある IP Phoneにそのサブネットを使用する。

• 既存のデータ デバイス（PC あるいはワークステーション）と同じサブネット内で IP アドレスを提供する。

• 既存の IP アドレス スペースで新しいサブネットを開始する（組織で使用される全体の IP アドレッシング計画を作成しなおすことが必要となる場合があります）

これらのオプションはすべて、DHCP あるいは静的 IP アドレス設定を使用して、実装が可能です。 IP Phoneを追加すると、組織が必要とする IP アドレス スペースに対する必要性も増す可能性があります。 このことが、問題とならない企業もありますが、一方では、特定のサブネットあるいは、企業全体でも使用可能なアドレス スペースがないという企業もあります。 管理と QoS の理由により音声とデータ ネットワークを分離しなければならないと同様に、IP アドレス スペースの関係から、シスコは IP Phoneに対して新しいサブネットを作成することを推奨します。

（注） 個別のサブネットおよび分離可能な、個別の IP アドレス スペースを使用することが必要ですが、一部の小さなブランチ オフィスなどでは、これらを個別に持つことができない場合があります。 IP Phoneとデータ デバイスの両方に接続するため必要な、単一アドレス スペースの設定については、「ブランチ オフィスの構築」を参照してください。

図 4-6 IP アドレッシング

• Catalyst 4000 と Catalyst 6000 ： set port auxiliaryvlan CatOS コマンドを次のように使用して、これらの IP Phone 802.1Q アクセス トランクを Catalyst 2948G、2980G、4000 および 6000 に作成します。

• Catalyst 3500/2900 XL ： Catalyst 3500 と 2900 XL シリーズで、次のような別のコマンド セットを使用して前述と同様の機能を設定できます。

（注） トラブルシューティングを容易にするために、VLAN をサブネット アドレスに一致させるように設定できます。

Cisco IP Phone での分類とキューイング

トラフィックを可能な限りネットワークのエッジに近いものとして分類（マーキング）することは、常に、シスコのネットワーク設計アーキテクチャに不可欠の部分です。 単一ケーブルのモデルを使用して IP Phoneを接続すると、その IP Phoneが管理対象ネットワークのエッジとなります。 したがって、IP Phoneでトラフィック フローを分類することが可能であり、また分類する必要があります。

802.1Q ヘッダーの 802.1p 部分にある 3 つのユーザプライオリティ ビットは、レイヤ 2 CoS 情報のシグナリング用に使用されます。 デフォルトでは、IP Phoneからのすべての VoIP RTP ベアラは、レイヤ 2 CoS 値を 5 に、レイヤ 3 IP Precedence 値を 5 に設定します。IP Precedence の使用は、すべての Cisco VoIP デバイスが最終的にレイヤ 3 分類の DSCP に移行するまでの移行ステップです。 移行完了時には、DSCP を使用する Cisco VoIP エンドポイントは、IP Precedence の代わりに、46 という DSCP 値、つまり緊急転送（EF）を使用します。 IP Phone内と企業ネットワークの両方で分類とキューイングがどのように作動するかを検証する際には、これらの CoS と ToS の値が重要となります。

Cisco IP Phone の中心部には、3 ポートの 10/100 スイッチがあります。 そのうちの 1 つのポート、P0 は内部ポートで、電話内の実際の音声電子機器を接続するために使用されます。 ポート P1 は、デイジーチェーン PC の接続に使用され、ポート P2 はワイヤリング クローゼット イーサネット スイッチへのアップリンクに使用されます。 各ポートには、単一のしきい値（4Q1T）が設定された 4 つのキューがあります。 これらのキューの 1 つである、キュー 0 は、すべてのブリッジ プロトコル データ ユニット（BPDU）および CoS = 5 のトラフィックに使用される高優先度キューです。 これらのキューは、高優先度キューで使用されるタイマーを使用したラウンドロビン方式ですべてサービスされます。 キューのスケジューラーが他のキューをサービスしている間に、このタイマーの期限が満了すると、スケジューラーは自動的に高優先度キューに戻り、キューのそのバッファーを空にして、音声品質を確保します。 図 4-7では IP Phoneのキューイングを示します。

図 4-7 IP Phoneのキューイング

IP Phoneの高優先度キューは、どのレイヤ 2 CoS = 5 のすべてのトラフィックにもアクセスできるため、IP Phoneのアクセス ポートに接続されている PC もトラフィックを分類しないようにすることが重要です。 イーサネット スイッチのトラスト境界を IP Phoneまでとし、それより先まで拡張しないことをお勧めします。

図 4-8 IP Phoneのトラスト境界

• Catalyst 6000 ： CatOS 5.5 の set port trust-ext コマンドを使用します。 このコマンドは、すべての VoIP フレームの CoS = 5、および接続した PC からのすべてのデータ トラフィックの CoS = 0 としてマーキングするよう IP Phoneに指示します。この CoS 値を操作するように IP Phoneを設定すると、IP Phoneの CoS を受け入れるラインカードも設定する必要があります。 この設定を最善の方法で完了するには、補助 VLAN にあるイーサネット ポートでの CoS 分類のすべてをトラストするように ACL を設定することです。 次の CLI コマンドをこれらのスイッチに使用します。

• Catalyst 2948G、2980G および 4000 ： Catalyst 2948G、2980G および 4000 は、現在のところ、 set port qos <mod/port> trust trust-ext コマンドを提供していないことに留意してくだい。 したがって、これらのスイッチでは、IP Phoneのデフォルト設定に依存しなければなりません。この設定は、すべての VoIP ストリームに CoS = 5 を使用し、PC 上のすべてのトラフィックを CoS = 0 に再分類します。

• Catalyst 3500/2900 XL ：単一ケーブルのモデルを使用して IP Phoneを Catalyst 3500 と 2900 XL に接続するとき、前述と同様の機能が必要になります。 IP Phoneが PC からの CoS 設定値をトラストしないように設定するには、次のコマンドを使用します。

複数ケーブルによる IP Phoneのインストール

一部の企業では、次の理由により、「IP Phone用複数ケーブル」のインストール モデルを使用した IP テレフォニー ネットワークの配備を計画しています。

• PC を接続する 2 番目のイーサネット ポートのない IP Phoneを配備する

• 音声とデータ ネットワークの間に物理的なセパレ-ションを作成する

• データ インフラストラクチャをアップグレードせずに、IP Phoneにインライン電源の供給を容易にする

• UPS（無停電電源装置）の電源を必要とするスイッチの数を制限する

• ネットワークの CatOS アップグレードの量を制限する

• ワイヤリング クローゼット スイッチのスパニングツリー設定を制限する

スピードとデュプレックス

IP Phoneの後ろに PC がない場合、ポートのスピードとデュプレックスの設定はさほど重要ではありません。 単一ケーブルの IP Phone インストールと同一の設定モデルを使用することが安全な設定といえますが、この設定は必須ではありません。

IP アドレッシング

IP テレフォニー に対して、個別の IP サブネットと個別の VLAN を使用することを推奨します。

（注） IP のルーティング設定のため、個別のサブネットおよび分離可能な別個の IP アドレス スペースを使用することが必要ですが、一部の小さなブランチ オフィスなどでは、これらを個別に持つことができない場合があります。 IP Phoneとデータ デバイスの両方に接続するための単一アドレス スペースの設定に関する詳細は、「ブランチ オフィスの構築」を参照してください。 IP ルーティングがリモート ブランチにある追加サブネットを処理できる場合、Cisco Network Registrar と二次アドレッシングを使用できます。

IP Phoneに必要な分類とキューイング

IP Phoneとデータ PC は、別々の物理ケーブル上に存在するため、IP Phoneでのキューイングは不要です。 ただし、IP Phoneは管理対象装置であるため、分類は、IP Phoneあるいは入り口アクセスのスイッチ ポート上で実行される必要があります。 VoIP パケットに対するこの分類は、ワイヤリング クローゼット スイッチで使用しているハードウェアに応じて、さまざまな方式で処理できます。 次のシナリオを参照してください。

• Catalyst 6000 ：図 4-9図 4-9では、Catalyst 6000 はワイヤリング クローゼット スイッチとして使用されています。 ポート 3/1-24 は IP Phoneに接続され、ポート 3/25-48 はデータ専用 PC に接続されています。この接続は、しっかりと管理された環境であるため、レイヤ 2 CoS のすべての設定値が Catalyst 6000 で実施されます。

図 4-9 複数ケーブルを使用した Catalyst 6000 の例

• Catalyst 4000 ：現在のところ、Catalyst 2948G、2980G および 4000 のスイッチには、 auxialaryvlan コマンドに対する「dot1p」拡張がありません。 IP Phoneの 802.1p 分類をスイッチ QoS に対して使用するには、ポート VLANID と同じ値を使用して補助 VALN を設定します。この設定により、IP Phoneがパケットを適切な CoS 設定値でマーキングできるようになります。

• Catalyst 3500/2900 XL ：トラストの設定をポート レベルで設定するときに使用する別のオプションです。 Catalyst 3500 と 2900 XL シリーズのスイッチでは、802.1p あるいはポートベースの CoS 設定値のどちらもトラフィックの分類に使用できます。 ポートベースの設定は、図 4-10で示した設定に類似しています。

図 4-10 複数ケーブルを使用した Catalyst 3500/2900 の例

SoftPhone

一部の企業では、IP Telephony SoftPhone アプリケーションを使用して IP テレフォニー を配備することを考慮しています。 さらに、多くの企業は PC ベースの VoIP アプリケーションの使用が可能であるかの評価を求めています。 SoftPhone がレイヤ 4 のアプリケーションであるため、すべての VoIP ベアラ トラフィックの分類とその結果に基づくプライオリティ キューイングは、レイヤ 4 が可能な最初のネットワーク デバイス上でだけで実行されます。 複数のキューもサポートし、レイヤ 4 を使用できるワイヤリング クローゼット イーサネット スイッチのモデルは、PFC がインストールされた Catalyst 6000 に限定されます。

スピードとデュプレックス

ワイヤリング クローゼット スイッチのすべてのアクセス ポートは、全二重 100BaseT に設定する必要があります。 PC の CPU のスピードが非常に高速であるため、半二重 10BaseT 接続では、データに音声不足が発生する可能性があります。 Catalyst スイッチでのスピードとデュプレックスの設定に関する詳細は、 「単一ケーブルによる IP Phoneのインストール」 を参照してください。

IP アドレッシング

SoftPhone アプリケーションは PC 上で実行されるため、IP アドレッシングは問題となりません。

IP Phoneでの分類とキューイング

SoftPhone アプリケーションは PC 上で動作（PC の MAC と IP アドレスを共用）するため、VoIP パケットを優先順位トラフィックとしてラベル付けする分類メカニズムを確立することは非常に困難です。 PC がデータ パケットにマーキングを実行できないため、アクセス イーサネット スイッチは、PC からのレイヤ 2 CoS マーキングのすべてをトラストできません。 ポートベースの CoS 設定も同様の理由により役に立ちません。 事実、すべてのオプションの検査後、SoftPhone VoIP ストリームの分類を実行できる唯一の方法は、レイヤ 4UDP ポート番号でフィルタに掛けることです。 フィルタを掛けるには、ディストリビューション レイヤへの最初のアップリンク前に音声トラフィックに優先順位を付ける必要があるため、アクセス スイッチはレイヤ 3 と 4 を認識できるものである必要があります。 そのため、複数キューを装着しているワイヤリング クローゼット スイッチの選択肢は、PFC がインストールされた Catalyst 6000 に限定されます。

• PFC がインストールされた Catalyst 6000 ：この例では、Catalyst 6000 は、ワイヤリング クローゼット スイッチとして使用されています。 6000 のスーパーバイザ エンジンには、レイヤ 3/4 QoS インテリジェンスを提供する PFC ドーター カードがインストールされています。 PC に接続されているアクセス ポートはトラストされないため、PC からのすべての CoS あるいは ToS 設定値は無視されます。 VoIP ベアラ ストリームにフィルタを掛け、それを EF の DSCP 値に再分類するように ACL（ACL_SOFTPHONE）を設定します。

個別のアクセス レイヤ スイッチ

企業によっては、まったく個別のスイッチをワイヤリング クローゼットに使用した IP テレフォニー の配備を考慮しています。 これらの企業では、現在使用中のデータ スイッチをアップグレードしない、または音声とデータのネットワークを完全に分離しておくことが良いと思われています。 このタイプのインストールは、ワイヤリング クローゼット スイッチの別のポートを使用するシナリオとほぼ同じです。

スピードとデュプレックス

IP Phoneの後ろに PC がないため、ポートのスピードとデュプレックスの設定はさほど重要ではありません。 安全な設定として、単一ケーブルの IP Phone インストールと同一の設定モデルを使用することがありますが、これは必須ではありません。

IP アドレッシング

IP テレフォニー に対して、IP アドレス スペースと VLAN をそれぞれ別個に使用することを推奨します。 この場合、新たにインストールした VoIP 専用のイーサネット スイッチ、つまり、2 番目のスイッチ全体が単一の VLAN を実行します。 IP Phoneとイーサネット スイッチ間のトランキングは必要ありません。 ただし、802.1p を使用して IP Phoneからの VoIP パケットに「重要」とタグ付けすることをお奨めします。

IP Phoneに必要な分類とキューイング

IP Phoneとデータ PC は、別々の物理ケーブル上に存在するため、IP Phoneでのキューイングは不要です。 ただし、IP Phoneは管理対象装置であるため、IP Phoneでの分類を実行する必要があります。 VoIP パケットに対するこの分類は、ワイヤリング クローゼット スイッチで使用されているハードウェアに応じて、さまざまな方式での処理が可能です。 ワイヤリング クローゼット スイッチがレイヤ 2 専用のデバイスの場合、IP Phoneの CoS 設定がアクセス レイヤでの分類に使用され、ディストリビューション レイヤへ入れられます。 次の例を参照してください。

• Catalyst 3500/2900 XL

高速キャンパスを使用可能にする

この項では、次の事項を強調または推奨します。

• 複数のキューをすべてのインターフェイスに割り当てて音声の品質を保証する必要がある

• ワイヤリング クローゼット スイッチで UplinkFast を使用し、Catalyst 2900 XL、3500、2948G、2980G、4000 および 6000 スイッチで高速のコンバージェンスをイネーブルにする。 これらのスイッチには複数の出力キューがあります。

• すべての IP テレフォニー 制御と管理トラフィックの CoS値 と ToS 値を最高で 3 に設定する。

• PC のアプリケーションが 4 ～ 7 の CoS あるいは ToS 値でトラフィックを送信できないようにする。

• ディストリビューション レイヤ スイッチが、レイヤ 3 ToS を レイヤ 2 CoS 値にマップできるようにする。

IP テレフォニー に必要なキャンパスのスイッチング設計

最近まで、QoS は、ネットワーク トラフィックのバースト特性とバッファのオーバーフロー機能により、企業キャンパスで問題となることはないとされていました。 しかし、キャンパスでは帯域幅ではなく、バッファリングが主要な問題であることが認識されるようになりました。したがって、これらのバッファを管理して、バッファの損失、遅延および遅延変動を最小限に抑えるために QoS ツールが必要となります。

図 4-11 QoS の問題領域（3 の 1）

転送バッファは、ネットワークに大量の小さい伝送制御プロトコル（TCP）パケットと重なって生じる高速キャンパス ネットワークでその容量がいっぱいになる傾向があります。 出力バッファが満杯になると、入り口のインターフェイスは、新しいフローのトラフィックを出力バッファに入れることができません。 入り口のバッファが満杯になる（瞬時に満杯になる可能性がある）と、パケット ドロップが発生します。 これらのドロップは、通常、どの所定フローでも 1 つのパケットより多くなります。 現在の Cisco DSP アルゴリズムは、30 msec の喪失音声を補正できます。 Cisco VoIP テクノロジーでは、VoIP パケット当たり 20 msec サンプルの音声ペイロードを使用します。つまり、どの所定の時間でも、喪失が許されるのは、1 つの RTP パケットだけとなります。 連続した 2 つのパケットが失われると、音声の品質が低下します。

図 4-12 QoS の問題領域（3 の 2）

VoIP トラフィックは、遅延およびドロップの両方からの影響を受けます。 シリアライゼーション時間は、非常に速いギガビット イーサネットのトランクをキャンパスで使用している限り、キュー バッファのサイズに関係なく、遅延が要素となることはありえません。 ただし、ドロップはキャンパスの音声品質にマイナスの影響を及ぼします。 ドロップの可能性をなくす唯一の方法としては、転送インターフェイスで複数のキューを使用することです。このドロップは、100 パーセントのキャパシティで動作するバッファが原因で発生します。 音声とビデオをそれぞれの独立したキューに入れることにより、データ送信バッファがフローで満杯になっていても、入り口インターフェイスでパケットフローのドロップを防止することができます。

図 4-13 QoS の問題領域（3 の 3）

（注） Catalyst スイッチ上の QoS（複数キュー）を イネーブルにする場合、フロー制御がディセーブルになっていることを確認することが重要です。 フロー制御は、キューイングがアクティブになる前に、ポート上で動作することにより設定済みのキューイング動作に干渉します。 フロー制御は、デフォルトではディセーブルとなっています。

スケジューラーのプロセスではさまざまな方式を使用して、これらの送信キューごとにサービスを実行できます。 最も簡単な方式は、ラウンドロビン（RR）アルゴリズムです。これは、キュー 1 からキュー N までを順番にサービスする方式です。 この方式は、堅牢ではありませんが、ブランチ オフィスとワイヤリング クローゼット スイッチに使用できるきわめて簡単で効果的な方式です。 ディストリビューション レイヤ スイッチは、より優先順の高いトラフィックにスケジューリングの「重み」が与えられるように、加重ラウンドロビン（WRR）アルゴリズムを使用します。 もう 1 つのオプションとして、遅延とドロップの影響を受けやすいアプリケーションに対してラウンドロビンあるいは加重ラウンドロビンのスケジューリングを優先順位のスケジューリングと組み合わせる方法があります。 この方法では、優先順位キュー（PQ）を使用します。このキューは、キューに複数のパケットがある場合、常に最初にサービスされます。 PQ にフレームがない場合、ラウンドロビンあるいは加重ラウンドロビンを使用して、追加キューがスケジュールされます。

次のようにして、キャンパスの転送インターフェイスで実際に必要となるキューの数を考慮することが重要です。

• 各 CoS 値に必要なワイヤリング クローゼット スイッチへキューを追加する必要があるか

• 8 つのキューをディストリビューション レイヤ スイッチへ追加する必要があるか

• 64 DSCP 値ごとにキューを追加する必要があるか

各ポートのバッファ メモリの量には制限があることに留意することが重要です。 単一のキューは、バッファのすべてのメモリ アドレスにアクセスします。 2 つめのキューを追加するとすぐに、有限のバッファ量は 2 つのキューのそれぞれに分割されます。 スイッチに入ってくる分類されていないすべてのフレームは、新しく作成した 2 つめのキューに入ろうとして、バッファしたメモリ レジスタのさらに小さな部分を競い合います。 したがって、高トラフィックの期間中にバッファは満杯になり、フレームは入り口インターフェイスでドロップしてしまいます。 ネットワーク トラフィックの大部分が TCP ベース（TCP ACK（40 バイト）、TCP SYN/ACK（44 バイト）、および 512 ～ 1024 バイトの TCP アプリケーション トラフィック（SMTP、HTTP、FTP）を含む）であることを考慮すると、ドロップしたパケットは、結果として再送信されることになります。 つまり、TCP 指向ネットワーク内でドロップしたパケットがネットワークの輻輳を増幅させることになります。 キューイングの使用は慎重に、そして、特定のドロップおよび遅延の影響を受けやすい優先順位のトラフィックがネットワークを通過する場合に限り使用する必要があります。

バッファ管理があまり重要とはならないワイヤリング クローゼット スイッチには、2 つのキューがあれば十分です。 これらのキューをトラフィックの集約量と比較すると、スケジューラーのプロセスが非常に高速であるため、これらのキューがラウンドロビン、加重ラウンドロビンあるいはプライオリティ キューイングのいずれの方式でサービスされているかは、あまり重要ではありません。

フローの集約はディストリビューション レイヤで発生するため、ディストリビューション スイッチには、より複雑なバッファ管理が必要となります。 優先順位キューだけでなく、標準キュー内にしきい値も必要となります。

シスコは、インターフェイス キューの数を頻繁に増やしていく方式ではなく、キュー内で複数のしきい値を使用する方式を採用しました。 キューを設定して割り当てるたびに、そのキューに関連付けられたすべてのメモリ バッファは、キューのエントランス基準に適合したフレームによってのみ使用されます。 たとえば、Catalyst 4000 10/100 イーサネット ポートに 2 つのキューが設定されていると想定します。 1 つが VoIP（VoIP ベアラと制御トラフィック）用のキューで、これは、デフォルトのキューです。もう 1 つは、HTTP、電子メール、FTP、ログイン、NT 共用、および NFS で使用されます。 128KB のキューは、7 対 1 の送信と受信の比率に分割されます。 TX バッファ メモリは、その後さらに 4 対 1 の比率で高優先順位区画と低優先順位区画に分けられます。 デフォルトのトラフィック（Web、電子メールおよびファイル共用）がわずか 24KB のデフォルトのキューに輻輳を発生させると、VoIP 制御トラフィックがそのキュー バッファのどれを使用しているかに関係なく、パケットのドロップが入り口のインターフェイスで始まります。 TCP 指向アプリケーションでのドロップしたパケットは、これらアプリケーションはいずれもデータの再送信をするため、ネットワークの輻輳した状況を悪化させることになります。 この同じシナリオが 1 つのキューに設定されているが、輻輳を回避するために複数のしきい値が使用されている場合、デフォルトのトラフィックは、VoIP 制御トラフィックとバッファ スペース全体を共用します。 輻輳中に限り、全バッファ メモリ全体が飽和に近づくと、低優先順位のトラフィック（HTTP と電子メール）がドロップすることになります。

このことは、複数キューが IP テレフォニー ネットワークで不可欠なコンポーネントではないと述べている訳ではありません。 前述したように、VoIP ベアラ ストリームは、ドロップと遅延による音声品質へのマイナスの影響を排除するために、別個のキューを使用する必要があります。 しかし、結果として生じるデフォルト キューのサイズが小さいために多数の TCP が再送信され、実際には、輻輳を増幅させる結果となります。そのため、すべての単一 CoS 値あるいは ToS 値が、それぞれ独自のキューを取得できなくなります。

VoIP ベアラ チャネルも、重み付けランダム早期検出（WRED）のようなキュー輻輳回避アルゴリズムとしては好ましくない選択肢です。 事前設定されたしきい値が指定されている場合に、キューのしきい値付けは、WRED アルゴリズムを使用してキューの輻輳を管理します。 輻輳が増幅し始めると、バッファ輻輳のモニタリングおよび TCP パケットの廃棄により WRED が動作します。 ドロップの結果、送信エンドポイントがドロップしたトラフィックを検出し、ウィンドウ サイズを調整して TCP の送信速度を遅くすることになります。 WRED のドロップしきい値とは、バッファの使用率のパーセンテージです。この使用率とは、より高い優先度の CoS 値のトラフィックがバッファを利用できるように、指定した CoS 値のトラフィックがドロップするパーセンテージです。 重要なのは、アルゴリズム名で「ランダム」という単語です。 重み付けが設定されていても、WRED はどのフロー内でもパケットを廃棄できます。統計的には、低順位 CoS しきい値からドロップする可能性が高くなります。

制御トラフィックと管理トラフィックのマーキング

シスコの内部ネットワークのような高トラフィックの負荷があるネットワークでは、ユーザが良い感触を確実に得られるようにするために、制御トラフィックの送信管理が非常に重要となります。 たとえば、ダイヤルトーンに対する遅延（DTT）時間では、IP Phoneは Skinny Station プロトコルを使用して CallManager と通信します。 IP Phoneは、オフフックになると CallManager にその対応を尋ねます。CallManager は IP Phoneにダイヤルトーンを再生するよう指示します。 この Skinny Client プロトコル管理と制御トラフィックがネットワーク内でドロップあるいは遅延すると、品質は低下します。 同じような考え方が、ゲートウェイおよび電話に対するすべてのシグナリング トラフィックにも当てはまります。

この制御と管理トラフィックが重要（ただし、実際の RTP ストリームほど重要ではない）とマーキングされるようにするには、ACL を使用して、これらのストリームをレイヤ 3/4 を認識する Catalyst 5000 と 6000 スイッチ上で分類します。 次に、これらの設定例を詳しく説明します。 Cisco IOS ルータが最初のレイヤ 3/4 のアクセス ポイントとなるように設計するには、アクセス リストを使用します。 その例については、 「ワイド エリア ネットワークを使用可能にする」 を参照してください。

図 4-14 制御トラフィックと管理トラフィックのマーキング

Skinny プロトコル

CallManager は、TCP ポート 2000 ～ 2002 を使用して、IP Phoneおよびゲートウェイと通信します。次の例のコマンドでは、IP Phoneとゲートウェイ（VLAN 110）および CallManager（4/2）からのすべてのSkinnyトラフィックを DSCP 26（IP Precedence 3 とバックワード コンパティビリティのある AF31）として分類します。

（注） Ver.3.0(5)のリリースにより、Cisco CallManager には、CallManager、IP Phoneそして Skinny ゲートウェイからのすべての VoIP 制御と管理トラフィックに対して、CoS と ToS の値を設定できる能力が含まれます。 前述の分類がサポートされると、Skinny VoIP 制御トラフィックのマーキングにネットワーク要素アクセス リストは不要となります。 H.323 と MGCP トラフィックは、ここ当分の間、外部のネットワーク要素マーキングを必要とします。

前述コマンドのそれぞれが次の機能を実行します。

• スイッチ全体で QoS をイネーブルにする。

• アクセス リスト（ACL_IP-PHONES）を作成し、DSCP 値が 26（AF31）の IP Phoneと Skinny ゲートウェイからの Skinny Client/Gateway プロトコルのトラフィックのすべてをマーキングする。

• ACL_IP-PHONE アクセス リストを追加し、ToS = 5 の RTP トラフィックが書き換えられないように、IP Phoneからのすべての DSCP マーキングをトラストする。

• アクセス リスト（ACL_VOIP_CONTROL）を作成し、DSCP 値が 26（AF31）の CallManager から Skinny Client/Gateway プロトコルのトラフィックのすべてをマーキングする。

• 着信レイヤ 2 CoS 分類を受け入れる（パーサーがエラーを戻しても、現在の 10/100 1 ラインカードの trust-cos がイネーブルになっている必要がある）。

• ポートに対応するすべての QoS が、VLAN ベースで実行されることをポートに通知する。

• IP Phone イーサネット ASIC 内で、PC からの CoS の値を CoS=0 に書き換えるように IP Phoneに指示する。

• ポートに対応するすべての QoS が、ポートベースで実行されることを CallManager ポート（4/2）に通知する。

• アクセス リストをハードウェアに書き込む。

• ACL_IP-PHONE アクセス リストを補助 VLAN にマップする。

• ACL_VOIP_CONTROL アクセス リストを CallManager ポートにマップする。

H.323

CallManager は、TCP ポート 1720（H.225）と 11 xxx（H.245）を使用して、H.323 ゲートウェイと通信します。 次のコマンドでは、CallManager（4/2）と H.323 ゲートウェイからの H.323 制御トラフィックを DSCP 26（IP Precedence 3 とバックワード コンパティビリティがある AF31）として分類します。

MGCP

CallManager は、UDP ポート 2427 を使用して MGCP ゲートウェイと通信します。次のコマンドでは、CallManager（4/2）および MGCP ゲートウェイ（4/4）からの MGCP 制御トラフィックを DSCP 26（IP Precedence 3 とバックワード コンパティビリティがある AF31）として分類します。

次の例にある、 show コマンドを使用して、ACL が正しい VLAN とポートに接続されているかを確認します。

Catalyst 6000 アクセス レイヤ

IP テレフォニー で最も定評のあるキャンパス設定の 1 つとして、ワイヤリング クローゼットとディストリビューション/コア レイヤの両方で Catalyst 6000 スイッチを使用する設定があります。 この設定を使用するのは、次のような理由によります。

• Calayst 6000 は、インライン電源を IP Phoneに供給できる

• Catalyst 6000 には、最高の拡張性を提供できる能力がある

• Catalyst 6000 は、シスコの製品ラインで最高性能のレイヤ 2/3 キャンパス QoS ツールをサポートする

この項にある Catalyst 6000 の QoS 設定例は、図 4-15の例に従って作成されています。

図 4-15 Catalyst 6000 QoS 設定

Catalyst 6000 は、PFC ドーター カードの追加により、レイヤ 2、3、および 4 の QoS を認識する固有のプラットフォームとなりました。 PFC カードを使用して拡張 QoS ツールの使用をイネーブルにして、パケットの分類とマーキング、スケジューリングおよび、輻輳回避をレイヤ 2 あるいは レイヤ 3/4 のいずれかあるいは両方のヘッダー情報に基づいて実行できるようにします。 しきい値をもつ複数の受信キューおよび送信キューは、スイッチ内で設定される QoS ポリシー規則に従って設定され、利用されます。

Catalyst 6000 の Supervisor Engines には、Sup1 と Sup1A の 2 つのバージョンがあります。 また、6000 ラインカードにも 2 つのバージョンがあり、このバージョンでも後者のものは A という製品番号で示されています。 すべての Catalyst 6000 イーサネット モジュールは、4 つのしきい値と 2 つの送信キューをもつ、1 つの単一受信キューをサポートします。これらの 2 つの送信キューには、それぞれに 2 つのしきい値があります。 A のカードには拡張 QoS 機能があり、特に、入り口インターフェイスと出口インターフェイスの両方に優先順位キューを追加します。 優先順位キューを除き、これらのキューは、通常、フレームがキューに入るとすぐにサービスされる、WRR 方式でサービスされます。 ポートの設定方法を参照するには、 show port capabilities <mod/port> CatOS コマンドを発行します。 ポートのデフォルトの Qos ケイパビリティは、 set qos map <port_type> rx | tx <queue#> <threshold#> および set qos wred-threshold コマンドを使用して変更できます。 キューのしきい値を修正する場合、優先順位の高いほど、大きな数値を割り当てることが重要です。

Catalyst 6000 転送インターフェイスのスケジュールは、WRR アルゴリズムによって管理されます。 各キューには、ユーザが設定できる重みが与えられます。 デフォルトでは、高優先度のキューにはスケジュールの 98 パーセントが与えられ、低優先度のキューには 2 パーセントしか与えられません。 この比率により、遅延許容値の低いパケットはキューで遅延しないようになります。 このことはまた、低優先度のキューにインターフェイス バッファ全体のより高いパーセンテージを与える理由にもなります。 優先順位キューを設定すると、常に、そのキューが最初にサービスされます。 フレームが PQ に常駐していない場合、加重ラウンドロビンは、他の 2 つのキューのスケジュールを開始します。

Catalyst 6000 ポートのスケジューリングとキューイングの方式

受信インターフェイス

1Q4T ：

• 4 つのドロップしきい値を使用する 1 つの標準キュー

• 10/100 Mbps に対して 8KB の受信バッファ

• 1000 Mbps に対して 64KB の受信バッファ

• 10/100/1000 Mbps の全モジュール

1P1Q4T ：

• 1 つの優先順位キューと、4 つのドロップしきい値をもつ 1 つの標準キュー

• ラインカードに応じて 10/100/1000 Mbps モジュールの特定のバージョンでのみ使用可能。

• デフォルトでは、すべての CoS 5 フレームが、優先順位キューに入れられる。このキューでは、厳格な優先順位スケジューリング アルゴリズムが使用されます。

転送インターフェイス

2Q2T ：

• 2 つのドロップしきい値をもつ 2 つの標準キュー

• 高優先度キューには、合計キュー サイズの 20 パーセントが割り当てられる。 低優先度キューには、キュー サイズ合計の 80 パーセントが割り当てられます。

• 10/100/1000 Mbps の全モジュール

1P2Q2T ：

• 1 つの PQ 、2 つのドロップしきい値をもつ 2 つの標準キュー。 デフォルトでは、すべての CoS 5 のフレームは PQ に入れられます。このキューでは、厳格な優先順位スケジューリング アルゴリズムが使用されます。PQ は、常に、最初にサービスされ、PQ が空になると、WRR が残りのキューに使用されます。 PQ は、高優先度キューと同じように、合計キュー サイズの 15 パーセントが割り当てられます。 低優先度キューには、合計キュー サイズの 70 パーセントが割り当てられます。

• ラインカードに応じて、10/100/1000 Mbps モジュールの特定のバージョンのみ使用可能。

QoS パラメータの設定

IP Phoneをワイヤリング クローゼット スイッチに接続（ 「IP Phoneの接続」 を参照）したら、スイッチに QoS パラメータを設定する必要があります。 この設定には、次のステップがあります。

1. 複数のキューをすべてのポートに設定する

2. キューへのアクセスを設定する

3. トラフィック ドロップのしきい値を設定する

4. ディストリビューション スイッチへのアップリンク インターフェイスを設定する

5. MLS と Catalyst QoS を設定する

6. Catalyst 6000 送信キューを設定する

7. Catalyst 6000 CoS/ToS の DSCP へのマッピングを設定する

8. CoS/ToS から DSCP へのマッピングを確認する

次の項では、これらのステップについて詳細に説明します。

ステップ 1 IP Phone ポートのキューを設定します。

単一ケーブルの IP Phone インストール シナリオに従って、このアクセス ポートを設定し、IP Phoneと PC に接続されていない IP Phoneをトラストするようにします。 また、複数の送信キューを設定し、そのうちの 1 つを音声トラフィックの優先順位キューとして使用します。

図 4-16 IP Phone ポートのキューイング

次のコマンドを使用して、アクセス レイヤ Catalyst 6000 上で QoS をイネーブルにします。

記述の各コマンドにより、次の機能が実行されます。

• スイッチ全体で QoS をイネーブルにする

• そのポートに関連付けられているすべての QoS が、VLAN ベースで実行されることをポートに通知する

• IP Phone イーサネット ASIC 内で、PC からの CoS を CoS=0 に書き換えるように IP Phoneに指示する

• 着信レイヤ 2 CoS 分類を受け入れる（パーサーがエラーを戻しても、現在の 10/100 1 ラインカードの trust-cos がイネーブルになっている必要がある）

• 着信レイヤ 3 ToS 分類を受け入れるアクセス リストを作成する（10/100 ポートでのみ必要）

• アクセス リストをハードウェアに書き込む

• アクセス リストを補助 VLAN にマップする

ステップ 2 キューへのアクセスを設定します。

アクセス レイヤ Catalyst 6000 で QoS がイネーブルになると、次のコマンドを使用して、すべての CoS=3（VoIP 制御トラフィック）を低ドロップしきい値をもつ 2 番目の送信キューに配置します。これにより、高輻輳発生時でも確実にコールの制御を実行することができます。 すべての CoS=5（VoIP RTP ベアラ トラフィック）は、自動的に 2 番目のキューに配置されます。

ステップ 3 トラフィック ドロップのしきい値を設定します。

QoS を実装する上で基本となるのが、設定が実際に予測どおり実行されているかを確認することです。 Catalyst 6000 アクセス レイヤ スイッチ上で、大規模な輻輳が発生している間に次のコマンドの出力検査を行い、そのパフォーマンスを検証します。

次のコマンドからの出力サンプルを参照してください。

ステップ 4 ディストリビューション スイッチへのアップリンク インターフェイスを設定します。

アクセス ポートのすべてのキューイングを設定したら、ディストリビューション/コア スイッチへのアップリンク インターフェイスを設定する必要があります。

ステップ 5 MLS と Catalyst QoS を設定します。

IP Phoneが CallManager 以外の異なる VLAN にある場合、追加設定が必要となります。 フローのパケットをレイヤ 3 スイッチングの MSFC に送信するときはいつでも、 CoS は 0 に設定します。 大部分の設定は、ディストリビューション レイヤ スイッチ内に MSFC を配置しているため、アクセス レイヤ スイッチは、ディストリビューション レイヤからのアップリンク トランク上の DSCP タギングをすべてトラストする必要があります。 これにより、DSCP マーキングを保持して、ワイヤリング クローゼット スイッチ内で DSCP をレイヤ 3 分類に使用できるようになります。 レイヤ 2 のアップリンクには、 trust-cos を使用し、レイヤ 3 のアップリンクには、 trust-dscp を使用します。 次のサンプル コマンドを参照してください。

ステップ 6 Catalyst 6000 送信キューを設定します。

QoS がイネーブルになるとすぐに、すべての VoIP（CoS=5）トラフィックは、1p2q2t インターフェイスの出口インターフェイスの優先順位キューおよび 2q2t インターフェイスのキュー #2 に入れられます。 また、Catalyst 6000 CoS キュー許可規則を設定して、CoS=3 のトラフィック フロー（VoIP 制御トラフィック）が必ず 2 番目のキューに配置されるようにしてください。

ステップ 7 Catalyst 6000 CoS/ToS の DSCP へのマッピングを設定します。

VoIP コントロール プレーン トラフィックと VoIP ベアラあるいはメディア プレーン トラフィックの両方に対する DSCP 分類値の設定に関して、シスコは、IETF（米国技術特別調査委員会）の勧告に従っています。 次の設定値を推奨します。

• VoIP コントロール プレーンには、DSCP=AF31

• VoIP ベアラ プレーンには、DSCP=EF

レイヤ 2 CoS とレイヤ 3 IP Precedence 設定値をこれらの DSCP 値に正確にマップするには、デフォルトの CoS/ToS から DSCP へのマッピングを次の例のように修正する必要があります。

ステップ 8 CoS/ToS から DSCP へのマッピングを確認します。

次の例ではカードを使用して、CoS/ToS から DSCP へのマッピングを確認します。

Catalyst 4000 アクセス レイヤ

IP テレフォニー でもう 1 つ定評のあるキャンパス設定があります。Catalyst 2948G、2980G および 4000 シリーズのスイッチをワイヤリング クローゼットに使用する方式です。 この設定を使用する理由として、次があります。

• Calayst 4006 は、インライン電源を IP Phoneに供給できる

• Catalyst 4000 は、ポート当たりの単価がきわめて低価格である

• これらのスイッチは、きわめてスケーラブルで、高速スイッチングも提供できる

CatOS 5.2 のリリースを使用して、Catalyst 4000 の回線はすべてのインターフェイスで二重送信キューをサポートします。 キューに対する許可は、レイヤ 2 CoS マーキングに基づき、802.1p ユーザ優先順位ペアで設定できます。

Catalyst 4000 ポートのスケジューリングとキューイングの方式

受信インターフェイス

FIFO：1 つの標準 FIFO（先入れ先出し）キュー

転送インターフェイス

2Q1TN：1 つのしきい値をもつ 2 つの標準キュー スケジューリングは、RR ベースで実行されます。 キューに対する許可は、802.1p CoS 値に基づき、ペアでユーザ設定が可能です。 QoS をイネーブルにしても、CoS から送信キューへのマッピングを修正しなければ、すべてのトラフィックがキュー 1 に割り当てられるため、スイッチのパフォーマンスにその影響が及びます。QoS が Catalyst 上でイネーブルになったら、新たに作成されたキューを使用するよう CoS マッピングを変更する必要があります。

このマニュアルに記載されている Catalyst 4000 QoS 設定の例は、次の例に基づいて作成されています。

図 4-17 Catalyst 4000 QoS 設定例

IP Phoneをワイヤリング クローゼット スイッチに接続（ 「IP Phoneの接続」 を参照）したら、スイッチに QoS パラメータを設定する必要があります。 この設定には、次のステップがあります。

1. スイッチ全体で QoS を使用可能にする

2. Catalyst 4000 キュー許可設定を確認する

3. 電話ポートのキューイングを設定する

4. ディストリビューション スイッチへのアップリンク インターフェイスを設定する

次の項では、これらのステップについて詳細に説明します。

ステップ 1 Catalyst 4000 スイッチ全体で QoS を使用可能にします。

デフォルトでは、1 つのキューだけが Catalyst 4000 回線のスイッチでイネーブルとなっています。 CatOS 5.5.1 内の 2 番目のキューを使用できるようにするには、 set qos map コマンドを使用します。VoIP 制御（CoS=3）フレームを Catalyst 4000 の 2 番目のキューに入れる必要があります。Catalyst 4000 は最初の 2 つの CoS ビットのみを調べるため、これらのマップは、CoS 値をペアで設定する必要があります。 次の例を参照してください。

ステップ 2 Catalyst 4000 キュー許可設定を検証します。

次のコマンドを使用して、Catalyst 4000 のキュー許可設定を検証します。

ステップ 3 Phone Port のキューイングを設定します。

バージョン 5.5.1 では、Catalyst 4000 回線は、どの拡張 IP Phone キューイング機能も提供していません。 したがって、Catalyst 4000 は、デフォルトの CoS マーキングと IP Phoneの追加機能に依存します。 詳細は、 「IP Phoneの接続」 を参照してください。

ステップ 4 ディストリビューション スイッチへのアップリンク インターフェイスを設定します。

アクセス レイヤ Catalyst 4000 からディストリビューション レイヤ Catalyst 6000 へのリンクの Catalyst 4000 側で、特別なキューイングあるいはコマンドのスケジューリングを設定する必要はありません。QoS がイネーブルで、分類およびキュー許可が実行済みであれば、キューイングはオンになります。

Catalyst 4000 を使用するときは、レイヤ 3 エンジンである、WS-X4232 を追加してください。 このエンジンにより、スイッチに対する IP、IPX およびマルチキャスト ルーティングをイネーブルにし、追加アップリンクの設定を実行できるようにします。 レイヤ 3 エンジンは、Catalyst 4000 が 2 つのギガビット アップリンクの入り口基準 IP Precedence に基づいて、4 つの送信キューのサポートを可能にします。 この 4 つのキューは、ユーザ設定可能な WRR アルゴリズムを使用してスケジュールされます。

転送インターフェイス

4Q1TN：1 つのしきい値をもつ 2 つの標準キュー スケジューリングは、RR ベースで実行されます。 キューに対する許可は、802.1p CoS 値に基づいており、ペアでユーザ設定が可能です。 QoS が Catalyst で イネーブルになったら、新たに作成されたキューを使用するよう CoS マッピングを変更する必要があります。

（注） レイヤ 3 キューの番号付けは、レイヤ 2 の番号付けの逆になります。

Catalyst 3500 アクセス レイヤ

Catalyst 2900 シリーズおよび Catalyst 3500 シリーズの IP テレフォニー 機能は、12.0(5) XU という必要最小限の Cisco IOS があると、CoS マーキング ルールを拡張して IP Phoneと相互に対話できます。 Catalst 2900XL と 3500XL スイッチは、各ポートにデフォルトの CoS 優先順位を設定して、入力ポートでタグなしパケットを分類することもできます。 ただし、これらのスイッチ（3548XL は除く）は、すべてのタグ付きパケットを再分類することはできず、802.1p 優先順位を有効と認め、パケットを適切な送信キューに配置するだけです。 8MB DRAM を装備したすべての Catalsyt 3500 スイッチとすべての Catalyst 2900XL スイッチは、これらの QoS 機能をサポートします。 4MB DRAM を装備した Catalyst 2900XL は、QoS 機能をサポートしていません。

Catalyst 3500 ポートのスケジューリングとキューイング スキーム

受信インターフェイス

1Q-FIFO ： 1 つの標準 FIFO（先入れ先出し）キュー

送信インターフェイス 10/100 ポート

2Q1TN：単一のドロップしきい値をもつ 2 つの標準キュー。 スケジューリングは、優先順位スケジューリング ベースで実行されます。 キューに対する許可は、802.1p CoS あるいはポート優先順位 CoS の値に基づいて設定されますが、ユーザは設定できません。

送信インターフェイスのギガビット イーサネット ポート

8Q-FIFO ：単一のドロップしきい値をもつ 8 つの標準キュー。 現在、2 つのキューだけが使用されています。 スケジューリングは、優先順位スケジューリング ベースで実行されます。 キューに対する許可は、802.1p あるいはポート優先順位 CoS の値に基づいて設定されますが、ユーザは設定できません。

Catalyst 3500 ギガビット イーサネットのキュー許可基準は、次のとおりです。

Catalyst 3500 QoS 設定は、次の例に基づき作成されています。

図 4-18 Catalyst 3500 ギガビット イーサネット QoS 設定例

IP Phoneをワイヤリング クローゼット スイッチに接続（ 「IP Phoneの接続」 を参照）したら、スイッチに QoS パラメータを設定する必要があります。 この設定には、次のステップがあります。

1. IP Phone ポートのキューイングを設定する

2. ディストリビューション スイッチへのアップリンク インターフェイスを設定する

ステップ 1 IP Phone ポートのキューイングを設定します。

単一ケーブルの IP Phone インストール シナリオに従って、IP Phoneおよび PC に接続されていない IP Phoneをトラストするようにこのアクセス ポートを設定します。 次のコマンドを使用します。

ステップ 2 ディストリビューション スイッチへのアップリンク インターフェイスを設定します。

Catalyst 3500XL シリーズ スイッチのワイヤリング クローゼット設定を設計する場合、ディストリビューション レイヤ Catalyst 6000 への二重アップリンクがある 3508 に、3524 PWR XL をスター型トポロジで接続する方式を推奨します。 これらのアップリンクはギガビット イーサネット リンクです。このリンクは、アップリンクを通過する VLAN の負荷バランシングを実行し、ファースト レイヤ 2 コンバージェンスに対しては UplinkFast で設定されています。 Catalyst 3500 シリーズの GigaStack 設定は、基本的に共有メディアのアクセス モデルのため、保証音声 QoS を提供できません。 次のコマンドを設定します。

Catalyst 6000 ディストリビューション レイヤ

アクセス スイッチを設定し、そのスイッチをディストリビューション レイヤに接続したら、ディストリビューション スイッチ上で QoS を設定する必要があります。 このとき、次のように設定を少し変更する必要があります。

1. VoIP 制御トラフィックの送信キューイングを設定する

2. レイヤ 3 アクセス スイッチを使用してディストリビューション レイヤを設定する

a. アクセス レイヤからの ToS と DSCP をトラストする

b. ToS から DSCP へのマッピングを設定する

3. レイヤ 2 アクセス スイッチを使用してディストリビューション レイヤを設定する

a. アクセス レイヤからの CoS と DSCP をトラストする

b. CoS から DSCP へのマッピングを設定する

c. VoIP 制御トラフィック分類に使用する レイヤ 3 アクセス リストを設定する

4. 7200 WAN ルータへの接続を設定する

このマニュアルに記載されているすべての Catalyst 6000 ディストリビューション レイヤの設定例は、次のネットワークに基づき作成されています。

図 4-19 Catalyst 6000 ディストリビューション レイヤの設定

ステップ 1 Catalyst 6000 ディストリビューション レイヤの VoIP 制御トラフィックの送信キューを設定します。

QoS がイネーブルになると即時に、すべての VoIP（CoS=5）トラフィックは、1p2q2t インターフェイス上では出口インターフェイス優先度キューに、2q2t（10/100 ラインカードのすべてのバージョン 1）インターフェイス上ではキュー #2 に入れられます。 また、Catalyst 6000 CoS キュー許可ルールを設定して、CoS=3 のトラフィック フロー（VoIP 制御トラフィック）が必ず 2 番目のキューに入れられるようにする必要があります。 次のコマンドを使用します。

ステップ 2 Catalyst 6000-PFC アクセス レイヤを使用する Catalyst 6000 ディストリビューション レイヤを設定します。

QoS をディストリビューション レイヤ スイッチでイネーブルにし、デフォルトのキュー許可を修正したら、次のステップを実行する必要があります。

• アクセス レイヤからの DSCP をトラストする

• ToS から DSCP へのマッピングを設定する

これらのステップについては、次に説明します。

a. レイヤ 3 アクセス スイッチからの DSCP をトラストする

隣接レイヤ 3 アクセス スイッチからの DSCP 値に対するトラストをオンにします。 トランキング ポートで port-base qos コマンドを使用して、 trust-cos の代わりに trust-dscp コマンドを使用します。 trust-dscp コマンドを使用するのは、trust-cos コマンドがマップした CoS 値でレイヤ 3 DSCP 値を上書きするからです。 分類がアクセス レイヤで実行されるまで、このコマンドを使用する必要はありません。

b. Catalyst 6000 ToS の DSCP へのマッピングを設定する

VoIP コントロール プレーン トラフィックと VoIP ベアラあるいはメディア プレーン トラフィックの両方に対する DSCP 分類値の設定に関して、シスコは、IETF（米国技術特別調査委員会）の勧告に従っています。 次の設定値を推奨します。

–VoIP コントロール プレーンには、DSCP=AF31

–VoIP ベアラ プレーンには、DSCP=EF

レイヤ 3 IP Precedence の設定値をこれらの DSCP 値に正確にマップするには、デフォルトの ToS から DSCP へのマッピングを次の例のように修正する必要があります。

ステップ 3 レイヤ 2 のアクセス スイッチだけを使用する Catalyst 6000 ディストリビューション レイヤを設定します。

QoS をディストリビューション レイヤ スイッチでイネーブルにしてデフォルトのキュー許可を修正したら、次のステップを実行する必要があります。

• アクセス レイヤからの CoS を信頼する

• CoS から DSCP へのマッピングを設定する

• VoIP 制御トラフィック分類に使用する レイヤ 3 アクセス リストを設定する（ 「制御トラフィックと管理トラフィックのマーキング」 を参照）

a. レイヤ 2 アクセス スイッチからの CoS をトラストする

隣接レイヤ 2 アクセス スイッチからの CoS 値に対するトラストをオンにします。 アクセス レイヤ スイッチが、CoS 分類を実行するレイヤ 2 専用デバイスの場合、次のように、トランキング ポートで Port-base qos コマンドを使用し、 trust-dscp の代わりに、 trust-cos コマンドを使用します。

b. Catalyst 6000 CoS の DSCP へのマッピングを設定する

VoIP コントロール プレーン トラフィックと VoIP ベアラあるいはメディア プレーン トラフィックの両方に対する DSCP 分類値の設定に関して、シスコは、IETF（米国技術特別調査委員会）の勧告に従っています。 次の設定値を推奨します。

–VoIP コントロール プレーンには、DSCP=AF31

–VoIP ベアラ プレーンには、DSCP=EF

レイヤ 2 をこれらの DSCP 値に正確にマップするには、デフォルトの CoS から DSCP へのマッピングを次の例のように修正する必要があります。

c. VoIP 制御トラフィック分類に使用する レイヤ 3 アクセス リストを設定する

次のコマンドを使用します。

固有の Cisco IOS を実行する Catalyst 6000 ディストリビューション/コア

アクセス スイッチを設定し、スイッチをディストリビューション レイヤに接続したら、ディストリビューション スイッチ上で QoS を設定する必要があります。 このとき、次のように設定を少し変更する必要があります。

1. QoS を設定する

2. VoIP 制御トラフィックの送信キューイングを設定する

3. レイヤ 3 アクセス スイッチを使用してディストリビューション レイヤを設定する

a. アクセス レイヤからの ToS と DSCP をトラストする

b. ToS から DSCP へのマッピングを設定する

4. レイヤ 2 アクセス スイッチを使用してディストリビューション レイヤを設定する

a. アクセス レイヤからの CoS と DSCP をトラストする

b. CoS から DSCP へのマッピングを設定する

c. VoIP 制御トラフィック分類に使用する QoS ポリシーとレイヤ 3 アクセス リストを設定する

固有の Cisco IOS を実行する Catalyst 6000 ディストリビューション レイヤのすべての例は、 に基づいています。

---

ステップ 1 固有の Cisco IOS Catalyst 6000 に QoS を設定します。

mls qos Cisco IOS コマンドを使用して、固有の Cisco IOS を使用する Catalyst 6000 で QoS を使用可能にします。

ステップ 2 VoIP 制御トラフィックの送信キュー許可を設定します。

QoS がイネーブルになると即時に、すべての VoIP（CoS=5）トラフィックは、1p2q2t インターフェイス上では出口インターフェイス優先度キューに、そして、2q2t（10/100 ラインカードのすべてのバージョン 1）インターフェイスのキュー #2 に入れられます。 また、Catalyst 6000 CoS キュー許可ルールを設定して、CoS=3 のトラフィック フロー（VoIP 制御トラフィック）が必ず 2 番目のキューに入れられるようにする必要があります。 次のコマンドを使用します。

int range gigabitEthernet 1/1 - 2

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

 

ステップ 3 Catalyst 6000-PFC アクセス レイヤを使用する Catalyst 6000 固有の Cisco IOS ディストリビューション レイヤを設定します。

QoS を固有の Cisco IOS ディストリビューション レイヤ スイッチでイネーブルにし、デフォルトのキュー許可を修正したら、次のステップを実行する必要があります。

• アクセス レイヤからの DSCP をトラストする

• ToS から DSCP へのマッピングを設定する

これらのステップについて、次に説明します。

a. レイヤ 3 アクセス スイッチからの DSCP をトラストする

隣接レイヤ 3 アクセス スイッチからの DSCP 値に対するトラストをオンにします。 port-base qos コマンドをトランキング ポート上で使用して、CatOS trust-dscp の代わりに mls qos trust dscp コマンドを使用します。 port-based qos コマンドは、 mls qos コマンドをイネーブルにすると、デフォルトで使用できます。 分類は、このモデルのアクセス レイヤで完了していることに留意してください。 次の例を参照してください。

interface GigabitEthernet2/1

description trunk port to PFC enabled cat6k-access

no ip address

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

mls qos trust dscp

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

 

b. 固有の Cisco IOS ToS の DSCP へのマッピングを設定し、レイヤ 3 アクセス スイッチで使用する

VoIP コントロール プレーン トラフィックと VoIP ベアラあるいはメディア プレーン トラフィックの両方に対する DSCP 分類値の設定に関して、シスコは、IETF（米国技術特別調査委員会）の勧告に従っています。 次の設定値を推奨します。

–VoIP コントロール プレーンには、DSCP=AF31

–VoIP ベアラ プレーンには、DSCP=EF

レイヤ 3 IP Precedence の設定値をこれらの DSCP 値に正確にマップするには、デフォルトの ToS-to-DSCP へのマッピングを修正する必要があります。 Catalyst 6000 の数値、 26 と 46 は、それぞれ DSCP=AF31 と DSCP=EF に相互に関連していることに留意してください。 このことは、グローバル設定モードで実行されます。

mls qos map ip-prec-dscp 0 8 16 26 32 46 56 0

 

ステップ 4 レイヤ 2 専用アクセス スイッチを使用する固有の Cisco IOS ディストリビューション レイヤを設定します。

QoS をディストリビューション レイヤ スイッチでイネーブルにし、デフォルトのキュー許可を修正したら、次のステップを実行する必要があります。

• アクセス レイヤからの CoS をトラストする

• CoS から DSCP へのマッピングを設定する

• VoIP 制御トラフィック分類に使用する レイヤ 3 アクセス リストを設定する（ 「制御トラフィックと管理トラフィックのマーキング」 を参照）

これらのステップについて、次に説明します。

a. レイヤ 2 アクセス スイッチからの CoS をトラストする

隣接レイヤ 2 アクセス スイッチからの CoS 値に対するトラストをオンにします。 アクセス レイヤ スイッチが CoS を実行するレイヤ 2 専用デバイスの場合、トランキング ポート上で port-base qos を使用し、CatOS trust-cos の代わりに、固有の Cisco IOS mls qos trust cos コマンドを使用します。 次の例を参照してください。

interface GigabitEthernet2/2

description trunk port to layer 2-only cat4k

no ip address

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

mls qos vlan-based

mls qos trust cos

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet3/1

description trunk port to layer 2-only 3500

no ip address

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

mls qos vlan-based

mls qos trust cos

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

 

b. 固有の Cisco IOS CoS の DSCP へのマッピングを設定してレイヤ 2 アクセス スイッチで使用する

VoIP コントロール プレーン トラフィックと VoIP ベアラあるいはメディア プレーン トラフィックの両方に対する DSCP 分類値の設定に関して、シスコは、IETF（米国技術特別調査委員会）の勧告に従っています。 次の設定値を推奨します。

–VoIP コントロール プレーンには、DSCP=AF31

–VoIP ベアラ プレーンには、DSCP=EF

レイヤ 2 をこれらの DSCP 値に正確にマップするには、デフォルトの CoS から DSCP へのマッピングを修正する必要があります。 Catalyst 6000 の数値、 26 と 46 は、それぞれ DSCP=AF31 と DSCP=EF に相互に関連していることに留意してください。 このマッピング修正は、グローバル設定モードで実行します。

mls qos map cos-dscp 0 8 16 26 32 46 56 0

 

c. VoIP 制御トラフィック分類に使用する QoS ポリシーとレイヤ 3 アクセス リストを設定する

固有の Cisco IOS Catalyst 6000 の QoS 設定は、WAN ルータ Cisco IOS 設定と非常によく似ています。ただし、トラフィック フローのマーキングにポリシーを使用することと、VLAN インターフェイスへのサービス ポリシーの適用が異なります。 物理的ギガビット イーサネットのアップリンク ポートは、 mls qos VLANベースの固有の Cisco IOS インターフェイス コマンドを使用して、VLAN ベースの QoS を使用するように設定します。 最終的に、サービス ポリシーをアップリンクのすべての VLAN トラフィック受信に適用します。

下記の例では、次の 3 つのクラスを定義します。

–VoIP メディア ストリームに対して 1 つのクラス

–制御トラフィックに対して 1 つのクラス

–その他すべてのトラフィックに対して 1 つのクラス

これらのクラスに対するトラフィックは、レイヤ 3/4 の発信元と宛先の IP アドレス、およびポートに基づいてフィルタに掛けられ、分類されます。 これらのクラスは、それぞれ音声 QoS ポリシー マップで参照されます。 ポリシー マップ ステートメントでは、ポリシング機能を使用して、クラスとマップのアクセス リストと一致する入り口基準を満たすすべてのトラフィックを分類します。

---

（注） Catalyst 6000 固有の Cisco IOS ソフトウェアは、set ip dscpコマンドをサポートとしていません。 その代わりとして、ポリシング アルゴリズムを使用してトラフィックを分類します。

---

次の例では、ポリシング コードは、VoIP 制御トラフィック、VoIP メディア トラフィック、およびその他すべてのパケットのそれぞれのトラフィック フローに、AF31、EF、および 0 の DSCP 値をタグ付けします。「8000」フロー サイズは小さいため、いずれのトラフィックも、 conform-action set-dscp-transmit 26 構文を使用した、タギングが必要です。

class-map match-all VoIP-Control

match access-group 100

class-map match-all VoIP-RTP

match access-group 101

class-map match-all Routine

match access-group 102

!

!

policy-map Voice-QoS

class VoIP-Control

police 8000 8000 8000 conform-action set-dscp-transmit 26 exceed action transmit

class VoIP-RTP

police 8000 8000 8000 conform-action set-dscp-transmit 46 exceed-action transmit

class Routine

police 8000 8000 8000 conform-action set-dscp-transmit 0 exceed-action transmit

!

! access-list 100 looks for VoIP Control Traffic

access-list 100 permit tcp any any range 2000 2002

access-list 100 permit tcp any any eq 1720

access-list 100 permit tcp any any range 11000 11999

access-list 100 permit udp any any eq 2427

!

! access-list 101 looks for VoIP Bearer Traffic

access-list 101 permit udp any any range 16384 32767

!

! access-list 102 filters for routine traffic

access-list 102 permit ip any any

!

interface GigabitEthernet2/2

description trunk port to layer 2-only cat4k

no ip address

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

! inform the port that QoS will be VLAN-Based

mls qos vlan-based

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface GigabitEthernet3/1

description trunk port to layer 2-only 3500

no ip address

wrr-queue cos-map 1 2 2

wrr-queue cos-map 2 1 3 4

! inform the port that QoS will be VLAN-Based

mls qos vlan-based

switchport

switchport trunk encapsulation dot1q

switchport mode trunk

!

interface Vlan111

description voice vlan on cat4k

ip address 10.1.111.77 255.255.255.0

ip helper-address 10.1.10.10

no ip redirects

! apply the QoS policy as an inbound policy

service-policy input Voice-QoS

standby 111 ip 10.1.111.1

!

interface Vlan112

description voice vlan on 3500

ip address 10.1.112.77 255.255.255.0

ip helper-address 10.1.10.10

no ip redirects

! apply the QoS policy as an inbound policy

service-policy input Voice-QoS

standby 112 ip 10.1.112.1

 

 

 

ios6k#sh mls qos

QoS is enabled globally

Microflow policing is enabled globally

 

QoS is vlan-based on the following interfaces:

Vl111 V112 Gi2/2 Gi3/1 Gi3/2 Gi3/3

Gi3/4 Gi3/5 Gi3/6 Gi3/7 Gi3/8 Gi4/1 Gi4/2 Gi4/3 Gi4/4 Gi4/5

Gi4/6 Gi4/7 Gi4/8 Fa9/1 Fa9/2 Fa9/3 Fa9/4 Fa9/5 Fa9/6 Fa9/7

Fa9/8 Fa9/9 Fa9/10 Fa9/11 Fa9/12 Fa9/13 Fa9/14 Fa9/15 Fa9/16 Fa9/17

Fa9/18 Fa9/19 Fa9/20 Fa9/21 Fa9/22 Fa9/23 Fa9/24 Fa9/25 Fa9/26 Fa9/27

Fa9/28 Fa9/29 Fa9/30 Fa9/31 Fa9/32 Fa9/33 Fa9/34 Fa9/35 Fa9/36 Fa9/37

Fa9/38 Fa9/39 Fa9/40 Fa9/41 Fa9/42 Fa9/43 Fa9/44 Fa9/45 Fa9/46 Fa9/47

Fa9/48

 

QoS global counters:

Total packets: 16750372458300

Packets dropped by policing: 55930847232

IP packets with TOS changed by policing: 16750372458300

IP packets with COS changed by policing: 55945330688

Non-IP packets with COS changed by policing: 16750372458300

ブランチ オフィスの構築

この項での強調および推奨する事項は、次のとおりです。

• ブランチ の WAN ルータは、IP テレフォニー WAN をサポートする拡張 QoS ツールをサポートする必要がある

• 複数キューをサポートするスイッチを使用する

• 現在、レイヤ 3 ToS 分類をレイヤ 2 CoS にパスする方法がルータにない

• レイヤ 3 ToS からレイヤ 2 CoS へのマッピングは、Cisco IOS バージョン 12.1(5)T/12.2(2)T のモジュラ CLI を追加することによりルータで発生する

IP テレフォニー を設計する上で推奨するブランチ オフィス

ユーザが 5 人から 100 人までのブランチ オフィスは、通常は、 1 台のブランチ ルータとイーサネット スイッチで構成されています。 そのルータは、すべての IP ルーティングと WAN 接続を処理します。 ローカル PC は、ルータにも接続している小型のイーサネット スイッチに接続されています。 ブランチ オフィス内の音声の品質については、2 つの重要な課題があります。 つまり、WAN を通過する VoIP とブランチ オフィス内の音声品質です。 WAN を通過する音声品質を確保するための WAN QoS ツールの詳細は、 「ワイド エリア ネットワークを使用可能にする」 で説明します。 この項では、ブランチ オフィスの設計、IP アドレッシングおよびブランチ オフィス内の音声品質について説明します。

図 4-20 QoS 問題となる可能性のある領域

 

一般に、ブランチ オフィスを設計する場合、各オフィスに使用されるのは、IP サブネット 1 つだけです。 このサブネットの設定を変更することは、企業全体のルーティング方式に影響を及ぼすため、現実的にはほとんど行われていません。 したがって、実際にブランチ オフィスを設計する際には、IP Phoneで使用する次の 3 つの IP アドレッシング オプションを検討する必要があります。

• ブランチ オフィスにおける単一サブネットの使用

• 音声サブネットとデータ サブネットをブランチ オフィスで分離するトランキングの 802.1Q を使用する

• 音声サブネットとデータ サブネットをブランチ オフィスで分離する 2 番目の IP アドレッシングを使用する

---

（注） これらの 2 番目のサブネットごとに使用する IP アドレスには、管理の容易な RFC 1918 アドレスを使用できます。

---

それぞれのシナリオには、最も一般的な配備方式である、単一ケーブル インストール方式を使用します（ 図 4-4 を参照）。

ブランチ オフィスにおける単一サブネットの使用

IP Phone用に追加の IP サブネットを割り当てるか、またはリモート ブランチ内で使用されている既存の IP アドレス スペースにさらにサブネットを割り当てることが実用的でない、あるいは不可能な場合は、単一の IP アドレス スペースを使用することが必要です。 この場合、レイヤ 2 と レイヤ 3 の両方で音声をデータより優先するように設定する必要があります。ただし、IP Phoneはすべてのメディア ストリームの ToS ビットを、IP Precedence を 5 に、あるいは DSCP 値を 40 に設定しているため、レイヤ 3 分類はすでに処理されています（詳細は、 「IP Phoneの接続」 を参照してください）。 ただし、複数のキューに対する許可に必要なレイヤ 2 分類がブランチ オフィスのスイッチで確保されるように、IP Phoneはレイヤ2 802.1p ヘッダーのユーザ優先度ビットを使用して CoS マーキングを提供する必要があります。 このことは、スイッチにネイティブの VLAN の 802.1p ヘッダーを検索させることによってのみ行えます。 ブランチ オフィスの設計で主として使用される 2 つのイーサネット スイッチである、Catalyst 3500 と 4000 は、このことを実行するために、異なる設定コマンドを使用します。

Cisco 1750 単一サブネット設定

Cisco 1750 シリーズのルータは、ISL あるいは 802.1Q イーサネット トランキングのどちらもサポートしていません。 次の例は、単一サブネット 1750 の設定例です。

interface FastEthernet0

mac-address 0000.1750.0001

ip address 10.1.40.1 255.255.255.0

ip helper-address 10.1.10.10

ip policy route-map Set-IP-QoS

no ip mroute-cache

load-interval 30

speed auto

full-duplex

 

Catalyst 3500 単一サブネット設定

Catalyst 3500 は、補助 VLAN の設定時、802.1p 専用オプションの使用をサポートします。 これにより、IP Phoneは、ネイティブ VLAN 上で VoIP パケットに 5 の CoS 値のタグを付けることができますが、すべての PC のデータ トラフィックはタグなしで送信されます。

interface FastEthernet0/2

description Port to IP Phone in single subnet

switchport trunk encapsulation dot1q

switchport trunk native vlan 40

switchport mode trunk

switchport voice vlan dot1p

spanning-tree portfast

!

interface FastEthernet0/15

description Port to 1750 Router in single subnet

load-interval 30

duplex full

speed 100

switchport access vlan 40

Cisco 2600 単一サブネット（トランキングなし）設定

interface FastEthernet1/0

mac-address 0000.2600.0001

ip address 10.1.60.1 255.255.255.0

ip helper-address 10.1.10.10

ip policy route-map Set-IP-QoS

no ip mroute-cache

load-interval 30

speed 100

full-duplex

Catalyst 4000 単一サブネット設定

Catalyst 4000 は、Catalyst 3500 と 6000 と異なり、補助 VLAN 設定時に使用される dot1p 専用オプションをサポートしません。 その代わりとして、ポート VLAN ID（PVID）あるいはネイティブの VLAN に一致する補助 VLAN ID を使用して、Catalyst 4000 に接続されている IP Phoneを設定する必要があります。 これにより、IP Phoneは、CoS 5 のタグが付いた電話のパケットを確実に送信できます。

cat4k> (enable) set vlan 60 name 171.69.60.0_data

cat4k> (enable) set vlan 60 2/1-49

cat4k> (enable) set port host 2/1-49

cat4k> (enable) set port auxiliaryvlan 2/1-48 60

音声サブネットとデータ サブネットをブランチ オフィスで分離するトランキングの 802.1Q を使用する

既存のブランチ オフィス IP アドレス スペースを分割するオプションがある場合、音声とデータに対して必ず別個の VLAN を使用する必要があります。 現在の 3500 と 4000 シリーズのような、レイヤ 2 サービスだけをサポートするイーサネット スイッチが、ほとんどすべてのブランチ オフィスの設計で使用されています。 このような場合、ブランチの WAN ルータは、イーサネット スイッチからの個別の VLAN をトランキングします。 このトランキングを行うために 802.1Q トランキングをルータとスイッチ上で使用します。

イーサネット スイッチの優先順位付けを行うのに、802.1Q 標準ヘッダーの 802.1p の部分にあるユーザ優先順位ビットが使用されます。 これは、IP テレフォニー の使用が可能なネットワークを設計するときに不可欠なコンポーネントです。 ブランチ オフィスに最初の IP テレフォニー を配備するときに直面する難問の 1 つは、現在、Cisco IOS ルータが VoIP ストリームを分類できないことです。このストリームは、WAN からレイヤ 2 802.1p CoS 値に入りブランチ オフィスのスイッチド インフラストラクチャ内で優先順位のキューイングに使用されます。

つまり、ブランチの IP Phoneが別のブランチの IP Phoneと通信する場合、両方の IP Phoneは 5 の CoS 値をすべてのレイヤ 2 パケットで使用し、それぞれの電話からの VoIP ストリームには、ブランチのスイッチド ネットワーク内での優先順位が与えられます。

ブランチの IP Phoneが別の本社の IP Phoneと通信する場合、本社の IP Phoneは 5/EF の値の ToS で分類され、その WAN を通過する間の優先順位が与えられます。 本社の IP Phoneの VoIP ストリームが、ブランチ ルータに達すると、ルータは VoIP ストリームを CoS=0 の値でイーサネット スイッチに送信します。その理由は、Cisco IOS ルータが、現在、レイヤ 3 ToS 設定値をレイヤ 2 CoS 設定値に再分類できないからです。 Cisco IOS バージョン 12.2(2)T では、モジュール CLI QoS コードを追加することでこの問題に対処します。

本社では、このシナリオは問題となりません。Catalyst 6000 はすべてのレイヤ 3 ToS 設定と相互に関係して、レイヤ 2 CoS 値を入り口インターフェイスで調整するからです。

802.1Q トランキングを使用する 3600 ブランチ オフィス ルータ

interface FastEthernet1/0

description Catalyst 3500 Branch Office Switch

no ip address

ip route cache policy

no ip mroute-cache

load-interval 30

speed 100

full-duplex

!

interface FastEthernet1/0.50

description native subnet 10.1.50.0 data

encapsulation dot1Q 50

ip address 10.1.50.1 255.255.255.0

no ip mroute-cache

!

interface FastEthernet1/0.150

description native subnet 10.1.150.0 voice

encapsulation dot1Q 150

ip address 10.1.150.1 255.255.255.0

ip helper-address 10.1.10.10

ip policy route-map Set-IP-QoS

ip route cache policy

no ip mroute-cache

 

802.1Q トランキングを使用する Catalyst 3500

interface FastEthernet0/1

description DOT1Q port to IP Phone

switchport trunk encapsulation dot1q

switchport trunk native vlan 50

switchport mode trunk

switchport voice vlan 150

spanning-tree portfast

!

interface FastEthernet0/15

description Port to 3640 (supports Dot1q)

duplex full

speed 100

switchport trunk encapsulation dot1q

switchport trunk native vlan 50

switchport trunk allowed vlan 1,50,150

switchport mode trunk

 

802.1Q トランキングを使用する Catalyst 4000

cat4k> (enable) set vlan 70 name data70

cat4k> (enable) set vlan 170 name voice170

cat4k> (enable) set vlan 70 2/1-48

cat4k> (enable) set port host 2/1-48

cat4k> (enable) set port auxiliaryvlan 2/1-48 170

cat4k> (enable) set port speed 2/1-49 100

cat4k> (enable) set port duplex 2/1-49 full

cat4k> (enable) set trunk 2/49 on dot1q 1-1005

 

音声サブネットとデータ サブネットをブランチ オフィスで分離する 2 番目の IP アドレッシングを使用する

ブランチ ルータが 802.1Q トランキングをサポートしていない場合、やはり、音声とデータに別個の VLAN を使用することをお薦めします。 たとえば、1750 はトランキングをサポートしませんが、音声トラフィックとデータトラフィックの論理的な分離を必要とする場合があります。 トランキングの代わりとして、次の例のように、シスコのルータで 2 番目の IP アドレッシングを使用します。

1750 ブランチ ルータ

interface FastEthernet0

description to Catalyst 3500

mac-address 0000.1750.0001

ip address 10.1.40.1 255.255.255.128

ip address 10.1.40.129 255.255.255.128 secondary

ip helper-address 10.1.10.10

ip policy route-map Set-IP-QoS

no ip mroute-cache

speed 100

full-duplex

 

VoIP 制御トラフィックのブランチでの分類

遠くにあるブランチ ルータも、CallManager あるいは WAN を通過する VoIP ゲートウェイに使用するローカルのサブネットをそのまま残して、VoIP 制御トラフィックを分類する必要があります。 ポリシーベース ルーティングとルート マップを入り口側イーサネット インターフェイスで使用して、この分類を実行できます。

---

（注） Ver.3.0(5)のリリースにより、Cisco CallManager には、CallManager、IP PhoneそしてSkinny ゲートウェイからのすべての VoIP 制御と管理トラフィックに対して、CoS と ToS の値を設定できる能力が含まれます。 CallManager ベースでユーザが設定できる、この分類がサポートされると、ネットワーク要素アクセス リストは、Skinny VoIP 制御トラフィックのマーキングに不要となります。 H.323 と MGCP トラフィックは、ここ当分の間、外部のネットワーク要素マーキングを必要とします。

---

interface FastEthernet0

mac-address 0000.1750.0001

ip address 10.1.60.1 255.255.255.0

ip helper-address 10.1.10.10

! Attach the route-map to the FastEthernet interface

ip policy route-map Set-IP-QoS

no ip mroute-cache

load-interval 30

speed auto

full-duplex

!

! Match all Skinny, H.323 and MGCP Control Traffic

access-list 101 permit tcp any any range 2000 2002

access-list 101 permit tcp any any eq 1720

access-list 101 permit tcp any any range 11000 11999

access-list 101 permit udp any any eq 2427

!

! Match all VoIP RTP Traffic

access-list 102 permit udp any any range 16384 32767

!

! Match all other traffic

access-list 103 permit ip any any

!

! Set all Skinny, H.323 and MGCP Control traffic, matched

! with ac 101 to IP Precedence 3

route-map Set-IP-QoS permit 10

match ip address 101

set ip precedence flash

!

! Just match VoIP RTP Traffic; don't change the

! default classification of ToS=5

route-map Set-IP-QoS permit 20

match ip address 102

!

! Make sure all data traffic is set to IP Precedence 0

route-map Set-IP-QoS permit 30

match ip address 103

set ip precedence routine

 

ワイド エリア ネットワークを使用可能にする

この項での強調および推奨する事項は、次のとおりです。

• 768 Kbps より遅い速度でのすべての WAN 接続では、LFI（Link Fragmentation and Interleave）技術を使用する。

• すべての WAN VoIP 接続で低遅延キューイング（LLQ）を使用する。

• すべてのフレームリレーと ATM 配備に対してトラフィック シェーピングが必須となる。

• 可能な場合は cTRP を使用する。

• 768kbps より遅い速度で動作する ATM WAN では、Multilink PPP（MLPPP）over ATM を使用してフレーム サイズを縮小する必要がある。 MLPPP over ATM は、Cisco IOS バージョン 12.1(4)T でサポートされています。

• フレームリレーから ATM へのインターネットワーキング環境では、MLPPP over ATM とフレームリレーを使用して、低速接続でフレーム サイズを縮小する必要がある。 MLPPP over ATM とフレームリレーは、Cisco IOS バージョン 12.1(4)T でサポートされます。

• WAN を通過するコール数が、プロビジョニングされた VoIP 帯域幅を上回るような場合、コール アドミッション制御を使用する必要がある。

QoS ツールを使用する推奨 Cisco IOS バージョンを、サポート メディア別に記載した次の表を参照してください。

 

表 4-11 QoS ツールを使用する推奨 Cisco IOS バージョン

メディア	必要最小限の Cisco IOS バージョン	優先順位付け	LFI	トラフィック シェーピング
PPP	12.0(7)T	LLQ	MLPPP	該当せず
フレームリレー	12.1(2)T	LLQ	FRF.12	CIR にシェープ
ATM	12.1(2)T	VC LLQ 当たり	MLPPP over ATM	帯域幅の保証部分にシェープ
フレームリレーから ATM のインターネットワーキングへ	12.1(5)T*	VC LLQ 当たり	MLPPP over ATM とフレームリレー	帯域幅の保証部分にシェープ

MLPPP over ATM とフレームリレーがサポートされている場合、Cisco IOS バージョン 12.1(4)T が必要最小限のバージョンとなります。

WAN QoS の概要

データ、音声およびビデオ ネットワークの集約化を進める最大の理由の 1 つは、これらを維持するのにかかる総コストが低いことです。 ネットワーク集約化は、企業通信インフラストラクチャの全体的なコストを低減することはできますが、正常な IP テレフォニー の配備のための、確実な計画と設計が必要となります。 このことは、VoIP を WAN 全体で実行するときに、特に重要になります。

データ ネットワーク全体で音声の品質を確保できる環境を提供するには、次の 3 つの基本ツールを使用する必要があります。

• 分類

• キューイング

• ネットワークのプロビジョニング

低帯域幅および低速リンクの WAN を IP テレフォニー の設計に導入するときは、次のような複数の QoS ツールも追加して使用する必要があります。

• LFI

• トラフィック シェーピング

• コール アドミッション制御

分類

分類とは、特定のトラフィック タイプに固有の処理要件を割り当てて、分類あるいはマーキングする方式です。 これらの処理要件には、必要最小限の帯域幅であることや、低遅延に対する許容値を低くすることなどがあります。 この分類は、次に含まれたタグによってネットワーク要素に信号が送られます。

• IP Precedence/DSCP

• 802.1p のようなレイヤ 2 スキーム

• 発信元と送信先の IP アドレス

• RTP と定義済みポート範囲を使用するトラフィック タイプのような、データの明示的特性

推奨する IP テレフォニー QoS の設計モデルでは、この分類は IP Phone上のレイヤ 2 とレイヤ 3 の両方で実行されます。 ここで、管理対象ネットワークのエッジとなっている IP Phoneは、レイヤ 2 802.1p CoS 値を 5 に、そしてレイヤ 3 IP 順位/DSCP を 5/EF に設定します。 分類に関する詳細は、 「IP Phoneの接続」 を参照してください。

キューイング

インターフェイス キューイングは、データ ネットワーク内で音声の品質を確保する上で最も重要なメカニズムの 1 つです。 ごく限られたネットワーク リソースを求めて多くのトラフィック フローが競い合うような WAN では、このキューイングがさらに重要になります。 トラフィックが分類されると、フローをその処理要件に一致するインターフェイス出口キューに配置できます。 VoIP は、パケット喪失および遅延に対して許容値が極端に低いため、優先順位キューに配置する必要があります。 ただし、他のトラフィック タイプにも、特定の帯域幅と遅延特性が割り当てられる可能性があります。 このような場合には、Cisco IOS の Cisco LLQ 機能を使用して対処します。

LLQ により、優先順位キューとクラスベースの均等化キューイング方式の同時使用が可能になります。 クラスは、分類許可方式を使用して定義されます。 トラフィック フローは、PQ、クラスベースのキューの 1 つ、あるいはデフォルトの WFQ のいずれかへのアクセスができます。 LLQ は、すべての低速リンクに対する推奨キューイング方式ですが、これにより、最高 64 までのトラフィック クラスに動作を指定する能力を許可することができます。トラフィック クラスは、この能力により、音声、SNA データと IP テレフォニー 制御プロトコルに必要な最小限の帯域幅および他のトラフィック タイプへの WFQ に対するプライオリティ キューイング動作を指定します。

プライオリティ キューイングのクラスが設定されると、インターリービングが設定されていない限り、優先順位キューは tx リングへの直接のアクセスが可能となります。 そのような場合、PQ のトラフィックが TX リングに配置される前に、インターリービングが発生します。 次の図を参照してください。

図 4-21 レイヤ 2 と 3 のキューイング

 

優先順位キューおよびクラスベースのキュー内での最大設定済み帯域幅は、WAN 接続上の最小使用可能量の帯域幅を超えることはできません。このことは重要なので留意してくだい。 実際の例としては、128Kbps CIR のフレームリレー LLQ シナリオがあります。 たとえば、VoIP の優先順位キューが 64 Kbps で設定され、SNA と IP テレフォニー 制御プロトコルがそれぞれ 20 Kbps と 10 Kbps に設定されていると、設定済みのキュー帯域幅は 94 Kbps となります。 Cisco IOS のデフォルトでは、CIR/2 という最小 CIR（minicir）値に設定されています。最小 CIR は、逆方向明示的輻輳通知（BECN）が受信されたときに、フレームリレー ルータが「レート ダウン」する送信値です。 この例では、MINCIR=64 Kbps で、結合されたキューの設定帯域幅より小さい値です。 この例で LLQ を有効にするには、128 Kbps という MINCIR 値を設定する必要があります。

リンク分割とインターリーブ（LFI）

実際の変換が 768 Kbps 以下のクロック速度を使用する低速 WAN 接続では、LFI に必要なメカニズムを提供する必要があります。 インターフェイスのシリアライゼーション レートで物理ワイヤに送信できるのは、データ フレームだけです。 このシリアライゼーション レートは、フレームのサイズをそのインターフェイスのクロック速度で除したものです。 たとえば、1500 バイトのフレームは、56 Kbps の回線上でのシリアライゼーションに 214 msec かかります。 遅延に影響されやすい音声パケットが出口インターフェイス キューにある大きなデータ パケットの後ろにあると、エンドツーエンド遅延で 150 ～ 200 msec のバジェット超過となる可能性があります。 また、比較的小さなフレームであっても、ジッタの値が受信装置に適応したジッタ バッファのサイズより大きくなるだけで、音声品質全体にマイナスの影響を及ぶす可能性があります。

 

表 4-12 シリアライゼーション遅延と LFI

シリアライゼーション遅延
バイト		64	128	256	512	1024	1500
リンク 速度	56kbps	9msec	18msec	36msec	72msec	144msec	214msec
	64kbps	8msec	16msec	32msec	64msec	128msec	187msec
	128kbps	4msec	8msec	16msec	32msec	64msec	93msec
	256kbps	2msec	4msec	8msec	16msec	32msec	46msec
	512kbps	1msec	2msec	4msec	8msec	16msec	23msec
	768kbps	.640msec	1.28msec	2.56msec	5.12msec	10.4msec	15msec

LFI ツールは、エンドツーエンド遅延を正確に予測できるように、大きなデータ フレームを適当なサイズの区分にフラグメント化し、音声フレームをフローにインターリーブするのに使用されます。 LFI 、音声トラフィックが大きなデータ フレームの後から遅延しないようにすることでジッタを制限します。 これには 2 つの技術、フレームリレー用の FRF.12 とポイントツーポイントのシリアル リンクに必要なマルチリンク PPP が使用されます。

図 4-22 LFI ：使用前と使用後

 

フラグメント化サイズを設定するために使用する推奨目標は、10 msec のブロッキング遅延です。 推奨フラグメント サイズを計算するには、プロビジョニングされた回線のクロック速度で 1 バイトのトラフィックを 10 msec の推奨遅延で除します。 計算は次のようになります。

フラグメント サイズ = ( Max_Allowed_Jitter * Link_Speed_in_kbps) / 8

例は、70 バイト = (10 msec * 56) / 8

 

表 4-13 リンク速度とフラグメント サイズ

リンク速度	推奨フラグメント サイズ
56 kbps	70 バイト
64 kbps	80 バイト
128 kbps	160 バイト
256 kbps	320 バイト
512 kbps	640 バイト
768 kbps	960 バイト

---

（注） ATM と ATM/フレームリレーのインターネットワーキング WAN での LFI をサポートするのに、Cisco IOS バージョン 12.1(5)T では、MLPPP over ATM とフレームリレーが使用可能です。

---

トラフィック シェーピング

ATM とフレームリレーのネットワークでは、物理的なアクセス速度は、2 つのエンドポイント間で異なりますが、トラフィック シェーピングは、これら速度の不一致が原因で輻輳したネットワーク インタフェース バッファからの過度の遅延の発生を防止するのに使用されます。 トラフィック シェーピングは、発信元ルータから宛先ルータへのフレームの送信レートを測定するツールです。 この測定は、通常、送信インターフェイスの回線レートあるいは回路レートより低い値で実行されます。 このことが、現在のマルチプル アクセス、非ブロードキャスト ネットワークに共通して発生する回線速度の不一致の原因となっています。 セントラル サイトの T1 のような高速インターフェイスを通過するトラフィックは、多くの場合、はるかに遅いリンク速度（たとえば、56 Kbps）を使用しているリモート サイトで終了することがあります。 これはきわめて一般的なことですが、フレームリレーを使用する主要な利点の 1 つです。 この例では、セントラル サイトにあるルータ上の T1 インターフェイスは、リモート サイトのクロック レートが 56 Kbps であっても T1 のレートでデータを送信します。 これにより、フレームはキャリアのフレームリレー ネットワーク内でバッファを入れられるため、変動遅延が増大することになります。 このシナリオが逆の状況に適用されることがあります。 たとえば、それぞれが小規模な WAN 接続を持つ多くのリモート サイトがまとめて追加されると、セントラル サイトでプロビジョニングされた帯域幅あるいは回線速度が過剰加入になる可能性があります。 次の図を参照してください。

図 4-23 トラフィック シェーピングのシナリオ

 

トラフィック シェーピングとフレームリレーの設計の詳細は、 ポリシングとシェーピングの概要 を参照してください。

ネットワーク プロビジョニング

IP テレフォニー を配備するためのネットワーク設計で重要な要素となるのが、ネットワーク帯域幅の適切なプロビジョニングです。 この適切なプロビジョニングは、主要アプリケーション（たとえば、音声、ビデオおよびデータ）ごとの帯域幅要件を加算することで計算されます。 この合計は、所定のリンクに必要な最小限の帯域幅を表し、そのリンクの帯域幅の約 75 パーセントまでの構成量となるようにします。 この 75 パーセント ルールは、電子メールや HTTP トラフィックのような追加アプリケーションに加え、ルーティングおよびレイヤ 2 キープアライブのようなオーバーヘッド トラフィックに対しても一部の帯域幅が必要となることを想定しています。

図 4-24 帯域幅のプロビジョニング

 

VoIP パケットは、ペイロード、IP ヘッダー、UDP ヘッダー、RTP ヘッダー、およびレイヤ 2 リンク ヘッダーで構成されています。 デフォルトの 20 msec パケット化レートでは、VoIP パケットには次が含まれます。

• G.711 に必要な 160 バイトのペイロード

• G0.729 に必要な 20 バイトのペイロード

• 40 バイトの IP ヘッダー

• 8 バイトの UDP ヘッダー

• 12 バイトの RTP ヘッダー

リンク ヘッダーは、メディアによって異なります。 次の VoIP パケットのサンプル図を参照してください。

図 4-25 VoIP パケット

 

VoIP ストリームが消費する帯域幅を計算するには、パケットのペイロードとすべてのヘッダー（ビットで）を加算し、これに 1 秒当たりのパケット レート（デフォルトは 50 pps）を乗します。 次の表では、デフォルトのパケット レート 50 pps の VoIP フロー当たりの帯域幅を示します。 この表では、レイヤ 2 オーバーヘッドを含まず、また圧縮 RTP（cRTP）のような可能な圧縮方式を考慮していません。

---

（注） パケットの秒当たりの優先レートは、CallManager 設定ページの Service Parameters セクションで調整できます。

---

---

（注） サンプリング レートを 30 msec 以上に設定できますが、通常、このレート以上では、音声品質は非常に劣化します。

---

 

表4-14、パート1 帯域幅のプロビジョニング図

コーデック	サンプリング レート	音声ペイロード（バイト）	パケット （秒当たり）	帯域幅 （会話当たり）
G.711	20 msec	160	50	80 Kbps
G.711	30 msec	240	33	53 Kbps
G.729A	20 msec	20	50	24 Kbps
G.729A	30 msec	30	33	16 Kbps

より正確なプロビジョニングの方式では、レイヤ 2 ヘッダーを帯域幅の計算に含めます。

 

表4-14、パート2 帯域幅のプロビジョニング図

コーデック	イーサネット： 14 バイトのヘッダー	PPP ： 6 バイトのヘッダー	ATM ： 48 バイトのペイロードを含む 53 バイトのセル	フレームリレー： 4 バイトのヘッダー
G.711	20 msec	160	50	80 Kbps
G.711	30 msec	240	33	53 Kbps
G.729A	20 msec	20	50	24 Kbps
G.729A	30 msec	30	33	16 Kbps

アドミッション制御

アドミッション制御は、音声フローが音声会話に割り当てられた最大供給帯域幅を超えないようにします。

音声、データおよび可能なビデオのアプリケーションをサポートするのに必要な帯域幅をネットワークに設定する計算を行った後、音声に割り当てられた帯域幅の部分を超えて音声が加入しないようにすることが重要です。 多くの QoS メカニズムが音声をデータから保護するために使用されるのに対し、コール アドミッション制御は、音声を他の音声から保護するために使用されます。 次の図では、ネットワークが 2 つの音声コールをサポートするようにプロビジョニングされた環境を示します。 ただし、3 つめの音声コールが試行されるとすべてのコールの品質が低下します。

コールアドミッション制御の詳細は、次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

図 4-26 アドミッション制御

 

その他の WAN QoS ツール： VoIP 制御トラフィック

IP WAN に必要な帯域幅を割り当てる際に、CallManager 制御トラフィックが見落とされがちです。 中央集中型コール処理の設計では、IP Phoneは TCP 制御接続を使用して CallManager と通信します。 これらの小規模な制御接続に対して十分な帯域幅がプロビジョニングされていないと、ユーザに対して悪影響を及ぼす可能性があります。 このような影響が作用する例として、ダイヤルトーンに対する遅延（DDT）時間が上げられます。 IP Phoneは、TCP ポート 2001 上の Skinny Station プロトコルを介して、CallManager と通信します。IP Phoneはオフフックになると、CallManager に次に実行する動作を尋ねます。CallManager は IP Phoneにダイヤルトーンの再生を指示します。 この Skinny 管理と制御のトラフィックがネットワーク内でドロップあるいは遅延すると、ユーザはダイヤルトーンの再生完了を取得できなくなります。 この同じ理論が、ゲートウェイと電話に対するすべてのシグナリング トラフィックにも当てはまります。

この制御と管理トラフィックに「重要」（ただし、音声と同じくらい重要ではありません）とマーキングされるようにするには、ACL を使用して、これらのストリームをセントラル ロケーションにあるレイヤ 3/4 を認識する Catalyst 6000 スイッチ上で分類します。 これらの設定例については、 「高速キャンパスを使用可能にする」 で説明します。 リモート オフィスでは、WAN にパケットが到達する前に Cisco のルータが最初のレイヤ 3/4 を認識するデバイスとなる可能性があります。 音声ほど重要ではないが、これらの制御接続を重要として確実に分類するには、ブランチ ルータでアクセス リストを使用します。 次の例を参照してください。

class-map VoIP-RTP

match access-group 100

class-map VoIP-Control

match access-group 101

!

policy-map QoS-Policy

class VoIP-RTP

priority 100

class VoIP-Control

bandwidth 8

class class-default

fair-queue

!

access-list 100 permit ip any any precedence 5

access-list 100 permit ip any any dscp ef

!

! Skinny Control Traffic

access-list 101 permit tcp any host 10.1.10.20 range 2000 2002

!

! MGCP Control Traffic

access-list 101 permit udp any host 10.1.10.20 2427

access-list 101 permit tcp any host 10.1.10.20 2428

!

! H.323 Control Traffic

access-list 101 permit tcp any host 10.1.10.20 1720

access-list 101 permit tcp any host 10.1.10.20 range 11000 11999

その他の WAN QoS ツール： TX リング サイジング

TX リングとは優先順位付けのない FIFO バッファで、リンクの使用率を 100 パーセントにするために、送信前のフレームを保持するために使用されます。 Cisco 7500 RSP では、TX キューと呼ばれ、 tx-queue-limit コマンドを使用してそれを修正します。 RSP は、かなり効率の悪い QoS プラットフォームで、特に TX キューのパラメータを修正するには、非効率的です。 7500 RSP TX キューは、MEM-D の FIFO キューと呼ばれますが、このキューはパケットを MEM-D から DRAM 内のシステム バッファにコピーし、その後システム バッファから MEMD に戻す必要があります。 TX リングは、TX キューよりはるかに効率がよく、7500 VIP、7200、3600、2600、および 1750 ルータでは使用されます。

フラグメント化とインターリービングによりジッタは少なくなりますが、TX リング値が大きくなると、リンクの使用率が飽和に近づくにつれて、ジッタが増大する可能性があります。 したがって、TX リングのサイジングはフラグメント化サイズに関連しています。

---

（注） TX リングは、ビット単位ではなく、パケット単位で測定されます。

---

 

表 4-15 リンク速度と TX リングのバッファサイズ

リンク速度/CIR/PVC	TX リングのバッファ サイジング（パケット）
=<128 Kbps	5
192 Kbps	6
256 Kbps	7
512 Kbps	14
768 Kbps	21

すべての PPP と MLPPP では、TX リングのバッファ サイズは自動的に設定されます。 これらのデフォルト バッファ値は変更できません。 フレームリレーのリンク上では、TX リングは、メインのインターフェイス用で、このインターフェイスでは、すべてのサブインターフェイスが使用されます。 デフォルト値は 64 パケットです。 サブインターフェイスが非常に小さい、あるいは多くのサブインターフェイスがある場合、この値の変更が必要となる場合があります。

 

表 4-16 メディアと TX リングのバッファサイズ

メディア	デフォルトの TX リングのバッファ サイジング（パケット）
PPP	6
MLPPP	2
ATM	8192 ：低速仮想回線（VC）に対しては変更が必要
フレームリレー	64（メイン T1 インターフェイス当たり）

その他の WAN QoS ツール：圧縮音声コーデック

限定された WAN 帯域幅を可能な限り多く利用するために、VoIP はコーデックを使用して、アナログ音声サンプルをデジタル化します。 G.729 など多くのコーデックは 64 Kbps のコールを 8 Kbps に圧縮できます。 これらのコーデックのタイプ（低ビット レート コーデック）は、一般的に WAN を通過する音声コールに使用されています。

圧縮 RTP（cRTP）

cRTP は、VoIP パケットの 40 バイトの IP/UDP/RTP ヘッダーをおよそ 2 ～ 4 バイトにまで圧縮します。cRTP は各リンクごとに作動します。シスコのルータでは、 ip rtp header-compression コマンドを使用すると cRTP がイネーブルになります。 次の表を参照してください。

---

（注） cRTPは、現在のところ、専用回線とフレームリレーに対してのみサポートされています。 Cisco IOS バージョン 12.1(2)T は、これらのプラットフォームに対するパフォーマンスを大幅に向上させるものですが、スケーラブルの最小推奨システム ソフトウェアです。

---

 

表 4-17 cRTP 図

コーデック	PPP ： 6 バイトの ヘッダー	ATM ： 48 バイトのペイロードを含む 53 バイトのセル	フレームリレー： 4 バイトのヘッダー
500 pps で G.711	68 Kbps	該当せず	67 Kbps
500 pps で G.711	44 Kbps	該当せず	44 Kbps
500 pps で G.711	12 Kbps	該当せず	11.2 Kbps
500 pps で G.711	8 Kbps	該当せず	7.4 Kbps

その他の WAN QoS ツール：VAD（Voice Activity Detection）検出

VAD（Voice Activity Detection）は、ほとんどの会話で、一度に話せるのは 1 人だけであるという事実を利用します。 VoIP コードの VAD アルゴリズムは、音声会話内に、会話でギャップがないかを調べます。 ギャップが発見されると、パケットは送信されず、WAN の帯域幅が回復し、データ アプリケーションで使用できるようになります。 システム全体で、VAD を常時オフにしておくことをお勧めします。 デフォルトでは、オンになっています。

---

（注） 固有の遅延が大量に発生しやすい環境では、VAD は、回復した帯域幅で調整される以上の音声品質の問題を引き起こす可能性があります。 このことは、ケースバイケースで検査する必要があります。 ただし、IP テレフォニー ネットワークで会話を開始するときにクリッピングをトラブルシューティングする場合、最初に VAD をディセーブルにしてください。

---

ポイントツーポイント WAN

この項では、次の事項を強調します。

• 必要最小限の推奨 Cisco IOS は、バージョン 12.1(5)T

• 768 Kbps より遅い速度のすべての WAN 接続に対して LFI 技術を使用する

• VoIP ベアラ ストリームには優先順位キューを、VoIP 制御セッションにはクラス キューのある LLQ を使用する

• WAN を通過するコール数が、割り当てられた VoIP 帯域幅を上回る場合、コール アドミッション制御を使用する必要がある

図 4-27 ポイントツーポイント WAN ： QoS 問題領域

 

以前ほどではありませんが、ポイントツーポイント WAN は、現在でもネットワークで最も定評のあるタイプの 1 つです。 IP テレフォニー ネットワークに対してポイントツーポイント WAN を設計するときは、次に説明する、複数の QoS 問題を考慮する必要があります。

ポイントツーポイント WAN での LFI

接続のクロッキング速度が 768 Kbps より遅い場合、LFI を使用する必要があります。 また、LFI が必要となるすべてのポイントツーポイント リンク上で PPP の代わりに MLPPP を使用する必要があります。 ポイントツーポイント WAN 上で LFI をイネーブルにするには、必ず、MLPPP Cisco IOS のコマンド セットを使用する必要があります。

---

（注） MLPPP を使用する場合、フラグメント化サイズは、キュー内の最大の許容遅延（10 msec）を使用して設定します。 また、TX リングも 2 つのパケットの値で静的に設定します。

---

interface Multilink1

ip address 10.1.61.1 255.255.255.0

ip tcp header-compression iphc-format

no ip mroute-cache

load-interval 30

service-policy output QoS-Policy

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

interface Serial0

bandwidth 256

no ip address

encapsulation ppp

no ip mroute-cache

load-interval 30

no fair-queue

ppp multilink

multilink-group 1

 

MLPPP 接続での cRTP

cRTP は、各音声コールで使用される帯域幅の量に大きな影響を及ぼすことがあります。 Cisco IOS バージョン 12.0(7)T より以前のリリースでは、cRTP がプロセス交換されていることに留意することが重要です。 事実、Cisco IOS バージョン 12.0(7)T でバグ修正が実装されるまで、cRTP のファースト スイッチングは実際に 2600 と 3600 では動作しませんでした。また、Cisco IOS の新しいバージョンの一部（特に、バージョン 12.1(2.x)T）も cRTP をプロセス交換します。

interface Multilink1

ip address 10.1.61.1 255.255.255.0

ip tcp header-compression iphc-format

no ip mroute-cache

load-interval 30

service-policy output QoS-Policy

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

 

MLPPP を通過する VoIP の LLQ

LLQ は、ＷＡＮ を通過する音声のサポートに必要です。 MLPPP をイネーブルにするインターフェイスに LLQ を設定するとき、サービス ポリシーの出力をマルチリンク インターフェイス設定に配置します。 下記の例では、2 つのクラスを定義します。 1 つは VoIP メディア ストリーム用のクラス、そして、もう 1 つは制御トラフィック用のクラスです。 これらのクラスへのアクセスとそのクラスがサービスするキューは、レイヤ 3 TOS 分類あるいは発信元/宛先 IP アドレスとポートのいずれかに一致するアクセス リストを介して実行されます。 アクセス リストは、セントラル サイトでの制御トラフィックに対しては少し異なるように見えます。その理由は、 Catalyst 6000 が 26 の DSCP 値（IP Precedence 3 とバックワード コンパティビリティのある AF31）を使用して VoIP 制御セッションを分類しているからです。

すべての IP メディア トラフィックは、PQ に配置され、そこで 100 Kbps の帯域幅が与えられます。 すべての Skinny 制御トラフィックは、クラスベースのキューに配置され、10 Kbps の帯域幅が与えられます。 その他のすべてのトラフィックは、WFQ を使用してキューに配置されます。

class-map VoIP-RTP

match access-group 100

class-map VoIP-Control

match access-group 101

!

policy-map QoS-Policy-256k

class VoIP-RTP

priority 100

class VoIP-Control

bandwidth 8

class class-default

fair-queue

!

interface Multilink1

ip address 10.1.61.1 255.255.255.0

ip tcp header-compression iphc-format

no ip mroute-cache

load-interval 30

service-policy output QoS-Policy

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

multilink-group 1

ip rtp header-compression iphc-format

!

! ToS VoIP Media Stream Classification: either IP Prec or DSCP

! This access-list is the same at the both the remote and

! central locations

access-list 100 permit ip any any precedence 5

access-list 100 permit ip any any dscp ef

!

! Skinny, H.323 and MGCP VoIP Control Traffic

! which has already been classified using the

! route-map in section 4.5.

access-list 101 permit ip any any precedence 3

access-list 101 permit ip any any dscp 26

 

MLPPP 接続でのキューイング、フラグメント化とインターリービングの検証

1750# sh queue multilink1

Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 8288

Queueing strategy: weighted fair

Output queue: 63/1000/64/8288/1967(size/maxtotal/threshold/drops/interleaves)

Conversations 1/3/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

 

! All drops and interleaves are occurring on ToS=0 flows

(depth/weight/discards/tail drops/interleaves) 63/32384/8288/0/1967

Conversation 60, linktype: ip, length: 1008

source: 10.1.60.98, destination: 10.1.10.98, id: 0x0322, ttl: 63,

TOS: 0 prot: 17, source port 1024, destination port 7

 

 

1750# sh policy interface multilink1

Multilink1

output : QoS-Policy-256k

Class VoIP-RTP

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 100 (Kbps)

(pkts matched/bytes matched) 28100/5675882

(pkts discards/bytes discards) 0/0

Class VoIP-Control

Weighted Fair Queueing

Output Queue: Conversation 265

Bandwidth 8 (Kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 204/10284

(pkts discards/bytes discards/tail drops) 0/0/0

Class class-default

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

 

フレームリレー WAN

この項では、次の事項について強調します。

• 必要最小限の推奨 Cisco IOS は、バージョン 12.1(5)T

• トラフィック シェーピングを使用する必要がある

• 768 Kbps 未満の速度のすべての WAN 接続に LFI 技術を使用する

• VoIP ベアラ ストリームには優先順位キューの LLQ を、VoIP 制御セッションにはクラス キューの LLQ を使用する

• WAN を通過するコール数が割り当てられた VoIP 帯域幅を上回る場合、コール アドミッション制御を使用する必要がある

図 4-28 フレームリレー WAN ： QoS 問題領域

 

フレームリレーのネットワークは、それにかかるコストが低いことから、今日使用されている WAN 中でも最も多く使用されている WAN です。 しかし、フレームリレーは、コスト節約のために加入超過を使用する非ブロードキャストの技術のため、必ずしも、IP テレフォニー を配置するのに容易なメディアではありません。

フレームリレーの設計に関する詳細は、「Policing and Shaping Overview」についての文書を参照してください。 この文書は、次の URL にあります。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart4/

トラフィック シェーピング

フレームリレー ネットワークでは、次の 3 つの理由により、トラフィック シェーピングを使用する必要があります。 それは、サイトの加入超過がフレームリレー ネットワークの特性の一部であること。CIR を超えるバースト性が普通に設定されること、およびシスコのフレームリレー デバイスのデフォルトのインターバルに不要な遅延が追加される可能性があることの 3 つです。

• CIR ：多くのフレームリレー ネットワークでは、セントラル サイトは T1 リンクあるいはそれ以上を使用して、多数のリモート オフィスからの WAN 接続を終了します。 セントラル サイトは、リモート サイトが 56 Kbps 回線だけしか使用できない場合があるにもかかわらず、1.536 Mbps でデータを送信します。 また、一般的にリモート オフィス対セントラルのハブの比率は、多数のリモート オフィスに対して 1 つのセントラル ハブとなっています。 すべてのリモートがトラフィックをハブの T1 を圧倒するレートで送信することは実際に可能です。 これらの両方のシナリオは、遅延、ジッタおよびドロップを誘発する可能性があるプロバイダ ネットワークでは、フレームのバッファリングを引き起こすことになります。 唯一のソリューションは、セントラルとリモート ルータの両方でトラフィックをシェーピングすることです。

• Bc ：ネットワークに関するもう 1 つの問題は、フレームリレーのノードが所定の時間に送信できるデータの量です。 56 Kpbs PVC は、1 秒間に最高 56 Kb のトラフィックを送信できます。 この秒を分割する方法を「インターバル」と呼びます。 このインターバル間でノードが送信できるトラフィックの量を、Bc (Committed Burst) レートと呼びます。 デフォルトでは、すべてのシスコのルータの Bc は CIR/8 に設定されています。インターバルの計算式は、次のとおりです。

インターバル＝ Bc/CIR、あるいは 125 msec ＝ 56 Kbps CIR に対する 7000/56,000

前述の例では、ルータは、その割り当て済みの 7000 ビットを送信した後、その次のトラフィックを送信するまで 125 msec 待機する必要があります。 これは、データにとっては適切なデフォルト値ですが、音声にとってはきわめて不適切な値となります。 Bc 値をはるかに低い数値に設定することで、インターバルは減少しますが、ルータがより頻繁にトラフィックを送信することになります。 Bc の最適な設定値は 1000 です。

• Be ：ルータにその Bc（たとえば、1000 ビット）のすべてを送信するのに十分なトラフィックがない場合、ルータはそのアカウントを「クレジット」し、後のインターバルの時により多くのトラフィックを送信できます。 ルータがクレジットできる最大アカウント量は、Be (Excess Burst) レートで設定します。 IP テレフォニー ネットワークで Be が問題となるのは、フレームリレー ネットワーク内でバッファリング遅延を引き起こす可能性があることです。その原因は、受信側は、回線からのトラフィックを Bc ＋ Be ではなく、Bc で「引き出す」ことしかできないからです。

• MINICIR ： Cisco IOS のデフォルトは、CIR/2 の最小 CIR 値に設定されています。最小 CIR は、BECN を受信したときに、フレームリレーのルータが「レートダウン」する送信値です。 優先順位キューとクラスベースのキューで設定される最大の帯域幅は、WAN 接続で可能な必要最小限の帯域幅の量を超えることはできません。このことは重要なので留意してくだい。 256 Kbps フレームリレー回線に接続されているリモート サイトの例を、次に示します。

interface Serial1

no ip address

encapsulation frame-relay

load-interval 30

frame-relay traffic-shaping

!

interface Serial1.71 point-to-point

bandwidth 256

ip address 10.1.71.1 255.255.255.0

frame-relay interface-dlci 71

class VoIP-256kbs

!

map-class frame-relay VoIP-256kbs

frame-relay cir 256000

frame-relay bc 1000

frame-relay be 0

frame-relay mincir 256000

no frame-relay adaptive-shaping

service-policy output QoS-Policy-256k

frame-relay fragment 160

 

フレームリレー WAN 上の LFI 用 FRF.12

フレームリレー WAN 上で LFI をイネーブルにするには、トラフィック シェーピングも使用する必要があります。 MLPPP と異なり、フレームリレー上で LFI を使用するときは、実際のフラグメント サイズを設定する必要があります。 次の例を参照してください。

map-class frame-relay VoIP-256kbs

frame-relay cir 256000

frame-relay bc 1000

frame-relay be 0

frame-relay mincir 256000

no frame-relay adaptive-shaping

service-policy output QoS-Policy-256k

frame-relay fragment 160

 

フレームリレー接続での cRTP

cRTP は、各音声コールで使用される帯域幅の量に大きな影響を及ぼすことがあります。 cRTP ファースト スイッチングが Cisco IOS バージョン 12.0(7)T ではイネーブルになっていますが、その一方で、新しい Cisco IOS のバージョンの一部（特に、12.1(2x)T）では、cRTP をプロセス交換します。

interface Serial1

no ip address

encapsulation frame-relay

load-interval 30

frame-relay traffic-shaping

ip rtp header-compression iphc-format

 

フレームリレーを介した VoIP に使用する LLQ

LLQ は、WAN を介して音声をサポートするのに必要です。 フレームリレーをイネーブルにするインターフェイスに LLQ を設定するとき、サービス ポリシーの出力を マップ クラス フレームリレー 設定セクションに配置します。 次の例では、 VoIP メディア ストリーム用のクラス、および制御トラフィック用のクラスの 2 つのクラスを定義します。 これらのクラスへのアクセスとそのクラスがサービスするキューは、レイヤ 3 TOS 分類あるいは発信元/宛先 IP アドレスとポートのいずれかに一致するアクセス リストを介して実行されます。 アクセス リストは、セントラル サイトでの制御トラフィックに対しては少し異なるように見えます。その理由は、 Catalyst 6000 が 26 の DSCP 値（IP Precedence 3 とバックワード コンパティビリティのある AF31）を使用して VoIP 制御セッションを分類しているからです。

すべての IP メディア トラフィックは、PQ に配置され、そこで 100 Kbps の帯域幅が与えらます。 すべての Skinny 制御トラフィックは、クラスベースのキューに配置され、10 Kbps の帯域幅が与えられます。 その他のすべてのトラフィックは、WFQ を使用してキューに配置されます。

class-map VoIP-RTP

match access-group 100

class-map VoIP-Control

match access-group 101

!

policy-map QoS-Policy-256k

class VoIP-RTP

priority 100

class VoIP-Control

bandwidth 8

class class-default

fair-queue

!

interface Serial1

no ip address

encapsulation frame-relay

load-interval 30

frame-relay traffic-shaping

!

interface Serial1.71 point-to-point

bandwidth 256

ip address 10.1.71.1 255.255.255.0

frame-relay interface-dlci 71

class VoIP-256kbs

!

map-class frame-relay VoIP-256kbs

frame-relay cir 256000

frame-relay bc 1000

frame-relay be 0

frame-relay mincir 256000

no frame-relay adaptive-shaping

service-policy output QoS-Policy-256k

frame-relay fragment 160

!

! ToS VoIP Media Stream Classification: either IP Prec or DSCP

! This access-list is the same at the both the remote and

! central locations

access-list 100 permit ip any any precedence 5

access-list 100 permit ip any any dscp ef

!

! Skinny, H.323 and MGCP VoIP Control Traffic

! which has already been classified using the

! route-map in section 4.5.

access-list 101 permit ip any any precedence 3

access-list 101 permit ip any any dscp 26

 

フレームリレーのキューイング、フラグメント化およびインターリーブの検証

3600# sh policy interface s 0/1.73

Remote Branch 3600

Serial0/1.73: DLCI 73 -

 

Service-policy output: QoS-Policy-256k (1117)

 

Class-map: VoIP-RTP (match-all) (1118/2)

5008 packets, 964953 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip precedence 5 (1120)

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 40

Bandwidth 100 (Kbps)

(pkts matched/bytes matched) 4976/955161

(pkts discards/bytes discards) 0/204

 

Class-map: VoIP-Control (match-all) (1122/3)

53 packets, 3296 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip precedence 3 (1124)

Weighted Fair Queueing

Output Queue: Conversation 41

Bandwidth 8 (Kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 53/3296

(pkts discards/bytes discards/tail drops) 0/0/0

 

Class-map: class-default (match-any) (1126/0)

5329 packets, 985755 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any (1128)

5329 packets, 985755 bytes

30 second rate 0 bps

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 32

 

 

HQ_7200# sh frame-relay pvc int s6/0 73

Headquarters 7200

 

PVC Statistics for interface Serial6/0 (Frame Relay DTE)

 

DLCI = 73, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial6/0.73

 

input pkts 114 output pkts 103 in bytes 8537

out bytes 10633 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 62 out bcast bytes 5203

pvc create time 00:04:22, last time pvc status changed 00:04:22

service policy QoS-Policy-256k

 

Service-policy output: QoS-Policy-256k (1099)

 

Class-map: VoIP-RTP (match-all) (1100/2)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp 46 (1102)

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 100 (Kbps)

(pkts matched/bytes matched) 0/0

(pkts discards/bytes discards) 0/0

 

Class-map: VoIP-Control (match-all) (1104/3)

25 packets, 3780 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: ip dscp 26 (1106)

Weighted Fair Queueing

Output Queue: Conversation 73

Bandwidth 8 (Kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 25/3780

(pkts discards/bytes discards/tail drops) 0/0/0

 

Class-map: class-default (match-any) (1108/0)

163 packets, 15708 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: any (1110)

163 packets, 15708 bytes

30 second rate 0 bps

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 64

Output queue size 0/max total 600/drops 0

fragment type end-to-end fragment size 160

cir 768000 bc 7680 be 0 limit 960 interval 10

mincir 768000 byte increment 960 BECN response no

frags 125 bytes 10913 frags delayed 125 bytes delayed 10913

 

shaping inactive

traffic shaping drops 0

ATM WAN

この項では、次の事項について強調します。

• 必要最小限の推奨 Cisco IOS は、MLPPP over ATM をサポートするバージョン 12.1(5)

• DS3 より遅い速度のすべての ATM 接続には、TX リングのバッファ サイズを調整する必要がある

• PVC 速度が 768 Kpbs より遅い場合、2 つの PVC を使用することを推奨

• 768 Kbps より遅い単一の PVC を使用する場合は、LFI に対して MLPPP over ATM を使用する

• 単一の PVC を使用する場合、VoIP ベアラ ストリームに優先順位キューの LLQ を、VoIP 制御セッションにクラス キューの LLQ を使用する

• WAN を通過するコール数が、割り当てられた VoIP 帯域幅を上回るような場合、コール アドミッション制御を使用する必要がある

図 4-29 ATM WAN ： QoS の問題領域

 

ATM は、多くのサービス プロバイダがこのテクノロジーを採用しているため、WAN で使用されるメディアとして普及し始めました。 WAN に ATM を配備する上で困難な点の 1 つが、低速用途ではなく、高速用途で設計されていることです。 多くの企業は、低速 ATM 接続を使用して IP テレフォニー を配備しようとしています。 このことが、一般的に、複雑な問題を引き起こします。これは、Cisco IOS QoS ツールが現在のところ ATM インターフェイスでサポートされておらず、インターフェイス デフォルトの多くは、高速 ATM 回線用に自動的に設定されるためです。

このことは、ATM TX リング バッファのデフォルト サイジングで明白になります。 たとえば、デフォルトでは、7200 の OC-3 インターフェイスである PA-A3 は、TX リングを 8192 を設定します。この設定値は、OC-3 に対しては適切な設定なのですが、インターフェイスで設定されている 256 Kpbs PVC に対しては、非常に大きな TX リング バッファ遅延が発生する可能性があります。 したがって、TX リングの値をサブインターフェイス レベルではるかに低い値に設定する必要があります。 256 Kbps ATM PVC に接続されているリモート サイト ルータの例を、次に示します。

interface ATM2/0

no ip address

no ip mroute-cache

shutdown

atm pvc 1 0 16 ilmi

no atm ilmi-keepalive

!

interface ATM2/0.37 point-to-point

pvc cisco37 0/37

tx-ring-limit 7

abr 256 256

service-policy output QoS-Policy-256k

protocol ppp Virtual-Template2

!

!

 

低速 ATM WAN 上の 2 つの PVC または LFI

768 Kpbs より遅い PVC を使用して、ATM ネットワーク全体で VoIP を使用する最善の方式を設計するには、音声とデータに対して別個の PVC を使用することです。 この設定は次のようになります。

interface ATM2/0.38 point-to-point

bandwidth 256

ip address 10.1.38.52 255.255.255.0

pvc cisco38 0/38

service-policy output Data-Policy-128k

vbr-nrt 128 128

encapsulation aal5snap

interface ATM2/0.39 point-to-point

bandwidth 256

ip address 10.1.39.52 255.255.255.0

pvc cisco39 0/39

tx-ring-limit 5

service-policy output VoIP-Policy-128k

vbr-nrt 128 128

encapsulation aal5snap

 

2 つの PVC の使用が、代替の設計として受け入れられない場合、別のオプションとして、
MLPPP-over-ATM（MLPoATM）ツールを LFI に使用する方法があります。 ATM は固定ペイロード サイズを使用するセル テクノロジーであるため、固有の LFI ツールはありません。 MLPoATM を使用する新しい標準は、Cisco IOS バージョン 12.1(4)T で利用できます。MLPoATM は、低速 ATM リンクにレイヤ 2 のフラグメント化とインターリーブ方式を提供します。

MLPoATM のフラグメント サイズが理想的なものであると、フラグメントは ATM セルの正確な倍数になります。 MLPPP と AAL5 のオーバーヘッドをすべてのフラグメント化計算に含めることが重要です。 MLPoATM ヘッダーは、10 バイトで、AAL5 パケットのオーバーヘッドは 8 バイトです。

MLPoATM のフラグメント サイズは、次のようにして計算できます。

Fragment_Size = (48 * Number_of_Cells) - 10 - 8

たとえば、フラグメント当たり 7 つのセルを必要とする場合、フラグメント サイズは、318 バイトになります。

MLPPP over ATM を使用する際には、興味深いフィーチャがいくつかあります。 たとえば、マルチリンク インターフェイスを使用する代わりに、「仮想テンプレート」を使用できます。 MLPoATM コードの新しいリリースでは、仮想テンプレートの設定は、マルチリンク インターフェイスに置き換えられます。 マルチリンク インターフェイスでは、スケーラビリティが向上すると同時に、既存の MLPPP インストーレーションへの統合が容易になるためです。 リモート サイトが MLPoATM を使用して通信する場合、PPP CHAP の設定も必要です。 MLPoATM では、発信パケットは ATM VC への送信前に MLP バンドルがそれらの発信パケットを分類する必要があります。 FIFO キューイングが ATM VC に対して VC 単位のキューイング ストラテジとして使用されることも必要です。 7200 の ATM Delux PA および 36x0 の OC3 NM などの一部の拡張 ATM ハードウェアは、VC 別トラフィック シェーピングをサポートします。 MLPoATM は、この ATM ハードウェアをサポートするプラットフォーム上でのみサポートされます。 この設定は次のようになります。

interface ATM2/0

no ip address

no ip mroute-cache

shutdown

atm pvc 1 0 16 ilmi

no atm ilmi-keepalive

!

interface ATM2/0.37 point-to-point

pvc cisco37 0/37

tx-ring-limit 7

abr 256 256

protocol ppp Virtual-Template2

!

!

interface Virtual-Template2

bandwidth 254

ip address 10.1.37.52 255.255.255.0

service-policy output QoS-Policy-256k

ppp authentication chap

ppp chap hostname HQ_7200

ppp chap password 7 05080F1C2243

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

 

ATM 接続での cRTP

cRTP は、現在、ATM インターフェイスでサポートされていません。

ATM を介した VoIP の LLQ

LLQ は、単一の PVC を配備する場合に、ATM WAN を介した音声をサポートするのに必要です。 ATM をイネーブルにするインターフェイスに対して LLQ を設定するとき、サービス ポリシー出力はサブインターフェイス PVC 設定セクション下に配置されます。 次の例では、 VoIP メディア ストリーム用のクラス、および制御トラフィック用の 2 つのクラスが定義されますす。 これらのクラスへのアクセス、つまりそのクラスがサービスするキューへのアクセスは、レイヤ 3 TOS 分類あるいは発信元/宛先 IP アドレスとポートのいずれかに一致するアクセス リストを使用して行われます。 アクセス リストは、セントラル サイトでの制御トラフィックとほんの少し異なるように見えます。その理由は、 Catalyst 6000 が 26 の DSCP 値（IP Precedence 3 とバックワード コンパティビリティのある AF31）を使用して VoIP 制御セッションを分類しているからです。

すべての IP メディア トラフィックは、PQ に配置され、そこで 100 Kbps の帯域幅が与えられます。 すべての Skinny 制御トラフィックは、クラスベースのキューに配置され、10 Kbps の帯域幅が与えられます。 その他のすべてのトラフィックは、WFQ を使用してキューに配置されます。

class-map VoIP-RTP

match access-group 100

class-map VoIP-Control

match access-group 101

!

policy-map QoS-Policy-256k

class VoIP-RTP

priority 100

class VoIP-Control

bandwidth 8

class class-default

fair-queue

!

interface ATM2/0

no ip address

no ip mroute-cache

shutdown

atm pvc 1 0 16 ilmi

no atm ilmi-keepalive

!

interface ATM2/0.37 point-to-point

pvc cisco37 0/37

tx-ring-limit 7

abr 256 256

protocol ppp Virtual-Template2

!

!

interface Virtual-Template2

bandwidth 256

ip address 10.1.37.52 255.255.255.0

service-policy output QoS-Policy-256k

ppp authentication chap

ppp chap hostname HQ_7200

ppp chap password 7 05080F1C2243

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

!

!

!

! ToS VoIP Media Stream Classification: either IP Prec or DSCP

! This access-list is the same at the both the remote and

! central locations

access-list 100 permit ip any any precedence 5

access-list 100 permit ip any any dscp ef

!

! Skinny, H.323 and MGCP VoIP Control Traffic

! which has already been classified using the

! route-map in section 4.5.

access-list 101 permit ip any any precedence 3

access-list 101 permit ip any any dscp 26

 

フレームリレー間 ATM インターネットワーキング WAN へ

この項では、次の事項について強調します。

• 必要最小限の推奨 Cisco IOS は、MLPoATM と MLPPP-over-Frame Relay（MLPoFR）をサポートするバージョン 12.1(5)

• FRF.8 の透過モードは、MLPoATM とフレームリレー サービスのインターネットワーキングをサポートする唯一の方式

• DS3 より遅い速度のすべての ATM 接続には、TX リングのバッファ サイズを調整する必要がある

• ATM とフレームリレーの PVC 速度が 768 Kpbs より遅い場合、2 つの PVC を使用することを推奨

• 768 Kbps より遅い単一の PVC を使用する場合は、MLPoATM とフレームリレー を LFI に使用する

• 単一の PVC を使用する場合、VoIP ベアラ ストリームに優先順位キューの LLQ を、VoIP 制御セッションにクラス キューの LLQ を使用する

• WAN を通過するコール数が、割り当てられた VoIP 帯域幅を上回るような場合、コール アドミッション制御を使用する必要がある

図 4-30 フレームリレーから ATM へ： QoS 問題領域

 

多くの企業では、リモート サイトでフレームリレーを使用し、セントラル ロケーションで ATM を使用するネットワーク全体に IP テレフォニー を配備しています。 ATM とフレームリレー間の変換は、ATM からフレームリレーへのサービス インターネットワーキング（FRF.8）を介してキャリア ネットワークで行われます。

---

（注） LFI に使用される MLPoATM とフレームリレーは、透過モード FRF.8 だけをサポートします。

---

低速 ATM での LFI からフレームリレーのインターネットワーキング WAN へ

現在、FRF.12 をサポートしているサービス プロバイダがないため、FRF.12 は使用できません。 また、シスコでは、FRF.12 をサポートする WAN スイッチング ギアを提供していません。 ATM 側に FRF.12 標準がないため、サービス プロバイダのネットワークを経由した FRF.12 のトンネル伝送の状態は良くありません。 フレームリレーを使用しているいずれかのリモート サイトが 768 Kpbs あるいはそれ以下の回線を使用している場合、フラグメント化が必要になるため、このトンネル伝送が問題となります。 768 Kpbs より遅い PVC を使用して、ATM ネットワーク全体で VoIP を使用する最善の方式を設計するには、音声とデータに対して別個の PVC を使用することです。

2 つの PVC を使用することが実用的ではない場合、Cisco IOS バージョン 12.1(5)T で使用可能な新しい MLPoATM とフレームリレーのツールをリンクのフラグメント化とインターリーブに使用できます。MLPoATM とフレームリレーは、フレームリレー FRF.8 のサービス インターネットワーキングのリンクに対して低速 ATM 用のエンドツーエンドのレイヤ 2 フラグメント化とインターリーブ方式を提供します。

FRF.8 のサービス インターネットワーキングは、フレームリレー ネットワークと ATM ネットワークを接続するフレームリレー フォーラムの標準です。 サービス インターネットワーキングは、サービス プロバイダ、企業およびエンド ユーザに標準ベースのソリューションを提供します。 サービス インターネットワーキングの変換モードでは、フレームリレー PVC は対称トポロジを必要とせずに、ATM PVC にマップされます。つまり、パスは ATM サイドで終了できます。 FRF.8 は、上位層ユーザプロトコルのカプセル化に必要な IWF の 2 つの動作モードをサポートします。 この 2 つの動作モードは、次のとおりです。

• 変換モード：ATM とフレームリレー間のカプセル化でマップします。 また、ルーテッド プロトコルあるいはブリッジド プロトコルのインターネットワーキングもサポートします。

• 透過モード：カプセル化はマップしませんが、カプセル化をそのまま送信します。 カプセル化方式がサービス インターネットワーキングをサポートしている標準に準拠していないため、変換が実用的ではない場合、このモードを使用します。

ATM およびフレームリレーの サービス インターネットワーキング ネットワーク上で LFI に使用する MLPPP は、透過モードで使用される場合にのみサポートされます。

MLPoFR と MLPoATM のインターネットワーキングを実行可能にするには、インターネットワーキング スイッチを透過モードで設定し、エンド ルータが MLPoFR と MLPoATM の両方のヘッダーを認識できるようにする必要があります。 フレームリレーには frame-relay interface-dlci <dlci> ppp コマンドを、ATM には protocol ppp コマンドを使用して、認識できるようにします。

ATM のフレームリレー側からフレームリーレーのサービス インターネットワーキング接続にフレームが送信されると、次のように処理されます。

1. 送信ルータは、MLPoFR ヘッダーのパケットをカプセル化します。

2. キャリア スイッチ（透過モードで）は、2 バイトフレームリレー DLCI フィールドを取り除き、パケットの残りをキャリア スイッチの ATM インターフェイスに送信します。

3. 受信ルータは、受信したパケットのヘッダーを検査します。 受信パケットの最初の 2 バイトが 0x03cf の場合、受信ルータはそれを大きな MLPoATM パケットとして処理し、そのパケットを MLPPP レイヤに送信してさらに処理します。

ATM の ATM 側からフレームリーレーのサービス インターネットワーキング接続に ATM のセルが送信されると、次のように処理されます。

1. 送信ルータは、MLPoATM ヘッダーのパケットをカプセル化します。

2. キャリア スイッチ（透過モードで）は、2 バイトのフレームリレー DLCI フィールドを受信したパケットの先頭に付加して、パケットをキャリア スイッチのフレームリレー インターフェイスに送信します。

3. 受信ルータは、受信したパケットのヘッダーを検査します。 受信パケットの 2 バイト DLCI フィールドに続く最初の 4 バイトが 0xfefe03cf の場合、受信ルータはそれを正当な MLPoFR パケットとして処理し、そのパケットを MLPPP レイヤに送信してさらに処理します。

新しい ATM からフレームリレーへのサービス インターネットワーキング標準である FRF.8.1 が、MLPoATM とフレームリレーのサービス インターネットワーキングをサポートすることになります。 ただし、すべてのスイッチが新しい標準にアップデートされるまでには、まだ数年間を必要とします。

MLPoATM に理想的なフラグメント サイズは、フラグメントが ATM セルの正確な倍数になるようにする必要があります。 MLPPP と AAL5 のオーバーヘッドをすべてのフラグメント化計算に含めることが重要です。 MLPoATM ヘッダーは、10 バイトで、AAL5 パケットのオーバーヘッドは 8 バイトです。

MLPoATM のフラグメント サイズは、次のようにして計算できます。

Fragment_Size = (48 * Number_of_Cells) - 10 - 8

たとえば、フラグメント当たり 7 つのセルを必要とする場合、フラグメント サイズは、318 バイトになります。

次の設定を参照してください。

セントラルの ATM 設定

interface ATM2/0

no ip address

no ip mroute-cache

shutdown

atm pvc 1 0 16 ilmi

no atm ilmi-keepalive

!

interface ATM2/0.37 point-to-point

pvc cisco37 0/37

tx-ring-limit 7

abr 256 256

protocol ppp Virtual-Template2

!

!

interface Virtual-Template2

bandwidth 254

ip address 10.1.37.52 255.255.255.0

service-policy output QoS-Policy-256k

ppp authentication chap

ppp chap hostname HQ_7200

ppp chap password 7 05080F1C2243

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

 

リモート フレーム リレー設定

interface Serial6/0

description T1 to Frame Relay switch

no ip address

encapsulation frame-relay

load-interval 30

no arp frame-relay

frame-relay traffic-shaping

!

interface Serial6/0.73 point-to-point

description 3640

no arp frame-relay

frame-relay interface-dlci 73 ppp Virtual-Template2

class VoIP-256kbs

!

interface Virtual-Template2

bandwidth 254

ip address 10.1.37.51 255.255.255.0

service-policy output QoS-Policy-256k

ppp authentication chap

ppp chap hostname R72HQ

ppp chap password 7 05080F1C2243

ppp multilink

ppp multilink fragment-delay 10

ppp multilink interleave

MLPoATM を使用する際には、興味深いフィーチャがいくつかあります。 たとえば、マルチリンク インターフェイスの代わりに、仮想テンプレート インターフェイスを使用できます。 ただし、MLPoATM コードの新しいリリースでは、仮想テンプレート設定はマルチリンク インターフェイスに置き換えられます。 マルチリンク インターフェイスでは、スケーラビリティが向上するのと同時に既存の MLPPP インストーレーションへの統合がより容易になるからです。 リモート サイトが、MLPoATM を使用して通信する必要がある場合、PPP CHAP を設定する必要があります。 MLPoATM では、発信パケットは ATM VC に送信される前に MLP バンドルがそれらの発信パケットを分類する必要があります。 FIFO キューイングが ATM VC に対して VC 単位のキューイング ストラテジとして使用されることも必要です。 7200 の ATM Delux PA および 36x0 の OC3 NM のような一部の拡張 ATM ハードウェアは、VC 別トラフィック シェーピングをサポートしています。 MLPoATM は、この ATM ハードウェアをサポートするプラットフォーム上でサポートされます。

---

（注） MLPoFR は、FR VC をバンドルする MLP からのパケットのフローを制御するために、フレームリレー のトラフィック シェーピング（FRTS）エンジンに依存します。

---

ATM からフレームリレーへの接続での cRTP

ATM インターフェイスは、現在、cRTP をサポートしていません。

ATM とフレームリレーを通過する音声の LLQ

サービス インターネットワーキングを使用するとき、フレームリレーと ATM リンクに対する LLQ 設定は、エンドツーエンド MLPoATM と同一です。 詳細は、 「ATM WAN」 を参照してください。

要約

適切な VoIP ネットワーク設計と新しい Catalyst 製品、最新の Cisco IOS イメージおよび CallManager Call Admission Control 制御テクノロジーを組み合わせることにより、VoIP 品質が保証されます。 IP テレフォニー ネットワークを構築するときは、次の原則に従う必要があります。

• IP Phoneと音声に使用する補助 VLAN との接続には 802.1Q/p 接続を使用する

• 音声 RTP ストリームを EF/IP Precedence 5 として分類し、それを 2 番目のキューあるいはすべてのネットワーク要素の PQ に配置する

• 音声制御トラフィックを AF/IP Precedence 3 として分類し、それをすべてのネットワーク要素の 2 番目のキューに配置する

• LAN バッファが 100 パーセントの使用率に近づいたら、キャンパス内で QoS をイネーブルにする

• 帯域幅の 25 パーセントを、オーバーヘッド、ルーティング プロトコル、レイヤ 2 リンク情報、およびその他のトラフィックに使用するように概算して、常に、適切に WAN をプロビジョニングする

• すべての WAN インターフェイス上で LLQ を使用する

• 768 Kpbs より遅いすべてのリンク速度には LFI 技術を使用する