内容
概要
このドキュメントでは、Quality of Service（QoS）に関して最もよく寄せられる質問（FAQ）について説明します。
全般
Q. Quality of Service(QoS)とは何ですか。
A. QoSとは、フレームリレー、非同期転送モード(ATM)、イーサネットおよび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 IOS® ソフトウェア リリース 12.1(5)T で DiffServ に準拠しました。詳細は、以下のドキュメントを参照してください。
Q.輻輳、遅延、ジッタとは何ですか。
A.インターフェイスで処理できるトラフィックの量を超えるトラフィックが発生すると、輻輳が発生します。Quality of Service（QoS）は、まずネットワークの輻輳ポイントに適用する必要があります。次の図は、典型的な輻輳ポイントの例です。
ネットワークの輻輳によって、遅延が生じます。ネットワークとネットワーク上のデバイスで発生する遅延には何種類かあり、これは『パケット音声ネットワークでの遅延について』で説明されています。遅延のばらつきはジッタと呼ばれ、これは『パケット音声ネットワークでのジッタについて（Cisco IOS プラットフォーム）』で説明されています。 リアルタイムでインタラクティブなトラフィックをサポートするには、遅延とジッタの両方を制御し、最小化する必要があります。
Q. MQCとは何ですか。
A. MQCは、モジュラQuality of Service(QoS)コマンドラインインターフェイス(CLI)を意味します。 この機能は、共通のコマンド構文を定義したり、プラットフォーム間での一連の QoS の動作を設定したりすることで、シスコのルータやスイッチでの 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.サービスポリシーの適用時に、ルーティングアップデートとポイントツーポイントプロトコル(PPP)/ハイレベルデータリンクコントロール(HDLC)キープアライブはどのように処理されるのですか。
A. Cisco IOSルータは、制御パケットの優先順位付けのために次の2つのメカニズムを使用します。
IP precedence
pak_priority
どちらのメカニズムも、主要な制御パケットがドロップされないこと、あるいは発信インターフェイスで輻輳が発生している場合はルータやキューイング システムによって最後にドロップされることを確実にするよう設計されています。詳細は、『インターフェイス上での QoS サービス ポリシーによるルーティング アップデートと制御パケットのキューイング方法について』を参照してください。
Q. Quality of Service(QoS)は、Integrated Routing and Bridging(IRB)が設定されたインターフェイスでサポートされていますか。
A.いいえ。インターフェイスがIRB用に設定されている場合は、QoS機能を設定できません。
分類およびマーキング
Q. Quality of Service(QoS)事前分類とは何ですか。
A. QoS事前分類を使用すると、トンネルのカプセル化や暗号化を行うパケットの元のIPヘッダーの内容を照合して分類できます。この文書では、Type of Service（TOS; タイプ オブ サービス）バイトの元の値を、元のパケット ヘッダーからトンネル ヘッダーへコピーするプロセスについては詳しく説明していません。詳細は、以下のドキュメントを参照してください。
Q.どのパケットヘッダーフィールドに再マーキングできますか。どんな値がありますか。
A.クラスベースマーキング機能を使用すると、パケットのレイヤ2、レイヤ3、またはマルチプロトコルラベルスイッチング(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ソフトウェアで導入されています。
Platform 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)を有効にする必要があります。
Distributed NBAR（DNBAR; 分散 NBAR）は、次のプラットフォームで使用できます。
Platform Cisco IOS ソフトウェアの最低バージョン 7500 12.2(4)T、12.1(6)E FlexWAN 12.1(6)E 注：NBARは、Catalyst 6000マルチレイヤスイッチフィーチャカード(MSFC)VLANインターフェイス、Cisco 12000シリーズ、またはCatalyst 5000シリーズのルートスイッチモジュール(RSM)ではサポートされません。上記のリストに含まれていないプラットフォームについては、シスコの技術担当者にお問い合せください。
キューイングと輻輳管理
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.重み付け均等化キューイング(WFQ)とクラスベース重み付け均等化キューイング(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.クラスベース重み付け均等化キューイング(CBWFQ)はサブインターフェイスでサポートされていますか。
A. Cisco IOS論理インターフェイスは、本質的に輻輳状態をサポートしておらず、キューイング方式を適用するサービスポリシーの直接適用もサポートしていません。その代わりに、Generic Traffic Shaping（GTS; ジェネリック トラフィック シェーピング）またはクラスベース シェーピングのいずれかを使用して、サブインターフェイスにシェーピングを最初に適用する必要があります。詳細は、『イーサネット サブインターフェイスへの QoS 機能の適用』を参照してください。
Q.ポリシーマップのpriority文とbandwidth文書の違いは何ですか。
A. priorityコマンドとbandwidthコマンドは、機能と一般的にサポートされるアプリケーションの両方で異なります。次の表では、これらの違いを要約しています。
機能 bandwidth コマンド priority コマンド 最小帯域幅保証 Yes Yes 最大帯域幅保証 No Yes 組み込みポリサー No Yes 低遅延 No Yes 詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。
Q. FlexWANおよびVersatile Interface Processor(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-2048KbpsAsynchronous Transfer Mode（ATM; 非同期転送モード）インターフェイスでは、インターフェイス全体に対してキュー制限が適用されます。この制限は、使用できるバッファ全体の機能、FlexWAN 上での物理インターフェイスの数、インターフェイスで許される最大キュー遅延です。各 PVC では、PVC の Sustained Cell Rate（SCR; 平均セルレート）または Minimum Cell Rate（MCR; 最小セルレート）に基づいてインターフェイスの制限の一部を適用しています。また、各クラスでは、帯域幅の割り当てに基づいて、PVC の制限の一部を適用しています。
次に示す show policy-map interface コマンドの出力例は、3687 グローバル バッファを備えた FlexWAN から得たものです。この値を表示するには 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 での ATM CoS に対する送信キュー制限について』を参照してください。
Q. queue-limit値を確認するにはどうすればよいのですか。
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 is the queue-limit. (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 matched は、インターフェイスが輻輳した際の、クラスの基準に合致したパケットの数を表示します。パケット カウンタの詳細は、次の文書を参照してください。
シスコ のクラスベースの QoS 設定と統計情報 MIB - ここでは Simple Network Management Protocol（SNMP; 簡易ネットワーク管理プロトコル）の監視機能について説明しています。
Q. RSVPは、クラスベース重み付け均等化キューイング(CBWFQ)と組み合わせて使用できます。 1 つのインターフェイスで Resource Reservation Protocol（RSVP; リソース予約プロトコル）と CBWFQ の両方が設定されると、RSVP と CBWFQ は互いに独立して機能します。そのため、各個が、それだけで実行されているのと動作は同じです。RSVP は、帯域幅のアベイラビリティ、評価、割り当てに関して CBWFQ が設定されていない場合と同様に動作します。
A. Cisco IOSソフトウェアリリース12.1(5)T以降でRSVPおよびCB-WFQを使用する場合、ルータはRSVPフローとCBWFQクラスがオーバーサブスクリプションなしでインターフェイスまたはPVCで使用可能な帯域幅を共有するように動作できます。
IOS ソフトウェア リリース 12.2(1)T 以降では、RSVP は固有の「ip rsvp bandwidth」プールによるアドミッション制御を行うことができます。同時に、CBWFQ では 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; ランダム早期検出）とシスコの WRED があります。このメカニズムでは、安定した平均的なキュー項目数を維持するために、キューがいっぱいになる前にランダムにパケットを廃棄し始めます。WRED では、廃棄の決定を行うために、パケットの IP 優先順位の値を使用します。詳細は、『重み付けランダム早期検出（WRED）』を参照してください。
Q. Weighted Random Early Detection（WRED；重み付けランダム早期検出）を監視して、実際に有効になっていることを確認するにはどうすればよいのですか。
A. WREDは平均キュー項目数を監視し、計算値が最小しきい値を超えるとパケットの廃棄を開始します。show policy-map interfacee コマンドを実行し、次の例で示すように 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; 伝送制御プロトコル）ウィンドウを格納するために、バッファリングをラウンドトリップ時間のビットレートに等しく設定することを推奨しています。
次の表では、通常および大規模なバースト値の目的と、推奨される計算式を示します。
バーストのパラメータ 目的 推奨される計算式 通常のバースト
標準のトークン バケットを実装する。
トークン バケットの最大サイズを設定する（ただし、Be が BC よりも大きい場合は、トークンの借用も可能）。
トークン バケットの大きさを決定する。バケットがいっぱいになってキャパシティに達した場合、新しく着信したトークンは廃棄され、将来のパケットで使用できないため。
注：1秒5は通常のラウンドトリップ時間です。
大規模なバースト
大規模なバースト用の機能を持つトークン バケットを構築する。
設定を BC = Be とすることで無効になる。
BC が Be と等しければ、トラフィック レギュレータはトークンを借用できず、トークンが不足した場合は、パケットが廃棄されるだけです。
すべてのプラットフォームで、ポリサーに同じ範囲の値を使用またはサポートしているとは限りません。使用しているプラットフォームでサポートされている値を調べるには、次の文書を参照してください。
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詳細は、以下のドキュメントを参照してください。
Q.バーストとキュー制限は互いに独立していますか。
A.はいえ、ポリサーバーストとキュー制限は分離されており、相互に独立しています。ポリサーは特定の数のパケット（またはバイト）が許可されるゲート、キューはネットワークに送信される前に認められた数のパケットが保持される、キュー制限というサイズのバケットと考えることができます。バケットは、ゲート（ポリサー）によって認められたバイト/パケットのバーストを十分保持できるサイズであることが理想的です。
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 IETFFRTS が有効にされていない場合は、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.クラスベース重み付け均等化キューイング(CBWFQ)および低遅延キューイング(LLQ)を使用したサービスポリシーを、非同期転送モード(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コマンドは、show interfaceコマンドの出力でカウントされる値と同バイトを数Kbps値でカウントします。特にレイヤ 3 キューイングのシステムでは、Logical Link Control/Subnetwork Access Protocol（LLC/SNAP; 論理リンク制御/サブネットワーク アクセス プロトコル）をカウントしています。 また、次の項目はカウントされません。
ATM アダプテーション レイヤ 5（AAL5）トレーラー
最後のセルを 48 バイトの偶数倍にするためのパディング
5 バイトのセル ヘッダー
Q. 1つのサービスポリシーを同時にサポートできる仮想回線(VCS)はいくつですか。
A.次のドキュメントでは、サポート可能な非同期転送モード(ATM)VCSの数に関する有用なガイドラインを示します。約 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.クラスベース重み付け均等化キューイング(CBWFQ)および低遅延キューイング(LLQ)を含むIP to ATM Class of Service(COs)機能をサポートする非同期転送モード(ATM)ハードウェアはどれですか。
A. IP to ATM COは、仮想回線(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. TelnetやVoice over IPなどの対話型トラフィックは、ネットワークがWAN経由のファイル転送プロトコル(FTP)転送などの大きなパケットを処理する際に、遅延が増大する可能性があります。FTP のパケットが低速の WAN リンク上でキューされている場合は、対話型トラフィックのパケット遅延が大きく影響します。このため、大きなパケットをフラグメント化し、また小さなパケット（音声）を大きなパケット（FTP）の間にキューするなどの方法が考え出されています。Cisco IOS ルータでは、レイヤ 2 のフラグメント化メカニズムを 2 種類サポートしています。詳細は、以下のドキュメントを参照してください。
Q. Voice over IP(VoIP)のパフォーマンスを監視するには、どのようなツールを使用できますか。
A.シスコは現在、シスコのVoice over IP(VoIP)ソリューションを使用してネットワークのQuality of Service(QoS)を監視するためのオプションをいくつか提供しています。これらのソリューションでは、音声品質を計測するための Perceptual Speech Quality Measurement（PSQM）やその他の新しいアルゴリズムを使用する音声品質の計測は行いません。音声品質の計測には、Agilent（HP）および NetIQ によるツールを使用します。しかし、シスコでは、遅延、ジッタ、およびパケットの損失などを計測し、ユーザが使用している音声品質に関する概念を提供するツールを用意しています。詳細は、『Cisco サービス保証エージェントとインターネットワーク パフォーマンス モニタを使用した Voice over IP ネットワークの QoS 管理』を参照してください。
Q.%SW_MGR-3-CM_ERROR_FEATURE_CLASS:Connection Manager Feature Error:Class SSS:(QoS) - install error, ignore.
A.表示される機能インストールエラーは、無効な構成がテンプレートに適用された場合の予期される動作です。これは、矛盾があるために、サービス ポリシーが適用されなかったことを意味しています。通常、階層ポリシー マップの子ポリシーの class-default ではシェーピングを設定せず、インターフェイスの親ポリシーでシェーピングを設定します。そのため、トレースバックとともにこのメッセージが出力されます。
セッション ベースのポリシーの場合、class-default でのシェーピングはサブインターフェイスまたは PVC のレベルでのみ実行する必要があります。物理インターフェイスでのシェーピングは、サポートされていません。設定を物理インターフェイス上で実行したのであれば、このエラー メッセージの発生は予想される動作です。
LNS の場合は、セッションを開始する時に RADIUS サーバを介してサービス ポリシーがプロビジョニングされるなどの、他の理由が考えられます。RADIUS サーバの設定を表示し、セッションの開始時やフラップ時に RADIUS サーバを介してインストールされた不適切なサービス ポリシーを確認するには、show tech コマンドを発行します。