サービス品質(QoS) : QoS 輻輳管理(キューイング)

インターフェイス上での QoS サービス ポリシーによるルーティング アップデートとレイヤ 2 制御パケットのキューイング方法について

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2009 年 1 月 14 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントでは、Modular Quality of Service Command Line Interface(MQC; モジュラ QoS コマンドライン インターフェイス)のコマンドを使用して発信ルータ インターフェイスにサービス ポリシーを設定した場合に、hello や Database Descriptor(DBD)などのルーティング プロトコル メッセージや、その他の重要な制御トラフィックがどのようにキューイングされるかについて説明しています。

具体的には、このドキュメントリビュー Cisco IOS によって使用されるこれら二つのメカニズムか。 制御パケットに優先順位をつけるルータ:

フィールド 場所 プライオリティ適用箇所
IP Precedence ビット IP ヘッダー内の Type of service(TOS; タイプ オブ サービス)バイト ネットワークを介してプライオリティを提供
pak_priority インターフェイス ドライバによって割り当てられた、ルータ内の内部パケット ラベル ルータを介してプライオリティを提供(per-hop)

どちらのメカニズムも、発信インターフェイスで輻輳が発生したときに、重要な制御パケットがルータやキューイング システムによってドロップ(廃棄)されないように、あるいは最後に廃棄されるような設計になっています。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、Cisco IOS ソフトウェア リリース 12.2 に基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

外部パケットのプライオリティ タグ

Request for Comments(RFC)791 では、IP パケットのヘッダー内の TOS バイトが定義されています。leavingcisco.com RFC 2474RFC 2475 では、このバイトは Differentiated Services Code Point(DSCP; DiffServ コード ポイント)として再定義されていますが、Cisco IOS ルータでは依然として RFC 791 による TOS バイトのオリジナル IP precedence ビットが使用されています。leavingcisco.com leavingcisco.com RFC では TOS バイトがどのように定義されているかを次に説明します。

「TOS では、必要な QoS の抽象的なパラメータの通知が提供されます。 これらのパラメータは、特定のネットワークを介してデータグラムを送信する際に、実際のサービス パラメータの選択をガイドするために使用されます。 いくつかのネットワークでは、サービスの優先順位が提供されます。このサービスの優先順位では、何らかの方法(一般的には、高負荷時に一定の優先順位以上のトラフィックだけを受け付ける方法)によって、高い優先順位のトラフィックが他のトラフィックよりも重要なトラフィックとして扱われます。

次のダイアグラムに示すように、IP precedence フィールドは TOS バイトの上位 3 ビットを占めています。 パケットのプライオリティまたは重要性は、TOS バイト全体の値ではなく、この IP precedence の 3 ビットだけで反映されます。

/image/gif/paws/18664/rtgupdates-a.gif

次の表に、precedence ビットの値を示します。

番号を入力します ビット値 名前
0 000 Routine
1 001 Priority
2 010 即時
3 011 Flash
4 100 Flash Override
5 101 CRITIC/ECP
6 110 Internetwork Control
7 111 ネットワーク管理

コントロール プレーン上のルーティング プロトコル パケットには、Cisco IOS によって 6 の IP precedence が割り当てられます。 RFC 791 では次のように言及されてます。「Internetwork Control の指定は、ゲートウェイ コントロール発信元だけによる使用を意図しています。」 特に、Cisco IOS では次の IP ベースの制御パケットがマーク付けされます。 OSPF(Open Shortest Path First)、Routing Information Protocol(RIP)、Enhanced Interior Gateway Routing Protocol(Enhanced IGRP)hello、およびキープアライブです。 ルータで送受信される Telnet パケットにも、IP precedence 値 6 が付与されます。 この割り当てられた値は、出力インターフェイスによってネットワークに送信される際にもパケットに保持されています。

内部パケット優先順位付けタグ

ネットワーク経由での転送中には IP precedence 値によってデータグラムの処理が指定され、ルータ内部での転送中には pak_priority メカニズムによってパケットの処理が指定されます。

ルータのコア CPU に加え、各インターフェイスではネットワーク コントローラやローカル CPU が使用されます。ネットワーク コントローラやローカル CPU では、ドライバと呼ばれる特別なソフトウェアが実行されます。 ドライバ コードは、インターフェイス固有の命令を発行します。

パケットの受信時、インターフェイス ドライバによって小さな First-In, First-Out(FIFO; ファーストイン ファーストアウト)バッファから、Input/Output(I/O; 入出力)メモリ内のデータ バッファに、このパケットがコピーされます。 次に、このバッファに小さなパケット ヘッダーが添付されます。 Cisco IOS 用語では paktype 構造と呼ばれるこのパケット ヘッダーには、バッファ内のデータ ブロックに関する主要な情報が含まれています。 パケット ヘッダーが参照するメモリ内のアドレスは、パケットの内容に応じて、Ethernet カプセル化ヘッダー、Internet Protocol(IP; インターネット プロトコル)ヘッダー、および Transmission Control Protocol(TCP; 伝送制御プロトコル)ヘッダーの始点アドレスである場合があります。

インターフェイス キュー内のパケット処理を制御するために、Cisco IOS ソフトウェアではパケット ヘッダー内のフィールドが使用されます。 このパケット ヘッダーには pak_priority フラグが含まれます。このフラグによって、マーク付けされたパケットの相対的な重要性がキューイング システムに示されます。

ルータのコア CPU 上で稼働している RIP および OSPF ルーティング プロセスによって発信されるすべてのトラフィックには、IP precedence 6 と pak_priority の両方を使用してマーク付けが行われます。 対照的に、Border Gateway Protocol(BGP; ボーダー ゲートウェイ プロトコル)では、TCP に対して IP precedence 6 のトラフィックにマーク付けするように指示しますが、pak_priority は設定しません。

また、一部のタイプの非 IP 制御パケットに対して、低い廃棄率を保証することも Cisco IOS の役割です。 これらのパケット タイプには、次のものがあります。

  • Intermediate System-to-Intermediate System(IS-IS)ルーティング プロトコル メッセージ

  • Enhanced Interior Gateway Routing Protocol(EIGRP)メッセージ

  • シリアルおよび Packet Over SONET(POS)インターフェイス上の Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)および High-level Data Link Control(HDLC; ハイレベル データリンク コントロール)キープアライブ

  • ATM インターフェイス上の Operation, Administration, and Maintenance(OAM)セルおよび Address Resolution Protocol(ARP; アドレス解決プロトコル)メッセージ

このようなトラフィックは IP ではないので、Cisco IOS ではプライオリティ設定を提供するために IP precedence 値の照合はできません。 代わりに、パケット バッファ ヘッダー内の内部 pak_priority 値だけが使用されます。

Cisco Catalyst 6000 および Cisco 7600 シリーズでは、当初、FlexWAN だけで pak_priority メカニズムがサポートされていました。 続いて、IP および非 IP 制御パケットのプライオリティ設定への拡張機能が実装されました。

パケット優先順位付けタグおよびキューイング

Cisco 7500 Route/Switch Processor(RSP; ルート スイッチ プロセッサ)やローエンド ルータ(Cisco 7200 や 3600 シリーズなど)などのルータでは、Cisco 7500 Versatile Interface Processor(VIP; バーサタイル インターフェイス プロセッサ)とは異なるルーティングおよび制御トラフィック用メカニズムが使用されています。 次の表には 2 つの方法がまとめられており、MQC で設定されたサービス ポリシーが発信インターフェイスに適用されるものと仮定しています。

プラットフォーム pak_priority メッセージのキューイング
Cisco 7500 シリーズ(分散 QoS および VIP 使用)
  • pak_priority トラフィックはデフォルトでは、class-default クラス キューに置かれます。デフォルト以外では、特別に設定された(別の)キューに置かれます。
  • class-default にキューイングされる際、パケットはキューの最後尾に置かれます。 高い優先順位のパケット廃棄を回避するために、pak_priority フラグが使用されます。
Cisco 7200、3600、および 2600 シリーズなどの RSP ベースの QoS およびその他のプラットフォーム
  • pak_priority トラフィックは、class-default とは別のキュー セットに置かれます。 (「非 RSP プラットフォームでの特殊なキューについて」のセクションを参照してください。)
  • このようなメッセージは特別の重み付け値(現在は 1024)でマーク付けされます。

言い換えると、Cisco 7500 シリーズでは、出力サービスポリシーがインターフェイスに関連付けられている場合、パケットはそのポリシー内のクラスによって分類されます。また、pak_priority パケットは選択されたクラス キューの末尾に置かれます。 pak_priority パケットがユーザ定義クラスのいずれにも一致しない場合、class-default キューの末尾に置かれます。

プライオリティ キューイングやカスタム キューイング、またはデフォルトのインターフェイス FIFO キューなどのレガシー キューイング方式を使用すると、非 RSP ルータでは pak_priority メッセージがキューの先頭にキューイングされます。これにより、遅延と廃棄の可能性が最小化されます。

非 RSP プラットフォームでの特殊なキューについて

上記の「パケットのプライオリティ タグとキューイング」の表で説明したように、Cisco 7200、3600、および 2600 シリーズなどの Cisco ルータ プラットフォームでは、class-default のキュー セットではなく、別のキュー セットに pak_priority メッセージが置かれます。

インターフェイスには、3 つのキュー セットがあります。

  • ヘッダー値を発信元 IP アドレスおよび宛先 IP アドレスとして認識する、フローベース キューの 2^n セット。 実際のキュー数は、インターフェイスあるいは仮想回線の帯域幅に基づきます。 『Cisco IOS コマンド リファレンス』で、fair-queue コマンドの説明を参照してください。

  • ユーザ作成クラス用のキュー。

  • リンクタイプのハッシュ ベースでアクセスされるキューです。 たとえば、均等化キューイング システムでは、発信元アドレスと宛先アドレスとポートのハッシュ、TOS ビット、および IP プロトコル番号に基づいて、IP マイクロフローがキューに分類されます。 フレームリレーの Local Management Interface(LMI; ローカル管理インターフェイス)メッセージは、メッセージが LMI であることを通知するマジック ナンバーのハッシュに基づいてキューイングされます。 pak_priority フラグを持つメッセージは、これら個別のリンクタイプ キューに置かれます。

次の表では、512 kbps 以上の帯域幅を持つインターフェイス用のさまざまなキューおよび(show policy-map interface または show queue コマンドの出力に表示される)そのカンバセーション ID を掲載しています。

カンバセーション/キュー番号 トラフィックのタイプ
1 ~ 256 一般的なフローベースのトラフィック キュー。 ユーザが作成したクラスに一致しないトラフィックは、class-default およびフローベースのキューの 1 つに一致します。
257 ~ 263 Cisco Discovery Protocol(CDP; Cisco 検出プロトコル)および内部の高優先順位フラグでマーク付けされたパケット用に予約されています。
264 プライオリティ クラス(priority コマンドで設定されたクラス)用に予約されているキュー。 show policy-map interface の出力でクラスの「Strict Priority」値を探してください。 プライオリティ キューによって、ダイナミック キューに 8 を加算した数値に等しいカンバセーション ID が使用されます。
265 以上 ユーザ作成クラス用のキュー。

この表内の値は実装に依存しており、変更される場合があります。

IS-IS パケットの優先順位付け

IS-IS(Intermediate System to Intermediate System)ルーティング制御パケットは、キューイングおよびパケットの優先順位付けに関する特殊なケースです。

IS-IS は、International Organization for Standardization(ISO; 国際標準化機構)の Connectionless Network Protocol(CLNP; コネクションレス型ネットワーク プロトコル)用のルーティング プロトコルです。 CLNP のデベロッパは、TCP/IP を最終的に OSI(Open System Interconnection; オープン システム インターコネクション)スイートによって置き換えられる、暫定的なプロトコル スイートとして認識していました。 したがって、この予想されている移行をサポートするために、Integrated IS-IS(またはデュアル IS-IS)が IS-IS に対する拡張として作成されました。これにより、CLNS と IP の両方のルーティング機能を持つ、単一のルーティング プロトコルが提供されます。 このプロトコルは、ピュア CLNS 環境、ピュア IP 環境、またはデュアル CLNS/IP 環境内で動作する設計になっています。

TCP/IP だけをルードするように IS-IS が使用される場合であっても、IS-IS は ISO CLNP プロトコルのままです。 IS-IS がそのピアと通信するために使用されるパケットは、CLNS Protocol Data Unit(PDU; プロトコル データ ユニット)です。これは言い換えると、IP だけの環境内であっても、キューイング システムおよび Cisco IOS においては、CLNS 制御メッセージの優先順位付けに IP precedence が使用できないことを意味します。 IS-IS パケットでは、代わりにルータ内で pak_priority メカニズムによりプライオリティが付与されます。

パケット ルーティングのキューイング方式設定

このセクションでは、キューイング方式を設計するための、一般的な 3 つの方法を検討します。具体的には、Cisco 7500 シリーズおよび VIP での高負荷の輻輳状況における、制御パケット廃棄の可能性を最小化することがその目的です (上述の非 RSP プラットフォームの場合、デフォルトでは制御パケットが別のキューに置かれることに注意してください)。

方式 いつ使用されるか 設定方法の説明
別のキューへの一致。 最も慎重な方式。 わずかな廃棄だけ、または廃棄なしを保証。 個別のクラスを設定するために、Modular QoS CLI(MQC; モジュラ QoS CLI)を使用します。また、bandwidth コマンドを使用して、輻輳発生時には一致するトラフィックに最小の帯域幅を割り当てます。 bandwidth コマンドを使用して設定されたクラスでは、IP precedence ではなく、帯域幅に基づくスケジューリング「重み付け」が使用されます。 『ATM でのクラスベース均等化キューイングについて』を参照してください。
均等化キューイングでの class-default への一致。 ほとんどの設定に対して有効です。 輻輳発生時、一部の制御パケットが廃棄される可能性があります。 Cisco IOS によってパケットに自動的に割り当てられた IP precedence 6 を使用します。これにより、重み付けへの影響と、さらに帯域幅の占有率に影響があります。 『ATM での均等化キューイングについて』を参照してください。
FIFO キューイングでの class-default への一致。 輻輳したリンクに対しては推奨されません。 輻輳発生時、一部の制御パケットが廃棄される可能性があります。 この方式では、IP precedence は考慮されません。 VIP ベース QoS では、pak_priority メッセージは FIFO キューの最後尾にキューイングされます。

次に、RIP 制御パケット用の別のキューを作成する方法の例を示します。

 class-map match-all rp 
   match access-group 104 
! 
 access-list 104 permit udp any eq rip any eq rip 

!--- Create a class-map that matches an ACL permitting RIP. 

! 
 policy-map bandwidth 
   class voip 
     priority 64 
   class bus 
    bandwidth 184 
   class RP 
    bandwidth 8 

!--- Create a policy-map (named "bandwidth") and specify 
!--- class RP. 

! 
interface Serial1/0:0.1 point-to-point 
  bandwidth 256 
  ip unnumbered Loopback0 
  ip accounting precedence input 
  no cdp enable 
  frame-relay class sample 
  frame-relay interface-dlci 100 IETF 

!--- Apply the map-class named "sample" to the PVC. 

! 
map-class frame-relay sample 
  frame-relay cir 256000 
  frame-relay bc 2560 
  frame-relay mincir 256000 
  no frame-relay adaptive-shaping 
  service-policy output bandwidth 
  frame-relay fragment 160 

!--- Create a frame relay map-class and apply the service 
!--- policy inside the map-class.

これらの方式のいずれかを選択するときは、次の要因を考慮します。

  • 使用されているルーティング プロトコル、および設定されている hello とデータベース リフレッシュのタイマー値。

  • 交換が必要なデータベースのサイズ。また、定期的にリフレッシュされるものが更新や変更だけなのか、または表全体なのかどうか。

  • インターフェイスまたは仮想回線で予想される輻輳の規模。

つまり、輻輳発生時における、高い優先順位のパケットの実際のキューイングの可能性を考慮します。

QoS とローカルで生成されたパケット

ルータによって生成されたトラフィックによって、発信 QoS サービス ポリシーの特殊な状況が示されます。 ローカルで生成された一部のトラフィックは、その他のユーザ トラフィックと同様に扱われる必要があります。また、QoS システムでは、設定された QoS メカニズムをこのトラフィックに適用する必要があります。 このようなトラフィックの例としては、任意クラスのパケットによって発生する動作を測定する設計になっている、パフォーマンス プローブが挙げられます。 ローカルで生成されたその他のトラフィック(特にレイヤ 2 キープアライブおよびルーティング プロトコル メッセージ)は、ルータの基本機能にとって必要不可欠であり、一部の QoS 機能の影響を受けないようにする必要があります。 たとえば、平均キュー項目数が最高水準点に達しても、Weighted Random Early Detection(WRED; 重み付けランダム早期検出)によってレイヤ 2 キープアライブが廃棄されることはありません。

また、ルータ宛てのパケットは慎重に処理される必要があります。 たとえば、重要な制御メッセージが廃棄されるのを避けるため、クラスベースのポリシングを適用するサービス ポリシーをルータ宛てのパケットに適用してはならないことに注意してください。

仕様上、RP で生成されたパケットは適切に分類およびキューイングされますが、Modular QoS CLI カウンタには加算されません。 これらのパケットは、show policy-map interface コマンドの出力には加算されません。

次の表には、ルータ宛てのパケットおよびルータからのパケットによる、主要な QoS 機能との相互作用の方法の現状が掲載されています。

QoS 機能 説明
クラスベースのマーキング
  • 当初は、Cisco Express Forwarding(CEF; Cisco エクスプレス転送)スイッチングのパケット上だけで作動。
  • プロセス スイッチングおよびファースト スイッチング方式のサポートは、Cisco IOS ソフトウェア リリース 12.2(5)(CSCdt74738)で導入されています。
ポリシング

  • 受信:レート制限を適用可能。 受信インターフェイスは、Committed Access Rate(CAR)が使用される場合(およびクラスベースのポリシングではない場合)、CEF を使用して設定する必要があります。 Cisco 7500 シリーズ ルータでは、トラフィック ポリシングによって CEF スイッチング パスだけの監視が可能です。
  • 発信:CAR を使用したレート制限またはクラスベースのポリシングが動作します。

Catalyst 6000 でのパケットの優先順位付け

Catalyst 6000 で、スーパーバイザと Multilayer Switch Feature Card(MSFC; マルチレイヤ スイッチ フィーチャ カード)の両方で Cisco IOS が稼働している場合、ルーティング制御パケットは RP により IP precedence 6 にマーク付けされます。 再マーク付けされたこの値は、ルーティング制御パケットを、WRR(Weighted Round-Robin)内の上限しきい値である優先度の高いキューにマッピングするために、出力スケジューリングで使用できます。 MSFC によって発信されたこのようなルーティング制御パケットのマッピングは、mls qos コマンドにより QoS がグローバルに有効にされている限り、自動的に行われます。 QoS を有効にすると、システムでは、WRED 廃棄しきい値、WRR 帯域幅、およびキュー制限などの全キューイング パラメータのセットアップが行われます。 QoS がグローバルに無効化されていると、出力スケジューリングの下限しきい値である、WRR の優先度の低いキューに、すべてのパケットがマッピングされます。

『Catalyst 6000 コンフィギュレーション ガイド』の「QoS の設定」の章で述べられているように、QoS では、イーサネット入力ポートにおけるレイヤ 2 Class of Service(CoS; サービス クラス)値を使用して、分類、マーキング、スケジューリング、および輻輳回避がサポートされています。 イーサネット入力ポートにおける、分類、マーキング、スケジューリング、および輻輳回避では、レイヤ 3 IP precedence または DSCP 値の使用や設定はされません。 さらに任意のスイッチング エンジンで、QoS により、レイヤ 2 CoS 値を使用したイーサネット出力ポート スケジューリングと輻輳回避がサポートされています。 そのため、重要な IP および非 IP パケットは、CoS 値がデータ バス ヘッダーの一部として内部だけで使用されている場合であっても、CoS 値へのマッピングを行う必要があります。 重大な IP パケットに pak_priority フラグで MSFC から起きる IS-IS パケットが含まれている 6.重大な非 IP パケットの同等の CoS 値にマッピング される 6 の IP優先値が、マークされますあり、それからそのようなフラグを付けられたパケットは 6.の CoS 値にマッピング されます。 現在の Cisco IOS リリースでは、このマッピングは自動的に行われます。

MSFC から発信され、物理イーサネット インターフェイスを介した送信宛てのパケットは、入力ポリサーおよび出力ポリサーのいずれによってもマーク付けされません。

Catalyst 6000 での QoS 設定については、この文書では扱いません。 詳細については、『QoS の設定』および『Catalyst LAN および ATM スイッチのサポート ページ』を参照してください。


関連情報


Document ID: 18664