Cisco テクニカル ソリューション シリーズ:IP テレフォニー ソリューション ガイド
IP テレフォニー ネットワークの設計
IP テレフォニー ネットワークの設計
発行日;2012/01/08 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

IP テレフォニー ネットワークの設計

この章の構成

関連情報とリンク

概要

IP テレフォニー 設計の概要

キャンパス インフラストラクチャの設計

LAN/WAN QoS の設計

QoS の重要性

ネットワークの品質

ネットワークの輻輳

遅延とジッタ

IP Phoneの接続

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

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

SoftPhone

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

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

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

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

Catalyst 6000 アクセス レイヤ

Catalyst 4000 アクセス レイヤ

Catalyst 3500 アクセス レイヤ

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

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

ブランチ オフィスの構築

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

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

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

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

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

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

WAN QoS の概要

ポイントツーポイント WAN

フレームリレー WAN

ATM WAN

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

要約

Cisco CallManagerクラスタの設計

ゲートウェイの選択

ダイヤル プランのアーキテクチャと設定

分散型コール処理を使用する複数サイト WAN の設計

中央集中型コール処理を使用する複数サイト WAN の設計

Catalyst DSP プロビジョニング

シスコ パケット ファックスとモデムのサポート ガイドライン

Cisco IOS VoIP ルータ ゲートウェイ

Ciso IOS ファックスリレー

Cisco IOS モデム サポート

Cisco VG200

VG200 ファックス サポート

VG200 モデム サポート

Catalyst 6000 VoIP ゲートウェイ

Catalyst 6000 ファックスリレー(G.729A)

Catalyst 6000 ファックス パススルー(G.711)

Catalyst 6000 モデム パススルー(G.711)

今後の T.38 ファックスリレー サポート

E911 と 911 緊急事態サービス

現在の E9-1-1 サービス

サービス プロバイダの展望

IP テレフォニー 緊急事態コールのサポート

ゲートウェイ選択

発側番号

IP テレフォニー ネットワークのセキュリティーに関する考慮事項

インフラストラクチャ セキュリティの最善の実施策

物理的なセキュリティ

認証、許可およびアカウンティング

Cisco IOS デバイスの保護

CatOS デバイスの保護

Cisco IOS セキュリティ/ファイアウォール機能

専用アドレス スペースと NAT

CallManager サーバの保護

Microsoft Windows 2000 のタスク

Microsoft Internet Information Server (IIS) タスク

Microsoft SQL Server タスク

音声メールの統合

Cisco Unity を使用した音声メッセージ

SMDI 音声メールの統合

設定の概要

SMDI 音声メールのトラブルシューティング

サンプル VG200 の設定詳細

Catalyst 6000 24-Port FXS ゲートウェイ設定の詳細例

SMDI 音声メールと IP WAN 全体との統合

トポロジ

非同期トンネル伝送の設定

IP テレフォニー ネットワークへの移行

IP テレフォニー ネットワークの設計

この章の構成

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

概要

IP テレフォニー 設計の概要

キャンパス インフラストラクチャの設計

LAN/WAN QoS の設計

Cisco CallManagerクラスタの設計

ゲートウェイの選択

ダイヤル プランのアーキテクチャと設定

分散型コール処理を使用する複数サイト WAN の設計

中央集中型コール処理を使用する複数サイト WAN の設計

Catalyst DSP プロビジョニング

シスコ パケット ファックスとモデムのサポート ガイドライン

E911 と 911 緊急事態サービス

IP テレフォニー ネットワークのセキュリティーに関する考慮事項

音声メールの統合

IP テレフォニー ネットワークへの移行

概要

この章では、IP テレフォニー ネットワークの設計に関するガイダンスを示します。また、この章は PDIO 設計モデルを参考にして構成されています。 この章の内容は、次に示すサイトから閲覧できる別の文書、
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf の『Cisco IP Telephony Network Design Guide』から抜粋されていますが、このマニュアルでは、PDIO 設計の考えに基づいて情報を再構成しています。 このマニュアルは IP テレフォニー 設計を PDIO の観点から理解する際にご利用ください。

IP テレフォニー 設計の概要

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf を参照してください。

キャンパス インフラストラクチャの設計

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf 参照してください。

LAN/WAN QoS の設計

この項では、エンドツーエンドで実現する QoS(Quality of Service)の青写真を詳細に説明します。このエンドツーエンドの QoS は、IP テレフォニー を成功裏に配備する上で必須のコンポーネントです。 このマニュアルでは、シスコ製品で実現可能な QoS に対する設定の組み合わせをすべて検証しているわけではありません。 また、読者は、Cisco IOS、CatOS、シスコ製品および QoS 理論に関する基礎知識を習得していることを前提としています。 この項では、次の配備ソリューションについて説明します。

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

ブランチ オフィスの構築

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

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)テクノロジーを使用して、シリアライゼーション遅延を固定遅延値に設定できます。

 

表 4-1 パケット サイズとリンク速度

パケット サイズ

リンク速度

64 バイト

128 バイト

256 バイト

512 バイト

1024 バイト

1500 バイト

56 Kbps

9 msec

18 msec

36 msec

72 msec

144 msec

214 msec

64 Kbps

8 msec

16 msec

32 msec

64 msec

128 msec

187 msec

128 Kbps

4 msec

8 msec

16 msec

32 msec

64 msec

93 msec

256 Kbps

2 msec

4 msec

8 msec

16 msec

32 msec

46 msec

512 Kbps

1 msec

2 msec

4 msec

8 msec

16 msec

23 msec

768 Kbps

.640 msec

1.28 msec

2.56 msec

5.12 msec

10.24 msec

15 msec

ネットワークの輻輳は、ネットワーク内でポイントで随時発生する可能性があるため、バッファは瞬時に満杯になる可能性があります。 このバッファが満杯になると、同一のボイス ストリーム内にあるパケット間で遅延時間差が生じることがあります。 この遅延差をジッタといい、パケットの到着予測時間とパケットの実際の受信時間との差異を意味します。 会話内の音声パケット間で発生するこれらの遅延変動を補正するために、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 分類

 

 

表 4-2 分類

レイヤ 2 のクラス オブ サービス(Cos)
IP 順位
DSCP

CoS 0

ルーチン(IP Precedence 0)

0-7

CoS 1

優先順位(IP Precedence 1)

8-15

CoS 2

即時(IP Precedence 2)

16-23

CoS 3

フラッシュ(IP Precedence 3)

24-31

CoS 4

フラッシュ上書き(IP Precedence 4)

32-39

CoS 5

重要(IP Precedence 5)

40-47

CoS 6

インターネット(IP Precedence 6)

48-55

CoS 7

ネットワーク(IP Precedence 7)

56-63

キューイング

キューイングとは、ネットワークでの処理が適切に行われるように複数のキューの 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 の回線上で、ポートを次のように設定できます。

cat6k-access> (enable) set port inlinepower 5/1-48 auto -> Default (only avail for Powered Ethernet linecards)
cat6k-access> (enable) set port speed 5/1-48 auto
cat6k-access> (enable) set port host 5/1-48
 

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

interface FastEthernet0/1
power inline auto
speed auto
spanning-tree portfast
 

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 に作成します。

cat6k-access> (enable) set vlan 10 name 10.1.10.0_data
cat6k-access> (enable) set vlan 110 name 10.1.110.0_voice
cat6k-access> (enable) set vlan 10 5/1-48
cat6k-access> (enable) set port auxiliaryvlan 5/1-48 110
 
cat4k> (enable) set vlan 11 name 10.10.11.0_data
cat4k> (enable) set vlan 111 name 10.1.111.0_voice
cat4k> (enable) set vlan 11 2/1-48
cat4k> (enable) set port auxiliaryvlan 2/1-48,111
 

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

interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 12
switchport mode trunk
switchport voice vlan 112
spanning-tree portfast
vlan database
vlan 112

) トラブルシューティングを容易にするために、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 コマンドをこれらのスイッチに使用します。

cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted ->Default
 

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 設定値をトラストしないように設定するには、次のコマンドを使用します。

interface FastEthernet0/1
switchport priority extend cos 0
 

複数ケーブルによる 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 の例

 

cat6k-access> (enable) set port inlinepower 6/1-24 auto
cat6k-access> (enable) set port inlinepower 6/25-48 off
cat6k-access> (enable) set vlan 110 6/1-24
cat6k-access> (enable) set vlan 10 6/25-48
cat6k-access> (enable) set port auxialaryvlan 6/1-24 dot1p
cat6k-access> (enable) set port host 6/1-24
cat6k-access> (enable) set port qos 6/1-24 trust-ext untrusted
 

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

cat4k> (enable) set vlan 11 2/25-48
cat4k> (enable) set vlan 111 2/1-24
cat4k> (enable) set port host 2/1-48
cat4k> (enable) set port auxiliaryvlan 2/1-24 111
 

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

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

 

interface FastEthernet0/1
description IP Phone port
spanning-tree portfast
switchport mode access
switchport access vlan 112
interface FastEthernet0/2
description Data-only PC port
switchport mode access
switchport access vlan 12

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)を設定します。

cat6k-access> (enable) set qos enable
cat6k-access> (enable) set port qos 7/1-48 port-based
cat6k-access> (enable) set port qos 7/1-48 trust untrusted
cat6k-access> (enable) set qos acl ip ACL_SOFTPHONE dscp 46 udp any any range 16384 32767
cat6k-access> (enable) commit qos acl ACL_SOFTPHONE
cat6k-access> (enable) set qos acl map ACL_SOFTPHONE 7/1-48
 

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

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

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

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

IP アドレッシング

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

cat4k> (enable) set port inlinepower 2/1-48 auto
cat4k> (enable) set port inlinepower 2/25-48 off
cat4k> (enable) set vlan 111 2/1-48
cat4k> (enable) set port host 2/1-48
cat4k> (enable) set port auxiliaryvlan 2/1-24 111
 

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

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

Catalyst 3500/2900 XL

interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 112
switchport mode trunk
switchport voice vlan dot1p
spanning-tree portfast
 

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

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

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

ワイヤリング クローゼット スイッチで 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 トラフィックは、ここ当分の間、外部のネットワーク要素マーキングを必要とします。


cat6k-access> (enable) set qos enable
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range 2000 2002
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any
cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range 2000 2002
cat6k-access> (enable) set port qos 5/1-48 trust trust-cos
cat6k-access> (enable) set port qos 5/1-48 vlan-based
cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted
cat6k-access> (enable) set port qos 4/2 port-based
cat6k-access> (enable) commit qos acl all
cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2
 

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

スイッチ全体で 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)として分類します。

cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any eq 1720
cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTOL dscp 26 tcp any any range 11000 11999
cat6k-access> (enable) set port qos 4/2 port-based
cat6k-access> (enable) set port qos 4/3 port-based
cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/3
 

MGCP

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

cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 udp any any eq 2427
cat6k-access> (enable) set port qos 4/2 port-based
cat6k-access> (enable) set port qos 4/4 port-based
cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2
cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/4
 

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

cat6k-access> (enable) sh qos acl map run all
 
ACL name Type Vlans
-------------------------------- ---- ---------------------------------
ACL_IP-PHONES IP 110,111,112
ACL name Type Ports
-------------------------------- ---- ---------------------------------
ACL_IP-PHONES IP
 
ACL name Type Vlans
-------------------------------- ---- ---------------------------------
ACL_VOIP_CONTROL IP
ACL name Type Ports
-------------------------------- ---- ---------------------------------
ACL_VOIP_CONTROL IP 4/2,4/3,4/4

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 の全モジュール

 

表 4-3 ドロップしきい値のデフォルト値

バッファ キャパシティのパーセント
ドロップ CoS 値

50

0-1

60

2-3

80

4-5

100

6-7

1P1Q4T :

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

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

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

 

表 4-4 標準キューにおけるドロップしきい値のデフォルト値

キュー番号
バッファ キャパシティのパーセント
ドロップ CoS 値

1

50

0-1

1

60

2-3

1

80

4

1

100

6-7

2

100

5

転送インターフェイス

2Q2T :

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

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

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

 

表 4-5 ドロップしきい値のデフォルト値

キュー番号
バッファ キャパシティのパーセント
ドロップ CoS 値

1 - 低優先度 - キュー サイズ合計の 80%

40

0-1

100

2-3

2 - 高優先度 - キュー サイズ合計の 20%

40

4-5

100

6-7

1P2Q2T :

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

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

 

表 4-6 ドロップしきい値のデフォルト値

キュー番号
バッファ キャパシティのパーセント
ドロップ CoS 値

1 - 低優先度 - キュー サイズ合計の 80%

40

0-1

100

2-3

2 - 高優先度 - キュー サイズ合計の 20%

40

4-5

100

6-7

3 - 優先順位キュー・キューサイズ合計の 15%

100

5

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 をイネーブルにします。

cat6k-access> (enable) set qos enable
cat6k-access> (enable) set port qos 5/1-48 vlan-based
cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted
cat6k-access> (enable) set port qos 5/1-48 trust trust-cos
cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos any
cat6k-access> (enable) commit qos acl ACL_IP-PHONES
cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110
 

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

スイッチ全体で 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 番目のキューに配置されます。

cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3
 

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

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

show port qos <mod/port>
show qos info runtime <mod/port>
show mac <mod/port>
show qos statistics l3
show qos stat <mod/port>
 

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

cat6k-access> (enable) sh port qos 5/1
QoS is enabled for the switch
QoS policy source for the switch set to local.
 
Port Interface Type Interface Type Policy Source Policy Source
config runtime config runtime
----- -------------- -------------- ------------- -------------
5/1 vlan-based vlan-based COPS local
 
Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS
config runtime config runtime
----- ------------ ------------ ------------ ------------- ------- -------
5/1 2q2t 1q4t trust-cos trust-cos* 0 0
 
Port Ext-Trust Ext-Cos
----- --------- -------
5/1 untrusted 0
 
(*)Runtime trust type set to untrusted.
 
Config:
Port ACL name Type
----- -------------------------------- ----
No ACL is mapped to port 5/1.
ACL is mapped to VLAN
Runtime:
Port ACL name Type
----- -------------------------------- ----
No ACL is mapped to port 5/1.
 
 
cat6k-access>(enable) sh qos info run 5/1
Run time setting of QoS:
QoS is enabled
Policy Source of port 5/1: Local
Current 10/100 "1" linecards support 2q2t/1q4t only
Tx port type of port 5/1 : 2q2t
Rx port type of port 5/1 : 1q4t
Interface type: vlan-based
ACL is mapped to VLAN
ACL attached:
The qos trust type is set to trust-cos.
Warning: Runtime trust type set to untrusted.
Default CoS = 0
Queue and Threshold Mapping for 2q2t (tx):
Queue Threshold CoS
----- --------- ---------------
1 1 0 1
1 2 2
2 1 3 4 5
2 2 6 7
Queue and Threshold Mapping for 1q4t (rx):
Queue Threshold CoS
----- --------- ---------------
1 1 0 1
1 2 2
1 3 3 4 5
1 4 6 7
<snip...>
 
 
cat6k-access> (enable) sh mac 5/1
 
Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast
-------- -------------------- -------------------- --------------------
5/1 267223 37 4
 
Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast
-------- -------------------- -------------------- --------------------
5/1 28748894 5206 72
 
Port Rcv-Octet Xmit-Octet
-------- -------------------- --------------------
5/1 17178128 1840430081
 
"Out-Discards" are packets drooped due to congestion in the tx interface buffers
MAC Dely-Exced MTU-Exced In-Discard Out-Discard
-------- ---------- ---------- ---------- -----------
5/1 0 0 0 262140
 
 
cat6k-access> (enable) sh qos stat l3
VoIP Control packets that have been re-written with CoS=3/DSCP=26 (AF31)
Packets dropped due to policing: 0
IP packets with ToS changed: 1885
IP packets with CoS changed: 781
Non-IP packets with CoS changed: 0
 
 
cat6k-access> (enable) sh qos stat 5/1
All packets dropped are in the 1st drop threshold of queue #1
Tx port type of port 5/1 : 2q2t
Q # Threshold #:Packets dropped
--- -----------------------------------------------
1 1:393210 pkts, 2:0 pkts
2 1:0 pkts, 2:0 pkts
Rx port type of port 5/1 : 1q4t
Q # Threshold #:Packets dropped
--- -----------------------------------------------
1 1:0 pkts, 2:0 pkts, 3:0 pkts, 4:0 pkts
 

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

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

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

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

cat6k-access> (enable) set port qos 1/1 trust trust-dscp
 

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

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

cat6k-access> (enable) set qos map 1p2q2t tx 2 1 cos 3
cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3
 

ステップ 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 へのマッピングを次の例のように修正する必要があります。

cat6k-distrib> (enable) set qos cos-dscp-map 0 8 16 26 32 46 48 56
cat6k-distrib> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56
 

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

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

cat6k-distrib> (enable) sh qos map run cos-dscp-map
CoS - DSCP map:
CoS DSCP
--- ----
0 0
1 8
2 16
3 26 -> 26 = AF31
4 32
5 46 -> 46 = EF
6 48
7 56
 
 
cat6k-distrib> (enable) sh qos map run ipprec-dscp-map
IP-Precedence - DSCP map:
IP-Prec DSCP
------- ----
0 0
1 8
2 16
3 26 -> 26 = AF31
4 32
5 46 -> 46 = EF
6 48
7 56
 


 

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 マッピングを変更する必要があります。

 

表 4-7 デフォルトの 4000 キュー許可基準

キュー番号
キュー許可 CoS 値

1

0-7

2

ブロードキャスト、マルチキャストおよび不明トラフィック

このマニュアルに記載されている 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 値をペアで設定する必要があります。 次の例を参照してください。

cat4k> (enable) set qos enable
cat4k> (enable) set qos map 2q1t 1 1 cos 0-1
cat4k> (enable) set qos map 2q1t 2 1 cos 2-3
cat4k> (enable) set qos map 2q1t 2 1 cos 4-5
cat4k> (enable) set qos map 2q1t 2 1 cos 6-7
 

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

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

cat4k> (enable) show qos info runtime
Run time setting of QoS:
QoS is enabled
All ports have 2 transmit queues with 1 drop thresholds (2q1t).
Default CoS = 0
Queue and Threshold Mapping:
Queue Threshold CoS
----- --------- ---------------
1 1 0 1
2 1 2 3 4 5 6 7
 

ステップ 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 の番号付けの逆になります。


 

表 4-8 デフォルト 4000 レイヤ 3 1000Mbps アップリンク キューの許可基準

キュー番号
キュー許可 IP 順位値

1

6-7

2

4-5

3

2-3

4

0-1

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 の値に基づいて設定されますが、ユーザは設定できません。

 

表 4-9 Catalyst 3500 キュー許可基準

キュー番号
キュー許可 IP 順位値

1

0-3

2

4-7

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

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

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

 

表 4-10 Catalyst 3500 ギガビット イーサネットのキュー許可基準

キュー番号
キュー許可 IP 順位値

1

0-3

2

4-7

3-8

未使用

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をトラストするようにこのアクセス ポートを設定します。 次のコマンドを使用します。

interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 12
switchport mode trunk
switchport voice vlan 112
switchport priority extend cos 0
spanning-tree portfast
 

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

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

interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
 


 

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 番目のキューに入れられるようにする必要があります。 次のコマンドを使用します。

cat6k-distrib> (enable) set qos map 1p2q2t tx queue 2 1 cos 3
cat6k-distrib> (enable) set qos map 2q2t tx queue 2 1 cos 3
 

ステップ 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 値を上書きするからです。 分類がアクセス レイヤで実行されるまで、このコマンドを使用する必要はありません。

cat6k-distrib> (enable) set port qos 1/1 port-based
cat6k-distrib> (enable) set port qos 1/1 trust trust-dscp
 

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

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

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

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

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

cat6k-distrib> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56
 
cat6k-distrib> (enable) sh qos map run ipprec-dscp-map
IP-Precedence - DSCP map:
IP-Prec DSCP
------- ----
0 0
1 8
2 16
3 26 -> 26 = AF31
4 32
5 46 -> 46 = EF
6 48
7 56
 

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

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

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

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

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

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

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

cat6k-distrib> (enable) set port qos 1/2,3/2 trust trust-cos
 

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

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

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

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

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

cat6k-distrib> (enable) set qos cos-dscp-map 0 8 16 26 32 46 48 56
 
cat6k-distrib> (enable) sh qos map run cos-dscp-map
CoS - DSCP map:
CoS DSCP
--- ----
0 0
1 8
2 16
3 26 -> 26 = AF31
4 32
5 46 -> 46 = EF
6 48
 

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

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

cat6k-distrib> (enable) set port qos 1/2,3/2 vlan-based
cat6k-distrib> (enable) set qos acl map ACL_IP-PHONES 111
(Use the ACL_IP-PHONES access-list from
cat6k-distrib> (enable) sh qos acl map run ACL_IP-PHONES
ACL name Type Vlans
-------------------------------- ---- ---------------------------------
ACL_IP-PHONES IP 110,111,112
ACL name Type Ports
-------------------------------- ---- ---------------------------------
ACL_IP-PHONES IP
 
 
cat6k-distrib> (enable) sh qos acl info run ACL_IP-PHONES
 
set qos acl IP ACL_IP-PHONES
----------------------------------------------
1. dscp 26 tcp any any range 2000 2002
2. dscp 26 tcp any any eq 1720
3. dscp 26 tcp any any range 11000 11999
4. dscp 26 udp any any eq 2427
5. trust-cos any
 

ステップ 4 7200 WAN ルータへの接続を設定します。

cat6k-distrib> (enable) set port qos 9/1 port-based
cat6k-distrib> (enable) set port qos 9/1 trust trust-ipprec
Current 10/100 "1" linecards must still have trust-ipprec enabled even though the parser returns an error
 
cat6k-distrib> (enable) set qos acl ip ACL_TRUST-WAN trust-ipprec any
cat6k-distrib> (enable) commit qos acl ACL_TRUST-WAN
cat6k-distrib> (enable) set qos acl map ACL_TRUST-WAN 9/1
 
cat6k-distrib> (enable) sh port qos 9/1
QoS is enabled for the switch.
QoS policy source for the switch set to local.
 
Port Interface Type Interface Type Policy Source Policy Source
config runtime config runtime
----- -------------- -------------- ------------- -------------
9/1 port-based port-based COPS local
 
Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS
config runtime config runtime
--------------------------------------------------------------------
9/1 2q2t 1q4t trust-ipprec trust-ipprec 0 0
 
Port Ext-Trust Ext-Cos
----- --------- -------
9/1 untrusted 0
 
(*)Runtime trust type set to untrusted.
 
Config:
Port ACL name Type
----- -------------------------------- ----
9/1 ACL_TRUST-WAN IP
Runtime:
Port ACL name Type
----- -------------------------------- ----
9/1 ACL_TRUST-WAN IP
 


 

固有の 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 は、WAN を通過する音声のサポートに必要です。 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 技術を使用する

Cisco CallManagerクラスタの設計

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

ゲートウェイの選択

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

ダイヤル プランのアーキテクチャと設定

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

分散型コール処理を使用する複数サイト WAN の設計

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

中央集中型コール処理を使用する複数サイト WAN の設計

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

Catalyst DSP プロビジョニング

次のサイトを参照してください。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

シスコ パケット ファックスとモデムのサポート ガイドライン

この項では、IP テレフォニー のパケット テレフォニー ネットワークに使用される各種ファックスおよびモデムの転送ソリューションについて説明します。 新しいファックスリレーとモデムのパススルー設定および設計は、Cisco CallManager 3.0.1 と新しい Catalyst 6000 ゲートウェイ モジュールのリリースで使用可能となります。 ただし、Catalyst 6000 ゲートウェイで使用される新しいファックスリレー テクノロジーは、Cisco IOS ルータ ゲートウェイ製品の既存のファックリレーと互換性がありません。 この項では、一緒に動作してファックスとモデムのソリューションを提供できるゲートウェイ ファックスとモデムのテクノロジーについて説明します。

次の理由により、G.711 コーデックで設定されている VoIP パケット ネットワーク全体でファックスとモデムがサポートされていません。このことは重要なので留意してください。

パケット喪失 :初期トレーニング インターバル時のパケット損失は、再トレーニングを引き起こすことになります。 また、ある量のパケットがデータ転送時に失われると、ファックス 機は接続を解除します。 コールがドロップされる前にモデムが許容できるのは、最大数のリトレーンだけのため、このことは特に解決の難しい問題となる可能性があります。 データ転送時にパケットが失われると、モデムのリトレーンを引き起こすことになります。

可変遅延とジッタ :パケット ネットワークに固有の変動遅延のため、受信 VoIP ゲートウェイのジッタ バッファはオーバーランするか、あるいは満杯になる可能性があります。 このことが発生すると、ファックス情報を含むパケットがドロップする可能性があります。

クロック スリュー :クロック スリューとは、入力ゲートウェイと出力ゲートウェイでのクロック速度の差異のことです。 この差異が非常に大きい場合、ゲートウェイ内のジッタ バッファがオーバーランして、結果としてデータの損失およびファックス/モデムのリトレーンが生じる可能性があります。

音声トラフィックに PQ(優先順位キュー)を使用する単一スイッチの設定により、損失、遅延およびクロック同期の問題を最小限にすることができます。 ただし、ファックスリレー、ファックス パススルーおよびモデム パススルー設定を使用するほうがより適切です。 これら 3 つの項目についての詳細な説明は、次の項を参照してください。

Cisco IOS VoIP ルータ ゲートウェイ

Cisco IOS ルータ ゲートウェイは、IP ネットワークで使用するファックスにシスコ専用のファックスリレー ソリューションを提供します。 このアルゴリズムは、別の Cisco IOS ルータ ゲートウェイ エンドポイントでのみ作動します。 たとえば、ファックスリレーを使用してファックスを IP ネットワーク全体に送信する Cisco 1750 は、次のいずれかの VoIP エンドポイントと通信します。 そのエンドポイントとは、1750、3810v3、2600、3600、7200、5300 および H.323v2 を使用する Catalyst 4000 VoIP ゲートウェイ モジュールのいずれかです。

5300 だけが、現在、モデム オーバー IP ケイパビリティのすべてのタイプをサポートしています。 詳細は、 「Cisco IOS モデム サポート」 を参照してください。

Ciso IOS ファックスリレー

Cisco IOS VoIP ルータ ゲートウェイは、Cisco IOS バージョン 11.3 以降、ファックスリレーをパケット ネットワーク全体のファックスのソリューションとして提供します。 Cisco IOS のファックスリレー アルゴリズムは、アナログ ファックス伝送を取得し、それを復調して、その情報をデジタル方式でパケットにカプセル化します。 このパケットは、ファーエンドでアナログ伝送として再変調され、受信ファックス機に送信されます。 次の、ファックスリレーで設定された Cisco IOS VoIP ダイヤルピアのサンプル設定を参照してください。

dial-peer voice 6743 voip
destination-pattern +3036636347
prefix 6347
Fax-rate 9600
no vad
ip precedence 5
session target ipv4:172.247.70.134
 

Cisco IOS モデム サポート

Cisco 5300 は、VoIP ネットワーク全体でモデム伝送をサポートする唯一の Cisco IOS VoIP ゲートウェイです。 モデム パススルーは、パケット ネットワーク内でのパケット損失、遅延およびジッタの可能性に対処するために作成されていました。 5300 Cisco IOS バージョン 12.1(3)T) により、シスコは新しい方式のモデム パススルーを公開しました。

この新しいモデム パススルー コードは、ゲートウェイで次のように各種の切り替えを使用して正常にモデム伝送を処理します。

エコー キャンセルをオフにする

VAD をオフにする

高度パス フィルタを除去する

RTP ペイロードの冗長性を作成する

200ms の静的ジッタ バッファを作成する

ただし、アベイラビリティが高く、損失性の少ないインフラストラクチャを配置して、モデム パススルーが動作するようにする必要があります。 G.711 コーデックも使用する必要があります。

図 4-31 Ciso IOS ゲートウェイ ファックスリレー

 

Cisco VG200

Cisco VG200 は、Cisco CallManager の通信に対して MGCP あるいは H.323v2 のいずれもサポートする IP テレフォニー ゲートウェイです。

VG200 ファックス サポート

次の 2 つのモードがあります。

MGCP モード

VG200 は、MGCP モードで設定されると、どのファックスリレー機能も提供しません。

この設計はサポートされていない設定ですが、次の設計条件に適合しています。

2 つの VG200 を同じ Catalyst 6000 あるいは 3500 イーサネット スイッチに接続する。 PQ を使用するすべての音声セッションでこのスイッチを設定する必要があります。

VAD をファックス ダイヤルピアで無効にする。

受信ファックス ポートでジッタ バッファを最高値に設定する。

エコー キャンセルを受信ファックス ポートでオフにする。

H.323v2 モード

FXS インターフェイスは VG200 でまだテストされていないため、Cisco IOS ファックスリレー オプションはサポートされていません。

FXS インターフェイスと Cisco IOS ファックスリレー コードを H.323v2 を実行する VG200 でテストすると、VG200 はすべての Cisco IOS VoIP ルータ ゲートウェイで動作できるようになります。

VG200 モデム サポート

VoIP ネットワークを通過するモデムは、VG200 ゲートウェイの使用がサポートされていません。

Catalyst 6000 VoIP ゲートウェイ

Cisco CallManager 3.0(1) のリリースを使用して、2 つの新しい VoIP テレフォニーのゲートウェイ モジュールを Catalyst 6000 で使用できます。これらの 2 つのモジュール、24 ポート アナログ FXS ゲートウェイおよび 8 ポート T1/E1 ゲートウェイは、IP テレフォニー VoIP ネットワーク全体でファックスとモデムの伝送をサポートします。 ファックスとモデムの伝送に Catalyst 6000 VoIP ゲートウェイを使用するサンプル ネットワークの設計については、 を参照してください。

Catalyst 6000 ファックスリレー(G.729A)

G.729A 音声圧縮を使用する場合、前述の 2 つのゲートウェイは、専用のファックスリレー アルゴリズムを使用して IP 全体でファックスをサポートします。 このファックスリレー アルゴリズムは、現在、Cisco IOS ゲートウェイのファックスリレー コードでは動作しません。 ただし、この問題は、早急に修正されることになります。 Catalyst 6000 ゲートウェイ モジュール間のファックスリレーはサポートされています。

Catalyst 6000 ファックス パススルー(G.711)

VoIP セッションに G.711 コーデックを使用する場合、Catalyst 6000 ゲートウェイは、ファックス伝送にファックス パススルーを使用します。 ファック パススルーの機能は、モデム パススルー( Catalyst 6000 モデム パススルー(G.711) を参照)と Cisco IOS バージョン 12.1(3)T で使用される 5300 モデム パススルー アルゴリズムに似ています。

ファックス パススルーを動作させるには、アベイラビリティが高く、損失性の少ないインフラストラクチャを配置する必要があります。 G.711 も設定する必要があります。

Catalyst 6000 モデム パススルー(G.711)

Catalyst 6000 VoIP ゲートウェイで利用できる新しいモデム パススルーのコードは、Cisco IOS バージョン 12.1(3)T に導入された 5300 のモデム パススルー テクノロジーに似ています。この新しいコードは、ゲートウェイ コードで各種の切り替えを使用して、モデム伝送を正常に処理します。 モデム伝送を受信する着信ポート上で実行される切り替えを動的に設定することにより、次のように動作させます。

エコー キャンセルをオフにする

VAD (Voice Activity Detection) をオフにする

高度パス フィルタを除去する

RTP ペイロードの冗長性(RFC 2198)を作成する

200ms の静的ジッタ バッファを作成する

ただし、モデム パススルーを動作させるための、アベイラビリティが高い、損失性の少ないインフラストラクチャを配置する必要があります。 また、サポートされているコーデックは G.711 だけです。

図 4-32 Catalst 6000 ファックスとモデム

 

今後の T.38 ファックスリレー サポート

すべての Cisco VoIP は、IP ネットワークで使用するファックスリレーの T.38 標準を準拠する方向で実装されています。 Cisco 3810、2600 および 5300 製品は、Cisco IOS バージョン 12.1.(3)T で T.38 ケーパビリティを使用できるようになります。T.38 ケーパビリティは、1750、7200、7500、Catalyst 6000 および VG200 ゲートウェイで使用される将来の機能です。

E911 と 911 緊急事態サービス

シスコ テレフォニー システムの設計者は、この項の内容を十分に理解し、ライフラインの問題に関する IP テレフォニー ソリューションを適切に配備する必要があります。

大まかに言えば、システム設計者は、システムが緊急事態のコールを処理する方法を明確に計画する必要があります。 ユーザが緊急事態番号(たとえば、北アメリカでは 9-1-1)をダイヤルしたとき、どのタイプのコール処理が適用されるかを理解します。

Enterprise Telephony System は、一般的に、次のように機能します。

コールを適切なポイント(オンネットあるいはオフネット)にルーティングします。

適切な場合、発信者 ID 、一般的には発信者の電話番号(内線番号あるいは PSTN 番号)を送信します。

緊急事態コールに適切なアカウンティングを含めるということは、IP テレフォニー のテレフォニー ソリューションに固有の設定範囲を越えた問題にまで発展します。 多くの場合、LEC システムに対するインターフェイスの必須タイプと必須数量はもとより、実際の機器タイプとカウントにも影響を及ぼします。 また、このマニュアルで提供できるのは、技術的なガイドラインのみです。 緊急事態コールの実装がまったく同じというサービス領域が 2 つ存在することはありません。緊急事態コールの設計を決める多くの要因はテクノロジーではなく政策の問題です。 これら政策上の要因は、このマニュアルでは扱っていません。

現在の E9-1-1 サービス

この項は、9-1-1 コールをサポートする既存の北アメリカ テレフォニー インフラストラクチャのクイック リファレンスとして使用してください。 この項では、北アメリカの E9-1-1 ネットワークの一般的なトポロジについて説明します。このトポロジは、企業テレフォニーが 9-1-1 コールを処理する方法を適切に計画するのに必要です。

北アメリカ以外の領域では、緊急事態コールの処理は、一般的に、非緊急事態コールの処理とほぼ同じです。 多くの場合、同じスイッチングおよびルーティング機器を両方のコール タイプに使用し、緊急事態コールの特別な処理は、公衆がダイヤルするために予約されている専用番号(北アメリカの 9-1-1 に相当)を割り当てて制限しています。 発信者の電話番号は、応答ポイントに送信されますが、通常、発信者のロケーションは送信されません。 当該関係機関に問い合わせて、緊急事態コールを LEC に渡す上での管理規則と最良の実践方法を確立する必要があります。

サービス プロバイダの展望

北アメリカでは、E9-1-1 は電話サービスの不可欠な部分です。 すべての LEC テレフォニー サービス プロバイダは、連邦、州、郡あるいは地域の法律により要求されたとおりに、機能を提供する必要があります。 これを行うには、北アメリカのほぼ大部分のテレフォニー サービス プロバイダは、オーバーレイ ネットワークを信頼し、スイッチド ダイヤル トーン ネットワーク外の音声とデータ トラフィックを処理します。


) 1999 年 12 月現在、2 つの主要な RBOC のみが、9-1-1 コールのルーティング部分に SS7 を使用する E9-1-1 をロール アウトしました。


このネットワークは、9-1-1 トラフィックの処理専用(コールの集約とルーティング用)のアナログ MF 信号方式トランクおよび、コールを PSAP (Public Safety Answering Point) に送信するアナログ MF 信号方式トランク、または ISDN 回線(PRI あるいは BRI)のいずれかで構成されています。

9-1-1 コールの処理が PSTN の機能だという間違った考えがあります。 ほとんどの場合、9-1-1 コールの処理に使用される PSTN の部分だけが、ローカル カスタマーをサービスする CLASS 5 スイッチの回線側です。 テレフォニー サービス プロバイダの E9-1-1 に対する責務は次のとおりです。

9-1-1 コールを適切な PSAP に自動的にルーティングする。

発信者電話番号を適切な PSAP に転送する。

自動ロケーション ID(ALI)の検索に使用するアドレス データベース リンクを PSAP に提供する(テレフォニー サービス プロバイダが ALI を提供することはありません)。

PSTN と異なり、9-1-1 コールは、送信先番号ではなく、発信元番号でルーティングされます。図 4-33は、E9-1-1 設計者に適切な 9-1-1 コールのフロー全体を表示しています。


) この情報は、単に例をサポートしているだけであり、San Francisco ベイエリアでの実際の E9-1-1 トポロジを表してるわけではありません。


次の図は、CLASS 5 スイッチに直接接続している電話回線から PSTN のサブスクライバが 9-1-1 をダイヤルしたことに対応した音声と情報のフローを表しています。 また、次に説明する例は、9-1-1 コールを作成する Enterprise Telephony のサブスクライバの仕様を強調するものでもありません。

図の上部は、信号方式と PSTN のトラフィックに使用する 2 つの CLASS 5 スイッチ間のベアラ接続を示しています。 シスコは、PSTN SS7 ファブリックと対応するスイッチド ベアラ トラフィックのトランクが、9-1-1 のルーティングに関連していないという事実を裏付けるために、細部をここに掲載しました。

図 4-33 一般的な E9-1-1 ネットワーク トポロジ

 

例 1 :

この例では、Santa Clara のサブスクライバが 9-1-1 をダイヤルします。そのコールがコールの受け手に接続されるまでをたどります。

前提:

回線番号を 408.222.1235 とします。

コールに使用されるスイッチの物理的な位置は San Jose で、このスイッチは Santa Clara のカスタマーのコールにも使用されます。

Silicon Valley エリアの E9-1-1 タンデム スイッチがサービスを提供する地理的なエリアの電話番号ごとに、データベースは、発信者の ANI、緊急事態サービス番号(ESN)、および ALI 間のアソシエーションを提供します。 このアソシエーションは、LEC(Local Exchange Carrier; 該当する電話回線が設置されている場所を示すサービス レコードを使用)と行政機関(Master Street Address Guide (MSAG))との間のコラボレーションを介して作成します。 つまり、電話番号に基づいて、タンデムはコールを受信する PSAP を学習します。 このケースでは、Santa Clara の PSAP に対応した ESN は 1 となっています。

プロセス:

1. Santa Clara のサブスクライバは、受話器を外し、San Jose CLASS 5 スイッチからのダイヤル トーンを取得します。

2. サブスクライバは 9-1-1 をダイヤルします。

3. San Jose のスイッチは、E9-1-1 タンデム Silicon Valley エリアに接続する発信トランクへのコールをルーティングします。 PSTN コール パスは取得されないことに留意してください。

4. San Jose のスイッチは、MF 信号方式を介して、ANI(408.222.1235)を CAMA (Centralized Automatic Message Accounting) トランクで送信します。

5. タンデムは、ANI に対応する ESN の選択ルーティング(SR)データベースに問い合わを行います。

6. タンデムは、ESN=1 を受信します。この値がコールのルーティングを Santa Clara の PSAP に促します。

7. タンデムは、ANI 情報を Santa Clara の ANI/ALI コントローラに送信します。

8. この時点で、音声パスは両方向でカットスルーとなります。 ANI/ALI コントローラは、呼び出し信号経過トーンを提供します。

9. ANI/ALI コントローラは、ANI に対応する ALI のデータベースに問い合わせを行います。

10. Santa Clara のコールの受け手がコールに応答すると、発信者の音声、ANI および ALI が提示されます。

例 2 :

この例では、San Jose のサブスクライバが 9-1-1 コールを発信します。

前提:

回線番号を 408.222.1234 とします。

コールに使用されるスイッチの物理的な場所は、例 1 と同じであるとします。

San Jose の PSAP に対応する ESN は、ESN 2 とします。

プロセス:

1. San Jose のサブスクライバは、受話器を外し、San Jose の CLASS 5 スイッチからのダイヤル トーンを取得します。

2. サブスクライバは 9-1-1 をダイヤルします。

3. San Jose のスイッチは、E9-1-1 タンデム シリコンバレー エリアに接続する発信トランクへのコールをルーティングします。 PSTN コール パスは取得されないことに留意してください。

4. San Jose のスイッチは、MF 信号方式を介して、ANI(408.222.1234)を CAMA トランクで送信します。

5. タンデムは、ANI に対応する ESN の選択ルーティング(SR)データベースに問い合わを行います。

6. タンデムは、ESN=2 を受信します。この値がコールのルーティングを San Jose の PSAP に促します。

7. タンデムは、ANI 情報を San Jose の ANI/ALI コントローラに送信します。

8. この時点で、音声パスは両方向でカットスルーとなります。 ANI/ALI コントローラは、呼び出し信号経過トーンを提供します。

9. ANI/ALI コントローラは、ANI に対応する ALI のデータベースに問い合わせを行います。

10. San Jose のコールの受け手がコールに応答すると、発信者の音声、ANI および ALI が提示されます。

例 1 と 2 の発信者は、サービスを提供するスイッチから E9-1-1 タンデム スイッチまで同じトランクを使用する同じスイッチでサービスが提供されてはいますが、このコールのルーティングが例 1 と異なることを確認できます。


) E9-1-1 タンデム トランクは、9-1-1 コールの処理専用です。 これらのトランクで送信されるスイッチド トラフィックはありません。


San Francisco のカスタマーは、カバーされるというより、異なる E9-1-1 タンデム、異なるデータベース(ただし、同じデータベースとなる可能性はある)によりサービスを受けているため、San Jose あるいは Santa Clara の PSAP にルーティングされないことに留意する必要があります。 この点が重要です。 つまり、E9-1-1 タンデムは、通常、相互接続されて いません 。 実際的な観点からすると、このことは、9-1-1 コールが誤った PSAP に送信された場合、そのコールが別の E9-1-1 タンデムでサービスを受けると、適切な PSAP に転送される可能性がないことを意味します。 このことは、VoIP ソリューションを WAN に配備する場合、LEC へのゲートウェイがそれぞれの E9-1-1 タンデムへアクセスできるかの評価が必要になることを意味します。

IP テレフォニー 緊急事態コールのサポート

IP テレフォニー は、2 つの基本アプローチにより緊急事態コールを処理します。

緊急事態コールの自動オンネット ルーティングを適切なアテンダント ステーションに提供する。 このことは、通常、発信者側の内線番号に伴って発生します。 典型的なケースとして、緊急事態コールがキャンパス セキュリティにルーティングされるキャンパス環境があります。キャンパス セキュリティは、必要であれば公共安全の関係者との電話会議ができます。 これにより、キャンパス セキュリティが発信者のロケーションの詳細を使用して公共安全担当者を支援できます。

緊急事態コールの自動オフネットルーティングを LEC の POP (Point Of Presence) に提供する POP は、通常、IP テレフォニー が適切な緊急事態コール番号(たとえば、北アメリカの大部分の場所では、9-1-1)をダイヤルする PSTN に接続している発信トランクのグループです。 北アメリカでは、LEC は、コールの発番号(CPN)を使用してコールを PSAP にルーティングします。 CPN が 9-1-1 コールの一部として使用されると、CPN は、自動番号 ID あるいは ANI として参照されます。 PSAP は、ANI を使用して、コールの自動ロケーション ID(ALI)を取得します。


注意 場合によっては、LEC に提供される CPN が発信者の DID 番号でない可能性があります。 また、PSALI(Public Safety Automatic Location Identification)データベースの対応エントリが、発信者のロケーションを適切に提示しない可能性があります。

緊急事態コールのオンネット処理あるいはオフネット処理の選択は、ポリシーに基づきます。

緊急事態コールをオンネットのロケーションにルーティングするには、システム設計者は、次のような IP テレフォニー 機能を使用できます。

ディジット変換テーブル

この場合、緊急事態番号(たとえば、9-1-1)が CallManager 変換テーブルのエントリと照合され、対応するオンネット DN がコールの送信先として使用されます(たとえば、ユーザがダイヤルする 911 が内線 5911 に送信される可能性があります)。

オンネット ルート パターン

このパターンは、オンネットのロケーションで緊急事態のコールに応答するときに使用される可能性があります。このロケーションでは、WAN を介して到達可能なリモート コール マネージャーがサービスを提供します。 この場合、リモート CallManager に提示されるディジットの数は、リモート サイトが内部コールに使用するダイヤルディジットの長さと一致する必要があります。 オンネット ルート パターンを使用して、リモート CallManager への提示に必要なダイヤル番号の前にディジットを付ける(たとえば、55 を 911 の前に付け、事実上は 9-1-1 コールを内線 55911 に送信する)ことができます。 このアプローチは、WAN リソースを使用できない非常事態のケースに使用できます。つまり、WAN ルートが使用できない場合、基本的なルート リストで PSTN の使用を 2 つめの選択肢として考慮することが可能です。

コールが PSTN を介して送信されていると、発信者の番号を着信者側に使用でないことに注意してください。

緊急事態コールのオフネット ルーティングの場合、次の IP テレフォニー ツールを使用することができます。

ダイヤル プラン グループ

ダイヤル プラン グループを使用して、IP テレフォニー は緊急事態コールを LEC に渡すために使用するゲートウェイを選択できる柔軟性を提供します。選択は、特定のコール検索スペースの発信電話のメンバーシップに基づきます。 コール検索スペースには、PSTN ゲートウェイが到達可能であるかの特性を定義するパーティションが含まれます。 このアプローチは、発信者のロケーションに応じて緊急事態コールのオフネット送信先が異なる、WAN IP テレフォニー 配備で役立つことを照明しています。

次の図は、緊急事態コールの利用に 2 つのゲートウェイを必要とする WAN 設定を示しています。


) 記載した例は、北アメリカ E9-1-1 ネットワーク モデルに基づいていますが、ここで説明したゲートウェイ選択メカニズムは、国際市場でも適用することができます。


San Francisco のユーザは、Oakland のユーザと異なる LEC ゲートウェイを使用する必要があることに留意してください。

図 4-34 WAN 緊急事態コール設定

 

ここでの目的は、コールを次のように動作させることです。

すべてのユーザがすべてのユーザに到達できるようにする

すべてのユーザは、優先 PSTN アクセスを使用するゲートウェイ A を使用する

すべてのユーザは、ゲートウェイ A を使用できない場合、代替 PSTN アクセスを使用するゲートウェイ B を使用する

San Francisco の ユーザは、9-1-1 アクセスに使用するゲートウェイ A を使用する

Oakland の ユーザは、9-1-1 アクセスに使用するゲートウェイ B を使用する

ゲートウェイ選択

次の解説は、CallManager 3.0 ルーティングの動作に熟知していることを前提としています。 ルート パターン、ルート リスト、ルート グループ、パーティションおよびコール検索スペースに関する詳細は、『Dial Plan 』文書を参照してください。 この文書は、次のサイトで参照できます。
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf

次の例は、緊急事態コールの適切なルーティングを計画する上で、IP テレフォニー のシステム設計に使用できる各種設定要素を強調しています。

ルート グループ:

PRI ゲートウェイ A を含む SanFransicoGW

PRI ゲートウェイ B を含む OaklandGW

ルート リスト:

ルート グループ SanFranciscoGW と OaklandGW を含む NonEmergencyCalls

ルート グループ SanFranciscoGW を含む SanFranciscoEmergency

ルート グループ OaklandGW を含む OaklandEmergency

ルート フィルタ:

911calls: SERVICE=911.

ルート パターン:

ルート パーティション: NonEmergencyCalls.

ルート パターン: 9.@.

ルート リスト: NonEmergencyCalls.

DiscardDigits : PreDot.

ルート パーティション: SanFranciscoEmergency.

ルート パターン: 9.@.

ルート フィルタ: 911calls:

ルート リスト: SanFranciscoEmergency.

DiscardDigits : PreDot.

ルート パーティション: OaklandEmergency.

ルート パターン: 9.@.

ルート フィルタ: 911calls:

ルート リスト: OaklandEmergency.

DiscardDigits : PreDot.

パーティション:

BayUsers.

SanFranciscoEmergency.

OaklandEmergency.

NonEmergencyCalls.

コール検索スペース:

BayUsers、SanFranciscoEmergency、および NonEmergencyCalls を含む UsersSanFrancisco

BayUsers、OaklandEmergency、および NonEmergencyCalls を含む UsersOakland

ユーザが 9,911 をダイヤルすると想定しました。911 のダイヤルインのサポートを追加するには、San Francisco と Oakland に必要な特別なルート パターンを作成する必要があります。

ルート パーティション : SanFranciscoEmergencyno9.

ルート パターン: @.

ルート フィルタ: 911calls:

ルート リスト: SanFranciscoEmergency.

および

ルート パーティション: OaklandEmergencyno9.

ルート パターン: @.

ルート フィルタ: 911calls:

ルート リスト: OaklandEmergency.

そして、これらを適切なコール検索スペースに追加します。

発側番号

コールがゲートウェイを介してオフネットにルーティングされると、CLASS 5 へ渡された CPN は、ANI と ALI を PSAP へ送信する自動プロセスをトリガーします。


) LEC CLASS 5 スイッチは、E9-1-1 タンデムに提示された ANI として CPN を使用できないことがあります。 場合によっては、ESN と ALI の取得を達成する番号として、トランク グループのディレクトリ番号リスト(LDN)を使用することができます。


DID 電話(E.164 アドレスに完全に適した電話)の場合、DID 番号は、通常、9-1-1 コールの LEC に送信される CPN として使用されます。 これにより、適正な関係機関が直接後から電話して、固有の ALI レコードを DID ごとに指定できます。 大まかに言えば、DID 番号のバンクは、LEC のトランク グループのディレクトリ番号リスト(LDN)と同等の ALI レコードに対応します。 それぞれ個別の DID 番号に対応するそれぞれの ALI データベース エントリをカスタマイズするプロセスは、手作業で、通常、LEC および/あるいはローカルの公共安全機関が開始する必要があります。

非 DID 電話では、次の 2 つのアプローチを使用してコールの送信に基づき LEC ゲートウェイに提示される CPN を制御できます。

外部電話番号マスクを各回線に適切に設定して、911 ルート パターンに必要な変換で
Use External Phone Number Mask をチェックします。

パーティションに対応する 発側変換マスク を使用します。 これにより、同じ適切な E.164 番号を電話のグループ(たとえば、1 階のすべての電話)に使用できます。


) シスコは、当該電話(あるいは電話のグループ)に対して許容できる対応 ESN と ALI エントリを含む完全に適合した E.164 電話番号を適宜、そして適切に使用します。 このことは、対応 ESN エントリがコールを正しい PSAP にルーティングし、そして、対応 ALI エントリが電話のロケーションを所定の許容差(たとえば、7000 ft2)内で記述します。


一部の州では、次の内容に関する要件を提起する法律が制定されています。

企業テレフォニーのシステムから着信する 9-1-1 コールに対する ALI レコードの精度

コール バック番号のアベイラビリティ

これらの要件は、 イリノイ、ミシシッピー、テネシー、テキサス、バーモント、ワシントンおよびケンタッキーの 7 州で定められています。 緊急事態コールの適正処理を考慮した企業テレフォニー システムの附加機器を提供する、サードパーティのベンダーがあります。


警告 IP テレフォニー は、特定の州の法的要件を満たすために、サードパーティ製の機器を必要とする可能性があります。 ローカル特有の要件を確認する必要があります。


緊急事態コールの適切処理に適応した IP テレフォニー 設定は、ユーザの動的移動はサポートしません。 各電話のロケーション変更を使用して、該当する電話の CallManager の設定(コール検索スペース、ゲートウェイ選択および CPN 操作)を正確に修正する必要があります。

TDD サポート:

TDD(聴覚障害者用のテレコミュニケーション デバイス)デバイスを使用することにより、言語障害/聴覚障害のある方のテレフォニー通信が可能となります。 TDD デバイスは、キーボード駆動のモデムで、テキスト情報を標準電話回線に変換できます。

大部分の TDD は ボード コードを使用します。 ただし、一部の新しい TDD マシンでは、ユーザは ボード コードあるいは ASCII 変調を選択できます。

現時点で、IP テレフォニー は TDD 通信デバイスをサポートしていません。 カスタマーが TDD コールのライフライン サポートを必要とする場合、別の電話会社の POTS 回線を使用する必要があります。

IP テレフォニー ネットワークのセキュリティーに関する考慮事項

音声セキュリティは、データ セキュリティよりはるかに注意を要する問題です。 ユーザは、多くの場合、すべての音声通信が機密であることを期待していますが、同じ情報を含む電子メールに対しては同じ期待を抱いていません。

多くのセキュリティ チームは、企業のファイアウォールあるいはインターネット上のバスチョン(要塞)サーバへの外部からの不正侵入を防ぐことに多くの時間を費やしています。 しかしながら、一部の情報によると、すべての企業ハッキング行為のおよそ 80 パーセントは内部の人間によるのもであることを示しています。 多くの企業は、内部ネットワーク インフラストラクチャあるいはサーバを内部のハッキング行為から防ぐ努力をほとんど、あるいはまったく行っていません。 音声コミュニケーションの観点からいうと、別の従業員個人の、あるいは会社の機密電話のコールを傍受することがハッキング行為に該当します。

合理的なセキュリティー手段をネットワーク インフラストラクチャ コンポーネントとサーバに実装することにより、IP テレフォニー ネットワークのセキュリティに対して危害を加える試みのほとんどを防ぐことができます。 今後の製品の機能改良で、これらの手段では保護できない複雑なハッキング シナリオに取り組みます。ただし、これらの機能拡張については、このマニュアルで説明しません。

この項では、次の問題について説明します。

インフラストラクチャ セキュリティの最善の実施策 :IP テレフォニー ソリューションに固有ではない、一般的なネットワーク インフラストラクチャのセキュリティについて説明します。 多くのネットワーク管理者には、これらのセキュリティ ガイドラインの一部が参考になります。 ただし、セキュリティに関する経験が豊富な管理者は、これらのガイドライン省略して次の項に直接進むことができます。

CallManager サーバの保護 :IP テレフォニー 特有のネットワーク セキュリティ問題

インフラストラクチャ セキュリティの最善の実施策

次の項では、ネットワークのセキュリティ保護に関する一般的なガイドラインを説明します。

物理的なセキュリティ

認証、許可およびアカウンティング

Cisco IOS デバイスの保護

CatOS デバイスの保護

Cisco IOS セキュリティ/ファイアウォール機能

専用アドレス スペースと NAT

物理的なセキュリティ

大部分のコンピューティング デバイスと同じように、シスコのルータ、スイッチ、サーバおよびその他のインフラストラクチャ コンポーネントは、不正侵入者の物理的な直接アクセスによる侵入あるいは破壊から保護されるようには設計されていません。 適切なステップを実行して権限のない人員による物理的なアクセスを防ぐ必要があります。

一般的な予防措置として、ワイヤリング クローゼットおよびデータ センターへのアクセスは「信頼されている」と見なされているスタッフに限定することがあります。ただし、一般的には、このようなスタッフは、保護されているデバイスに直接的あるいは間接的を問わず、既に論理的にアクセスしているため、物理的アクセスからはなんの利益を得ることはありません。 「信頼されている」スタッフ以外のスタッフが入室できるデータ センターでは、各品目に対して別個に施錠できるキャビネット、あるいはより厳格なセキュリティ要件を満たすラックを使用します。

ドアに鍵あるいは電子ロックを使用するときは、すべての施設関係のスタッフ、セキュリティ スタッフおよび管理スタッフに対しては施錠を迂回する能力あるいは許可を保有できるように考慮する必要があります。

認証、許可およびアカウンティング

RADIUS と TACACS+

ユーザ別 AAA 機能を実行する RADIUS あるいは TACACS+ のいずれかを使用することは、インフラストラクチャ デバイスのセキュリティおよびアカウンティングに不可欠です。 これらの機能は、アカウントとパスワード情報の集中管理を可能にし、信頼したユーザが追加あるいは削除されたときの、デバイスごとのメンテナンスにかかる労力(とエラー)を排除できます。 CiscoSecure ACS を確保して、「強力な」パスワード、パスワードのエージングおよび侵入者に対するロックアウトを要求することもできます。

アクセスとイネーブルなパスワード

RADIUS あるいは TACACS+ を AAA に使用するとき、各ユーザはそれぞれ独自のパスワードを使用してネットワーク デバイスにアクセスします。 デバイスへのアクセスを取得した後、設定変更あるいは微妙な設定情報のビューを可能にするコマンドをイネーブルにするのに別のパスワード(あるいは、ユーザ別あるいはネットワーク全体)が必要です。 セキュリティ レベルの数字が下がるため、ユーザがデフォルトをレベル 15(使用可能)に設定することを推奨しません。

確実なパスワードの選択

理想的には、SoftToken、SecureID あるいは DEG Gold Cards のようなワンタイム パスワードシステムを使用して、信頼しているユーザのパスワードの再使用による不正侵入を防ぐようにする必要があります。 ただし、多くの組織はこれらのツールが面倒あるいは非常に高価であると考えています。 普通のパスワードを使用する場合、1 つ以上の辞書の単語を順番に試行する、あるいは他人がそのユーザのタイプを観察して、そのユーザのパスワードを推測できないようなパスワードを選択する必要があります。 最高のセキュリティを確保するために、大文字小文字に加え、数字あるいは句読記号を含める必要があります。

Cisco IOS デバイスの保護

仮想コンソールのアクセス制限

仮想コンソール アクセスをオペレーション スタッフおよびネットワーク管理ホストの IP アドレス範囲に制限することは、パスワードが発見されても、権限のないユーザがネットワーク デバイスへアクセスできないようにする有益な方式です。

次の例では、ネットワーク 192.89.55.0 のホストだけに仮想コンソールへの接続を許可するアクセス リストを定義します。

access-list 12 permit 192.89.55.0 0.0.0.255
line vty 0 4
access-class 12 in
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_r/1rprt2/1rip.htm

SNMP アクセスの制限

仮想コンソールを介してビューできる、あるいは設定できるほぼすべての情報は、SNMP を介してもアクセスできます。 SNMP コミュニティは、基本的にユーザ名が不要なパスワードであるため、この方式のアクセスはできる限り制限することが不可欠です。 SNMP 書き込みの実行が必要と確認されたコミュニティのホストだけへ、フル アクセスできるようにする必要があります。

次の例では、ネットワーク 192.89.55.0 のホストだけがコミュニティ foobar を使用して SNMP 読み込みの実行を許可し、そして、192.89.55.132 のホストだけがコミュニティ foobaz を使用して SNMP 書き込みの実行を許可するアクセス リストを定義します。

access-list 12 permit 192.89.55.0 0.0.0.255
snmp-server community foobar RO 12
access-list 13 permit host 192.89.55.132
snmp-server community foobaz RW 13
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt3/frmonitr.htm#xtocid1998360

セッション タイムアウトを有効にする

オペレーション スタッフは、ネットワーク デバイスにログインしている間に、そのシステムへの注意が散漫になる、あるいは人に呼ばれて離席することがあります。 アイドル状態になったユーザの接続を自動的に解除することは、権限のないユーザによる偶発的なアクセスを防ぐことに役立ちます。

次の例では、5 分間の非アクティビティ後、ユーザの接続を自動的に解除するように実コンソールと仮想コンソールを設定します。

line con 0
session-timeout 5
line vty 0 4
session-timeout 5
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/dial_r/drprt1/drtermop.htm#4907

暗号で設定されたパスワード

ダイヤルアップ リンクあるいはローカル ユーザのパスワードのような、一部のパスワードはデバイスの設定ファイルに格納する必要があります。 設定ファイルに格納するパスワードを暗号化することにより、意図しない人が設定ファイルを入手した場合でも、そのパスワードを判別する、あるいは記憶することが困難になります。

次の例では、設定ファイルで静的パスワードの暗号化をイネーブルにします。

service password-encryption
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_r/srprt5/srpass.htm#4899

マイナー ホスト サービスを無効にする

デフォルトでは、不正侵入者が容易にデバイスのリソースを消費できる、ほかのホストに間接的に侵入できる、あるいは、現在ネットワーク デバイスにアクセスしているオペレーション スタッフに関する情報を入手できる、このいずれもが可能となるサービスが複数あります。 これらのサービスを無効にすることにより、これらサービスの悪用の防止、あるいは、これらサービスが提供できる情報を保護することができます。

次の例は、これらのサービスを無効にします。

no service tcp-small-servers
no service udp-small-servers
no service finger
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt3/frgenral.htm

HTTP サーバの無効あるいは制限

Web 設定は、多くのプラットフォームでディセーブルとなっています。しかし、ネットワーク管理の初心者は、多くの場合、それを有効にしてしまいます。 HTTP 設定が必要でない場合、それを完全に無効にする必要があります。 サービスの無効化が実行できない場合、HTTPアクセスを管理アドレスに制限します。

次の例では、ネットワーク 192.89.55.0 のホストだけに HTTP サーバへの接続を許可するアクセス リストを定義します。

access-list 12 permit 192.89.55.0 0.0.0.255
ip http access-class 12
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt1/frui.htm

ディレクティド ブロードキャストの転送を無効にする

ディレクティド ブロードキャストは、別のサブネットのブロードキャスト アドレスにアドレスするユニキャスト パケットです。 これらのパケットを転送することには限られた意味での診断値となりますが、各種 Denial of Service アタックでは増幅器となる可能性が非常に高くなります。 Cisco IOS バージョン 12.0 とそれ以降のバージョンでは、デフォルトでディレクティド ブロードキャストが無効になっていますが、それより以前のすべてのバージョンでも手作業で無効にする必要があります。

次の例では、インターフェイス Ethernet 0/0 と Serial 1/1 でディレクティド ブロードキャストを無効にします。

interface Ethernet 0/0
no ip directed-broadcast
interface Serial 1/1
no ip directed-broadcast
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_r/1rprt2/1ripadr.htm

ソースルート パケットの転送を無効にする

ソースルート パケットには、ルーティング テーブルの内容を置き換えることができる、追加ホップバイホップ ルーティング情報が含まれています。 このパケットは、本来はネットワーク オペレータ用の診断ツールでしたが、この用途にはあまり有効ではありません。むしろセキュリティの弱点を突くために使用される可能性があります。すべてのルータでこのツールを無効にする必要があります。

次の例では、ソースルート 情報を含むパケットの転送を無効にします。

no ip source-route
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_r/1rprt2/1rip.htm

RCP と RSH のサービスを無効にする

RCP(Berkeley Remote Copy)コマンドを使用して、ファイルをデバイスにコピーし、RSH(Remote Shell)コマンドを使用して、ログインせずにコマンドを実行します。しかし、これらのサービスは、認証を極端に脆弱にすることを理解した上で、他のオプション(たとえば、 Cisco IOS バージョン 12.1T の SSH サポートのようなオプション)が使用できない場合以外は、これらのサービスは有効にしないでください。

次の例では、RCP と RSH のサービスを無効にします。

no ip rcmd rcp-enable
no ip rcmd rsh-enable
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt2/fraddfun.htm

ネイバー認証を有効にする

もっとも一般的なネットワーキングのプロトコルは、ネイバーに対して、ネイバーどうしが認証を行い、不正なデバイスがネットワークの安定性あるいはセキュリティに影響が及ばないようにする手段を提供します。 認証メカニズムにより、適正なオペレーションを混乱させる偶発的なミスは防ぐことはできますが、不正を意図した侵入者を止めるということは期待しないでください。

HSRP

次の例では、認証文字列 foobar をインターフェイス Ethernet 2/1 上の HSRP グループ 21 に対して有効にします。

interface Ethernet 2/1
standby 21 authentication foobar
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt2/1cip.htm

拡張 IGRP

次の例では、認証文字列 foobar をインターフェイス Ethernet 2/1 上の EIGRP AS 1 に対して有効にします。

key chain baz
key 1
key-string foobar
interface Ethernet 2/1
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 baz
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1ceigrp.htm

OSPF

次の例では、認証文字列 foobar をインターフェイス Ethernet 2/1 の OSPF Area 2 に対して有効にします。

interface Ethernet 2/1
ip ospf message-digest-key 1 md5 foobar
router ospf 1
area 2 authentication message-digest
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cospf.htm

IS-IS

次の例では、認証文字列 foobar をレベル 1 ルートに、そして foobaz をレベル 2 ルートに対して有効にします。

router isis
area-password foobar
domain-password foobaz
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cisis.htm

BGP

次の例では、TCP MD5 認証文字列 foobar をネイバー 192.89.55.12 への接続に対して有効にします。

router bgp 1
neighbor 192.89.55.12 password foobar
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt1/1cbgp.htm

PPP(専用回線)

PPP CHAP 認証は、リンクがトラフィックに使用される前に、そのリンク全体でお互いの ID を確認する近接ルータを必要とします。 PPP は、一般的に専用回線で使用されます。ただし、最近の Cisco IOS 機能を使用すれば、PPP を ATM とフレームリレーのリンク上で使用できます。

次の例では、PPP CHAP 認証文字列 foobar を、専用回線を介して接続されているルータ SJ-WAN と DALLAS-WAN に対して有効にします。

hostname dallas-wan
username sj-wan password foobar
interface Serial 2/1
encapsulation ppp
ppp authentication chap
 
hostname sj-wan
username dallas-wan password foobar
interface Serial 4/3
encapsulation ppp
ppp authentication chap
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/dial_c/dcppp.htm

正確なタイムスタンプの設定

Denial of Service アタックあるいはファイアウォールを通過しようとするトレーシングの種類を特定するなどの、多くのトラブルシューティング タスクは、複数デバイスからのログとの相互関係を伴ないます。 これらのデバイスのクロックが同期化されていない限り、異なるログとの相互関係は非常に困難です。


) このマニュアルでは、企業全体の NTP 設計とアップストリームのタイムソースの詳細は説明しません。


次の例では、ログとデバッグ メッセージのミリ秒精度のタイムスタンプを有効にして、アップストリーム NTP サーバを 192.89.55.132 に設定します。

service timestamps debug datetime msec
service timestamps log datetime msec
ntp server 192.89.55.132
 

詳細については、次のサイトを参照してください。

トラブルシューティング コマンド

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt3/frtroubl.htm

基本システム管理の実行

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt3/fcgenral.htm

シスログ サーバ

すべてのシステム通知とエラー メッセージをロギングすることは、多くの場合、運用ステータスの洞察に役立ちます。 アクセス リスト違反がログされた場合、そのログにより、デバイス間で相互に関連して、ネットワークがプローブされている、あるいはデバイスの信頼性がなくなったことを判別することも可能です。

次の例では、192.89.55.132 で シスログ サーバへのロギングを有効にします。

logging 192.89.55.132
 

詳細については、次のサイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt3/frtroubl.htm

IP アカウンティング

IP アカウンティング機能は、基本 IP トラフィック統計情報機能を提供します。 IP アカウンティングを有効にすることで、ユーザは発信元と宛先の IP アドレスに基づき、Cisco IOS ソフトウェアを介してスイッチされたバイト数とパケット数を確認できます。

次の例では、インターフェイス Ethernet 2/1 で IP アカウンティングを有効にします。

interface Ethernet 2/1
ip accounting
 

詳細については、次のサイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c/1cprt2/1cip.htm

CatOS デバイスの保護

仮想コンソールと SNMP のアクセス制限

仮想コンソールと SNMP からオペレーション スタッフおよびネットワーク管理ホストの IP アドレス範囲へのアクセスを制限することにより、パスワードが発見されても、権限のないユーザがネットワーク デバイスへアクセスできないようにします。

次の例では、ネットワーク 192.89.55.0 のホストだけに仮想コンソールへの接続、あるいは SNMP 要求を許可するアクセス リストを定義します。

set ip permit 192.89.55.0 255.255.255.0 all
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_gd/ip_perm.htm

SNMP コミュニティの設定

仮想コンソールを介してビューできる、あるいは設定できるほぼすべての情報は、SNMP を介してもアクセスできます。 SNMP コミュニティは、基本的にユーザ名が不要なパスワードなため、この方式のアクセスはできる限り制限することが不可欠です。 SNMP 書き込みの実行が必要と確認されたコミュニティのホストへのアクセスだけを許可する必要があります。

次の例は、それぞれ、 foo bar 、および baz の RO、RW および RWA のコミュニティを定義します。

set snmp community read-only foo
set snmp community read-write bar
set snmp community read-write-all baz
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_gd/snmp.htm

セッション タイムアウトを有効にする

オペレーション スタッフは、ネットワーク デバイスにログインしている間に、そのシステムへの注意が散漫になる、あるいは人に呼ばれて離席することがあります。 アイドル状態になったユーザの接続を自動的に解除することは、権限のないユーザによる偶発的なアクセスを防ぐことに役立ちます。

次の例は、5 分間の非アクティビティ後、ユーザの接続を自動的に解除するようにスイッチを設定します。

set logout 5
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_refr/set_m_pi.htm

ポート セキュリティを有効にする

インフラストラクチャへ不正に侵入しようとする場合の多くは、不正侵入者が、犠牲となるデバイスの MAC アドレスを仮定するか、あるいは犠牲となるデバイスを偽のクローンに置き換えることが必要なります。 Catalyst スイッチのポート セキュリティを有効にすることにより、MAC アドレスを変更する、あるいは別のポートの MAC アドレスを使用するポートをスイッチが自動的に無効にします。 ラップトップあるいは別のデバイスが異なるスイッチ ポートに普通に接続されている環境では、この機能の使用に注意する必要があります。

次の例では、ポート 2/1 から 2/48 までのポート セキュリティを有効にして、それぞれの違反が検出されてから 30 分間無効になるように設定します。

set port security 2/1-48 enable
set port security 2/1-48 shutdown 30
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_gd/sec_port.htm

VTP サーバ認証を有効にする

VTP サーバは、VTP ドメイン内で VLAN を追加あるいは削除できます。 すべての Catalyst スイッチを所定のドメインに対する VTP サーバとしての設定が可能なため、意図する VTP サーバにパスワードを設定することが、不正侵入者による偽の VTP コマンド送信を防ぐ唯一の方法となります。

次の例では、パスワード foobar を現在の VTP ドメインに対して有効にします。

set vtp passwd foobar
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cnfg_gd/vtp.htm

Cisco IOS セキュリティ/ファイアウォール機能

アンチスプーフィング フィルタ

広範囲にわたるサービス Denial of Service アタックは、捏造(スプーフ)した発信元アドレスを使用してパケットを送信する能力に依存しています。この捏造された発信元アドレスが侵入者の真の送信元をトラッキングすることを非常に困難にしています。 これらタイプの攻撃からサイトを保護する支援として、使用している独自のアドレス スペース外のすべての送信パケットをブロックする必要があります。

次の例では、192.168.123.0/24 のサイトのアドレス ブロックから送られないすべての送信パケットを阻止します。

access-list 101 permit ip 192.168.123.0 0.0.0.255 any
access-list 101 deny ip any any
interface Serial 2/1
ip access-group 101 out
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/warp/public/707/21.html#spoofing

TCP 代行受信

TCP 代行受信は、SYN 攻撃に脆弱なホストを保護するために特別に設計された Cisco IOS 機能です。 これらの攻撃は、TCP 実装のコモン フローを悪用し、ホストが着信接続を一時的に受け入れられないようにします。

次の例では、ネットワーク 192.168.1.0 の任意のホストに向かうすべての接続に対して TCP 代行受信を有効にします。

access-list 101 permit tcp any 192.168.1.0 0.0.0.255
ip tcp intercept list 101
 

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/scdenial.htm

コンテキストベース アクセス制御(CBAC)

シスコのコンテキストベース アクセス制御(CBAC)は、従来のアクセス リストの機能を拡張したもので、接続状態をモニターすることにより、ファイアウォールの機能を果します。

詳細は、次の Web サイトを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/sccbac.htm

侵入検知

シスコの侵入検知システム IDS (Intrusion Detection System) は、業界初のリアルタイム ネットワーク侵入検知システムで、ネットワーク境界、エクストラネット、および、脆弱な内部ネットワークを保護します。 この検知システムは、高速ネットワーク機器のセンサーを使用して、個別のパケットを分析し疑いのあるアクティビティを検出します。 ネットワークのデータ ストリームが、権限のないアクティビティあるいはネットワークに対する攻撃を提示し、センサーがこれらの不正使用をリアルタイムで検出した場合、アラームを管理者に転送してネットワークから違反者を削除します。 多くのシスコのルータ、スイッチ、および Cisco Secure PIX Firewall にも IDS 機能があります。

シスコの侵入検知システム製品に関する詳細と特定の環境にそれを適用する方法については、シスコのアカウント チームにお問い合わせください。

専用アドレス スペースと NAT

多くの場合、企業ネットワークの内部に RFC 1918 専用アドレス スペース(10/8、172.16/12 と 192.168/16)を使用することが、セキュリティ手段として考えられています。その理由は、これらのアドレスが公衆のインターネットから直接アクセスできないためです。

専用アドレッシングを使用することは、他の目的でもその多くの場合に役立っていますが、最善の方法ではありません。 公衆インターネットからのすべての侵入は、おそらく、公開されている会社のインターネット サーバの 1 つを経由した最初のステップです。公開されているインターネット サーバを経由すれば、NAT あるいはプロキシ デバイスより後ろにある専用アドレスに常に到達できます。

また、大部分の不正侵入は、内部の不正侵入者によるものであるため、インターネット上の不正侵入者からデバイスを隠すことができても、最も重大な脅威に対する保護措置とはなりません。

CallManager サーバの保護

CallManager サーバは、複数の別個のコンポーネント(Windows 2000 Server、SQL Server および Internet Information Server)で構成され、これらコンポーネントごとのセキュリティについては、個別に説明する必要があります。

Microsoft Windows 2000 のタスク

使用できるすべてのセキュリティ パッチをインストールする

Microsoft オペレーティング システム、特に、Windows NT および 2000 は、ハッキング コミュニティによる激しい詮索の対象となっています。 新しい脆弱性が発見されると、Microsoft は通常、数日以内にパッチを使用してセキュリティの脆弱性に対応します。 バグが発見される頻度が高いため、管理者は、適宜、すべての Microsoft 製品に対して可能なセキュリティ パッチのすべてを必ず適用していることを確認することが不可欠です。

不要なサービスの停止

サーバーを保護する基本原則の 1 つは、実行中のぞれぞれのサービスが潜在的なセキュリティの脆弱性をさらしていることを認識することです。 すべてのサービスを保護することは困難で時間が掛かるため、たとえ必須でないサービスにセキュリティ ホールがあることがすぐに認識されなくても、必須でないサービスはすべてディセーブルにすることが論理的なタスクです。

システムで必要としない限りは、次のサービスのすべてを停止し、手動起動ステータスに設定する必要があります。

アラーター サービス

コンピュータ ブラウザ

ディストリビューション ファイル システム

DHCP クライアント

DHCP サーバ

DNS サーバ

FTP サーバ

ファックス サービス

ライセンス ロギング サービス

ネット ミーティング リモート デスクトップ シェアリング

ディスク セキュリティ

FAT スタイルのファイル システムには、特定ユーザへのアクセスを制限する、あるいはディスク全体を暗号化する固有の手段は備わっていません。 特権情報を確認あるいは変更できる権限のないユーザが CallManager のセキュリティを危うくする可能性があるため、NTFS を使用する必要があります。 NTFS は、CallManager を新たにインストールするときのデフォルトです。

不要なアカウントを削除する

不明のユーザが CallManager システムにロギングする論理的な理由はありません。 Guest アカウントをディセーブルにして、 Guests グループからすべてのユーザを削除します。 このことは、ユーザとパスワードのコントロール パネルを介して実行します。

不正侵入の多くは、管理者としてのコマンド実行を盲目的に行っています。つまり、管理者アカウントの名前を CallmgrAdmin あるいは、その他一部の論理名に変更すると、システムのセキュリティが危うくなったとしても、これらの不正侵入が正常に作用するのを防ぐことになります。 これは、ローカル セキュリティー ポリシーのセキュリティ オプションを介して実行します。

多くの不正侵入では、システムへの非特権ユーザとしてのアクセス権を必要とします。 不正侵入は、管理者に CallManager にローカルにのみログオンさせるだけで防げます。 これは、ローカル セキュリティー ポリシーのユーザ権利の割り当てを介して実行されます。

管理者アカウントには特権が付与されているため、権限のないユーザがこれらのアカウントのパスワードを推測できないように確認することが不可欠です。 CallManager ですべてのローカル パスワードを、少なくとも 8 文字の長さにして、偶発的なパスワードの解読を防ぐ必要があります。また、5 回の不正試行後、自動的にロックアウトして、無作為の推測入力によって正確なパスワードを不正侵入者に発見させないようにすることも必要です。 これらのタスクは、ローカル セキュリティ ポリシーのローカル セキュリティの設定を介して実行できます。

システムの監査

監査は、Windows 2000 の多くの特権タスクのトラッキングに使用できます。監査をイネーブルにすると、イベント ビューワを定期的にリビューして、システムが危うくなったかどうかの判別を行えます。

次の表が、提案する監査方式です。

 

表 4-18 監査方式

説明
ログ成功
ログ障害

監査アカウントのログオン イベント

監査アカウント管理

監査ディレクトリ サービス アクセス

監査ログオン イベント

監査オブジェクト アクセス

不可

監査ポリシー変更

監査特権使用

監査プロセス トラッキング

不可

監査システム イベント

Microsoft Internet Information Server (IIS) タスク

Microsoft Internet Information Server は、セキュリティ ホールに悩まされてきました。 少なくとも、1 ~ 2 つのセキュリティ冊子が毎月 IIS のために発行されています。

次のセキュリティ冊子は、Micorsoft が IIS 製品の強化のためにリリースした最新のセキュリティ パッチを表しています。

Microsoft Security Bulletin (MS00-018)
チャンクしたエンコーディング転送

Microsoft Security Bulletin (MS00-019)
仮想 UNC シェアの脆弱性に使用できるパッチ

Microsoft Security Bulletin (MS00-023)
無数のエスケープ特性の脆弱性に使用できるパッチ

Microsoft Security Bulletin (MS00-030)
URL の奇形拡張データの脆弱性に使用できるパッチ

Microsoft Security Bulletin (MS00-031)
限界設定のない .HTR 要求と .HTR を介したファイル分割読み込みに使用できるパッチ

セキュリティ パッチの頻度と数量は、定期的に適用するセキュリティ パッチの重要性を示しています。

Microsoft IIS の保護

IIS に関する参照文書では、IIS アプリケーションのセキュリティを最高にする次の処置を推奨しています。


) 任意の推奨レジストリ変更を SecEdit スクリプトに追加して、単一のスクリプトでサーバ上のセキュリティを厳しくできます。



ステップ 1 不要サービスを無効にする。

必須サービス

イベント ログ

MSDTC

ライセンス ロギング サービス

ワールド ワイド ウエッブ パブリッシング サービス

Windows NTLM セキュリティ サポート プロバイダ

保護ストレージ

リモート プロシージャ コール(RPC)サービス

サーバ

Windows NT Server あるいは Windows NT Workstation

ワークステーション

IIS Admin サービス

必須の可能性あり

FTP パブリッシング サービス(FTP サーバに必要)

RPC ロケータ(リモート管理実行の場合は必要)

NNTP サービス(NNTP News サービスに必要)

サーバ サービス(停止できますが、ユーザ マネージャーが必要な場合は再起動)

SMTP サービス(SMTP サービスに必要)

テレフォニー サービス(ダイアルアップを経由したアクセスに必要)

コンテンツ インデックス(インデックス サーバ使用時に必要)

リモート アクセス サービス(ダイヤルアップ アクセスの使用時に必要)

認証発行機関(認証発行の計画時に必要)

ワークステーション(オプション: UNC 仮想ルートの使用時は重要)

プラグアンドプレイ(推奨、ただし必要ではない)

UPS(オプション: UPS の使用を推奨)

大部分のインストールで不要

アラーター

簡単 TCP/IP サービス

クリックブック サーバ

スプーラ

コンピュータ ブラウザ

ネットバイオス インターフェイス

DHCP クライアント

TCP/IP ネットバイオス ヘルパー

メッセンジャー

WINS クライアント(TCP/IP)

ネット ログオン

NWLINK ネットバイオス

ネットワーク DDE とネットワーク DDE DSDM

NWLink IIPX/SPX 互換転送(TCP/IP がある場合は不要)

ネットワーク モニタ エージェント

ステップ 2 RDS サポートをディセーブルにします。

RDS Datafactory(RDS の単一のコンポーネント)を使用して、デフォルトでデータ アクセス要求を暗黙にリモートで実行できます。 したがって、それを不正に利用して、権限のないインターネット クライアントが、サーバが使用できる OLE DB データ ソースにアクセスできます。 無効化を達成するには、次のレジストリ キーとすべてのサブキーを削除します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\RDSServer.DataFactory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\AdvancedDataFactory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\VbBusObj.VbBusObjCls
 

ステップ 3 W3C 拡張ロギング形式をイネーブルにします。

デフォルトのロギング メカニズムは、サーバが攻撃されているかどうかの判別を支援する十分な情報を記録しません。

ステップ 4 インデックス付けをクリアします。

ソース コードにインデックス付けを行うことで、不正侵入者がウェッブ ページの内容をビューすることができます。 インデックス付けをクリアするには、次のステップを実行します。

a. IIS MMC(Micorsoft 管理コンソール)を起動し、Web サイト エントリ上で右クリックしてウェブ サイト プロパティにジャンプし、 プロパティ を選択します。

b. ホーム ディレクトリ タブを選択します。

c. Index this Directory Directory browsing allowed オプションをクリアします。

ステップ 5 親パスをディセーブルにします。

ディセーブルにすることで、MapPath へのコールで「 . 」 の使用を防ぎます。 このオプションは、デフォルトではイネーブルになっていますが、ディセーブルにする必要があります。 次のステップを実行します。

a. IIS MMC を起動し、Web Site entry で右クリックして Web Site Properties にジャンプし、 Properties を選択します。

b. Home Directory タブを選択します。

c. Configuration タブを選択します。

d. App Options を選択します。

e. Enable Parent Paths オプションをクリアします。

ステップ 6 未使用のスクリプト マッピングを削除します。

IIS は、.ASP、.SHTML、および .HTR のような各種共通のファイル名の拡張子をサポートするように事前に設定されています。 これらの要求の処理は、システムに配置されている各種の DLL により扱われます。 未使用の拡張子へのマッピングを削除して、潜在的な不正侵入ポイントを必要最少限にします。 次のステップを実行します。

a. IIS MMC を起動し、Web Site entry で右クリックして Web Site Properties にジャンプし、 Properties を選択します。

b. Home Directory タブを選択します。

c. Configuration タブを選択します。

d. App Mappings タブを選択します。

e. 必要なマッピングを削除します。

ステップ 7 IIS 仮想ディレクトリを削除します。

IIS には、削除する必要のある仮想ディレクトリがいくつか含まれています。 削除するのは、次の仮想ディレクトリです。

IISAMPWD

IISSAMPLES

IISADMIN

IISHELP

ステップ 8 すべてのサンプル アプリケーション ディレクトリを削除します。

次のディレクトリには、システムから削除する必要のあるサンプル ファイルが含まれています。 削除することで、サンプル ファイルの 1 つにある脆弱性を不正侵入者が不正に利用して、システムへアクセスすることを防ぎます。

\Inetpub\iisamples

\Inetpub\scripts\samples

\Inetpub\wwroot\samples

\Program Files\Common Files\System\msadc\Samples

\WINNT\system32\inetsrv\adminsamples

\WINNT\system32\inetsrv\iisadmin

\WINNT\system32\inetsrv\iisadminpwd

ステップ 9 適切な仮想ディレクトリ許可/ウェッブ アプリケーション スペースを設定します。

正しい権限を適用して、ファイルをウェッブ サーバで使用できるようにすることが重要です。 これらの権限は、アクセスするファイルのタイプに応じて異なります。 次の表には、準拠するガイドラインの概略が記載されています。

 

ファイル タイプ
ACL

CGI と関連ファイル
.EXE、.DLL、.CMD、.PL

全利用者(実行)
管理者とシステム(完全制御)

スクリプト ファイル
.ASP など

全利用者(実行)
管理者とシステム(完全制御)

組み込みファイル
.INC、.SHTML、.SHTM

全利用者(実行)
管理者とシステム(完全制御)

スタティック コンテンツ
.HTML、.GIF、.JPEG

全利用者(実行)
管理者とシステム(完全制御)

ステップ 10 適切な IIS ログ ファイル ACL を設定します。

悪意のあるユーザが自分のアクティビティをカバーするログ ファイルを削除できないようにするには、IIS が生成するログ ファイル(%systemroot%\system32\LogFiles)のファイル権限を次のように設定する必要があります。

 

ファイル タイプ
ACL

.LOG ファイル

全利用者(実行)
管理者とシステム(完全制御)

ステップ 11 Microsoft MDAC 2.1.2.4202.3 をインストールします。

IIS と MDAC の一定のバージョンの両方を使用する Web サイトでは、訪問者がシステム上で特権アクションを実行する可能性があります。 MDAC 2.1 をインストールしてこの脆弱性をなくし、セーフ モードで動作するように MDAC 2.1 を設定できます。 次のレジストリ キーを変更します。

Hive : HKEY_LOACL_MACHINE\SOFTWARE

Key : \Microsoft\DataFactory\HandlerInfo

Name : HandlerRequired

Type : REG_DWORD

値 0 がアンセーフ モード、 1 がセーフ モードです。

Microsoft SQL Server タスク

デフォルトの設定値

STAT は、デフォルトのデータベース インストレーション インストラクションを使用して、セキュリティの設定値を大まかに分析しました。 SQL データベースには、CCM の心臓部が含まれています。 デバイス、設定およびコール データに関する情報は、このデータベースにすべて格納されいるため、データベースの破損は、CCM クラスタの全オペレーションを破壊することになります。 この分析は、データベース設定について、いちじるしく目立つ問題をすべて発見することを意図しました。 データの複製とデータベースのリモート アクセスを含め、SQL 設定のセキュリティを徹底的に検査するために、より詳細な調査が必要です。

シスコの調査で、次のようなセキュリティに関する重要な問題を発見しました。

デフォルトのアクセスが Mixed Mode に設定されている

監査レベルが none に設定されている

グループ Everyone がデータベース ファイルへフルアクセスできる

次の項では、これらの重要な問題について説明します。

デフォルトのアクセスは Mixed Modeである

Microsoft SQL 7.0 には、 Mixed モード Windows NT 専用 モードの 2 つのアクセス モードがあります。 Windows NT 専用モードを指定すると、オペレーティング システムは、すべての認証を処理します。 このことは、ログオン プロセスの時、NT の身元証明─要求応答メカニズムが使用されることを意味します。 一方、Mixed モードは OS 認証と SQL サーバ認証の 2 つを許可します。 SQL サーバ認証によりログインは、SQL サーバにより格納されたユーザ/パスワードの組み合わせテーブルと照合して認証されます。

監査レベルが none に設定されている

Microsoft SQL には、データベース サーバへのログオンを追跡する機能があります。 この情報は非常に役立ちます。データベースに対する不正侵入のモニタを試行するとき、特に、失敗したログオンの試行を調べるのに役に立ちます。 SQL は、次のレベルの監査を提供します。

None:監査情報をまったく記録しない

Success:成功したログインだけを記録する

Failure:失敗したログインだけを記録する

All:成功および失敗したログインを記録する

少なくとも、失敗ログオン試行を監査する必要があります。

Everyone がデータベース ファイルにフルアクセスできる

Windows 2000 サーバには、 Everyone と呼ばれるデフォルトのグループが含まれています。 このグループは、guest および anonymous のようなデフォルトのログオンを含め、システムへのログオンがすべてイネーブルになることを表しています。 データベース ファイルへのフルアクセスを Everyone へ提供することにより、Windows 2000 サーバへログオン アクセスをした全員がデータベースに格納された情報の読み込み、変更あるいは削除が可能となります。 このデータベースは、CCM クラスタの心臓部となっているため、このような状況は容認できません。 データベース ファイルへのフルアクセスを管理者に限定する必要があります。 さらに、データベースへのすべてのアクセスを as-needed ベースで提供する必要があります。

保護されている SQL Server 7.0 のインストールの設定

この項では、Windows 2000 にインストールされた SQL Server 7.0 だけについて説明します。Windows 95 および Windows 98 の環境では、これらのセキュリティ機能を提供しないためです。


) 次の項では、SQL Server 7.0 を Windows 2000 の認証モードに設定して、最高レベルのセキュリティを提供していることを想定しています。



ステップ 1 sysadmin(sa)アカウントを使用しません。

すべての SQL サーバ管理者に、Windows 2000 グループ メンバーシップを介して SQL サーバへのアクセスを認可し、同じグループを sysadmin サーバ ロールのメンバにすることを推奨します。 このアプローチには、小さな欠点が 1 つあります。 Windows 2000 管理者は、すべてのユーザを適切な Windows 2000 グループを追加できるため、全員に SQL Server 7.0 の sysadmin 特権を付与することが可能です。

サイトが他のユーザ(あるいは Windows 2000 管理者自身)に SQL サーバへの sysadmin アクセスを与える能力を、Windows 2000 管理者に与える必要がない場合、Windows 2000 の個別のアカウントを sysadmin のロールに割り当てる必要があります。

それぞれの場合、sa アカウントを日次管理作業に使用するのではなく、パスワードを割り当てることを強くお勧めします。 その後、パスワードを安全な場所にロックし、緊急事態のアクセスだけに使用するようにします。

SQL Server 7.0 を Windows 2000 認証モード(このマニュアルで推奨)を使用して実行している場合、信頼できる接続だけを許可する sa アカウントを使用してログオンすることはできません。


) SQL Server 7.0 が認証モードで実行されているときは、sa アカウントを使用して SQL Server 7.0 にログインできませんが、sa パスワードを割り当てることは重要です。 レジストリを少し変更することで、セキュリティ モードを認証モードから Mixed Mode に変更できます。 ログイン モードを設定するレジストリ キーは、次のとおりです。
HKLM/Software/microsoft/MSSQLServer/MSSQLServer/LoginMode
値が 0 の場合、Mixed Mode が設定されています。 値が 1 の場合、Windows 2000 認証モードが選択されています。 sa パスワードがブランク(デフォルトのインストールではブランク)の場合、侵入者(あるいは Windows 2000 管理者)は、サーバへのアクセスを取得できます。


ステップ 2 サービス アカウントを設定します。

SQL Server 7.0 は、次の 3 つの Windows 2000 サービスを実行します。

MSSQLS Server :SQL Server のコア機能を提供するエンジン

SQLServerAgent :他のサポート機能に加えて、正規のコマンドと複製をスケジュールする機能、エラー処理の方式を提供する機能、そして、エラー発生時に SQL Server のオペレータに連絡する機能の提供

Microsoft Search :フルテキスト検索機能を提供。常に、ローカル システム アカウントを使用するように設定することが必要

MSSQLSServer サービスと SQLServerAgent サービスを、次の Windows 2000 アカウントのいずれかのタイプを使用するように設定できます。

ローカル サービス アカウント

ローカル ユーザ アカウント

ドメイン ユーザ アカウント

どのタイプを選択するかは、SQL Server 7.0 に必要な機能に応じて異なります。 同じ Windows 2000 ユーザ アカウントを使用するように、両方のサービスを設定できます。 サービスのインストール後にサービス アカウントを変更する必要がある場合、SQL Server Enterprise Manager を使用する必要があります。 MSSQLServer サービスと SQLServerAgent サービスのサービス アカウントをコントロール パネルで変更することも可能ですが、Microsoft Serach サービスの設定詳細が同期化されないため、この変更はお勧めしません。

アカウント情報への変更は、サービスを次に起動したときに有効となります。 別の Windows 2000 ユーザ アカウントを使用するように、MSSQLServer サービスと SQLServerAgent サービスを設定できますが、通常、この設定はお勧めできません。 サービス アカウントを変更するときは、これら 2 つのサービスは別々に設定されているため、両方のサービスに変更を行う必要があります。 複数サーバ環境で管理オーバーヘッドを削減できると考えられる方法の 1 つが、企業のすべての SQL Server 7.0 サーバに 1 つのドメイン ユーザ アカウントを使用することです。

ローカル システム アカウント

SQL Server が複製に設定されておらず、ネットワーク リソースへのアクセスを必要としない場合、ローカル システムアカウントを使用して SQL Server 7.0 を実行できます。

SQL Server 7.0 がそのタスクを適切に実行するように、次の権限を SQL Server 7.0 のローカル システム アカウントに設定する必要があります。

SQL Server ディレクトリ(デフォルトでは、\MSSQL7)上での完全制御

.mdf、.ndf、および .ldf のすべてのデータベース ファイル上での完全制御

次のディレクトリおよびその下にあるレジストリ キー上での完全制御

HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer
HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\M
SSQLServer
 

ローカル ユーザ アカウント

Windows 2000 ローカル ユーザ アカウントを使用するように SQL Server 7.0 を設定する場合、ローカルシステムとして、同じ制限を適用します。適用するとき、ユーザ アカウントに サービスとしてログオン 権利を付与する必要があります。

ドメイン ユーザ アカウント

ドメイン ユーザ アカウントを使用して SQL Server を設定すると、最高レベルの柔軟性が提供されます。 次の例は、ドメイン ユーザ アカウントだけを使用したときに使用できる機能の一部です。

複製

ネットワーク デバイスへのバックアップと復元

リモート データ アクセスを伴う異機種加入の実行

SQL Server Agent メール機能および SQL Mail

SQL Server 7.0 がそのタスクを実行できるようにするには、ドメイン ユーザ アカウントを、前述したローカル ユーザ アカウントと同じ設定にする必要があります。 ただし、詳細な権限を考慮する場合、一部の拡張機能を使用できます。 次の表を参照してください。

 

表 4-19 SQL Server 7.0 拡張機能

サービス
権限
機能

MSSQLServer

ネットワーク書き込み権限

リモート バックアップ、データ ロードなどへの読み込み/書き込み能力

MSSQLServer

オペレーティング システムの一部として動作し、プロセス レベル トークンを置き換える

SQL Server 管理者よりユーザに xp_cmdshell を実行する

SQLServerAgent

管理者ローカル グループのメンバ

SQL Server 管理者より他のユーザに属する CMDExec と ActiveScript のジョブを作成する

SQLServerAgent

管理者ローカル グループのメンバ

自動再起動機能を使用する

SQLServerAgent

管理者ローカル グループのメンバ

アイドル時実行ジョブを使用する

最高の機能性を SQL Server 7.0 に提供するには、ドメイン ユーザ アカウントを管理者ローカル グループのメンバにすることを推奨します。

ステップ 3 ファイル権限を設定します。

Windows 2000 は、ファイルのようなオペレーティング システムのオブジェクトに高度なセキュリティ フレームワークを提供します。 Microsoft は、NT ファイル システム(NTFS)ファイル権限をすべてのデータベースのデータとログ ファイルに適用することを推奨しています。 SQL Server 7.0 を設定するユーザ アカウントには、データベース ファイルに関する完全制御権限を付与する必要があります。

さらに、実行可能ファイルとダイナミック リンク ライブラリ(DLL)を含む、すべての SQL Server 7.0 ファイルを設定して、ユーザがそれらのファイルを操作できないようにする必要があります。 SQL Server が使用するユーザ アカウント、管理者グループとローカル システム アカウント、完全制御権限を許可する権限をこれらのファイルに設定する必要があります。 それ以外の権限を設定する必要はありません。

ステップ 4 レジストリ権限を設定します。

ログオン権利のあるユーザによる物理サーバへの不正侵入から SQL Server 7.0 のインストールを保護するには、SQL Server 7.0 の設定に使用するレジストリ キーに Windows 2000 権限を設定する必要があります。 特に、次のレジストリ キー下にあるすべてのキーを保護する必要があります。

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MICROSOFT SQL SERVER 7.0\
 

このキーの Everyone グループ権限を削除して、管理者グループ、ローカル システム アカウント、あるいは SQL Server サービス アカウントに完全制御権限を追加する必要があります。

SQL サーバの管理者が、Windows 2000 の管理者による SQL サーバへのアクセスを停止する場合、レジストリ キーに権限を設定することが特に重要となります。 この場合、SQL サーバ管理者も、レジストリ キーの所有権を取得し、管理者グループから権限を削除する必要があります。 その後、SQL サーバのサービス アカウントに完全制御権限を設定することが不可欠です。 このことで、管理者がアクセスを取得することを止めさせることはできませんが、SQL サーバの管理者は、Windows 2000 管理者がセキュリティを危険にさらした時期を知ることができます。 管理者は、いつでも、所有権を取得できますが、それを与えることはできません。

ステップ 5 監査レベルを設定します。

SQL Server 7.0 が Windows 2000 認証モードを使用すると、この認証モードは、サーバへのログオンを監査する機能を提供します。 SQL Server Enterprise Manager を使用して、あるいは、プロシージャに格納されている sp_loginconfig を使用して、監査レベルを設定できます。 次の設定値を使用することができます。

None:監査情報をまったく記録しない

Success:成功したログインだけを記録する

Failure:失敗したログインだけを記録する

All:成功および失敗したログインを記録する

監査情報は、SQL Server 7.0 エラー ログに書き込まれます。

ステップ 6 プロファイラを監査に使用します。

SQL Server 7.0 は、非常に強力なプロファイラを提供して、SQL サーバ内で発生する多くの内部イベントを分析できます。

SQL サーバ プロファイラは、SQL サーバで実行されたすべてのアクションを取り込み、そのアクションを分析できる SQL サーバ プロファイラに送信するように動作します。 取り込みを画面でリアルタイムでビューして、テキスト ファイルに保存、あるいはSQL サーバ テーブルに挿入できます。

SQL サーバ プロファイラは、次のイベントを含め、SQL サーバで起きたすべての仮想イベントの取り込みを許可します。

ログイン失敗

ロッキング:デッドロック

オブジェクト:クローズド

格納したプロシージャ:ステートメント起動

セッション:接続解除

RPC :完了

この情報は、イベントの時刻と起点を確立するための優れたサポートを提供します。

ステップ 7 バックアップ ファイルとメディアを保護します。

バックアップの最も確実な方式は、SQL Server 7.0 を使用してデータ ファイルをバックアップし、その後、Windows 2000 バックアップ プログラムを使用してデータ ファイルをメディアに(パスワード機能を使用して)バックアップします。 これにより、パスワードを知っているユーザだけが、ファイルを復元できることを保証します。 バックアップ データ ファイルは、ディレクトリ権限が設定された NTFS のパーティションに設定し、一般のユーザがファイルへのアクセスを取得できないようにする必要があります。

バックアップ メディアが物理的に保護されている場合、SQL Server 7.0 バックアップで、セキュリティの危険性が提起されることはまったくありません。

ステップ 8 データベースを別のサーバに復元します。

次の 3 つの状況が、データベースを別のサーバに復元することに関係しています。

Mixed Mode

Windows NT 認証(同じドメイン)

Windows NT 認証(別ドメイン)

Mixed Mode

セキュリティ認証に Mixed Mode を使用するサーバーにデータベースを復元すると、データベースのセキュリティは無効になります。 原因は、ログオンがマスター データベースの sysxlogins テーブルに維持されているの対して、ユーザのデータベースへのアクセス権は、それぞれのデータベースの sysusers テーブルに格納されているためです。つまり、論理リンクは、sysxlogins テーブルのユーザのエントリと sysusers テーブルのユーザのエントリとの間で維持されます。 このリンクは、生成した 16 バイト GUID です。

Mixed Mode 認証に GUID を実装する効果が最終的に表れるのは、SQL Server 7.0 を実行するコンピュータにデータベースを復元する時です。つまり、データベース アクセスが付与されてはいるが、syslogins テーブルと sysusers テーブルの間のリンクが破れ、その結果、事実上は、データベースへのアクセスを誰にも付与していないコンピュータにデータベースを復元する時ではありません。 sysadmin グループのメンバは、この復元の例外となります。 すべてのロール メンバシップとユーザ権限を再度作成する必要があります。

データベースを別のサーバに復元することは、Mixed Mode 認証の脆弱性の 1 つをさらけ出すことになります。

Windows NT 認証(同じドメイン)

データベースを、同じドメインで SQL Server 7.0 を実行する別のコンピュータに復元すると、データベースの権限は、そのまま残ります。 ここで考慮する唯一のことは、そのサーバにログオンする権限がユーザに付与されているかどうかという点です。 そのサーバにログオンする権限は、SQL サーバの各インスタンスで実装されます。

たとえば、ボブが営業グループのメンバーで、営業グループには SQLSERVER1 でログイン権限が付与されています。 ボブには、営業データベースへのデータベース アクセス権が付与されています。 営業データベースが SQLSERVER2 に復元されると、ボブの権限は営業データベースに存在します。 しかしながら、営業グループには、そのサーバへのログイン権が付与されていないため、ボブはそのデータベースを使用できません。 管理者が Everyone グループ ログイン権をそのサーバに付与すると、ボブはそのデータベースを使用できます。 原因は、ボブに営業データベースの使用を停止する唯一の制限が、サーバへのロギングであったためです。

データベースを同じドメインの別のサーバに復元すると、データベース内の権限はそのまま残りますが、この特定のサーバへのログイン権限は付与する必要があります。

信頼できるドメインからのユーザ

Windows 2000 信頼関係が、新しいドメインが古いドメインを信頼するように、新旧のドメイン間で確立していれば、旧ドメインからのユーザは、そのまますべての権限でデータベースを使用できます。ただし、旧ドメインのユーザに、SQL サーバへのログイン権が付与されていることが条件です。

別の信頼できるドメインからのユーザは、むしろ新しいドメインからのユーザに似て、データベースへのアクセス権が付与されていません。

新しいドメインからのユーザ

新しいドメインからのユーザは、各自の SID がデータベースの sysusers テーブルに存在していないため、誰もアクセス権がありません。

唯一の例外が、Windows 2000 の BUILTIN アカウントです。BUILTIN アカウントは、すべてのサーバで常に同じ SID を使用するため、ローカル 管理者グループのような BUILTIN アカウントに付与されたすべての権限は、そのまま残ります。 このことは、BUILTIN アカウントにログイン権があり、SQL サーバがドメイン コントローラにインストールされることを想定しています。

同じユーザ名とパスワードを使用する任意のドメインからのユーザ

大部分の Windows 2000 のセキュリティ実装では、ユーザ独自のドメインにないリソースへのアクセスが必要な場合、そのユーザはそのリソースにアクセスできます。ただし、ユーザ アカウントが同じユーザ名とパスワードの組み合わせで存在していることが条件です。 この動作は透過的です。

もし、ユーザが同じ名前付きパイプを使用してサーバに接続すると、ユーザが最初にファイル共用への接続を確立できれば、この接続は成功します。 ユーザが Windows 2000 をコンピュータ オペレーティング システムとして実行していれば、別名でアカウントを使用しても、この方式で接続できます。 Windows 2000 オペレーティング システムからファイル リソースへ接続するとき、ユーザがアクセスを拒否された(そして、ユーザが接続するコンピュータの別のクレデンシャルを現在まったく使用していない)場合、ログオン目的でユーザ名とパスワードを提供する機会が与えられます。

ステップ 9 データベース ファイルを接続または接続解除します(あるいはその両方)。

データベース ファイルの接続と接続解除に対応する問題は、ステップ 8 で説明した内容と同じです。例外は、データベースを作成してからデータを復元する必要があるという点です。

ステップ 10 Windows 2000 Guest アカウントをディセーブルにします。

Windows 2000 認証モードで SQL Server 7.0 を実行すると、サーバは Windows 2000 を信頼してクライアントのすべての認証を実行します。 これにより、Windows 2000 に適用されるセキュリティ フレームワーク、強さと弱さの両方をサーバにもたらします。 幸いにも、脆弱性は多くありません。 しかしながら、多くの Microsoft およびサードパーティの文書で十分に文書化されている問題が 1 つあります。それが、Windows 2000 Guest アカウントの使用です。 Guest アカウントが無効にされていない場合、その Guest アカウントを無効にすることを強くお勧めします。


 

音声メールの統合

この項では、次の項目を含め、IP テレフォニー の音声メール統合について説明します。

Cisco Unity を使用した音声メッセージ

SMDI 音声メールの統合

SMDI 音声メールと IP WAN 全体との統合

Cisco Unity を使用した音声メッセージ

http://www.cisco.com/univercd/cc/td/doc/product/voice/uone/index.htm を参照してください。

SMDI 音声メールの統合

SMDI 統合を使用して、コール情報は、CallManager と音声メール システムの間の RS-232 シリアル リンクに送信されます。 音声通信は、ハント グループにより作成された個別のパッチを介して提供されます。 ハント グループは、CallManager と音声メール システムの間のアナログステーション(VG 200 ゲートウェイ、あるいは Catalyst 6000 24 ポート FXS ゲートウェイ WS-X6624 のいずれかから派生した FXS ポート)で構成されています。 ハント グループが、着信コールを受信すると、着信コールは、CallManager からの標準 SMDI 形式のデジタル メッセージを伴っています。 このデジタル メッセージは、必要なコール情報のすべてを含んでいます。 その後、音声メール システムは、指定したポートで応答し、適切なグリーティングを再生します。 メッセージ待機通知を設定あるいは取り消すためには、音声メール システムは、デジタル メッセージを RS-232 シリアル リンクを通して CallManager に送信します。

次の項は、このトポロジに基づいています。

図 4-35 音声メール トポロジ

 

設定の概要

次のステップに従って、SMDI 音声メール システムを設定します。


ステップ 1 CMI(Cisco Messaging Interface)のインストールを確認します。

CMI アプリケーションを介して SMDI を使用可能にします。 このアプリケーションは、デフォルト インストレーションの一部ではないので、SMDI が必要な場合は、 Optional Components 下で手作業で選択する必要があります。 インストールすると、 Service メニューから Cisco Messaging Interface を選択できます。

図 4-36 Cisco Messaging Interface コマンド

 

CMI は、クラスタ内で機能しますが、クラスタ内の単一サーバにだけ常駐します。 たとえば、同じ音声メール システムに接続されている 2 つの CMI アプリケーションを同時に実行することはできません。

音声メール システムを追加した場合は、CMI アプリケーションを追加する必要があります。 たとえば、クラスタに 4 つのアクティブ CallManager があり、それぞれの CallManager に CallManager 独自の音声メール システムが接続されているとします。 それぞれの音声メール システムでは、システムに独自の CMI アプリケーションを実行する必要があります。

ステップ 2 FXS ポート:VG200 あるいは Catalyst 6000 の 24 ポート ゲートウェイをインストールし、設定します。

a. MGCP(またはSkinny)ゲートウェイを設定します。 この場合、4 ポート VG200 MGCP ゲートウェイを設定します。

図 4-37 MGCP 設定画面

 

b. Installed Interface Cards には FXS を選択していることを確認してください。

図 4-38 音声インターフェイス カードの選択

 

ゲートウェイには 4 つのポートあるいは Endpoint Identifier があります。


) 音声メール システムに接続するときは、アナログ ポートを常に FXS ポートとして設定してください。


図 4-39 Endpoint Identifier

 

c. それぞれのポートを POTS 回線として設定します。

図 4-40 選択ポート タイプ: POTS

 

変更が必要な唯一のパラメータは、 Device Pool です。この場合、 Default を選択します。 ただし、実際には、カスタマーの設定に従った適切な Device Pool を選択します。 これに応じて、CallManager Redundncy Group、Time Zone、および Region が定まります。

図 4-41 最初のポートの設定

 

d. ここで、1 つのポートを POTS として設定したので、残りの 3 つを設定できます。

図 4-42 残りのポートの設定

 


) 最初の POTS 回線の次に、Add DN が表示されます。 POTS 回線が、DN を派生するルート パターンを後から構成するため、Add DN は必要ありません。


これで、4 つすべてのポートを POTS 回線として設定しました。

図 4-43 ポート設定の完了

 

ステップ 3 ルート グループを作成します。

a. のウィンドウから、 Update をクリックします。

次の画面が表示されます。

図 4-44 新しいルート グループ設定

 

b. Device Name のドロップ リストから最初のポートを選択します。

図 4-45 最初のポートの選択

 

c. Port のドロップ リストから 1 を選択します。


All を選択すると、正確な Order をポートに割り当てられなくなります。 たとえば、All を選択することは、実際に利用したポートに関係なく、普通、SMDI パケット内の 1 の LTN(Logical Terminal Number; 論理端末番号)を送信することになります。 このことは、結果として統合の失敗となります。


図 4-46 Port の選択

 

d. Order のドロップ リストから 1 を選択します。 これは、ルート グループ内でポートに設定される順序です。

図 4-47 Order の選択

 

これで、ポートを 1 つルート グループに追加しました。

図 4-48 ルート グループに追加されるポート

 

e. ステップ B から E までを繰り返して次のポートを設定しますが、 Device Name ドロップ リストから 2 番目のポートを選択し、 Order ドロップ リストから 2 を選択します。 Port のドロップ リストから 1 を選択することを忘れないでください。

これまでで、ルート グループは 2 つのポートで構成されています。

図 4-49 設定された 2 番目のポート

 

f. 残りのポートを設定します。

ルート グループが完了しました。

図 4-50 完了したルート グループ

 

ステップ 4 ルート リストを作成します。

a. Route Plan メニューから、 Route List を選択します。

次の画面が表示されます。

図 4-51 新しいルート リストの追加

 

b. Route List Name に入力して、 Insert をクリックします。

次の画面が表示されます。

図 4-52 ルート グループの追加

 

c. Add Route Group ボタンをクリックします。

次の画面が表示されます。

図 4-53 ルート グループの追加(続き)

 

d. 適切なルート グループを選択して、 Add をクリックします。

これで、ルート リストへの挿入が準備できました。

図 4-54 ルート グループ選択

 

e. Insert ボタンをクリックします。

ルート リストが設定され、次のような画面が表示されるはずです。

図 4-55 ルート詳細設定

 

ステップ 5 ルート パターンを作成します。

のウィンドウから、 Update をクリックします。

次のウィンドウで、ルート パターンに 4000 の DN、つまり、音声メールのアクセス コードを割り当てました。 Provide Outside Dial Tone ボックスもクリアします。 このオプションを選択すると、サブスクライバは、最初のディジットを入力するとすぐに 2 番目のダイヤル トーンを受信し、一部のサブスクライバがこの混乱に気づくことがあります。

図 4-56 完了したルート リスト

 

ステップ 6 CMI を設定します。

a. Device メニューから、 Cisco Messaging Interface を選択します。

次の画面が表示されます。

図 4-57 サーバの選択

b. CMI を実行するサーバを選択して、 Insert ボタンをクリックします。

次の画面が表示され、VoiceMailDN、BaudRate、SerialPort、およびその他のパラメータを設定できます。

図 4-58 CMI パラメータの設定

c. CMI に次のパラメータを設定する必要があります。

 

表 4-20 CMI パラメータ

パラメータ
説明

CallManagerName

このパラメータをブランクのまま残すと、CMI はローカル ホストへの接続を試行します。

BackUpCallManager

クラスタ化した環境では、CMI にプライマリ(CallManagerName)とバックアップ(BackUpCallManager)を与えることを推奨します。 コストもまったくかからず、プライマリがダウンしたときでも音声メール サービスを確実に取得できます。

VoiceMailDn

このパラメータは設定する必要があります。コールが指定した番号に送信されると、CMI をトリガーして SMDI パケットを提供させるようにするからです。

SerialPort

デフォルトは、 COM1 です。 COM ポートを、CMI 専用としてください。

BaudRate

デフォルトは、 9600 です。

Parity

デフォルトは、 Even です。

DataBits

デフォルトは、 7 です。

StopBits

デフォルトは、 1 です。

* OutputDnFormat

デフォルトは、 %010s です。 このパラメータを使用して、指定したディジットを含む出力文字列をパッドできます。 この場合、 % はフォーマッティング コマンドです。 文字列 010s は、SMDI メッセージを先頭文字が 0 の 10 ディジットとしてフォーマットするように、CMI に指示します。 たとえば、CMI に 7 ディジットの文字列を表示させるには、 OutputDnFormat as %07s と設定します。 s は、CMI に文字列としての結果を表示させるだけです。

* OutputExternalFormat

デフォルトは、 %010s です。 音声メール システムに CallManager の内線の長さより長い文字列の長さを予測させるときに、このパラメータを使用します。 たとえば、4 桁の内線で設定された CallManager に接続する 7 桁の文字列を音声メール システムに予測させるには、 OutputExternalFormat 525%4s と設定します。 この結果は、内線 1234 に対して、文字列 5251234 となります。

InputDnSignificantDigits

デフォルトは、 10 です。 7 桁の MWI コマンドを 4 桁の内線に設定されている CallManager に送信するシスコの音声メール システムの場合、 InputDnSignificantDigits 4 と設定します。 つまり、4 つの重要な最小ディジットは維持します。


) これらのパラメータはオプションで、ほとんどの場合、どのような修正も必要ありません。


また、次の点にも留意してください。

サブスクライバの Messages ボタンを設定するには、 Service/Service Parameters/Cisco CallManager メニュー下にある VoiceMail パラメータを使用します。 この変更をアクティブにするには、CallManager を再起動する必要があります。

CallManager が音声メール システムに転送コールを送信する SMDI リンク メッセージは、通常、 A を転送理由コードとして提供します。 転送理由コード A の意味は、すべてのコールを転送するということです。 正確な転送コード、 N (応答なし)および B (使用中)は、現時点でサポートされていません。 Octel 製品のような一部の音声メール システムを設定して、転送理由コードに基づいた異なるグリーティングを提供できます。 Cisco CallManager は、この機能をサポートしていません。

SMDI リンクのハートビート メッセージ:一部の音声メール システムは、SMDI リンクが正しく機能しているか判断するための手段として、遠くの端からの NAK 応答を予期して、にせの OP:MWI メッセージ(たとえば、OP:MWI 5551212)を送信できます。 KeepAliveDn パラメータには、このアクティビティに一致した、にせのステーション番号が含まれています。

IP Phoneのメッセージ待機インジケータが点灯し、デバイスの電源をオン/オフするか、あるいは CallManager メニュー内のデバイスのいずれかによりその IP Phoneがリセットされると、メッセージ待機インジケータは、その IP Phoneが CallManager に再度登録されてから再度点灯します。 また、CallManager を停止し、その後再起動すると、システムをリセットするまでオンの状態だったメッセージ待機インジケータもオンに戻ります。

CMI 内のそれぞれのパラメータを修正した場合、 Update を実行する必要があります。 実行しないと、修正はデータベースに書き込まれません。

CallManager は、現在のところ、設定可能な Message Desk ID をサポートしていません。 ハードコード ID は、 001 です。 ID 001 を使用するスイッチと統合されている音声メール システムと CallManager を統合すると、このハードコードが問題となる可能性があります。 この場合は、スイッチを別の ID に再設定して、2 つの統合が正しく機能することを確認してください。

DB-9 シリアル ポート情報:CallManager は標準の PC で動作します。つまり、標準の PC に、実際に配線されている 9 ピンのシリアル ポートがあることを意味します。 ただし、CMI は RS-232 回線の 3 つ、TD、RD および GND だけを使用します。 発信制御には、RTS と DTR の 2 回線があります。 ポートが開かれると、これらは 2 つとも割り当てられますが、CMI は回線の使用、不使用については注意しません。 着信制御には、 DCD、CTS、DSR および RI の 4 回線があります。 これらのすべての回線が無視されます。 有効なハンドシェイキング回線をこれらの回線に接続することをお勧めしますが、回線が無視されるように、ハードウェアのハンドシェイキングをディセーブルにしてポートを開ける必要があります。

SMDI 音声メールのトラブルシューティング

SMDI のトラブルシューティングで唯一実質的な手段は、ハイパー ターミナルのある PC を SMDI ポートに接続して、テスト コールを実施することです。


ヒント ヌルモデム アダプタを使用するようにしてください。 このアダプタを使用することで、CallManager の送信する内容を正確に把握し、音声メールの技術者と共にすべての問題を解決できます。


CallManager からの SMDI パケットが、着信コールを受信する音声メールのポート設定と一致しない限り、音声メール システムが、正確な方法でコールに応答しないことに留意してください(たとえば、 Message Desk Logical Terminal Number が一致している必要があります)。

サンプル VG200 の設定詳細

現在の設定

!
mgcp
mgcp call-agent 10.1.1.2 IP Address of CallManager
mgcp dtmf-relay codec all mode out-of-band
mgcp ip-tos precedence 5 Sets IP “Precedence” of RTP Stream to 5
mgcp default-package hs-package
!
ccm-manager switchback immediate
ccm-manager redundant-host 10.1.1.253 Backup CallManager - if applicable
ccm-manager mgcp
!
interface FastEthernet0/0
ip address 10.1.1.3 255.255.255.0
duplex auto
speed auto
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.1.1.1 Default Route
no ip http server
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer voice 100 pots
application MGCPAPP
port 1/0/0
!
dial-peer voice 101 pots
application MGCPAPP
port 1/0/1
!
dial-peer voice 102 pots
application MGCPAPP
port 1/1/0
!
dial-peer voice 103 pots
application MGCPAPP
port 1/1/1
!
end
 

Catalyst 6000 24-Port FXS ゲートウェイ設定の詳細例

1. Device メニューから、 Gateway を選択します。

次の画面が表示されます。

図 4-59 新規ゲートウェイの追加

 

2. Add a New Gateway ウィンドウから、次のフィールドの値を選択します。

Gateway Type Cisco Catalyst 6000 24 port FXS Gateway を選択します。

Device Protocol Analog Access を選択します。

3. Next をクリックします。

Gateway Configuration ウィンドウが表示されます。

図 4-60 ゲートウェイ設定ウィンドウ

 

4. 次のフィールドの値を入力あるいは選択します。

MAC Address :ゲートウェイの MAC ドレス(Catalyst 6000 CLI にあります)を入力します。

Device Pool Default を選択します。

Port Selection Order Top Down あるいは Bottom Up を選択します。

5. Insert をクリックします。

これで、シスコのゲートウェイが挿入されました。

図 4-61 最初に挿入されるゲートウェイ

 

6. Add New Port をクリックします。

ポップアップ ウィンドウが表示されます。

図 4-62 ポート タイプ ポップアップ ウィンドウ

 

7. 次のフィールドの値を入力あるいは選択します。

Port Type POTS を選択します。

Port Number Port - 1 を選択します。 All Port を選択すると、正確な順番をポートに割り当てられなくなります。 たとえば、All Port を選択すると、実際に利用したポートに関係なく、普通、SMDI パケット内の 1 の論理端末番号(LTN)を送信することになります。 このことは、結果として統合の失敗となります。

End Port Number Port - 1 を選択します。

8. Insert をクリックします。

次に示すように、シスコのゲートウェイに FXS ポートが設定されました。

図 4-63 1 つの FXS ポートが設定されているゲートウェイ

 

9. ステップ 1 から 7 までをそれぞれのゲートウェイに繰り返します。


) ステップ 6 では、それぞれのゲートウェイに適した Port NumberEnd Port Number を選択していることを確認してください。 たとえば、2 番目のゲートウェイでは、これらのフィールドに Port -2 を、3 番目のゲートウェイには Port-3 のように選択します。


終了すると、完了した設定は次のようになります。

図 4-64 12 の FXS ポートが設定されているゲートウェイ

 


) FXS ポートに、ダイヤルトーンのオン接続解除(リオーダートーンとは対照的)を提供するには、Port Configuration ウィンドウの Call Restart Timer パラメータに 1234 を設定する必要があります。 このパラメータの他のすべての値は、FXS ポートにリオーダートーンのオン接続解除を提供します。 次の数字を参照してください。


図 4-65 コールのリスタート時刻オプションの設定

 

10. この設定変更をすべてのポートに繰り返します。

11. Reset Gateway をクリックすると変更が有効になります。

SMDI 音声メールと IP WAN 全体との統合

SDMI を IP WAN 全体に統合すると、Cisco CallManager と IP WAN クラウドの終端の 1 つに配置されたルータの非同期ポートとの間の RS-232 シリアル リンクを介して、コール情報が送信されます。 このコール情報がこのルータに到達すると、非同期トンネル伝送は、IP WAN クラウドの他の終端に配置されているルータにコール情報を伝送します。 このコール情報がこのルータに到達すると、このコール情報は、そのルータの非同期ポートと音声メッセージ システムとの間の RS-232 シリアル リンクを介して転送されます。

音声通信は、別個のパスを介して提供されます。そのパスは、CallManager と音声メール システムの間のアナログステーション(VG 200 ゲートウェイ、あるいは Catalyst 6000 の 24 ポート FXS ゲートウェイ WS-X6624 のいずれかから派生した FXS ポート)で構成されているハント グループにより作成されます。 VG200 ゲートウェイあるいは Catalyst 6000 の 24 ポート FXS ゲートウェイ WS-X6624 は、音声メッセージ システムと同様に、IP WAN クラウドを介してではなく、同じ場所に配置される必要があります。 ハント グループが IP WAN を介した着信コールを受信すると、そのコールには、CiscoCallManager から IP WAN を介した標準 SMDI 書式のデジタル メッセージが付随しています。そのデジタル メッセージには、必要とするコール情報のすべてが含まれています。 その後、音声メッセージ システムは、そのコールに指定したポートで応答し、適切なグリーティングを再生します。

従来の SMDI 統合で RS-232 を使用する場合の制限として、音声メッセージ システムと CallManager を同じ場所に配置しなければならないことです。 一部のカスタマーのシナリオでは、IP テレフォニー ソリューションを小規模なリモート サイトにインストールして、音声メッセージ システムは IP WAN クラウドを経由するセントラル サイトに配置します。

IP WAN 間の非同期トンネル伝送を使用することにより、リモート サイトとセントラル サイトに配置されたルータは、これらの RS-232 信号をトンネル伝送できます。 サイト A( を参照)に配置された CallManager の SUMI インターフェイスから伸びている RS-232 ケーブルは、サイト A に配置されたルータ A の非同期ポートに接続する必要があります。この接続は、ルータのモデルに応じて、任意の非同期ポート(AUX ポートも非同期ポートです)を使用して達成できます。 もう一方の IP WAN クラウドでは、RS-232 ケーブルを、サイト B に配置されたルータ B と Octel 音声メッセージ システムの SMDI との間の、非同期ポート(AUX ポートも非同期ポートです)に接続する必要があります。 Octel 音声メッセージ システムは、サイト B に配置されます。

このソリューションを実装する前に、サイト間コールに必要なキャパシティと同様に、音声メールにロールできるコール数に適切な QoS(LLQ)を設定しておく必要があります。 また、アドミッション制御方式を実装してからこのソリューションを実装する必要があります。

詳細は、 SMDI 音声メールの統合 を参照してください。

トポロジ

非同期トンネル伝送の設定 は、次のトポロジに基づいています。

図 4-66 CallManager SMDI トポロジ

 

非同期トンネル伝送の設定

次の非同期トンネル伝送を設定して、コール情報を IP WAN クラウドを経由して搬送する必要があります。

サイト A に配置されたルータ A の非同期トンネル伝送の設定

! On the router A serial link <10.1.2.3> define an IP hostname to use on the TELNET so we can use !BUSY-MESSAGE to suppress display message
ip host router_b 4129 10.3.2.1 ! port 4xxx is raw TCP, 129 is the line number for aux 0 !on the router B
busy-message router_b # #
service tcp-keepalives-out ! [2]
!
line 2
no motd-banner
no exec-banner
no vacant-message
autocommand telnet router_b /stream
autohangup
! The following command means incoming serial data is saved till the TCP
! connection is made.
no flush-at-activation ! not available in all feature sets
no activation-character ! any character will create the EXEC escape-character NONE ! or "escape-char BREAK"
exec ! need an EXEC to do the TELNET
special-character-bits 8
exec-timeout 0 0
session-timeout 0 0
! RS232 config:
no modem inout ! disable modem control [1]
no autobaud
speed 9600 ! set the desired speed
stopbits 1 ! or 2, as desired
flowcontrol NONE ! or HARDWARE, or SOFTWARE
transport input NONE ! do not allow reverse connections
 

サイト B に配置されたルータ B の非同期トンネル伝送の設定

! On router_b Ethernet link <10.3.2.1>
no banner incoming
service tcp-keepalives-in ! [2]
line 3
no exec
no exec-banner
no vacant-message
! RS232 config:
modem DTR-active ! DTR indicates status of TCP
! connection
no autobaud
speed 9600 ! as desired - does not need to match
! the speed on the called side
stopbits 1 ! or 2, as desired
flowcontrol NONE ! or HARDWARE, or SOFTWARE
transport input telnet ! allow the incoming TCP connection

) ルータ A で no modem inout コマンドを使用します。モデムの信号方式を使用して、ルータが DSR が高速で進んでいることを確認すると、ルータ A は自動コマンドを開始します。 ただし、ルータの電源をオンからオフにして、そしてルータをオンにしたときにDSR が高速の場合、自動コマンドは開始されず、ユーザが自身で clearline を開始します。



) TCP キープアライブを両方でイネーブルにして、適切に接続できるようにしてください。 イネーブルにしないと、もしサイト A あるいはネットワークパスが停止すると、サイト B は、(送信するアプリケーション データがない限り)サイト A の接続が停止していることに気づきません。 このことは、サイト A の新しい接続試行の失敗を引き起こします。


ヒント

シスコは、テストの際に、Octel 250 音声メッセージ システムを使用しました。 ただし、このソリューションは、SMDI をサポートするすべての音声メッセージ システムで動作します。 Octel 音声メッセージ システムを使用するときは、次のヒントに従ってください。

使用可能な非同期ポートを統合ポートとして定義します(メニュー 6.3)。 CPU シリアル チャネルを統合 リンクとして定義したら、システムを再起動する必要があります。

統合リンク(メニュー 6.5)をスイッチ タイプ 3(1AESS/SMDI、完全二重)として設定します。 統合 リンクを 9600 bps、7、E、1 に設定します。

IP Phoneにメールボックスを作成します。

Cisco CallManager 側で、CMI は設定され実行していることを確認します。 また、CallManager が、Calistra PBXLink デバイス(Calistra PBXLink がこのトポロジで使用されている場合)が送信する DN(DN の長さは通常はメールボックスの長さに等しい)に対して、同じ数のディジットを送ることを確認してください。 最後に、シリアル リンクを 9600、7、E、1 に設定します。

Octel Aria 250 は統合に必要なシリアル ポートを 3 つまでサポートします。 これらのシリアル ポートの 2 つが、現在、PBX 統合デバイス(PIDs)で使用されている場合、CallManager に使用できるスペア ポートは 1 つです。 最初に、PID を停止させて現在の統合を SMDI に変換して、SMDI を Castra PBXLink に置き換える必要があります。 Octel Aria 250 を SMDI を介して統合すると、Cisco CallManager に接続できます。

音声メッセージ システムへのコンバージ パスとなる、PBX で非 DID(ダイヤルイン)の内線が必要になることがあります。 PBX は、音声メッセージ システムへのカバレージ パスをもっています。音声メッセージは、正確な音声メールボックスに送信され、ユーザはそのメッセージを取得できます。 このシナリオでは、WAN が停止しても、ユーザは音声メッセージの除外と取得ができます。 ただし、ユーザは音声待機インジケータ(MWI)は取得できません。


) IP WAN が停止した場合、ISDN のバックアップ ソリューションを使用することは可能です。 ただし、このバックアップ ソリューションに関連する制限を注意深く評価する必要があります。


IP テレフォニー ネットワークへの移行

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/ccmigration_09186a00800d6805.pdf を参照してください。