内容

はじめに

一般

分類およびマーキング

キューイングと輻輳管理

輻輳回避 Weighted Random Early Detection（WRED; 重み付けランダム早期検出）

ポリシングとシェーピング

Quality of Service（QoS）フレームリレー

非同期転送モード（ATM）での QoS

音声と Quality of Service（QoS）

関連情報

はじめに

このドキュメントでは、Quality of Service（QoS）に関して最もよく寄せられる質問（FAQ）について説明します。

一般

Q. 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 IOS® ソフトウェア リリース 12.1(5)T で DiffServ に準拠しました。詳細は、以下のドキュメントを参照してください。

- Cisco IOS 12.1 での統合サービス

- エンドツーエンドの QoS のための DiffServ の実装

- DSCP による QoS ポリシーの実装

Q.輻輳、遅延、ジッタとは何ですか。

A. あるインターフェイスに処理能力を超えたトラフィックが集中した状態が輻輳です。Quality of Service（QoS）は、まずネットワークの輻輳ポイントに適用する必要があります。次の図は、典型的な輻輳ポイントの例です。

ネットワークの輻輳によって、遅延が生じます。ネットワークとネットワーク上のデバイスで発生する遅延には何種類かあり、これは『パケット音声ネットワークでの遅延について』で説明されています。遅延のばらつきはジッタと呼ばれ、これは『パケット音声ネットワークでのジッタについて（Cisco IOS プラットフォーム）』で説明されています。 リアルタイムでインタラクティブなトラフィックをサポートするには、遅延とジッタの両方を制御し、最小化する必要があります。

Q. MQCとは何ですか。

A. MQCとはModular Quality of Service(QoS)Command Line Interface（CLI；コマンドラインインターフェイス）の略です。 この機能は、共通のコマンド構文を定義したり、プラットフォーム間での一連の QoS の動作を設定したりすることで、シスコのルータやスイッチでの QoS 設定を簡単にできるように設計されています。QoS およびプラットフォームごとに構文が異なっていた以前のモデルは、このモデルに置き換えられます。

MQC には、次の 3 つのステップが含まれます。

1. class-map コマンドでトラフィック クラスを定義する。

2. policy-map コマンドで 1 つあるいは複数の QoS 機能をトラフィック クラスに関連付け、トラフィック ポリシーを作成する。

3. 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でサポートされているのは、分散型のQuality of Service(QoS)機能だけです。Distributed Cisco Express Forwarding（dCEF）をイネーブルにすると、分散型 QoS も自動的にイネーブルにされます。

従来型の Interface Processor（IP; インターフェイス プロセッサ）などの非 VIP インターフェイスでは、主要な QoS 機能は Route Switch Processor（RSP）でサポートされています。 詳細は、以下のドキュメントを参照してください。

- 分散型クラスベースの重み付け均等化キューイングと分散型重み付けランダム早期検出

- 分散型低遅延キューイング

- 分散型トラフィック シェーピング

- Versatile Interface Processor ベースの Cisco IOS リリース 12.1 T 用分散型 FRF.11 および FRF.12

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)は、Integrated Routing and Bridging(IRB)が設定されたインターフェイスでサポートされていますか。

A. いいえ。インターフェイスが IRB 用に設定されている場合、QoS 機能を設定することはできません。

分類およびマーキング

Q. Quality of Service(QoS)の事前分類とはどのようなものですか。

A. QoSの事前分類により、トンネルカプセル化や暗号化が適用されたパケットの元のIPヘッダーコンテンツの照合と分類ができます。この文書では、Type of Service（TOS; タイプ オブ サービス）バイトの元の値を、元のパケット ヘッダーからトンネル ヘッダーへコピーするプロセスについては詳しく説明していません。詳細は、以下のドキュメントを参照してください。

- 仮想私設ネットワーク向けの QoS の設定

- 仮想私設ネットワーク向けの QoS、12.2(2)T 機能モジュール

Q.パケットヘッダーのどのフィールドに、再マーキングできますか。どんな値がありますか。

A. クラスベースのマーキング機能により、パケットのレイヤ2、レイヤ3、またはMultiprotocol Label Switching（MPLS；マルチプロトコルラベルスイッチング）ヘッダーの設定やマーキングができます。詳細は、以下のドキュメントを参照してください。

- クラスベースのパケット マーキングの設定

- ルータが ATM セルの CLP ビットを設定するのはいつですか

- フレーム リレー PVC へのパケット マーキングの設定

Q. URLに基づいてトラフィックに優先順位を付けることはできますか。

A. あります。Network Based Application Recognition（NBAR）を使用すれば、アプリケーション層でフィールドを照合してパケットを分類できます。NBAR が導入される以前、最も細かい分類は、レイヤ 4 の Transmission Control Protocol（TCP; 伝送制御プロトコル）と User Datagram Protocol（UDP; ユーザ データグラム プロトコル）のポート番号でした。詳細は、以下のドキュメントを参照してください。

- ネットワークベースのアプリケーション認識に関する Q&A

- NBAR アプリケーション ネットワーキング

- ネットワークの入口で「Code Red」ワームをブロックするためのネットワークベースのアプリケーション認識 （NBAR）および アクセス制御リスト（ACL） の使用方法

- Nimda ウイルスからネットワークを保護する方法

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 シリーズなどのハイエンドの分散プラットフォームの受信インターフェイスでは、発信インターフェイスへスイッチされたトラフィックのうち超過したものを、受信インターフェイスのスイッチングの決定に従って、自身のパケット バッファに保存します。まれに、通常は受信インターフェイスから低速の発信インターフェイスへパケットが送られている場合、パケット メモリが使い尽くされると無視エラーが増加する場合があります。過度の輻輳によって出力キューの廃棄が引き起こされる場合があります。ほとんどの場合、入力キューの廃棄には、他に根本原因があります。廃棄をトラブルシューティングする場合の詳細は、次の文書を参照してください。

- 入力キュー廃棄と出力キュー廃棄に関するトラブルシューティング

詳細は、以下のドキュメントを参照してください。

- ATM ポート アダプタでの「Ignored」エラーのトラブルシューティング

- Cisco 12000 シリーズ インターネット ルータでの Ignored エラーとメモリ不足による廃棄のトラブルシューティング

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 文で特定のクラスを定義します。次に、ポリシーマップを使って各クラスにポリシーを割り当てます。このポリシーマップをインターフェイスの発信側に割り当てます。詳細は、以下のドキュメントを参照してください。

- ATM でのクラスベース重み付け均等化キューイングについて

- ATM での均等化キューイングについて

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

最大帯域幅保証

いいえ

Yes

組み込みポリサー

いいえ

Yes

低遅延

いいえ

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-2048Kbps

Asynchronous 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 は、インターフェイスが輻輳した際の、クラスの基準に合致したパケットの数を表示します。パケット カウンタの詳細は、次の文書を参照してください。

show policy-map interface 出力内のパケット カウンタについて

- シスコ のクラスベースの 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および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 よりも大きい場合は、トークンの借用も可能）。

- トークン バケットの大きさを決定する。バケットがいっぱいになってキャパシティに達した場合、新しく着信したトークンは廃棄され、将来のパケットで使用できないため。

CIR [BPS] *

(1 byte)/(8 bits) *

1.5 seconds

注：一般的なラウンドトリップ時間は1.5秒です。

大規模なバースト

- 大規模なバースト用の機能を持つトークン バケットを構築する。

- 設定を BC = Be とすることで無効になる。

- BC が Be と等しければ、トラフィック レギュレータはトークンを借用できず、トークンが不足した場合は、パケットが廃棄されるだけです。

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

詳細は、以下のドキュメントを参照してください。

- ポリシングとシェーピングに関する概要

- Catalyst 6000 での QoS ポリシング

- Catalyst 4000 での QoS に関する FAQ

- Catalyst G-L3 シリーズ スイッチと WS-X4232-L3 レイヤ 3 モジュール QoS に関する FAQ

Q.バーストとキュー制限は互いに独立していますか。

A. はい、ポリサーバーストとキュー制限は分離されており、互いに独立しています。ポリサーは特定の数のパケット（またはバイト）が許可されるゲート、キューはネットワークに送信される前に認められた数のパケットが保持される、キュー制限というサイズのバケットと考えることができます。バケットは、ゲート（ポリサー）によって認められたバイト/パケットのバーストを十分保持できるサイズであることが理想的です。

Quality of Service（QoS）フレームリレー

Q. Committed Information Rate（CIR；認定情報レート）、Committed Burst（BC；認定バースト）、Excess Burst（Be；超過バースト）、およびMinimum CIR（MinCIR；最小CIR）にはどの値を選択すればよいのですか。

A. フレームリレートラフィックシェーピングは、frame-relay traffic-shapingコマンドの発行によってイネーブルにされますが、いくつかの設定可能なパラメータをサポートしています。これらのパラメータには、frame-relay cir、frame-relay mincir、および frame-relay BC があります。これらの値の選択、および関連する show コマンドについての詳細は、次のドキュメントを参照してください。

- 7200 ルータおよび下位プラットフォームでのフレーム リレー トラフィック シェーピングの設定

- フレームリレー トラフィック シェーピングのための show コマンド

- QoS（フラグメンテーション、トラフィック シェーピング、IP RTP プライオリティ）を使用した VoIP over Frame Relay

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.フレームリレートラフィックシェーピング(FRTS)は、Distributed Cisco Express Forwarding(dCEF)および分散クラスベース重み付け均等化キューイング(dCBWFQ)と連動しますか。

A. Cisco IOS 12.1(5)Tの時点では、Cisco 7500シリーズのVIPでは分散バージョンのQoS機能だけがサポートされています。フレームリレー インターフェイスでトラフィック シェーピングを有効にするには、Distributed Traffic Shaping（DTS; 分散トラフィック シェーピング）を使用します。 詳細は、以下のドキュメントを参照してください。

- Versatile Interface Processor ベースの Cisco IOS リリース 12.1 T 用分散型 FRF.11 および FRF.12

- Cisco 7500 シリーズでの分散型 QoS を使用したフレームリレーのトラフィック シェーピング

非同期転送モード（ATM）での QoS

Q.クラスベース重み付け均等化キューイング(CBWFQ)と低遅延キューイング(LLQ)によるサービスポリシーは、非同期転送モード(ATM)インターフェイスのどこに適用するのですか。

A. Cisco IOS 12.2の段階で、ATMインターフェイスでは、メインインターフェイス、サブインターフェイス、およびPermanent Virtual Circuit（PVC；相手先固定接続）の3つのレベル、つまり論理インターフェイスでのサービスポリシーがサポートされています。 ポリシーを適用する箇所は、有効にする QoS 機能によって決まります。キューイング ポリシーは、ATM インターフェイスが Virtual Circuit（VC; 仮想回線）単位に輻輳レベルを監視し、VC 単位で超過したパケットのためのキューを保持しているため、VC に適用します。詳細は、以下のドキュメントを参照してください。

- ATM インターフェイスで QOS サービス ポリシーを適用する箇所はどこですか。

- PA-A3 および NM-1A ATM インターフェイスでの 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 バイトのセル ヘッダー

- IP to ATM CoS キューイングでカウントされるバイト

Q. 1つのサービスポリシーを同時にサポートできる仮想回線(VC)の数はいくつですか。

A. 次の文書には、サポートできるAsynchronous Transfer Mode（ATM；非同期転送モード）VCの数に関しての役に立つガイドラインがあります。約 200 から 300 の VBR-nrt Permanent Virtual Circuits（PVC; 相手先固定接続）が問題なく展開されています。

- IP to ATM Class of Service Design Guide

次の項目も考慮してください。

- 処理能力の高いプロセッサを使用します。たとえば、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 COsとは、Virtual Circuit（VC；仮想回線）単位でイネーブルにされている一連の機能のことです。この定義に従って、IP to ATM CoS は ATM Interface Processor（AIP; ATM インターフェイス プロセッサ）、PA-A1、または 4500 ATM ネットワーク プロセッサではサポートされていません。この ATM ハードウェアでは、PA-A3 やほとんどのネットワーク モジュール（ATM-25 以外）が定義している VC 単位のキューイングをサポートしていません。詳細は、次のドキュメントを参照してください。

- ATM ハードウェアでの IP to ATM CoS のサポートについて

- RSP ベースのプラットフォームでの、VC 単位、クラスベースの重み付け均等化キューイング

- Cisco 7200、3600、および 2600 ルータでの、VC 単位、クラスベースの重み付け均等化キューイング（Per-VC CBWFQ）

- PA-A3-8T1/E1 IMA ATM ポート アダプタでの VC 単位のキューイング

- MC3810 での VC 単位の ATM キューイング

音声と Quality of Service（QoS）

Q. Link Fragmentation and Interleaving(LFI)はどのように動作するのですか。

A. WAN経由でのFile Transfer Protocol（FTP；ファイル転送プロトコル）転送のように、ネットワーク上に大きなパケットが流れている場合、TelnetやVoice over IP(VoIP)などの対話型トラフィックは遅延の増大に大きく影響されます。FTP のパケットが低速の WAN リンク上でキューされている場合は、対話型トラフィックのパケット遅延が大きく影響します。このため、大きなパケットをフラグメント化し、また小さなパケット（音声）を大きなパケット（FTP）の間にキューするなどの方法が考え出されています。Cisco IOS ルータでは、レイヤ 2 のフラグメント化メカニズムを 2 種類サポートしています。詳細は、以下のドキュメントを参照してください。

- リンクの効率化メカニズムの概要

- QoS（フラグメンテーション、トラフィック シェーピング、IP RTP プライオリティ）を使用した VoIP over Frame Relay

- QoS を実装した PPP リンク上での VoIP（LLQ/IP RTP プライオリティ、LFI、cRTP）

Q. Voice over IPのパフォーマンスを監視するには、どのようなツールを使用できますか。

A. シスコでは現在、シスコのVoice over IPソリューションを使用して、ネットワークの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：接続マネージャの機能エラー：クラスSSS:(QoS) – インストールエラー。無視します。

A. 表示される機能インストールエラーは、テンプレートに無効な設定が適用された場合の予期される動作です。これは、矛盾があるために、サービス ポリシーが適用されなかったことを意味しています。通常、階層ポリシー マップの子ポリシーの class-default ではシェーピングを設定せず、インターフェイスの親ポリシーでシェーピングを設定します。そのため、トレースバックとともにこのメッセージが出力されます。

セッション ベースのポリシーの場合、class-default でのシェーピングはサブインターフェイスまたは PVC のレベルでのみ実行する必要があります。物理インターフェイスでのシェーピングは、サポートされていません。設定を物理インターフェイス上で実行したのであれば、このエラー メッセージの発生は予想される動作です。

LNS の場合は、セッションを開始する時に RADIUS サーバを介してサービス ポリシーがプロビジョニングされるなどの、他の理由が考えられます。RADIUS サーバの設定を表示し、セッションの開始時やフラップ時に RADIUS サーバを介してインストールされた不適切なサービス ポリシーを確認するには、show tech コマンドを発行します。

関連情報

- パフォーマンス チューニングの基本

- Quality of Service（QOS）に関するサポート ページ

- テクニカル サポートとドキュメント - Cisco Systems