サービス品質(QoS) : QoS ポリシング

QoS に関する FAQ

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2010 年 3 月 10 日) | 英語版 (2015 年 4 月 22 日) | フィードバック


目次


概要

このドキュメントでは Quality of Service(QoS)に関するよくある質問を取り扱っています。

一般

Q. Quality of Service(QOS)とは何ですか。

A. QOS とは、フレーム リレー、Asynchronous Transfer Mode(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(R) Ciscoルータのソフトウェア リリース 12.1(5)T によって導入される DiffServ 準拠性。 詳細は、次の文書を参照してください。

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

A. あるインターフェイスに制御できないほどのトラフィックが集中することを、輻輳といいます。 Quality of Service(QoS)は、まずネットワークの輻輳ポイントに適用する必要があります。 次の図は、典型的な輻輳ポイントの例です。

/image/gif/paws/22833/qos_faq1.gif

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

Q. MQC とは何ですか。

A. MQC とは、モジュラ 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 で、分散型 QoS 機能だけがサポートされています。 Distributed Cisco Express Forwarding(dCEF)をイネーブルにすると、分散型 QoS も自動的にイネーブルにされます。

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

Q. Quality of Service(QOS)ポリシーでは、どれくらいの数のクラスがサポートされますか。

A. 最大で 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 あるいは 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)ではサポートされていません。 上記のリストに含まれていないプラットフォームについては、シスコの技術担当者にお問い合せください。

キューイングと輻輳管理

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. はい。 bandwidthpriority コマンドで提供される帯域幅保証は、説明では「reserved(予約済)」および「bandwidth to be set aside(確保される帯域幅)」と表現されていますが、どちらのコマンドでも実際に予約が実行されるわけではありません。 つまり、トラフィック クラスに対して設定された帯域幅が使用されていない場合は、未使用の帯域幅すべてが他のクラスとの間で共有されます。

キューイング システムには、この規則に対する重要な例外が組み込まれており、それはプライオリティ クラスに関係しています。 前述したように、プライオリティ クラスに与えられた負荷はトラフィック ポリサーによって測定されます。 輻輳状態の間、プライオリティ クラスは超過帯域幅を使用できません。 詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。

Q. クラスベース重み付け均等化キューイング(CBWFQ)は、サブインターフェイスでもサポートされていますか。

A. Cisco IOS の論理インターフェイスでは、本質的な理由で輻輳状態をサポートせず、キューイング方法を適用するサービス ポリシーの直接的な適用もサポートしていません。 その代わりに、Generic Traffic Shaping(GTS; ジェネリック トラフィック シェーピング)またはクラスベース シェーピングのいずれかを使用して、サブインターフェイスにシェーピングを最初に適用する必要があります。 詳細は、『イーサネット サブインターフェイスへの QoS 機能の適用』を参照してください。

Q. ポリシーマップにおける priority 文と bandwidth 文の違いは何ですか。

A. prioritybandwidth コマンドでは機能、および通常にサポートするアプリケーションが異なっています。 次の表では、これらの違いを要約しています。

機能 bandwidth コマンド priority コマンド
最小帯域幅保証 はい はい
最大帯域幅保証 いいえ はい
組み込みポリサー いいえ はい
低遅延 いいえ はい

詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。

Q. FlexWAN および Versatile Interface Processor(VIP)でのキュー制限はどのように計算しますか。

A. キューの制限は、VIP または FlexWAN 上の十分な SRAM のサイズを推定し、最大遅延が 500 ミリ秒、平均的なパケット サイズが 250 バイトとして計算されます。 帯域幅が 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. キューイングの監視には、次のコマンドを使用します。

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 パケットは異なったマーキングがされているものとしています。

輻輳回避 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. 次の図は、その主な違いを示しています。 トラフィック シェーピングでは、超過パケットはキューに保持され、一定の時間間隔でスケジュールされてから遅れて伝送されます。 トラフィック シェーピングの結果、パケットの出力レートは平滑化されます。 対照的に、トラフィック ポリシングは、バーストを伝搬します。 トラフィック レートが最大レートの設定値に達すると、超過トラフィックが廃棄(またはマーキング)されます。 その結果、出力レートは頂上と谷間のある鋸歯状になります。

/image/gif/paws/22833/qos_faq2.gif

詳細は、『ポリシングとシェーピングに関する概要』を参照してください。

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 Information Rate(CIR; 認定情報レート)に適合または超過したことを、Committed Access Rate(CAR; 専用アクセス レート)またはクラスベース ポリシングではどのように判定しますか。 設定された 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. CIR、認定情報レート(CIR)、Committed Burst(BC)、Excess Burst(Be)、および最小 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. フレームリレー トラフィック シェーピング(FRTS)は、分散 Cisco Express Forwarding(dCEF)および 分散クラスベース均等化キューイング(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 ATM 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; 論理リンク制御/サブネットワーク アクセス プロトコル)をカウントしています。 また、次の項目はカウントされません。

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

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. どんな非同期転送モード(ATM)ハードウェアで、クラスベース重み付け均等化キューイング(CBWFQ)と低遅延キューイング(LLQ)を含む IP to ATM COS 機能をサポートしていますか。

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 単位のキューイングをサポートしていません。 詳細は、次のドキュメントを参照してください。

音声と Quality of Service(QoS)

Q. リンク フラグメンテーション アンド インターリービング(LFI)はどのように動作しますか。

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

Q. Voice over IP のパフォーマンスを監視するツールには何がありますか。

A. シスコでは、ネットワークの QOS の監視にシスコの Voice over IP ソリューションを使用するいくつかの方法を用意しています。 これらのソリューションでは、音声品質を計測するための 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 コマンドを発行します。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 22833