このドキュメントでは、Modular Quality of Service Command-Line インターフェイス(MQC)のコマンドを使用してアウトバウンド ルータ インターフェイスにサービス ポリシーを設定した場合に、ルーティング プロトコル メッセージ(hello やデータベース記述子など)とその他の重要な制御トラフィックがキューイングされる仕組みを説明します。
このドキュメントでは具体的に、Cisco IOS® ルータが制御パケットを優先順位付けするために使用する 2 つのメカニズムを検討します。
フィールド | 場所 | 優先順位の適用場所 |
---|---|---|
IP precedence ビット | IP ヘッダー内のタイプ オブ サービス(ToS)バイト | 優先順位をネットワークで指定 |
pak_priority | インターフェイス ドライバによって割り当てられる、ルータ内の内部パケット ラベル | 優先順位(ホップ単位)をルータで指定 |
どちらのメカニズムも、主要な制御パケットがドロップされないこと、あるいは発信インターフェイスで輻輳が発生している場合はルータやキューイング システムによって最後にドロップされることを確実にするよう設計されています。
このドキュメントに特有の要件はありません。
この文書の情報は、Cisco IOS ソフトウェア リリース 12.2 に基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
Request for Comments(RFC)791 では、IP パケットのヘッダー内の TOS バイトが定義されています。 RFC 2474およびRFC 2475 は、このバイトをDifferentiated Services Code Point(DSCP)値として再定義します 。Cisco IOSルータは、RFC 791に従ってTOSバイトののの元IP優先ビットをバイト:
タイプ オブ サービス(ToS)は、必要な Quality of Service の抽象的なパラメータの指標を与えます。これらのパラメータは、データグラムを特定のネットワークを介して伝送するときに、実際のサービス パラメータの選択をガイドするために使用されます。一部のネットワークで提供されるサービス優先度は、ある意味、優先度が高いトラフィックを他のトラフィックよりも重要なものとして扱います(通常は、負荷が高い間は特定の優先度以上のトラフィックを受け入れるという形)。
以下の図に示されているように、IP precedence フィールドは TOS バイトの 3 つの最上位ビットを占めます。TOS バイトの値全体ではなく、3 つの IP precedence ビットのみがパケットの優先順位または重要度を反映します。
以下の表に、precedence ビットの値を記載します。
番号 | ビット値 | [名前(Name)] |
---|---|---|
0 | 000 | 標準 |
1 | 001 | 優先順位 |
0 | 010 | 即時 |
3 | 011 | フラッシュ |
4 | 100 | フラッシュ オーバーライド |
5 | 101 | CRITIC/ECP |
6 | 110 | インターネットワーク制御 |
7 | 111 | ネットワーク制御 |
Cisco IOS は IP precedence 値 6 をコントロール プレーン上のルーティング プロトコル パケットに割り当てます。RFC 791 に記述されているように、「インターネットワーク制御の指定は、ゲートウェイ制御トラフィックの発信者のみが使用するように意図されています」。 Cisco IOS がマークする IP ベース制御パケットは、具体的にはOpen Shortest Path First(OSPF)、Routing Information Protocol(RIP)、Enhanced Interior Gateway Routing Protocol(EIGRP)の hello およびキープアライブです。ルータとの間で送受信されるTelnetパケットも、IP precedence値6を受信します。出力インターフェイスがパケットをネットワークに送信しても、割り当てられた値はパケットに残ります。
IP precedence 値はネットワーク内で送信されている間のデータグラムの扱い方を指定する一方、pak_priority メカニズムはルータ内で送信されている間のパケットの扱い方を指定します。
ルータ CPU のコアに加え、すべてのインターフェイスがドライバと呼ばれる特殊なソフトウェアを実行するネットワーク コントローラまたはローカル CPU を使用します。ドライバ コードは、インターフェイス固有の命令を提供します。
インターフェイスがパケットを受信すると、インターフェイス ドライバが小さなファーストイン ファーストアウト(FIFO)バッファから入出力(I/O)メモリ内のデータ バッファにパケットをコピーします。その上で、このバッファにサイズの小さいパケット ヘッダーを付加します。Cisco IOS の用語では paktype 構造と呼ばれるこのパケット ヘッダーには、バッファ内のデータ ブロックに関する情報が格納されます。パケットのコンテンツによっては、パケット ヘッダーが、メモリ内のイーサネット カプセル化ヘッダー、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 は設定しないように指示します。
Cisco IOS は、いくつかのタイプの非 IP 制御パケットがドロップされる可能性も低くなるようにしなければなりません。これに該当するパケット タイプには、以下が含まれます。
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 インターフェイス上の Operations, Administration, and Mintenance(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)とは異なるメカニズムを使用してトラフィックをルーティングおよび制御します。 以下の表に、MQC で設定されたサービス ポリシーが発信インターフェイスに適用されるという前提で、この 2 つの手法を要約します。
Platform | pak_priority メッセージのキューイング |
---|---|
Cisco 7500 シリーズ(分散 QoS および VIP を使用) |
|
RSP ベース QoS およびその他のプラットフォーム(Cisco 7200、3600、2600 シリーズを含む) |
|
つまり Cisco 7500 シリーズでは、出力サービス ポリシーがインターフェイスに関連付けられている場合、そのポリシーに含まれるクラスを基準にパケットが分類され、選択されたクラス キューの末尾に pak_priority パケットが配置されます。pak_priority パケットがユーザ定義のクラスのいずれとも一致しなければ、そのパケットは class-default キューの末尾に配置されます。
注:プライオリティキューイングやカスタムキューイングなどの従来のキューイング方式や、デフォルトのインターフェイスFIFOキューを使用すると、非RSPルータはpak_priorityメッセージをキューの先頭にキューイングし、遅延と廃棄確率を最小限に抑えます。
インターフェイス上には 3 つのキュー セットがあります。
ヘッダーの値を送信元および宛先 IP アドレスであると見なすフローベースのキューの 2^n セット。キューの実際の数は、インターフェイスまたは仮想回線の帯域幅に基づきます。『Cisco IOS コマンド リファレンス』の fair-queue コマンドの説明を参照してください。
ユーザ作成クラス用のキュー。
linktype のハッシュに基づいてアクセスされるキュー。たとえば均等化キューイング システムでは、IP マイクロフローを送信元および宛先アドレスとポートのハッシュ、TOS ビット、および IP プロトコル番号に基づいてキューに分類します。フレーム リレー ローカル管理インターフェイス(LMI)メッセージは、このメッセージが LMI であることを示す Magic 番号のハッシュに基づいてキューに入れられます。pak_priority フラグが付いたメッセージは、これらの個別の linktype キューに入れられます。
以下の表に、帯域幅が 512 Kbps を超えるインターフェイスの場合の各種キューとそれぞれのカンバセーション ID(show policy-map interface または show queue コマンドで出力される ID)を記載します。
カンバセーション/キュー番号 | トラフィックのタイプ |
---|---|
1 ~ 256 | 汎用フローベース トラフィック キュー。ユーザ作成クラスと一致しないトラフィックは、class-default およびいずれかのフローベース キューと一致します。 |
257 ~ 263 | Cisco Discovery Protocol 用、および内部高優先順位フラグでマーキングされたパケット用として予約されています。 |
264 | プライオリティ クラス(priority コマンドで設定されたクラス)用のキューとして予約されています。 show policy-map interface 出力でクラスに関する Strict Priority 値を探します。プライオリティ キューは、ダイナミック キューの数に 8 を加えた数に一致するカンバセーション ID を使用します。 |
265 以降 | ユーザ作成クラス用のキュー。 |
注:この表の値は実装に依存しており、変更される可能性があります。
Intermediate System to Intermediate System(IS-IS)ルーティング制御パケットは、キューイングおよびパケット優先順位付けに関して特殊なケースです。
IS-IS は、国際標準化機構(ISO)の Connectionless Network Protocol(CLNP)を対象としたルーティング プロトコルです。 CLNP の開発者たちは TCP/IP を、いずれはオープン システム相互接続(OSI)に置き換わる、暫定プロトコル スイートとして見ていました。この予期される移行をサポートするために、IS-IS の拡張として、コネクションレス型ネットワーク サービス(CLNS)と IP の両方のルーティングに対応する単一のルーティング プロトコルとなる Integrated IS-IS(または Dual IS-IS)が作成されました。このプロトコルは、純粋な CLNS 環境、純粋な IP 環境、またはデュアル CLNS/IP 環境で稼働するよう設計されています。
IS-IS が TCP/IP だけをルーティングするために使用されるとしても、IS-IS が ISO CLNP プロトコルであることに変わりはありません。IS-IS がそのピアと通信するために使用するパケットは、CLNS プロトコル データ ユニット(PDU)です。つまり、IP のみの環境でも、キューイング システムと Cisco IOS は CLNS 制御メッセージに優先順位を付けるために IP precedence を使用することはできません。そのため、IS-IS パケットにはルータ内部の pak_priority メカニズムを使用して優先順位を割り当てます。
このセクションでは、Cisco 7500 シリーズおよび VIP で重度の輻輳が発生している間、制御パケットがドロップされる可能性を最小限に抑えることを具体的な目的としたキューイング戦略を設計する際の一般的な 3 つのアプローチを検討します。(非 RSP プラットフォームはデフォルトで、制御パケットを別個のキューに入れることを念頭に置いてください)。
戦略 | 使用するケース | 設定方法の説明 |
---|---|---|
別個のキューに一致させる。 | 最も保守的な戦略。ほとんど、またはドロップされないことが確実になります。 | Modular 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.
3 つのアプローチのうちのいずれかを選択する際は、次の要素を検討してください。
使用する特定のルーティング プロトコルと、hello およびデータベース更新に対して設定するタイマー値
交換する必要があるデータベースのサイズと、更新/変更だけを定期的に更新するのか、またはテーブル全体を定期的に更新するのか
インターフェイスまたは仮想回線で期待される輻輳の量
つまり、輻輳発生時に実際に高優先度のパケットがキューに入れられる可能性を検討する必要があります。
ルータが生成するトラフィックは、アウトバウンド QoS サービス ポリシーにとって特殊なケースを表します。他のあらゆるユーザ トラフィックと同じように扱う必要がある、ローカルで生成される一部のトラフィックには、QoS システムは設定済みの QoS メカニズムを適用します。このようなトラフィックの一例は、特定クラスのパケットによる動作を測定するよう意図されたパフォーマンス プローブです。レイヤ 2 キープアライブやルーティング プロトコル メッセージをはじめとする他のローカルに生成されるトラフィックは、ルータの基本的機能に不可欠であるため、いくつかの QoS 機能を適用する必要があります。たとえば、平均キュー深さが上限に達しても、重み付けランダム早期検出(WRED)によってレイヤ 2 キープアライブがドロップされることがあってはなりません。
さらに、ルータ宛てのパケットも慎重に扱う必要があります。重要な制御メッセージがドロップされないようにするためには、ルータ宛てのパケットに、たとえばクラス ベースのポリシングを適用するサービス ポリシーを適用しないでください。
注: 設計により、RP で生成されるパケットは、適切に分類/キューイングされるとしても、Modular QoS CLI カウンタに計上されません。これらのパケットは show policy-map interface コマンドの出力では無視されます。
以下の表に、ルータ宛てのパケットおよびルータから送信されるパケットが現在どのように重要な QoS 機能と相互作用するのかを記載します。
QoS 機能 | 説明 |
---|---|
クラスベース マーキング |
|
ポリシング |
|
Catalyst 6000でスーパーバイザとMultiLayer Switch Feature Card(MSFC;マルチレイヤスイッチフィーチャカード)の両方でCisco IOSを実行すると、RPはルーティング制御パケットをIP precedence 6でマークします。この再マーク値は、出力スケジューリングで使用できます。MSFC から発信されたルーティング制御パケットのこのマッピングは、mls qos コマンドで QoS がグローバルに有効にされている限り、自動的に行われます。QoS を有効にすると、システムがすべてのキューイング パラメータ(WRED ドロップしきい値、WRR 帯域幅、キュー制限など)を設定します。QoS がグローバルに無効にされている場合、すべてのパケットは WRR の低優先度キュー(出力スケジューリングの下限しきい値)にマッピングされます。
Catalyst 6000 構成ガイドのQoS の設定に関する章に記載されているように、QoS はイーサネット入力ポートでのレイヤ 2 のサービス クラス(CoS)値を使用して分類、マーキング、スケジューリング、および輻輳回避をサポートします。イーサネット入力ポートでの分類、マーキング、スケジューリング、および輻輳回避では、レイヤ 3 の IP precedence 値または DSCP 値は使用されません。また、設定も行われません。さらに、使用するスイッチング エンジンの種類に関係なく、QoS はレイヤ 2 の CoS 値を使用して、イーサネット出力ポートでのスケジューリングおよび輻輳回避をサポートしています。したがって、CoS 値はデータ バス ヘッダーの一部として内部でのみ使用されるとしても、きわめて重要な IP および非 IP パケットは CoS 値にマッピングされていなければなりません。重要なIPパケットのIP precedence値は6で、同等のCoS値にマッピングされます。MSFCから発信されるIS-ISパケットを含む重要な非IPパケットにはpak_priorityフラグが付けられ、CoS値6にされます。
入力ポリサーと出力ポリサーのどちらも、MSFC から発信されて物理イーサネット インターフェイスで送信されるパケットにはマーキングしません。
Catalyst 6000 での QoS 設定は、このドキュメントの範囲外です。詳細については、QoS の設定および Catalyst LAN および ATM スイッチに関するサポート ページを参照してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
15-Feb-2008 |
初版 |