ダウンロード |
| ライター翻訳版 - January 10, 2006 |
| 機械翻訳版 - January 10, 2006 |
| 英語版 - January 10, 2006 |
| Document ID: 22833 |
目次
概要全般
分類とマーキング
キューイングと輻輳管理
輻輳回避 Weighted Random Early Detection（WRED; 重み付けランダム早期検出）
ポリシングとシェーピング
Quality of Service（QoS）フレームリレー
非同期転送モード（ATM）での QoS
音声と Quality of Service（QoS）
関連情報
概要
このドキュメントでは Quality of Service（QoS）に関する FAQ を取り扱っています。
全般
Q. Quality of Service（QoS）とは何ですか。
A. QoS とは、Frame Relay、Asynchronous Transfer Mode（ATM）、Ethernet と 802.1 のネットワーク、SONET、および、IP ルーテッド ネットワークなどの多様な基本テクノロジーによる、他のトラフィックよりもよいサービスを特定のネットワーク トラフィックに提供するネットワークの機能を意味します。
QoS は、データ スループットのキャパシティ（帯域幅）、遅延のばらつき（ジッタ）、遅延について、要求した予測可能なサービスレベルをアプリケーションが受けることができるようにする技術の集まりです。QoS 機能では、特に次の方法を取り入れることにより、より高品質で予測が可能なネットワーク サービスを提供しています。
専用に割り当てられた帯域幅のサポート。
損失特性を改善。
ネットワークの輻輳を回避および管理。
ネットワーク トラフィックのシェーピング。
ネットワーク全体にトラフィックの優先順位を設定。
Internet Engineering Task Force（IETF; インターネット技術特別調査委員会）では、QoS に関して次の 2 種類のアーキテクチャを定義しています。
統合サービス（IntServ）
差別化サービス（DiffServ）
IntServ は、Resource Reservation Protocol（RSVP; リソース予約プロトコル）を使用して、ネットワークにわたるエンドツーエンドのパス上にあるデバイスに対して、アプリケーション トラフィックに QoS を行う必要があることを信号で示します。経路上にあるすべてのネットワーク デバイスで必要な帯域幅が予約できると、送信元のアプリケーションは送信を開始します。Request for Comments（RFC; コメント要求）2205 では RSVP を定義し、また RFC 1633 では IntServ を定義しています。
DiffServ は、集約化およびプロビジョニングされた QoS に重点を置いています。DiffServ では、アプリケーションの QoS 要求として信号を送信する代わりに、IP ヘッダー内の DiffServ Code Point（DSCP; DiffServ コード ポイント）を使用して、必要な QoS のレベルを示します。Cisco のルータは、Cisco IOS(R) ソフトウェア リリース 12.1(5)T で DiffServ 準拠になっています。詳細は、次のドキュメントを参照してください。
Q. 輻輳、遅延、ジッタとは何ですか。
A. あるインターフェイスに処理能力を超えたトラフィックが集中した状態が輻輳です。Quality of Service（QoS）は、まずネットワークの輻輳ポイントに適用する必要があります。次の図は、典型的な輻輳ポイントの例です。
ネットワークの輻輳によって、遅延が生じます。ネットワークとネットワーク上のデバイスで発生する遅延には何種類かあり、これは『パケット音声ネットワークでの遅延について』で説明されています。遅延のばらつきはジッタと呼ばれ、これは『パケット音声ネットワークでのジッタについて（Cisco IOS プラットフォーム）』で説明されています。リアルタイムでインタラクティブなトラフィックをサポートするには、遅延とジッタの両方を制御し、最小化する必要があります。
Q. MQC とは何ですか。
A. MQC とは Modular Quality of Service（QoS）Command Line Interface（CLI）を意味します。この機能は、共通のコマンド構文を定義したり、プラットフォーム間での一連の QoS の動作を設定したりすることで、簡単に Cisco のルータやスイッチでの QoS 設定ができる設計になっています。QoS およびプラットフォームごとに構文が異なっていた以前のモデルは、このモデルに置き換えられます。
MQC には、次の 3 つのステップが含まれます。
class-map コマンドでトラフィック クラスを定義する。
policy-map コマンドで 1 つあるいは複数の QoS 機能をトラフィック クラスに関連付け、トラフィック ポリシーを作成する。
service-policy コマンドで、インターフェイス、サブインターフェイス、あるいは、Virtual Circuit（VC; 仮想回線）にトラフィック ポリシーを割り当てる。
注：マーキングやシェーピングなどの DiffServ のトラフィック調整機能を実装するには、MQC 構文を使います。
詳細は、『モジュラ QoS コマンドライン インターフェイス』を参照してください。
Q.「service-policy is supported only on VIP interfaces with DCEF enabled」というエラー メッセージは何を意味しているのですか。
A. Cisco 7500 シリーズの Versatile Interface Processor（VIP）では、Cisco IOS 12.1(5)T、12.1(5)E、および 12.0(14)S で、分散型 QoS 機能だけがサポートされています。Distributed Cisco Express Forwarding（dCEF）をイネーブルにすると、分散型 QoS も自動的にイネーブルにされます。
従来型の Interface Processor（IP; インターフェイス プロセッサ）などの非 VIP インターフェイスでは、主要な QoS 機能は Route Switch Processor（RSP）でサポートされています。詳細は、次のドキュメントを参照してください。
Q. Quality of Service（QoS）ポリシーではクラスがいくつサポートされていますか。
A. 12.2 よりも古いバージョンの Cisco IOS では、定義できるクラスが最大でも 256 だけでした。同じクラスが別のポリシーでも再利用される場合、各ポリシーに 256 クラスまで定義できていました。ポリシーが 2 つあるとすると、両方のポリシーを合わせたクラスの合計が 256 を超えることはできません。あるポリシーに Class-Based Weighted Fair Queueing（CBWFQ）があると（つまり、どのクラスにも bandwidth 文か priority 文があると）、サポートされるクラスの合計は 64 になります。
Cisco IOS バージョン 12.2(12)、12.2(12)T、および 12.2(12)S では、256 グローバル クラスマップの制限が変更され、1024 までのグローバル クラスマップが設定でき、同一のポリシーマップで 256 のクラスマップが使えるようになっています。
Q. サービス ポリシーが適用されると、ルーティング アップデートと Point-to-Point Protocol（PPP）/High-Level Data Link Control（HDLC）キープアライブはどのように処理されるのですか。
A. Cisco IOS ルータは、次の 2 つのメカニズムで制御パケットの優先順位付けを行います。
IP precedence
pak_priority
どちらのメカニズムも、発信インターフェイスで輻輳が発生したときに、重要な制御パケットがルータやキューイング システムによってドロップ（廃棄）されないように、あるいは最後に廃棄されるような設計になっています。詳細は、『インターフェイス上での QoS サービス ポリシーによるルーティング アップデートと制御パケットのキューイング方法について』を参照してください。
分類とマーキング
Q. Quality of Service（QoS）の事前分類とは何ですか。
A. QoS の事前分類により、トンネル カプセル化あるいは暗号化（またはその両方）が適用されたパケットの元の IP ヘッダー コンテンツの照合と分類ができます。このドキュメントでは、Type of Service（TOS; タイプ オブ サービス）バイトの元の値を、元のパケット ヘッダーからトンネル ヘッダーへコピーするプロセスについては詳しく説明していません。詳細は、次のドキュメントを参照してください。
Q. パケット ヘッダーのどのフィールドに、再マーキングできますか。どんな値を使用できますか。
A. クラスベースのマーキング機能により、パケットのレイヤ 2、レイヤ 3、あるいは Multiprotocol Label Switching（MPLS）ヘッダーの設定またはマーキングができます。詳細は、次のドキュメントを参照してください。
Q. URL に基づいたトラフィックの優先順位付けができますか。
A. できます。Network Based Application Recognition（NBAR）を使用すれば、アプリケーション層でフィールドを照合してパケットを分類できます。NBAR が導入される以前、最も細かい分類は、レイヤ 4 の Transmission Control Protocol（TCP; 伝送制御プロトコル）と User Datagram Protocol（UDP; ユーザ データグラム プロトコル）のポート番号でした。詳細は、次のドキュメントを参照してください。
Q. Network Based Application Recognition（NBAR）は、どのプラットフォームと Cisco IOS ソフトウェアのバージョンでサポートされているのですか。
A. NBAR は次のバージョンの Cisco IOS ソフトウェアでサポートされています。
| プラットフォーム | Cisco IOS ソフトウェアの最低バージョン |
|---|---|
| 7200 | 12.1(5)T |
| 7100 | 12.1(5)T |
| 3660 | 12.1(5)T |
| 3640 | 12.1(5)T |
| 3620 | 12.1(5)T |
| 2600 | 12.1(5)T |
| 1700 | 12.2(2)T |
注：NBAR を使用するには、Cisco Express Forwarding（CEF; Cisco エクスプレス転送）を有効にする必要があります。
Distributed NBAR（DNBAR; 分散 NBAR）は、次のプラットフォームで使用できます。
| プラットフォーム | Cisco IOS ソフトウェアの最低バージョン |
|---|---|
| 7500 | 12.2(4)T、12.1(6)E |
| FlexWAN | 12.1(6)E |
注：NBAR は、Catalyst 6000 Multilayer Switch Feature Card（MSFC）の VLAN インターフェイス、Cisco 12000 シリーズ、あるいは、Catalyst 5000 シリーズ用 Route Switch Module（RSM）ではサポートされていません。上記のリストに見当たらないプラットフォームについては、Cisco の技術担当者にお問い合せください。
キューイングと輻輳管理
Q. キューイングの目的は何ですか。
A. キューイングは、ネットワーク デバイスのインターフェイスでの一時的な輻輳に対処する設計になっており、帯域幅が利用可能になるまで、過剰なパケットをバッファに保存します。Cisco IOS ルータでは、複数のキューイング方法をサポートし、異なるアプリケーションからのさまざまな帯域幅、ジッタ、および遅延に関する要求に対処しています。
ほとんどのインターフェイスに対するデフォルトの方式は、First In First Out（FIFO; 先入れ先出し）です。特定のトラフィック タイプでは、遅延/ジッタに関する要求がさらに厳しくなっています。このため、次に示す他のメカニズムのいずれかを設定するか、デフォルトで有効にします。
重み付け均等化キューイング（WFQ）
クラスベース重み付け均等化キューイング（CBWFQ）
Low Latency Queueing（LLQ）、これは実際には Priority Queue（PQ）による CBWFQ で、PQCBWFQ として知られています。
プライオリティ キューイング（PQ）
カスタム キューイング（CQ）
キューイングは、通常、発信インターフェイスだけで行われます。ルータでは、インターフェイスから発信されるパケットのキューイングが行われます。受信トラフィックのポリシングは可能ですが、通常、受信側のキューイングはできません。（例外として、入力インターフェイスから出力インターフェイスへパケットをフォワーディングするために distributed Cisco Express Forwarding（dCEF）を使っている Cisco 7500 シリーズ ルータでの受信側のバッファリングがあります。詳細は、『CPU 利用率 99 % で動作する VIP および Rx サイド バッファリングについて』を参照してください。）Cisco 7500 や 12000 シリーズなどのハイエンドの分散プラットフォームの受信インターフェイスでは、発信インターフェイスへスイッチされたトラフィックのうち超過したものを、受信インターフェイスのスイッチングの決定に従って、自身のパケット バッファに保存します。まれに、通常は受信インターフェイスから低速の発信インターフェイスへパケットが送られている場合、パケット メモリが使い尽くされると無視エラーが増加する場合があります。また、過度の輻輳によって出力キューの廃棄が引き起こされる場合があります。ほとんどの場合、入力キューの廃棄には、他に根本原因があります。廃棄をトラブルシューティングする場合の詳細は、次のドキュメントを参照してください。
詳細は、次のドキュメントを参照してください。
Q. Weighted Fair Queueing（WFQ; 重み付け均等化キューイング）と Class Based Weighted Fair Queueing（CBWFQ: クラスベース重み付け均等化キューイング）はどのように動作するのですか。
A. 均等化キューイングは、アクティブな会話間、あるいは、IP フロー間で、インターフェイスの帯域幅の均等な割り当てを試みます。パケットは会話識別番号で識別されてサブキューに分類されます。このとき、IP ヘッダーのフィールドやパケットの長さに基づいて、ハッシュ アルゴリズムが使用されます。重み付けは次のように計算されます。
W=K/(優先順位 +1)
K は、Cisco IOS 12.0(4)T 以前のリリースでは 4096、12.0(5)T 以降のリリースでは 32384 です。
重みが小さいほど、割り当てられる優先順位と帯域幅が高くなります。重みの他、パケットの長さも関係します。
CBWFQ を使用すると、トラフィックのクラスを定義でき、これを最小帯域幅の保証として割り当てることができます。このメカニズムの背後にあるアルゴリズムは、名前が表しているとおり、WFQ です。CBWFQ を設定するには、map-class 文で特定のクラスを定義します。次に、ポリシーマップを使って各クラスにポリシーを割り当てます。このポリシーマップをインターフェイスの発信側に割り当てます。詳細は、次のドキュメントを参照してください。
Q. Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）のあるクラスがその帯域幅を使っていない場合、他のクラスがその帯域幅を使用できるでしょうか。
A. できます。bandwidth と priority コマンドで提供される帯域幅保証は、説明では「reserved（予約済）」および「bandwidth to be set aside（確保される帯域幅）」と表現されていますが、どちらのコマンドでも実際に予約が実行されるわけではありません。つまり、トラフィック クラスに対して設定された帯域幅が使用されていない場合は、未使用の帯域幅すべてが他のクラスとの間で共有されます。
キューイング システムには、この規則に対する重要な例外が組み込まれており、それはプライオリティ クラスに関係しています。前述したように、プライオリティ クラスに与えられた負荷はトラフィック ポリサーによって測定されます。輻輳状態の間、プライオリティ クラスは超過帯域幅を使用できません。詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。
Q. Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）はサブインターフェイスでサポートされていますか。
A. Cisco IOS の論理インターフェイスでは本来、輻輳状態はサポートされておらず、キューイング方式を適用するサービス ポリシーの直接適用はサポートされていません。その代わりに、Generic Traffic Shaping（GTS; ジェネリック トラフィック シェーピング）またはクラスベース シェーピングのいずれかを使用して、サブインターフェイスにシェーピングを最初に適用する必要があります。詳細は、『イーサネット サブインターフェイスへの QoS 機能の適用』を参照してください。
Q. ポリシーマップでの priority 文と bandwidth 文との違いは何ですか。
A. priority と bandwidth コマンドでは機能、および通常にサポートするアプリケーションが異なっています。次の表では、これらの違いを要約しています。
| 機能 | bandwidth コマンド | priority コマンド |
|---|---|---|
| 最小帯域幅保証 | ○ | ○ |
| 最大帯域幅保証 | × | ○ |
| 組み込みポリサー | × | ○ |
| 低遅延 | × | ○ |
詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。
Q. FlexWAN と Versatile Interface Processors（VIP）では、キュー制限はどのように算出されるのですか。
A. VIP あるいは FlexWAN に十分な SRAM があると仮定して、250 バイトの平均パケット サイズでの最大遅延. 500 ミリ秒をもとに、キュー制限が算出されます。帯域幅が 1 Mbps のクラスの例を次に示します。
キュー制限値 = 1000000 / (250 x 8 x 2) = 250
より大きな数の Virtual Circuit（VC; 仮想回線）により使用可能なパケット メモリが減少するにつれて、小さなキュー制限が割り当てられます。
次の例では、Cisco 7600 シリーズ用として FlexWAN に PA-A3 が取り付けられ、2 MB の Permanent Virtual Circuit（PVC; 相手先固定接続）を持つ複数のサブインターフェイスをサポートしています。各 VC にはサービス ポリシーが適用されています。
class-map match-any XETRA-CLASS
match access-group 104
class-map match-any SNA-CLASS
match access-group 101
match access-group 102
match access-group 103
policy-map POLICY-2048Kbps
class XETRA-CLASS
bandwidth 320
class SNA-CLASS
bandwidth 512
interface ATM6/0/0
no ip address
no atm sonet ilmi-keepalive
no ATM ilmi-keepalive
!
interface ATM6/0/0.11 point-to-point
mtu 1578
bandwidth 2048
ip address 22.161.104.101 255.255.255.252
pvc ABCD
class-vc 2048Kbps-PVC
service-policy out POLICY-2048Kbps
Asynchronous Transfer Mode（ATM; 非同期転送モード）インターフェイスでは、インターフェイス全体に対してキュー制限が適用されます。この制限は、使用できるバッファ全体の機能、FlexWAN 上での物理インターフェイスの数、インターフェイスで許される最大キュー遅延です。各 PVC では、PVC の Sustained Cell Rate（SCR; 平均セルレート）または Minimum Cell Rate（MCR; 最小セルレート）に基づいてインターフェイスの制限の一部を適用しています。また、各クラスでは、帯域幅の割り当てに基づいて、PVC の制限の一部を適用しています。
3687 グローバル バッファ装備の FlexWAN では show policy-map interface コマンドによる出力例は次のようになります。この値を表示するには show buffer コマンドを発行します。2 つの Mbps PVC に、それぞれ 50 パケットが、2 つの Mbps の PVC 帯域幅に基づいて割り当てられています（2047/149760 x 3687 = 50）。各クラスには、次の出力で示されているように、50 のうちの一部が割り当てられています。
service-policy output: POLICY-2048Kbps
class-map: XETRA-CLASS (match-any)
687569 packets, 835743045 bytes
5 minute offered rate 48000 bps, drop rate 6000 BPS
match: access-group 104
687569 packets, 835743045 bytes
5 minute rate 48000 BPS
queue size 0, queue limit 7
packets output 687668, packet drops 22
tail/random drops 22, no buffer drops 0, other drops 0
bandwidth: kbps 320, weight 15
class-map: SNA-CLASS (match-any)
2719163 packets, 469699994 bytes
5 minute offered rate 14000 BPS, drop rate 0 BPS
match: access-group 101
1572388 packets, 229528571 bytes
5 minute rate 14000 BPS
match: access-group 102
1146056 packets, 239926212 bytes
5 minute rate 0 BPS
match: access-group 103
718 packets, 245211 bytes
5 minute rate 0 BPS
queue size 0, queue limit 12
packets output 2719227, packet drops 0
tail/random drops 0, no buffer drops 0, other drops 0
bandwidth: kbps 512, weight 25
queue-limit 100
class-map: class-default (match-any)
6526152 packets, 1302263701 bytes
5 minute offered rate 44000 BPS, drop rate 0 BPS
match: any
6526152 packets, 1302263701 bytes
5 minute rate 44000 BPS
queue size 0, queue limit 29
packets output 6526840, packet drops 259
tail/random drops 259, no buffer drops 0, other drops 0
トラフィック ストリームで大きなパケット サイズが使われている場合は、キュー制限に達する前にバッファを使い果たしてしまう可能性があるので、show policy-map インターフェイス コマンド出力では no buffer drops フィールドの値の増加が報告されることがあります。この場合は、手動で non-priority クラスのキュー制限を下方に調整してみてください。詳細は、『IP to ATM CoS に関する送信キュー制限について』を参照してください。
Q. キュー制限の値の確認はどのようにするのですか。
A. 非分散型プラットフォームでは、キュー制限はデフォルトで 64 パケットになっています。次の出力例は、Cisco 3600 シリーズ ルータで得られたものです。
november# show policy-map interface s0
Serial0
Service-policy output: policy1
Class-map: class1 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 BPS, drop rate 0 BPS
Match: ip precedence 5
Weighted Fair Queueing
Output Queue: Conversation 265
Bandwidth 30 (kbps) Max Threshold 64 (packets)
!--- Max Threshold はキュー制限値です。
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class2 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 BPS, drop rate 0 BPS
Match: ip precedence 2
Match: ip precedence 3
Weighted Fair Queueing
Output Queue: Conversation 266
Bandwidth 24 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 BPS, drop rate 0 BPS
Match: any
Q. クラス内で均等化キューイングを有効にできますか。
A. 分散 Quality of Service（QoS）を実装する Cisco 7500 シリーズでは、クラスごとの均等化キューイングがサポートされています。その他の Cisco 7200 シリーズや Cisco 2600/3600 シリーズなどのプラットフォームでは、class-default クラスで Weighted Fair Queueing（WFQ; 重み付け均等化キューイング）がサポートされ、全帯域幅のクラスが First In First Out（FIFO; 先入れ先出し）を使用しています。
Q. キューイングの監視にはどのコマンドを使いますか。
A. 次のコマンドを使って、キューイングを監視します。
show queue {インターフェイス}{インターフェイス番号}：Cisco 7500 シリーズ以外の Cisco IOS プラットフォームでは、このコマンドでアクティブなキューやカンバセーションを表示します。そのインターフェイスあるいは Virtual Circuit（VC; 仮想回線）で輻輳が発生していない場合、キューは表示されません。Cisco 7500 シリーズでは、show queue コマンドはサポートされていません。
show queueing interface interface-number [vc [[vpi/] vci]：このコマンドにより、インターフェイスや VC のキューイング統計情報が表示されます。輻輳が発生していない場合でも、いくつかのデータが表示されます。これは、プロセス交換されたパケットは、輻輳の有無に関係なく常にカウントされるからです。Cisco Express Forwarding（CEF; Cisco エクスプレス転送）およびファースト スイッチングされたパケットは輻輳が発生しない限り、カウントされません。Priority Queueing（PQ; プライオリティ キューイング）、Custom Queueing（CQ; カスタム キューイング）、および Weighted Fair Queueing（WFQ; 重み付け均等化キューイング）などの従来型のキューイング メカニズムの場合、分類の統計は作成されません。この統計情報は、12.0(5)T 以降のイメージにある modular Quality of Service Command Line Interface（MQC; モジュラ QoS コマンドライン インターフェイス）ベースの機能だけで作成できます。
show policy interface {インターフェイス}{インターフェイス番号}：カウンタ packets が、クラスの基準に合致したパケットの数をカウントします。このカウンタは、インターフェイスで輻輳が発生してしなくても増加します。カウンタ packets matched は、インターフェイスが輻輳した際の、クラスの基準に合致したパケットの数を表示します。パケット カウンタの詳細は、次のドキュメントを参照してください。
Cisco のクラスベースの QoS 設定と統計情報 MIB：ここでは Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）の監視機能について説明しています。
Q. RSVP は Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）と一緒に使用できますか。1 つのインターフェイスで Resource Reservation Protocol（RSVP; リソース予約プロトコル）と CBWFQ の両方が設定されると、RSVP と CBWFQ は互いに独立して機能します。そのため、各個が、それだけで実行されているのと動作は同じです。RSVP は、帯域幅のアベイラビリティ、評価、割り当てに関して CBWFQ が設定されていない場合と同様に動作します。
A. Cisco IOS ソフトウェア リリース 12.1(5)T 以降で RSVP と CBWFQ と使うと、ルータは、RSVP のフローと CBWFQ のクラスとが、加入過多を起こさずに、インターフェイスあるいは PVC 上での利用可能な帯域幅を共有するように動作できます。
IOS ソフトウェア リリース 12.2(1)T 以降では、RSVP は固有の「ip rsvp bandwidth」プールによるアドミッション制御を行うことができます。同時に、CBWFQ では RSVP パケットの分類、ポリシング、および、スケジューリングを行います。これは、送信者によりあらかじめマーキングされたパケットを前提にしています。さらに非 RSVP パケットは異なったマーキングがされているものとしています。
詳細は、『RSVP のスケーラビリティ改善』を参照してください。
輻輳回避 Weighted Random Early Detection（WRED; 重み付けランダム早期検出）
Q. Weighted Random Early Detection（WRED; 重み付けランダム早期検出）と Low Latency Queueing（LLQ; 低遅延キューイング）、あるいは、Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）を同時に有効にできますか。
A. できます。キューイングでは、キューから出るパケットの順序を定義します。つまり、パケットのスケジューリングのメカニズムを定義します。また、帯域幅の均等な割り当てや、最小帯域幅の保証にも使用されます。これとは対照的に、Request for Comments（RFC; コメント要求）2475 では、「特別なルールに基づいたパケットの廃棄処理」として、ドロッピングを定義しています。デフォルトの廃棄メカニズムはテール ドロップです。この場合、キューがいっぱいになると、インターフェイスがパケットを廃棄します。他の廃棄メカニズムとしては、Random Early Detection（RED; ランダム早期検出）と Cisco の WRED があります。このメカニズムでは、安定した平均的なキュー項目数を維持するために、キューがいっぱいになる前にランダムにパケットを廃棄し始めます。WRED では、廃棄の決定を行うために、パケットの IP 優先順位の値を使用します。詳細は、次のドキュメントを参照してください。
Q. Weighted Random Early Detection（WRED; 重み付けランダム早期検出）を監視して、実際の効果を確認するにはどうすればよいでしょう。
A. WRED は平均的なキュー項目数を監視し、算出値が最小しきい値を超えると、パケットの廃棄を開始します。次の例のように、show policy-map interface コマンドを発行して、mean queue depth の値を監視します。
Router# show policy interface s2/1
Serial2/1
output : p1
Class c1
Weighted Fair Queueing
Output Queue: Conversation 265
Bandwidth 20 (%)
(pkts matched/bytes matched) 168174/41370804
(pkts discards/bytes discards/tail drops) 20438/5027748/0
mean queue depth: 39
Dscp Random drop Tail drop Minimum Maximum Mark
(Prec) pkts/bytes pkts/bytes threshold threshold probability
0(0) 2362/581052 1996/491016 20 40 1/10
1 0/0 0/0 22 40 1/10
2 0/0 0/0 24 40 1/10
[output omitted]
ポリシングとシェーピング
Q. ポリシングとシェーピングの違いは何ですか。
A. 次の図は、その主な違いを示しています。トラフィック シェーピングでは、超過パケットはキューに保持され、一定の時間間隔でスケジュールされてから遅れて伝送されます。トラフィック シェーピングの結果、パケットの出力レートは平滑化されます。対照的に、トラフィック ポリシングは、バーストを伝搬します。トラフィック レートが最大レートの設定値に達すると、超過トラフィックが廃棄（またはマーキング）されます。その結果、出力レートは頂上と谷間のある鋸歯状になります。
詳細は、『ポリシングとシェーピングに関する概要』を参照してください。
Q. トークン バケットとは何で、そのアルゴリズムはどのように動作するのですか。
A. トークン バケット自体は廃棄ポリシーまたは優先順位ポリシーを持っていません。次の例では、トークン バケットというメタファの動作を示します。
トークンはある一定のレートでバケットに入れられます。
各トークンは、ある数のビットを送信するための発信元に対する権限に相当します。
パケットを送信するには、パケット サイズに相当する数のトークンをトラフィック レギュレータがバケットから削除できる必要があります。
パケットを送信するために十分なトークンがバケットにない場合は、バケットに十分な数のトークンが溜まるまで待機するか（シェーパの場合）、廃棄またはマークダウンされます（ポリサーの場合）。
バケットには指定されたキャパシティがあります。バケットがキャパシティに達すると、新しく着信したトークンは廃棄され、将来のパケット用に使用できません。したがって、どんな場合でも、発信元がネットワークに送信できる最大のバーストは、だいたい、バケットのサイズに比例します。トークン バケットは、バーストを許可しますが、制限があります。
Q. クラスベースのポリシングのようなトラフィック ポリサーがある場合、Committed Burst（BC）と Excess Burst（Be）は何を意味しており、どのようにしてこれらの値を選択すればよいのでしょうか。
A. トラフィック ポリサーは、シェーパのように過剰パケットをバッファリングして、後で送信するということは行いません。その代わり、ポリサーでは単純な送信を行います。また、バッファリングなしのポリシーの送信は行いません。バッファができないため、輻輳が発生している間にできる最善の方法は、大規模なバーストについて適切に設定することによって、パケットをやや控えめにドロップすることです。したがって、ポリサーでは、設定された Committed Information Rate（CIR; 認定情報レート）に達するために、通常のバースト値と大規模なバースト値を使用すると理解しておくことが大切です。
バーストのパラメータは、ルータの一般的なバッファリング規則に従って、簡単にモデル化されています。この規則では、輻輳時に全接続について現在の Transmission Control Protocol（TCP; 伝送制御プロトコル）ウィンドウを格納するために、バッファリングをラウンドトリップ時間のビットレートに等しく設定することを推奨しています。
次の表では、通常および大規模なバースト値の目的と、推奨される計算式を示します。
| バーストの パラメータ |
目的 | 推奨される計算式 |
|---|---|---|
| 通常のバースト |
|
CIR [BPS] * (1 byte)/(8 bits) * 1.5 seconds 注：通常のラウンド トリップ時間は 1.5 秒です。 |
| 大規模なバースト |
|
2 * normal burst |
すべてのプラットフォームで、ポリサーに同じ範囲の値を使用またはサポートしているとは限りません。使用しているプラットフォームでサポートされている値を調べるには、次のドキュメントを参照してください。
Q. Committed Access Rate（CAR; 専用アクセス レート）あるいはクラスベースのポリシングでは、パケットが Committed Information Rate（CIR; 認定情報レート）に適合しているか、あるいは超過しているかをどのようにして判断しているのですか。設定された CIR より適合レートが低い場合でも、ルータがパケットを廃棄して、超過レートが報告されます。
A. トラフィック ポリサーでは、設定された CIR に達したことを確認するのに、ノーマル バーストと拡張バーストの値を使っています。良好なスループットを得るには、十分に大きいバースト値を設定する必要があります。設定されているバースト値が小さすぎると、到達した値が設定された値より非常に小さくなる場合があります。一時的なバーストをなくすと、Transmission Control Protocol（TCP; 伝送制御プロトコル）のトラフィックのスループットに重大な悪影響を及ぼすことがあります。CAR により、show interface rate-limit コマンドを発行して、現在のバーストを監視し、表示された値が定常的に limit（BC）と extended limit（Be）の値に接近しているかどうかを判断してください。
rate-limit 256000 7500 7500 conform-action continue exceed-action drop
rate-limit 512000 7500 7500 conform-action continue exceed-action drop
router# show interfaces virtual-access 26 rate-limit
Virtual-Access26 Cable Customers
Input
matches: all traffic
params: 256000 BPS, 7500 limit, 7500 extended limit
conformed 2248 packets, 257557 bytes; action: continue
exceeded 35 packets, 22392 bytes; action: drop
last packet: 156ms ago, current burst: 0 bytes
last cleared 00:02:49 ago, conformed 12000 BPS, exceeded 1000 BPS
Output
matches: all traffic
params: 512000 BPS, 7500 limit, 7500 extended limit
conformed 3338 packets, 4115194 bytes; action: continue
exceeded 565 packets, 797648 bytes; action: drop
last packet: 188ms ago, current burst: 7392 bytes
last cleared 00:02:49 ago, conformed 194000 BPS, exceeded 37000 BPS
詳細は、次のドキュメントを参照してください。
Quality of Service（QoS）フレームリレー
Q. Committed Information Rate（CIR）、Committed Burst（BC）、Excess Burst（Be）、および Minimum CIR（MinCIR）にはどの値を選択すればよいのでしょう。
A. frame-relay traffic-shaping コマンドの発行により有効にされるフレームリレー トラフィック シェーピングは、いくつかの設定可能なパラメータをサポートしています。これらのパラメータには、frame-relay cir、frame-relay mincir、および、frame-relay BC があります。これらの値の選択、および関連する show コマンドについての詳細は、次のドキュメントを参照してください。
Q. フレームリレー メイン インターフェースのプライオリティ キューイングは Cisco IOS 12.1 で動作しますか。
A. フレームリレーのインターフェイスでは、インターフェイスのキューイング メカニズムと Virtual Circuit（VC; 仮想回線）ごとのキューイング メカニズムの両方をサポートしています。Cisco IOS 12.0(4)T では、Frame Relay Traffic Shaping（FRTS; フレームリレー トラフィック シェーピング）を設定した場合にだけ、.インターフェイス キューで First In First Out（FIFO; 先入れ先出し）または Per Interface Priority Queueing（PIPQ; インターフェイス単位プライオリティ キューイング）がサポートされます。したがって、Cisco IOS 12.1 にアップグレードした場合、次の設定は動作しません。
interface Serial0/0 frame-relay traffic-shaping bandwidth 256 no ip address encapsulation frame-relay IETF priority-group 1 ! interface Serial0/0.1 point-to-point bandwidth 128 ip address 136.238.91.214 255.255.255.252 no ip mroute-cache traffic-shape rate 128000 7936 7936 1000 traffic-shape adaptive 32000 frame-relay interface-dlci 200 IETF
FRTS が有効にされていない場合は、Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）などの他のキューイング方法を主インターフェイスに適用します。主インターフェイスは単一の帯域幅のパイプのように動作します。さらに、Cisco IOS 12.1.1(T) では、フレームリレーの主インターフェイスで、フレームリレーによる Permanent Virtual Circuit（PVC; 相手先固定接続）の Priority Interface Queueing（PIPQ; プライオリティ インターフェイス キューイング）を有効にできます。次の例に示すように、メイン インターフェイスで、高、中、ノーマル、および、低優先順位の PVC を定義でき、さらに、frame-relay interface-queue priority コマンドの発行ができます。
interface Serial3/0 description framerelay main interface no ip address encapsulation frame-relay no ip mroute-cache frame-relay traffic-shaping frame-relay interface-queue priority interface Serial3/0.103 point-to-point description frame-relay subinterface ip address 1.1.1.1 255.255.255.252 frame-relay interface-dlci 103 class frameclass map-class frame-relay frameclass frame-relay adaptive-shaping becn frame-relay cir 60800 frame-relay BC 7600 frame-relay be 22800 frame-relay mincir 8000 service-policy output queueingpolicy frame-relay interface-queue priority low
Q. Frame Relay Traffic Shaping（FRTS）は、Distributed Cisco Express Forwarding（dCEF）、および、Distributed Class Based Weighted Fair Queueing（dCBWFQ; 分散クラスベース重み付け均等化キューイング）と共存して動作しますか。
A. Cisco IOS 12.1(5)T までのところ、Cisco 7500 シリーズの VIP では分散バージョンの QoS 機能だけがサポートされています。フレームリレー インターフェイスでトラフィック シェーピングを有効にするには、Distributed Traffic Shaping（DTS; 分散トラフィック シェーピング）を使用します。詳細は、次のドキュメントを参照してください。
非同期転送モード（ATM）での QoS
Q. Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）と Low Latency Queueing（LLQ; 低遅延キューイング）によるサービス ポリシーは、Asynchronous Transfer Mode（ATM; 非同期転送モード）インターフェイスのどこに適用するのですか。
A. Cisco IOS 12.2 までのところ、ATM インターフェイスでは、サービス ポリシーを次の 3 段階の論理インターフェイスでサポートしています。これは、メイン インターフェイス、サブインターフェイス、および、Permanent Virtual Circuit（PVC; 相手先固定接続）です。ポリシーを適用する箇所は、有効にする QoS 機能によって決まります。キューイング ポリシーは、ATM インターフェイスが Virtual Circuit（VC; 仮想回線）単位に輻輳レベルを監視し、VC 単位で超過したパケットのためのキューを保持しているため、VC に適用します。詳細は、次のドキュメントを参照してください。
Q. IP to Asynchronous Transfer Mode（ATM）Class of Service（CoS）のキューイングでは、どのバイトがカウントされるのですか。
A. Class-Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）と Low Latency Queueing（LLQ; 低遅延キューイング）を有効にするためにサービス ポリシー内で設定される bandwidth コマンドと priority コマンドでは、それぞれに Kbps の値を使用します。これは、show interface コマンドの出力でカウントされているものと同じオーバーヘッド バイトをカウントする単位です。特にレイヤ 3 キューイングのシステムでは、Logical Link Control/Subnetwork Access Protocol（LLC/SNAP; 論理リンク制御/サブネットワーク アクセス プロトコル）をカウントしています。また、次の項目はカウントされません。
ATM アダプテーション レイヤ 5（AAL5）トレーラ
最後のセルを 48 バイトにするためのパディング
5 バイトのセル ヘッダー
Q. 1 つのサービス ポリシーは、同時にいくつの Virtual Circuits（VC; 仮想回線）でサポートできますか。
A. 次のドキュメントには、サポートできる Asynchronous Transfer Mode（ATM）VC の数に関しての役に立つガイドラインがあります。約 200 から 300 の VBR-nrt Permanent Virtual Circuits（PVC; 相手先固定接続）が問題なく展開されています。
次の項目も考慮してください。
処理能力の高いプロセッサを使用します。たとえば、VIP4-80 の性能は VIP2-50 に比べて大幅に優れています。
使用可能なパケット メモリの量。NPE-400 では、最大 32 MB（256MB のシステム内で）をパケット バッファ用に使用できます。NPE-200 の場合、128MB のシステムで最大 16 MB をパケット バッファ用に使用できます。
最大 200 の ATM PVC で同時に動作する VC 単位の Weighted Random Early Detection（WRED; 重み付けランダム早期検出）による設定が、広範囲に渡ってテストされています。VC 単位のキューに使用できる VIP2-50 のパケット メモリの量には限りがあります。たとえば、8MB の SRAM を持つ VIP2-50 では、WRED が動作する IP to ATM CoS の VC 単位のキューイングに、1085 のパケット バッファが用意されています。100 本の ATM PVC が設定され、すべての VCS で過度の輻輳が同時に発生すると（送信元に TCP のフロー制御が使用されていないテスト環境でシミュレート可能）、平均して各 PVC 当たり 10 パケット程度のバッファリングが行われます。これは WRED が正常に動作するには少なすぎる場合があります。したがって、大容量の SRAM を備えた VIP2-50 は、VC 単位の WRED を動作している大量の ATM PVC に同時に輻輳が発生する設計において使用することを推奨します。
アクティブな PVC が設定されている数が多いほど、Sustained Cell Rate（SCR; 平均セルレート）が少なくなる必要があり、したがって WRED が PVC で動作するために必要なキューも短くなります。このため、IP to ATM CoS フェーズ 1 機能のデフォルト WRED プロファイルを使用している場合も同様です。輻輳が発生している非常に多数の低速 ATM PVC に VC 単位の WRED がアクティブにされているときに、WRED の廃棄のしきい値を低く設定すると、VIP でのバッファ不足の恐れが最小限になります。VIP でのバッファの不足によって誤動作は生じません。VIP でバッファが不足した場合、IP to ATM CoS フェーズ 1 の機能は、そのバッファ不足の間は単純に First In First Out（FIFO; 先入れ先出し）のテール ドロップになります（つまり、PVC 上で IP to ATM CoS 機能がアクティブ化されていない場合、同じ廃棄ポリシーが発生します）。
同時にサポート可能な VCS の最大数。
Q. Class Based Weighted Fair Queueing（CBWFQ; クラスベース重み付け均等化キューイング）と Low Latency Queueing（LLQ; 低遅延キューイング）などの IP to ATM Class of Service（CoS）機能をサポートしている Asynchronous Transfer Mode（ATM; 非同期転送モード）ハードウェアはどれですか。
A. IP to ATM Class of Service（CoS）とは、Virtual Circuit（VC; 仮想回線）ごとに使用される一連の機能を意味します。この定義に従って、IP to ATM CoS は ATM Interface Processor（AIP; ATM インターフェイス プロセッサ）、PA-A1、または 4500 ATM ネットワーク プロセッサではサポートされていません。この ATM ハードウェアでは、PA-A3 やほとんどのネットワーク モジュール（ATM-25 以外）が定義している VC 単位のキューイングをサポートしていません。詳細は、次のドキュメントを参照してください。
音声と Quality of Service（QoS）
Q. Link Fragmentation and Interleaving（LFI）はどのように動作するのですか。
A. WAN 経由での File Transfer Protocol（FTP）転送のように、ネットワーク上に大きなパケットが流れている場合、Telnet や Voice over IP のような対話型トラフィックは遅延の増大に大きく影響されます。FTP のパケットが低速の WAN リンク上でキューされている場合は、対話型トラフィックのパケット遅延が大きく影響します。このため、大きなパケットをフラグメント化し、また小さなパケット（音声）を大きなパケット（FTP）の間にキューするなどの方法が考え出されています。Cisco IOS ルータでは、レイヤ 2 のフラグメント化メカニズムを 2 種類サポートしています。詳細は、次のドキュメントを参照してください。
Q. Voice over IP のパーフォーマンスを監視するのにはどのようなツールが使えますか。
A. Cisco では、現在、Cisco の Voice over IP ソリューシンを使ったネットワークでの Quality of Service（QoS）の監視にいくつかのオプションを提供しています。これらのソリューションでは、音声品質を計測するための Perceptual Speech Quality Measurement（PSQM）やその他の新しいアルゴリズムを使用する音声品質の計測は行いません。音声品質の計測には、Agilent（HP）および NetIQ によるツールを使用します。しかし、Cisco では、遅延、ジッタ、およびパケットの損失などを計測し、ユーザが使用している音声品質に関する概念を提供するツールを用意しています。詳細は、次のドキュメントを参照してください。
Q. %SW_MGR-3-CM_ERROR_FEATURE_CLASS: Connection Manager Feature Error: Class SSS: (QoS) - install error, ignore.
A. この機能インストール エラーは、無効な設定がテンプレートに適用された場合に発生する、予期された動作です。これは、矛盾があるために、サービス ポリシーが適用されなかったことを意味しています。通常、階層ポリシー マップの子ポリシーの class-default ではシェーピングを設定せず、インターフェイスの親ポリシーでシェーピングを設定します。そのため、トレースバックとともにこのメッセージが出力されます。
LNS の場合は、セッションを開始する時に RADIUS サーバを介してサービス ポリシーがプロビジョニングされるなどの、他の理由が考えられます。RADIUS サーバの設定を表示し、セッションの開始時やフラップ時に RADIUS サーバを介してインストールされた不適切なサービス ポリシーを確認するには、show tech コマンドを発行します。