- はじめに
- 製品概要
- CLI
- スイッチの初期設定
- スイッチの管理
- RPR および SSO を使用したスーパーバイザ エンジンの冗長 設定
- Cisco IOS XE インサービス ソフトウェア アップグレード プロセスの設定
- インターフェイスの設定
- ポートのステータスと接続の確認
- Cisco NSF/SSO スーパーバイザ エンジンの 冗長構成の設定
- 環境モニタリングおよび電源管理
- Power over Ethernet（PoE）の設定
- VLAN、VTP、および VMPS の設定
- IP アンナンバード インターフェイスの設定
- レイヤ 2 イーサネット インターフェイスの設 定
- SmartPort マクロの設定
- STP および MST の設定
- 任意の STP 機能の設定
- EtherChannel の設定
- CDP の設定
- IGMP スヌーピングとフィルタリングの設定
- IPv6 MLD スヌーピングの設定
- LLDP と LLDP-MED の設定
- UDLD の設定
- レイヤ 3 インターフェイスの設定
- CEF の設定
- ユニキャスト Reverse Path Forwarding の 設定
- IP マルチキャストの設定
- PBR の設定
- VRF-Lite の設定
- Flexible NetFlow の設定
- QoS の設定
- 音声インターフェイスの設定
- プライベート VLAN（PVLAN）の設定
- 802.1X ポートベース認証の設定
- Web ベース認証の設定
- ポート セキュリティの設定
- コントロール プレーン ポリシングの設定
- DHCP スヌーピング、IP ソース ガード、 およびスタティック ホストの IPSG の設定
- DAI の設定
- ACL によるネットワーク セキュリティの設定
- IPv6 のサポート
- ポート ユニキャストおよびマルチキャスト フラッディング ブロック
- ストーム制御の設定
- SPAN と RSPAN の設定
- システム メッセージ ロギングの設定
- SNMP の設定
- Cisco IOS IP SLA 動作の設定
- RMON の設定
- Call Home の設定
- 診断の実行
- ROM モニタ
- MIB サポートの設定
- 略語
- 索引
Catalyst 4500 シリーズ スイッチ Cisco IOS ソフトウェアコンフィギュレーションガイド リリース IOS-XE 3.1.0 SG
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月9日
章のタイトル： QoS の設定
QoS の設定
この章では、Supervisor Engine 7-E を実行しているスイッチ上で Quality of Service（QoS）を設定するために、自動 QoS（auto-QoS）コマンドまたは標準の QoS コマンドを使用する方法について説明します。ここでは、VLAN だけでなくさまざまな種類のインターフェイス（アクセス、レイヤ 2 トランク、レイヤ 3 ルーティング、EtherChannel）での QoS 設定を指定する方法を説明します。また、所定のインターフェイスの異なる VLAN 上で異なる QoS（per-Port per-VLAN QoS（PVQoS））を設定する方法についても説明します。
Supervisor Engine 7-E は、Modular QoS CLI（MQC; モジュラ QoS コマンドライン インターフェイス）と呼ばれる QoS コンフィギュレーション モデルをサポートします。QoS が設定されているスーパーバイザ エンジンの該当する設定セクションを参照してください。MTU の詳細については、『 Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3 』の「Modular Quality of Service Command-Line Interface」を参照してください。
•
「Catalyst 4500 シリーズ スイッチでの QoS の概要」
（注） この章で使用するスイッチ コマンドの構文および使用方法の詳細については、次の URL で『Cisco Catalyst 4500 Series Switch Command Reference』と関連資料を参照してください。
http://www.cisco.com/en/US/products//hw/switches/ps4324/index.html
Catalyst 4500 のコマンド リファレンスに掲載されていないコマンドについては、より詳細な Cisco IOS ライブラリを参照してください。次の URL で『Cisco IOS Command Reference』と関連資料を参照してください。
http://www.cisco.com/en/US/products/ps6350/index.html
Catalyst 4500 シリーズ スイッチでの QoS の概要
ネットワークは通常、 ベスト エフォート型 の配信方式で動作します。したがって、すべてのトラフィックに等しいプライオリティが与えられるため、正しいタイミングで配信される可能性はどのトラフィックでも同等です。輻輳が発生した場合にドロップされる可能性についても、すべてのトラフィックで同等です。
QoS は、ネットワーク トラフィック（ユニキャストおよびマルチキャスト）を選択して、トラフィックの相対的な重要度に従ってプライオリティを与え、プライオリティ ベースの処理を実行して、輻輳を回避します。QoS はさらに、ネットワーク トラフィックが使用する帯域幅を制限します。QoS を実装すると、ネットワーク パフォーマンスが予測可能になり、帯域幅をより効率的に利用できます。
• 「分類」
• 「PVQoS」
プライオリティ
QoS の実装は、DiffServ アーキテクチャに基づきます。このアーキテクチャでは、ネットワークの入口で各パケットを分類すると規定されています。この分類は、IP パケット ヘッダーで伝送され、現在ほとんど使用されていない IP Type of Service（ToS; サービス タイプ）フィールドの 6 ビットを使用して分類（ クラス ）情報が伝送されます。分類は、レイヤ 2 フレームで伝送される場合もあります。レイヤ 2 フレームまたはレイヤ 3 パケットのこのような特殊ビットについては、図 31-1 を参照してください。
レイヤ 2 の ISL（スイッチ間リンク）フレーム ヘッダーには、1 バイトのユーザ フィールドがあり、Least Significant Bit（LSB; 最下位ビット）3 ビットで IEEE（米国電気電子学会）802.1p Class of Service（CoS; サービス クラス）値が伝送されます。レイヤ 2 ISL トランクとして設定されたインターフェイス上では、すべてのトラフィックが ISL フレームを使用します。
レイヤ 2 802.1Q フレーム ヘッダーには、2 バイトのタグ制御情報フィールドがあり、Most Significant Bit（MSB; 最上位ビット）3 ビット（ユーザ プライオリティ ビットと呼ばれる）で CoS 値が伝送されます。レイヤ 2 802.1Q トランクとして設定されたインターフェイスでは、ネイティブ VLAN のトラフィックを除き、すべてのトラフィックが 802.1Q フレームに収められます。
その他のフレーム タイプでは、レイヤ 2 CoS 値は伝送されません。
レイヤ 2 CoS 値の範囲は、0（ロー プライオリティ）～7（ハイ プライオリティ）です。
レイヤ 3 IP パケットは、IP precedence 値または Differentiated Services Code Point（DSCP; DiffServ コード ポイント）値のいずれかを伝送します。DSCP 値は IP precedence 値と下位互換性があるので、QoS ではどちらの値でも使用できます。
図 31-1 フレームおよびパケット内の QoS 分類レイヤ
インターネット上のすべてのスイッチおよびルータはクラス情報に基づき、同じクラス情報を持ったパケットに対しては転送上、同じ取り扱いを行い、クラス情報が異なるパケットに対しては異なった取り扱いを行います。設定されたポリシー、パケットの詳しい検証、またはその両方に基づき、エンド ホストあるいは途中にあるスイッチまたはルータによって、パケット内のクラス情報が割り当てられる場合があります。パケットの詳しい検証は、コア スイッチおよびルータが過負荷にならないように、ネットワーク エッジに近い位置で行われることが前提になります。
パス上にあるスイッチおよびルータは、クラス情報を使用して、トラフィック クラスごとに割り当てられるリソースの量を制限できます。DiffServ アーキテクチャで個々の装置がトラフィックを処理するときの動作を、Per-Hop Behavior（PHB）といいます。パス上のすべての装置が一貫性のある PHB を提供する場合、エンドツーエンドの QoS ソリューションを構築できます。
ネットワークに QoS を実装する作業は、インターネットワーキング装置が提供する QoS 機能、ネットワーク上のトラフィック タイプおよびトラフィック パターン、着信トラフィックおよび発信トラフィックに対して適用すべき制御の粒度に応じて、簡単なものにも複雑なものにもなります。
QoS の用語
• フレーム ：レイヤ 2 でトラフィックを伝送します。レイヤ 2 フレームが、レイヤ 3 パケットを伝送します。
• ラベル ：レイヤ 3 パケットおよびレイヤ 2 フレームで伝送されるプライオリティ値です。
– レイヤ 2 CoS 値。範囲は 0（ロー プライオリティ）～ 7（ハイ プライオリティ）です。
レイヤ 2 ISL フレーム ヘッダーには、1 バイトのユーザ フィールド（LSB 3 ビットで IEEE 802.1p CoS 値を伝送）があります。
レイヤ 2 802.1Q フレーム ヘッダーには、2 バイトのタグ制御情報フィールドがあり、MSB 3 ビット（ユーザ プライオリティ ビット）で CoS値が伝送されます。
その他のフレーム タイプでは、レイヤ 2 CoS 値は伝送されません。
（注） レイヤ 2 ISL トランクとして設定されたインターフェイスでは、すべてのトラフィックが ISL フレームに収められます。レイヤ 2 802.1Q トランクとして設定されたインターフェイスでは、ネイティブ VLAN のトラフィックを除き、すべてのトラフィックが 802.1 Qフレームに収められます。
– レイヤ 3 IP precedence 値：IPv4 の仕様では、1 バイトの ToS フィールドの MSB 3 ビットを IP precedence と定義しています。IP precedence 値の範囲は、0（ロー プライオリティ）～ 7（ハイ プライオリティ）です。
– レイヤ 3 DSCP 値：Internet Engineering Tasks Force（IETF; インターネット技術特別調査委員会）は、1 バイトの IP ToS フィールドのうち MSB 6 ビットを DSCP と定義しています。個々の DSCP 値が表す PHB は、設定変更可能です。DSCP 値の範囲は 0 ～ 63 です。
（注） レイヤ 3 の IP パケットは、IP precedence 値または DSCP 値のいずれかを伝送します。DSCP 値は IP precedence 値と下位互換性があるので、QoS ではどちらの値でも使用できます。表 31-1 を参照してください。
|
Precedence |
|
DSCP |
|
Precedence |
|
DSCP |
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
• マーキング ：RFC 2475 に従い、レイヤ 3 の DSCP 値をパケットに設定する処理です。このマニュアルでは、マーキングの定義を拡大して、レイヤ 2 CoS 値の設定までを含めています。
• ポリシング ：トラフィック フローが使用する帯域幅を制限する処理です。ポリシングによって、トラフィックのマーキングまたはドロップが可能になります。
QoS の基本モデル
図 31-2 に、Supervisor Engine 7-E QoS 機能の概要フローを示します。
ステップ 1 着信パケットが、複数のパケット フィールド、受信ポート、または VLAN に基づいてトラフィック クラスに分類されます。
ステップ 2 トラフィック クラスに基づいて、パケットがレート制限/ポリシングされ、オプションでそのプライオリティがマークされ（その多くは、ネットワークのエッジで）、低プライオリティ パケットがドロップされる、または、パケット フィールド（DSCP と CoS）で低プライオリティとしてマークされます。
ステップ 3 パケットがマークされたら、転送用に検索されます。このアクションでは、送信ポートとパケットを送信する VLAN が取得されます。
ステップ 4 パケットが、送信ポートまたは VLAN に基づいて出力方向に分類されます。この分類では、入力 QoS によるパケットのマーキングが考慮されます。
ステップ 5 出力分類に基づいて、パケットがポリシングされ、オプションでそのプライオリティが（再び）マークされ、パケットの送信キューがトラフィック クラスに従って決定されます。
ステップ 6 送信キューのステートが Active Queue Management（AQM; アクティブ キュー管理）アルゴリズムとドロップしきい値設定を介して動的にモニタされ、そのパケットをドロップするか、送信用にキューに入れるかが決定されます。
ステップ 7 伝送に適格である場合、パケットは送信キューに入れられます。送信キューが、出力 QoS 分類基準に基づいて選択されます。選択されたキューは、遅延と帯域幅に応じた振る舞いをします。
分類
分類は、パケットの各フィールドを検証することで、トラフィックの種類を区別するプロセスです。また、QoS ポリシー マップがインターフェイスに対応付けられているときに、イネーブルになります。
フレームまたはパケットの、どのフィールドを使用して着信トラフィックを分類するかを、ユーザが指定します。
IP 以外のトラフィックについては、次の分類オプションがあります。
• 着信フレームの VLAN タグ内の CoS 値がパケットの分類に使用されます。
• フレームに CoS 値が含まれていない場合は、ポートのデフォルト CoS 値（「0」）が分類に使用されます。
レイヤ 2 ヘッダー内のフィールドを検査する、設定済みの MAC ACL に基づいて分類を実行します。
IP トラフィックについては、次の分類オプションがあります。
• 着信パケット内の IP DSCP または IP Precedence が分類に使用されます。DSCP 値の範囲は 0 ～ 63 です。
• 設定された IP 標準 Access Control List（ACL; アクセス コントロール リスト）または拡張 ACL（IP ヘッダーの各種のフィールドを検証する）に基づいて、分類を実行します。
QoS ACL に基づく分類
QoS のパケット分類は、複数の一致基準を使用して行うことができ、指定された一致基準をパケットがすべて満たしている必要があるか、または少なくとも 1 つの一致基準を満たしていればよいかを指定できます。QoS 分類基準を定義するには、クラス マップで一致（match）文を使用して一致基準を指定します。「match」文では、照合するパケット内のフィールドを指定することも、IP 標準 ACL、IP 拡張 ACL、または MAC ACL を使用することもできます。詳細については、「クラス マップおよびポリシー マップに基づく分類」を参照してください。
すべての一致基準に一致するようにクラス マップを設定した場合、パケットがクラス マップ内のすべての一致文を満たしていないと、QoS アクションは実行されません。パケットがクラス マップの一致基準を 1 つでも満たさない場合、そのパケットについて QoS アクションは実行されません。
最低 1 つの一致基準に一致するようにクラス マップを設定した場合、パケットがクラス マップ内の少なくとも 1 つの一致文を満たしていれば、QoS アクションが実行されます。パケットがクラス マップの一致基準をどれも満たしていない場合、そのパケットについて QoS アクションは実行されません。
（注） IP 標準 ACL および IP 拡張 ACL を使用する場合、QoS コンテキストでは、ACL の中の許可 ACE と拒否（deny）ACE の意味は多少異なります。
• 「permit」を指定している ACE を検出し、なおかつパケットがそれを満たしている場合、そのパケットは QoS 分類の一致基準に「一致した」ことになります。
• 「deny」を指定している ACE を検出し、なおかつパケットがそれを満たしている場合、そのパケットは QoS 分類の一致基準に「一致しない」ことになります。
• 一致する許可（permit）アクションが検出されないまま、すべての ACE の検証が終わった場合、そのパケットは QoS 分類の基準に「一致しない」ことになります。
（注） アクセス リストを作成するとき、アクセス リストの末尾にはデフォルトで、リストの末尾に達しても一致が見つからなかった場合に使用される、暗黙の拒否（deny）文がある点に留意してください。
クラス マップを使用してトラフィック クラスを定義したあとで、トラフィック クラスに対する QoS アクションを定義するポリシーを作成できます。ポリシーでは、複数のクラスのそれぞれについて、アクションを指定できます。ポリシーには、クラスを集約的に分類する（たとえば、DSCP を割り当てる）コマンド、またはクラスをレート制限するコマンドを組み込めます。このポリシーを特定のポートに付加して、そのポート上でポリシーを有効にします。
IP トラフィックを分類するための IP ACL を実装するには、 access-list グローバル コンフィギュレーション コマンドを使用します。
クラス マップが match-all キーワードを使用して作成されている場合は、一致基準として IP ACL と MAC ACL の両方を含めることはできません。
クラス マップおよびポリシー マップに基づく分類
クラス マップは、特定のトラフィック フロー（クラス）を、他のすべてのトラフィックから切り離して名前を付けるためのメカニズムです。クラス マップは、特定のトラフィック フローを分類する目的で使用する一致基準を定義します。基準としては、ACL で定義されるアクセス グループとのマッチング、または特定の DSCP 値、IP precedence 値、または L2 CoS 値のリストとのマッチングを指定できます。複数のタイプのトラフィックを分類する必要がある場合は、別のクラス マップを別の名前で作成します。クラス マップの基準に関するパケットのマッチングが終わったあとで、ポリシー マップを使用して QoS アクションを指定できます。
ポリシー マップは、各トラフィック クラスに対する QoS アクションを指定します。アクションには、特定の CoS、DSCP、または IP precedence 値の設定、指定されたレートに対するトラフィックのポリシング、トラフィック帯域幅制限の指定、指定されたレートに対するトラフィックのシェーピングが含まれます。ポリシー マップを有効にするには、インターフェイスにポリシー マップを付加する必要があります。
クラス マップを作成するには、 class-map グローバル コンフィギュレーション コマンドを使用します。 class-map コマンドを入力すると、スイッチはクラス マップ コンフィギュレーション モードになります。このモードでは、 match クラス マップ コンフィギュレーション コマンドを使用して、トラフィックの一致基準を定義します。
ポリシー マップを作成して名前を付けるには、 policy-map グローバル コンフィギュレーション コマンドを使用します。このコマンドを入力すると、スイッチはポリシー マップ コンフィギュレーション モードになります。このモードでは、set、police、bandwidth、または shape ポリシー マップ コンフィギュレーション コマンドおよびポリシー マップ クラス コンフィギュレーション コマンドを使用して、特定のトラフィック クラスに対して実行するアクションを指定します。ポリシー マップを有効にするには、 service-policy インターフェイス コンフィギュレーション コマンドを使用して、ポリシー マップをインターフェイスに対応付けます。
ポリシー マップには、ポリサーを定義するコマンド（トラフィックの帯域幅制限）および制限を超過した場合に実行するアクションを含めることもできます。詳細については、「ポリシングおよびマーキング」を参照してください。
ポリシングおよびマーキング
ポリシングを行うには、トラフィックの帯域幅制限を指定するポリサーを作成します。この制限を超過するパケットは、 アウト オブ プロファイル つまり 不適合 パケットです。各ポリサーは、イン プロファイルまたはアウト オブ プロファイル パケットに対して実行すべきアクションを指定します。これらのアクション（マーカーによって実行される）では、パケットを変更せずにそのまま通過させること、パケットをドロップすること、または、設定変更可能なポリシング済み DSCP マップから得られる新しい DSCP 値にパケットをマークダウンすることが可能です。ポリシー マップ クラス コンフィギュレーション モードで police コマンドを使用して、ポリシー マップ内のポリサーを設定できます。ポリシング済み DSCP マップの詳細については、「キューイングおよびスケジューリング」を参照してください。
ポリシングおよびポリサーを設定する場合、次の点に注意してください。
• Supervisor Engine 7-E では、ポリサーがポリサー レートの計算時にレイヤ 2 ヘッダー長のみを考慮します。これに対し、シェーパーは、レートの計算でヘッダーの長さだけでなく IPG も考慮します。
• 設定できるのは、平均レートおよび認定バースト パラメータだけです。
• ポリシー マップおよびポリシング アクションを設定したあと、 service-policy インターフェイス コンフィギュレーション コマンドを使用して、入力インターフェイスまたは出力インターフェイスにポリシーを付加します。
• 2 レート 3 カラー（2r3c）ポリサーの場合は、違反アクションが明示的に指定されていなければ、超過アクションが違反アクションとして使用されます。
キューイングおよびスケジューリング
Supervisor Engine 7-E ハードウェアは、ポートごとに 8 つの送信キューをサポートします。パケットをポートから転送する決定が下されると、出力 QoS 分類によって、パケットを入れる送信キューが決定されます。
出力ポリシーが、1 つまたは複数のトラフィックのクラスに対する 1 つまたは複数のキューイング関連アクションでポートに付加されるとき、キューが割り当てられます。1 つのポートにはキューが 8 つしかないため、キューイング アクションを伴うトラフィック クラスは最大で 8 つです（予約クラスの class-default を含む）。キュー アクションを持たないトラフィックのクラスは、キューイングなしクラスと呼ばれます。非キューイング クラス トラフィックでは、class-default に対応するキューが使用されます。
AQM
Active Queue Management（AQM）は、バッファ オーバーフローが発生する前に輻輳に関して通知する先行型の手法です。AQM は、Dynamic Buffer Limiting（DBL）を使用して実行されます。DBL はスイッチ内の各トラフィックのキュー長を追跡します。フローのキュー長が上限を超えた場合は、DBL がパケットをドロップします。
送信キュー間のリンク帯域幅の共有
送信ポート用の 8 つの送信キューが、そのポートで使用可能なリンク帯域幅を分け合います。クラス モードで policy-map class コンフィギュレーション コマンド内の bandwidth コマンドを使用して、送信キュー間で個別に共有されるようにリンク帯域幅を設定できます。
ストリクト プライオリティ/低遅延キューイング
Supervisor Engine 7-E では、1 つのポート上で完全優先（低遅延キューまたは LLQ）として設定できる送信キューは 1 つだけです。
LLQ では、トラフィック クラスに対して完全優先キューイングが提供されます。これにより、他のキューのパケットの前に、音声など遅延の影響を受けやすいデータを送信できます。プライオリティ キューは、空になるまで、または、シェーピング レートを下回るまで、最初に処理されます。クラスレベル ポリシーごとのプライオリティ キューの宛先にできるのは、1 つのトラフィック ストリームだけです。クラス モードで priority policy-map class コンフィギュレーション コマンドを使用して、トラフィック クラスのプライオリティ キューをイネーブルにします。
トラフィック シェーピング
トラフィック シェーピングは、トラフィックが設定上の最大送信速度に従うように、発信トラフィックの速度を制御する能力を提供します。ある制限に適合するトラフィックを、ダウンストリーム トラフィックの速度要件を満たすようにシェーピングし、データ速度の不一致を解消できます。
各送信キューは、クラス モードで policy-map class コンフィギュレーション コマンド内の shape コマンドを使用して、最大レートで送信するように設定できます。
この設定により、トラフィックの最大速度を指定できます。設定されたシェープ レートを超過するトラフィックは、キューに格納されたあと、設定された速度で送信されます。バースト トラフィックによってキューの容量を超過した場合には、設定されたシェープ レートを維持するために、パケットがドロップされます。
パケットの変更
パケットの分類、ポリシング、およびキューイングによって、QoS が提供されます。次のプロセスで、パケットの変更が行われることがあります。
• IP パケットの場合、分類によって、パケットに DSCP が割り当てられます。ただし、この段階でパケットは変更されません。割り当てられた DSCP が伝送されるだけです。その理由は、QoS の分類と ACL の検索が並行して実行され、ACL によってパケットの拒否とロギングが指示される場合があるためです。この状況では、パケットは元の DSCP 付きで CPU に転送され、CPU で再び ACL ソフトウェアによって処理されます。
• IP 以外のパケットの場合、分類によってパケットに内部 DSCP が割り当てられますが、非 IP パケットに DSCP はないので、上書きは行われません。代わりに、内部 DSCP がキューイングおよびスケジューリング決定の両方で使用され、さらにパケットが ISL または 802.1Q トランク ポートのいずれかで送信される場合、タグへの CoS プライオリティ値の書き込みに使用されます。
• ポリシングでは、IP パケットおよび IP 以外のパケットに別の DSCP が割り当てられます（パケットがアウト オブ プロファイルであり、なおかつポリサーでマークダウン DSCP が指定されている場合）。この場合にも、パケットの DSCP は変更されませんが、マークダウン後の値が伝えられます。IP パケットの場合、あとの段階でパケットの変更が行われます。
PVQoS
PVQoS により、トランク ポート上の個別の VLAN に差別化された QoS が提供されます。この機能により、サービス プロバイダーはビジネスまたは住宅への各トランク ポートの個々の VLAN ベース サービスをレート制限できるようになります。企業の Voice over IP（VoIP）環境で、攻撃者が IP Phone になりすましている場合でも、この機能を使用して音声 VLAN をレート制限できます。ポート単位/VLAN 単位サービス ポリシーは、入力トラフィックまたは出力トラフィックのいずれかに別々に適用できます。設定方法については、「PVQoS のイネーブル化」を参照してください。
フローベース QoS
（注） このセクションを読む前に、Flexible Netflow（第 30 章「Flexible NetFlow の設定」）と QoS の実装を理解しておく必要があります。
フローベース QoS を使用すれば、マイクロフロー ポリシングおよびマーキング機能でトラフィック フローを動的に学習することができます。また、フローごとにレートを制限することができます。フローベース QoS は、NetFlow ハードウェアが内蔵された Supervisor Engine 7-E 上で使用できます。また、Flexible Netflow（FNF）を使用して定義されたフロー マスク付きのスイッチド インターフェイスとルーテッド インターフェイスの両方に適用できます。さらに、ハードウェア上の最大 100,000 の個別フローと、最大 512 の一意のポリサー設定をサポートします。フローベース QoS は、ユーザ単位の細かいレート制限が必要な環境でよく使用されます。たとえば、フロー単位の発信トラフィックと着信トラフィックのレートが異なる場合です。フローベース QoS は、User Based Rate Limiting（UBRL）とも呼ばれています。
フローは、FNF フロー レコード内のキー フィールドで定義されたものとプロパティが同じパケットのストリームとして定義されます。パケットのキー フィールド内の値が既存のフローに対して一意の場合に、新しいフローが作成されます。
フローベース QoS ポリシーには、FNF フロー レコードに対して照合する 1 つ以上のクラス マップが含まれています。このようなクラス マップは、その中で指定されたすべての一致基準を満たす match-all として設定する必要があります。フローベース QoS ポリシーが QoS ターゲットに対応付けられている場合は、最初に、ターゲット上の入力トラフィックがクラス マップ内で指定された分類ルールに基づいて分類されます。分類基準に FNF フロー レコードが含まれている場合は、FNF フロー レコード内で指定されたキー フィールドが、フローが存在しなかったときにフローを作成するための分類済みトラフィックに適用されます。その後で、対応するポリシー アクション（ポリシングとマーキング）がこれらの個別のフローに適用されます。フローベース ポリサー（マイクロフロー ポリサーとも呼ばれる）はフローごとにレートを制限します。フローは動的に作成され、非アクティブ フローは定期的にドロップされます。
フローベース QoS ポリシーは、ポート（P）、VLAN（V）、ポート単位/VLAN 単位（PV）、EtherChannel などの QoS ターゲットに対応付けることができますが、入力方向に限定されます。
FNF のイネーブル化方法については、「フローベース QoS ポリシーの適用」を参照してください。
QoS の設定
（注） HQoS は Supervisor Engine 7-E でサポートされていません。
• 「プラットフォームでサポートされる分類基準および QoS 機能」
• 「分類」
• 「ポリシング」
• 「シェーピング、共有（帯域幅）、プライオリティ キュー、キュー制限、および DBL」
MQC ベースの QoS の設定
Cisco IOS Release 15.0(1)XO 以降では、Supervisor Engine 7-E を使用しているスイッチが QoS の MQC モデルを採用しています。QoS を適用するには、次の作業を完了できる CLI 構造であるモジュラ QoS コマンドライン インターフェイス（MQC）を使用します。
• トラフィック クラスの定義に使用する一致基準を指定します。
• トラフィック ポリシー（ポリシー マップ）を作成します。トラフィック ポリシーは、各トラフィック クラスに実行する QoS ポリシー アクションを定義します。
• ポリシー マップで指定されたポリシー アクションをインターフェイス、VLAN、またはポートおよび VLAN に適用します。
MQC についての詳細は、『 Cisco IOS Quality of Service Solutions Configuration Guide, Release 12.3 』の「Modular Quality of Service Command-Line Interface」を参照してください。
（注） デフォルトで、着信トラフィックは信頼できると見なされます。インターフェイスで信頼境界機能がイネーブルの場合だけ、ポートを非信頼モードにすることができます。このモードでは、スイッチは IP パケットの DSCP 値とイーサネット フレーム上にある VLAN タグの Cos 値を「0」とマークします。
プラットフォームでサポートされる分類基準および QoS 機能
次の表に、Supervisor Engine 7-E でサポートされているさまざまな分類基準とアクションの概要を示します。詳細については、『Catalyst 4500 Series Switch Command Reference』を参照してください。
|
|
|
|
|
|
CIR と PIR（Peak Information Rate； 最大情報レート）の 2 つのレートを使用して、トラフィック ポリシングを設定します。 |
|
IPv4 の ToS バイトまたは IPv6 パケットのトラフィック クラス バイトで DSCP 値を設定して、パケットにマークを付けます。 |
|
プラットフォーム ハードウェアの機能
QoS サービス ポリシーを適用するための前提条件
スイッチ QoS モデルとは異なり、さまざまなターゲットで QoS をイネーブルにするための前提条件はありません。サービス ポリシーを適用すれば QoS がイネーブルになり、そのポリシーの適用を解除すると、ターゲット上で QoS がディセーブルになります。
QoS サービス ポリシーの適用に関する制約事項
インターフェイス、VLAN、またはポートおよび VLAN 上で、トラフィック マーキングを設定できます。インターフェイスは、レイヤ 2 アクセス ポート、レイヤ 2 スイッチ トランク、レイヤ 3 ルーテッド ポート、または EtherChannnel が考えられます。ポリシーは、vlan configuration モードを使用して VLAN に付加されます。
QoS サービス ポリシーの VLAN および EtherChannel への適用については、「ポリシーの関連付け」を参照してください。
分類
Supervisor Engine 7-E は、レイヤ 2、IP、および IPv6 パケットの分類をサポートします。入力に対して実行される ARP パケット マーキングは出力方向で照合できます。前述の表では、すべての機能が一覧になっています。デフォルトで、Supervisor Engine 7-E は分類リソース共有もサポートします。
デフォルトで、ポート、VLAN、またはポート単位/VLAN 単位 ターゲットに同じポリシーが適用されている場合は、ACL エントリが Supervisor Engine 7-E 上で共有されます。CAM エントリが共有されている場合でも、QoS アクションはターゲットごとに異なります。
ポリシーマップ p1 がインターフェイス Gig 1/1 および Gig 1/2 に適用されている場合、1 つの CAM エントリ（IP パケットに一致する 1 つの ACE）が使用されますが、2 つのポリサー（ターゲットごとに 1 つずつ）が割り当てられます。したがって、dscp 50 を伴うすべての IP パケットがインターフェイス Gig 1/1 上で 1 Mbps にポリシングされ、インターフェイス Gig 1/2 上のパケットも 1 Mbps にポリシングされます。
（注） Cisco IOS Release 12.2(46)SG では、match protocol arp コマンドを実行できます。詳細については、『Catalyst 4500 Series Switch Cisco IOS Command Reference』を参照してください。
分類統計
Supervisor 7-E は、分類統計に基づくパケットしかサポートしません。
また、Supervisor 7-E は TCAM リソース共有をサポートします。ポリシー マップが複数のターゲットに適用されている場合は、show policy-map interface コマンドによって、インターフェイスに依存しない集約分類統計が表示されます。
（注） インターフェイス単位のポリシー マップ統計を取得するには、インターフェイスごとに一意のポリシー マップ名を設定する必要があります。
ポリシー マップの設定
1 つのインターフェイスに対応付けられるポリシー マップは 1 つだけです。ポリシー マップには、一致基準とアクションがそれぞれ異なる 1 つまたは複数のポリシー マップ クラスを含めることができます。
インターフェイスで受信するトラフィック タイプごとに、個別のポリシー マップ クラスをポリシー マップ内に設定します。各トラフィック タイプ用のすべてのコマンドを、同一のポリシー マップ クラスに入れます。QoS が、一致したトラフィックに複数のポリシー マップ クラスのコマンドを適用することはありません。
ポリシー マップの作成
|
|
|
|---|---|
|
|
インターフェイスへのポリシー マップの対応付け
ポリシング
Supervisor Engine 7-E は、次の動作モードでポリサーをサポートします。
• Single Rate Policer Two Color Marker
この種類のポリサーは、CIR と通常バーストでだけ設定され、conform アクションと exceed アクションだけがあります。
これは、Supervisor Engine II-Plus から V-10GE ベース システムでサポートされる唯一の形式です。
Supervisor Engine 7-E は、16384（16 × 1024、16K）単一レート、単一バースト ポリサーをサポートします。16K ポリサーは、2K ポリサーの バンク 8 個で編成されています。ポリサー バンクは、QoS 設定に従い、ソフトウェアによって動的に割り当てられます（入力または出力ポリサー バンク）。したがって、16K ポリサーは、次のように動的にソフトウェアで分割されます。
これらの数値は、単一レートおよびバースト パラメータをサポートするハードウェア内の個々のポリサー エントリを表します。この数値に基づき、Supervisor Engine 7-E は、次の数のポリサーをサポートします。
• 単一バースト付き 16K 単一レート ポリサー（Two Color Marker）
これらのポリサーは、2K ポリサー バンクの塊で、入力と力の間で分割されます。さまざまなタイプのポリサーは、すべてシステム内に共存できます。ただし、ポリサーの特定タイプ（srTCM、trTCM など）は、128 個のポリサーのブロックとして設定可能です。
（注） 2 つのポリサーが内部で使用するために予約されています。
ポリシングの実装方法
Catalyst 4500 シリーズ スイッチにポリシング機能を実装する方法については、次のリンク先で Cisco IOS マニュアルを参照してください。
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpolsh.html
プラットフォームの制約事項
• マルチポリサー アクションを指定できます（CoS および IP DSCP の設定がサポートされています）。
• 無条件マーキングとポリサー ベース マーキングが同じフィールド（cos、dscp、または precedence）上に存在する場合は、ポリサー ベース マーキングが優先されます。
• ポリサー ベースのサービスポリシーがポートと VLAN の両方に付加されている場合、ポートベースのポリシングがデフォルトで優先されます。特定の VLAN ポリシーを指定ポートで優先させるには、ポート単位/VLAN 単位ポリシーを設定する必要があります。
• PVQoS ポリシーのあるポート チャネルを削除すると、スイッチはクラッシュします。
ネットワーク トラフィックのマーク付け
ネットワーク トラフィックのマーク付けにより、特定のクラスまたはカテゴリに属するトラフィック（つまりパケット）のアトリビュートを設定または変更できます。ネットワーク トラフィックの分類とともに使用すると、ネットワーク トラフィックのマーク付けは、ネットワーク上で多くの QoS 機能をイネーブルにする基礎となります。ここでは、ネットワーク トラフィックのマーク付けのための概念的情報と設定作業を説明します。
内容
ネットワーク トラフィックのマーク付けに関する情報
ネットワーク トラフィックのマーク付けの目的
トラフィック マーキングは、特定のトラフィック タイプを識別して個別に処理し、ネットワーク トラフィックを異なるカテゴリに分割するために使用されます。
トラフィック分類でネットワーク トラフィックをクラスに編成したあとには、トラフィック マーキングにより特定クラスに属するトラフィックに対して値（アトリビュート）をマーク付け（つまり設定または変更）できます。たとえば、あるクラスで CoS 値を 2 から 1 に変更したり、別のクラスで DSCP 値を 3 から 2 に変更したりします。ここでは、これらの値はアトリビュートまたはマーキング フィールドと呼ばれています。
ネットワーク トラフィックのマーク付けの利点
トラフィック マーキングにより、ネットワーク上のトラフィックのアトリビュートを細かく調整できます。より細かく調整できるようになったことで、特別な処理が必要なトラフィックを分離し、それによって最適なアプリケーション パフォーマンスの実現に役立ちます。
トラフィック マーキングにより、ネットワーク トラフィックのアトリビュートがどのように設定されているのかに基づき、トラフィックを処理する方法を決定できます。これにより、ネットワーク トラフィックは、次のようにアトリビュートに基づいて複数のプライオリティ レベルまたは CoS にセグメント化できます。
• トラフィック マーキングは、ネットワークに入っていくトラフィックの IP Precedence 値または IP DSCP 値の設定によく使用されます。ネットワーク内のネットワーク デバイスは、新たにマーク付けされた IP Precedence 値を使用して、トラフィックの処理方法を決定します。たとえば、音声トラフィックには特定の IP Precedence または DSCP でマーク付けし、そのマーキングのすべてのパケットをキューに入れるように完全優先を設定できます。この場合、マーキングは完全優先キューのトラフィックを識別するために使用されます。
• トラフィック マーキングは、クラスベースの QoS 機能（一部、制約事項があるものの、ポリシー マップ クラス コンフィギュレーション モードで使用可能な機能）のトラフィックを識別するために使用できます。
• トラフィック マーキングは、スイッチ内の QoS グループにトラフィックを割り当てるために使用できます。スイッチは QoS グループを使用し、送信用にトラフィックのプライオリティを設定する方法を決定します。通常 QoS グループ値は、次の 2 つの理由のうちいずれかのために使用されます。
– 広範囲のトラフィック クラスを利用するため。QoS グループ値には、DSCP に類似する、64 の異なる個別マーキングがあります。
トラフィック アトリビュートをマーク付けする 2 つの方法
（注） ここでは、ポリサー ベースのマーキングとは異なる無条件マーキングを説明します。無条件マーキングは、分類にだけ基づきます。
ポリシー マップで設定された set コマンドを使用して、変更するトラフィック アトリビュートを指定します。次の表に、使用可能な set コマンドと対応するアトリビュートを示します。set コマンドの詳細については、『Catalyst 4500 Series Switch Command Reference』を参照してください。
|
|
|
|
|---|---|---|
個別の set コマンドを使用している場合、それらの set コマンドはポリシー マップで指定されます。次に、 表 31-2 に一覧になっている set コマンドの 1 つで設定されたポリシー マップの例を示します。
この設定例では、set cos コマンドがポリシー マップ（policy1）で設定され、CoS アトリビュートをマーク付けしています。
ポリシー マップの設定の詳細については、「ポリシー マップの作成」を参照してください。
最後の作業として、インターフェイスにポリシー マップを付加します。インターフェイスへのポリシー マップの付加の詳細については、「インターフェイスへのポリシー マップの対応付け」を参照してください。
トラフィック アトリビュートのマーク付けに使用できるテーブル マップを作成できます。テーブル マップとは、1 つのトラフィック アトリビュートを別のトラフィック アトリビュートにリストしてマップする、一種の 2 方向変換チャートです。テーブル マップは、多数対 1 タイプの変換とマッピング スキームをサポートします。テーブル マップは、トラフィック アトリビュートの to-from 関係を確立し、アトリビュートに行われる変更を定義します。つまりアトリビュートは、別の値から取得された 1 つの値に設定されます。値は、変更される特定のアトリビュートに基づきます。たとえば、Precedence アトリビュートは 0 ～ 7 の数値に、一方 DSCP アトリビュートは 0 ～ 63 の数値にそれぞれ設定できます。
次の表に、テーブル マップを使用して to-from 関係を確立できるトラフィック アトリビュートの一覧を示します。
|
|
|
|---|---|
次に、前に作成したテーブル マップ（table-map1）を使用するように設定されたポリシー マップ（policy2）の例を示します。
この例では、テーブル マップで定義されたように、CoS アトリビュートと DSCP アトリビュートの間にマッピング関係が確立されています。
テーブル マップを使用するためのポリシー マップの設定の詳細については、「ポリシー マップの設定」を参照してください。
最後の作業として、インターフェイスにポリシー マップを付加します。インターフェイスへのポリシー マップの付加の詳細については、「インターフェイスへのポリシー マップの対応付け」を参照してください。
アクション ドライバのマーク付け
マーキング アクションは、2 つの QoS 処理手順のうちの 1 つに基づいてトリガーされます。
分類ベース：この場合、クラスに一致するすべてのトラフィックは、明示的方法またはテーブルマップ ベースの方法のいずれかを使用してマーク付けされます。この方法は、無条件マーキングと呼ばれます。
ポリサー結果ベース：この場合、トラフィックのクラスは、パケットで使用可能なポリサー結果（conform/exceed/violate）に基づいて、別にマーキングされます。この方法は、条件付きマーキングと呼ばれます。
トラフィック マーキング手順のフローチャート
図 31-3 に、トラフィック マーキングの設定手順の順番を示します。
ネットワーク トラフィックのマーク付けに関する制約事項
パケット マーキング アクションには、次の制約事項が適用されます。
マルチアトリビュート マーキングのサポート
Supervisor Engine 7-E は、トラフィック クラスと一致するパケットの複数の QoS アトリビュートをマークできます。たとえば、DSCP、CoS、および QoS グループは、明示的マーキングまたはテーブルマップベース マーキングのいずれかを使用して、すべて一緒に設定できます。
（注） 複数フィールドまたはポリサーベース マルチフィールドの無条件明示的マーキングを使用している場合は、ToS または CoS マーキング テーブルで設定可能なテーブルマップ数をマークするマルチリージョン（conform/exceed/violate）が、サポートされている最大数より少なくなります。
マーキング用のハードウェア機能
Supervisor Engine 7-E は、パケットを送信、マークダウン、ドロップするポリサー アクションだけでなく、CoS および DSCP/Precedence フィールドでのマーキング アクションの種類を各エントリが指定する、256 エントリのマーキング アクション テーブルを提供します。このテーブルは、入力および出力の各方向でサポートされます。このテーブルは、無条件マーキングとポリサーベース マーキングの両方に使用されます。256 の一意のマーキング アクションまたは 64 の一意のポリサーベース アクション、またはこの 2 つの組み合わせをサポートするために使用可能です。
各マーキング フィールド（CoS および DSCP）のために、Supervisor Engine 7-E は、各方向に 512 エントリのマーキング テーブルを提供します。これらのテーブルは、スイッチ QoS モデルをサポートするスーパーバイザ エンジンで使用可能なマッピング テーブルに類似しています。ただし、ユーザが設定する複数の固有マッピング テーブルを保持する機能を持ちます。
たとえば、ToS マーキング テーブルは、DSCP/Precedence フィールド マーキングを提供し、次のいずれかとして使用できます。
• それぞれが 64 の DSCP または QoS グループ値を他の DSCP にマッピングする 8 つの異なるテーブルマップ
• それぞれが 8 つの CoS（16 の CoS および CFi）値を入力（出力）方向の DSCP にマッピングする 64（32）の異なるテーブルマップ
ポリシー マップ マーキング アクションの設定
ここでは、ネットワーク トラフィックに無条件マーキング アクションを確立する方法を説明します。
前提条件として、クラス マップ（ipp5）とポリシー マップを作成します（「ポリシー マップの設定」を参照）。
（注） Supervisor Engine 7-E で、マーキング アクション コマンド オプションが拡張されました（表 31-2 と表 31-3 を参照）。
テーブルマップベース無条件マーキングの設定
テーブルマップ ベースの無条件マーキングを設定するには、次の作業を実行します。
次に、テーブルマップを使用してマーキング アクションをイネーブルにする例を示します。
ポリサー結果ベースの条件付きマーキングの設定
ポリサー結果ベースの条件付きマーキングを設定するには、単一レートまたはデュアル レート ポリサーを設定します。「ポリシングの実装方法」を参照してください。
次に、各ポリサー リージョンの明示的アクションで Two Rate Three Color ポリサーを設定する例を示します。
マーキング統計
無条件マーキングの場合、分類エントリは、マーク付けされたパケットにあるフィールドを代わりに示すマーキング アクション テーブルのエントリを示します。したがって、分類統計はそれ自身で無条件マーキング統計を示します。
ポリサーを使用する条件付きマーキングでは、ポリサーがパケット レート ポリサーである場合、ポリサーは異なるポリシング結果のバイト統計だけを提供するため、マーク付けされたパケット数は判別できません。
シェーピング、共有（帯域幅）、プライオリティ キュー、キュー制限、および DBL
Supervisor Engine 7-E は、送信キューを選択するための分類ベース（クラス ベース）モードをサポートします。このモードでは、送信キューは、出力 QoS 分類検索に基づいて選択されます。
Supervisor Engine 7-E ハードウェアは、ポートごとに 8 つの送信キューをサポートします。パケットをポートから転送することが決定されると、出力 QoS 分類により、パケットが入れられる必要がある送信キューが決定されます。
デフォルトで、ポートにサービス ポリシーが関連付けられていない Supervisor Engine 7-E には、帯域幅や優先順位付けの類に関する保証のない 2 つのキュー（制御パケット キューとデフォルト キュー）があります。唯一の例外は、制御トラフィックに多少の最小リンク帯域幅が与えられるように、システム生成制御パケットが制御パケット キューに入れられることです。
出力ポリシーが、1 つまたは複数のトラフィックのクラスに対する 1 つまたは複数のキューイング関連アクションでポートに付加されるとき、キューが割り当てられます。ポートごとに 8 つのキューしかないので、キューイング アクションを持つトラフィック クラスは最大でも 8 つ（予約クラス、class-default を含む）となります。キュー アクションを持たないトラフィックのクラスは、キューイングなしクラスと呼ばれます。キューイングなしのクラス トラフィックは、最終的にクラス class-default に対応するキューを使用します。
キューイング ポリシー（キューイング アクションを伴うポリシー）が対応付けられている場合は、制御パケット キューが削除され、制御パケットが分類ごとに関連キューに入れられます。これは、制御トラフィックが Catalyst 4924、Catalyst 4948、Catalyst 4948-10GE、および Supervisor Engine II+、II+10GE、VI、V、V-10GE で優先されるのとは方法が異なります。これらのプラットフォームでは、QoS が設定されているかどうかに関係なく、制御トラフィックにデフォルトで 25 % のリンク帯域幅が保証されていました。Supervisor Engine 7-E 上でもこの動作が必要な場合は、出力 QoS クラスを一致するように設定する必要があります。
IP Precedence 6 および 7 トラフィックと帯域幅保証を設定する必要があります。
キューのダイナミックなサイズ変更（キュー制限クラスマップ アクション）は、 queue-limit コマンドを使用することでサポートされています。シャーシとライン カードの種類に基づいて、ポート上の 8 つのキューすべては、同じキュー サイズで設定されます。
シェーピング
シェーピングにより、キューにあるアウト オブ プロファイル パケットを遅延させて指定のプロファイルに適合させることができます。シェーピングは、ポリシングとは異なります。ポリシングは、設定したしきい値を超えたパケットをドロップしますが、シェーピングは、パケットをバッファし、トラフィックを指定のしきい値内に保ちます。シェーピングでは、トラフィックの処理がポリシングよりも滑らかに行われます。policy-map クラス コンフィギュレーション コマンドを使用して、トラフィック クラスの平均レート トラフィック シェーピングをイネーブルにします。
Supervisor Engine 7-E は、約 ± 0.75% の精度で 32 Kbps ～ 10 Gbps の範囲のシェーピングをサポートします。
キューイング クラスが明示的シェーピング設定を使用せずに設定されているとき、キュー シェーピングはリンク レートに設定されます。
サービス ポリシー内でクラスレベル シェーピングを設定するには、次の手順を実行します。
既存のポリシー マップを削除するには、no policy-map policy-map-name グローバル コンフィギュレーション コマンドを使用します。既存のクラスを削除するには、no class class-name policy-map コンフィギュレーション コマンドを使用します。平均レート トラフィック シェーピングをディセーブルにするには、no shape average policy-map クラス コンフィギュレーション コマンドを使用します。
次に、クラスレベル、平均レート シェーピングを設定する例を示します。ここでは、トラフィック クラス class1 をデータ伝送レート 256 Kbps に制限します。
次に、queuing-class トラフィックについて、クラスレベル、平均シェーピング パーセンテージを、リンク帯域幅の 32% に設定する例を示します。
共有（帯域幅）
トラフィックのクラスに割り当てられた帯域幅は、輻輳中にクラスに対して保証される最小帯域幅です。送信キュー シェーピングは、出力リンク帯域幅が指定ポートの複数キューで共有されるプロセスです。
Supervisor Engine 7-E は、約 ± 0.75% の精度で 32 Kbps ～ 10 Gbps の範囲の共有をサポートします。すべてのキューイング クラスにわたる設定帯域幅の合計は、リンク帯域幅を超えないようにしてください。
サービス ポリシーにクラスレベル帯域幅アクションを設定するには、次の手順を実行します。
既存のポリシー マップを削除するには、no policy-map policy-map-name グローバル コンフィギュレーション コマンドを使用します。既存のクラスを削除するには、no class class-name policy-map コンフィギュレーション コマンドを使用します。デフォルトの帯域幅に戻すには、no bandwidth policy-map クラス コンフィギュレーション コマンドを使用します。
次に、prec1、prec2、および prec3 という 3 つのクラスに対して、policy11 という名前のクラスレベル ポリシー マップを作成する例を示します。これらのクラスのポリシーでは、最初のクラスのキューに 30%、2 番めのクラスのキューに 20%、3 番めのクラスのキューに 10% の使用可能帯域幅が、それぞれ割り当てられます。
次に、prec1、prec2、および prec3 という 3 つのクラスに対して、policy11 という名前のクラスレベル ポリシー マップを作成する例を示します。これらのクラスのポリシーでは、最初のクラスのキューに 300 Mbps、2 番めのクラスのキューに 200 Mbps、3 番めのクラスのキューに 100 Mbps の使用可能帯域幅が、それぞれ割り当てられます。
キューで最小帯域幅が保証されないために、キューイング クラスが明示的共有/帯域幅設定を使用せずに設定されている場合、ハードウェア キューはポート上の未割り当て帯域幅の共有を取得するようにプログラミングされます。以下の例を参照してください。
新しいキューに対して帯域幅が残っていない場合、または明示的共有/帯域幅設定を持たないすべてのキューの最小設定可能レート（32 Kbps）を満たすのに未割り当て帯域幅が十分でない場合、ポリシーの関連付けは拒否されます。
同様に、もう 1 つのキューイング クラス（q3 とします）が明示的帯域幅なしで（たとえば、shape コマンドだけで）追加されると、帯域幅割り当ては次のようになります。
プライオリティ キューイング
Supervisor Engine 7-E では、1 つのポート上で完全優先（低遅延キューまたは LLQ）として設定できる送信キューは 1 つだけです。
LLQ では、トラフィック クラスに対して完全優先キューイングが提供されます。これにより、他のキューのパケットの前に、音声など遅延の影響を受けやすいデータを送信できます。プライオリティ キューは、空になるまでまたはシェーピング レートを下回るまで、最初に処理されます。クラスレベル ポリシーごとのプライオリティ キューの宛先にできるのは、1 つのトラフィック ストリームだけです。トラフィック クラスのプライオリティ キューをイネーブルにするには、クラス モードで priority policy-map class コンフィギュレーション コマンドを使用します。
LLQ は、レート制限されていない限り、他のキューを停止させることがあります。Supervisor Engine 7-E は、キューが輻輳すると（キュー長に基づく）、2 パラメータ ポリサー（レート、バースト）が有効になる条件付きポリシングをサポートしません。ただし、完全優先キューに入れられたパケットのレート制限のための無条件ポリサーの適用はサポートします。
プライオリティ キューがポリシー マップの 1 つのクラスで設定されている場合、bandwidth remaining だけが他のクラスに受け入れられ、その他のクラスのための最小帯域幅は、プライオリティ キューの使用後に残されている残りの帯域幅から保証されます。プライオリティ キューがポリサーで設定されている場合は、bandwidth と bandwidth remaining のどちらも他のクラスに受け付けられます。
（注） すべてのクラスに対して、bandwidth または bandwidth remaining を使用してください。1 つのポリシー マップ内で 1 つのクラスに bandwidth を適用して、別のクラスに bandwidth remaining を適用することはできません。
サービス ポリシーにクラスレベル プライオリティ キューイングを設定するには、次の手順を実行します。
既存のポリシー マップを削除するには、no policy-map policy-map-name グローバル コンフィギュレーション コマンドを使用します。既存のクラスを削除するには、no class class-name policy-map コンフィギュレーション コマンドを使用します。プライオリティ キューをディセーブルにするには、no priority policy-map class コンフィギュレーション コマンドを使用します。
次に、policy1 というクラスレベル ポリシーを設定する例を示します。class 1 は、プライオリティ キューとして設定され、空になるまで最初に処理されます。
キュー制限
クラスベース キューが物理ポートでインスタンス化される際に、デフォルト サイズで設定されます。このサイズは、このトラフィック クラスに属するパケットがキューイング可能なキュー エントリの数を表します。スケジューラは、キュー シェーピング、帯域幅、およびプライオリティ設定に基づいて、すでに送信可能なキューからパケットを移動します。
キュー制限は、指定時間内のキュー内にあるパケットの最大数を指定します。キューが一杯になった場合に、後続のパケットをキューイングしようとするとテール ドロップになります。ただし、DBL がキューでイネーブルである場合は、キューが一杯になっていなくても DBL アルゴリズムに基づいてパケットが確率的にドロップされます。
帯域幅、シェーピング、またはプライオリティなどのキュー スケジューリングがすでに設定されている場合だけ、 queue-limit コマンドをクラスの下に設定できます。この要件の例外は、クラスデフォルト クラス上でスタンドアロン queue-limit コマンドをサポートしている場合です。
キュー メモリ
割り当て可能なキュー エントリの数は、16 ～ 8184 の範囲内の 8 の倍数です。クラスベース キューが物理ポートでインスタンス化される際に、デフォルトのエントリ数が与えられます。このデフォルト キュー サイズは、シャーシ内のスロット数と、各スロットの前面パネル ポート数に基づいています。
Supervisor Engine 7-E には、1M（1,048,576）のキュー エントリがあり、そのうち 100K（102,400）のキュー エントリが空きリザーブ プールに保留されています。残りの 412K（421,88）のうち、ドロップ ポートに 8,184 エントリが割り当てられ、CPU ポートに 11,704 エントリが割り当てられています。残りのエントリは、シャーシ内のスロットに均等に分割されます。冗長シャーシ内では、このエントリ分配のために 2 つのスーパーバイザ スロットが 1 つとして扱われます。各スロット内では、そのスロットにあるライン カード上に存在する前面パネルのポート間でキュー エントリの数が均等に分割されます。
インターフェイス上にあるキュー エントリのユーザ設定が専用割り当て分を越えた場合、システムが空いているリザーブ プールを活用して設定に対応しようとします。空いているリザーブ プールからのエントリは、先着順でインターフェイスに割り当てられます。
サーバ ポリシーの関連付け
キューイング アクションのある QoS サービス ポリシーが設定されているものの、明示的に queue-limit コマンドが物理インターフェイスの出方向に添付されていない場合、クラスベースの各キューはその物理ポートの専用割り当て分から同数のキュー エントリを取得します。queue-limit コマンドを使用してキューに明示的にサイズが指定されている場合、スイッチはインターフェイスの専用割り当てから全エントリを割り当てようとします。必要なエントリ数がインターフェイスの専用割り当て分を越える場合、スイッチは空いているリザーブからエントリを割り当てようとします。
キューに関連付けられたキュー エントリは常に連続している必要があります。この要件により、スイッチ間で共有されている 512K のキューエントリにフラグメンテーションが発生する可能性があります。たとえば、あるインターフェイスで専用割り当て分のキュー エントリが十分ない場合、そのキューを設定するために空いているリザーブ分を使用することになります。この場合、他のポートやスロットと共有できないため、専用割り当て分のキュー エントリは未使用のままになります。
インターフェイスに関連付けられている QoS サービスポリシーが削除された場合、空いているリザーブ分から取得したキュー エントリは空いているリザーブ プールに戻されます。インターフェイス キューイング コンフィギュレーションは、2 つのキュー（デフォルトのシェーピング、帯域幅、サイズを持つクラスデフォルトおよび制御パケット キュー）に戻ります。制御パケットキューはサイズ 16 で設定されていて、デフォルト キューはインターフェイスの専用割り当て分に基づいて可能な最大サイズに設定されています。
キュー割り当て障害
キュー メモリのフラグメンテーションや十分な空いているリザーブ エントリがないために、スイッチがインターフェイス上の 1 つまたは複数のキューで必要な明示的キュー サイズを満たすことができない場合があります。このシナリオでは、スイッチはエラー メッセージをログして、ユーザに障害を通知します。QoS サービス ポリシーはインターフェイス上に設定されたままになります。QoS サービスポリシーを削除し、スイッチ上の他のポートで、空いているリザーブ分からキュー エントリの現在の利用率を調査することで、エラーを修復することができます。
サービス ポリシーにクラスレベル queue-limit を設定するには、次の手順を実行します。
明示的キュー サイズを削除するには、ポリシーマップ内のクラスで no queue-limit コマンドを使用します。
次に、明示的な queue-limit コマンドを使用してクラスベースのキューを設定する例を示します。ここでは、トラフィック クラス class1 をキュー サイズ 4048 に制限します。
DBL を経由した AQM
AQM は、パケットをポートの送信キューに入れる前の、トラフィック フローのバッファ制御を提供します。この機能は、共有メモリ スイッチで非常に役立ち、特定のフローによるスイッチ パケット メモリの占有が行われないようにします。
（注） Supervisor Engine 7-E は、DBL 経由のアクティブ スイッチ バッファ管理をサポートします。
トラフィックのデフォルト クラス（クラス class-default）を除き、他のキューイング アクションが少なくとも 1 つ設定されている場合にだけ DBL アクションを設定できます。
サービス ポリシーのシェーピングとともにクラスレベル DBL アクションを設定するには、次の手順を実行します。
既存のポリシー マップを削除するには、no policy-map policy-map-name グローバル コンフィギュレーション コマンドを使用します。既存のクラスを削除するには、no class class-name policy-map コンフィギュレーション コマンドを使用します。関連付けられたキューで DBL をディセーブルにするには、no dbl policy-map class コンフィギュレーション コマンドを使用します。
次に、クラスレベルの DBL アクションを平均レート シェーピングとともに設定する例を示します。トラフィッククラス class1 に関連付けられたキューで DBL をイネーブルにします。
送信キューの統計
送信キューの統計情報を表示するには、show policy-map interface コマンドを使用します。
PVQoS のイネーブル化
PVQoS 機能を使用すれば、指定したインターフェイス上の複数の VLAN 上で複数の QoS 設定を指定できます。通常、この機能は、トランク ポートや音声 VLAN（シスコ製 IP 電話機）ポートなどの複数の VLAN に属しているポート上で使用します。
例 1
図 31-4 に、PVQoS 構成のトポロジ例を示します。トランク ポート gi3/1 は、複数の VLAN（101 および 102）で構成されています。ポート内部には、独自のサービス ポリシーを VLAN 単位で作成できます。このポリシーは、ハードウェアで実行され、入出力ポリシングまたはデータを上回る音声パケットの優先処理で構成されます。
次のコンフィギュレーション ファイルでは、ギガビット イーサネット ポート 3/1 に適用されるポリシーマップ P31_QOS を使用して、VLAN 単位で入力および出力ポリシングを実行する方法について示しています。
match ip access-group 101
match ip access-group 103
Class RT
Police 200m 16k conform transmit exceed drop
Class PD
Police 100m 16k conform transmit exceed drop
例 2
たとえば、ギガビット イーサネット インターフェイス 6/1 がトランク ポートで、VLAN 20、300 ～ 301、および 400 に属しているとします。次に、VLAN 20 と VLAN 400 内のトラフィックにポリシー マップ p1 を、VLAN 300 ～ 301 内のトラフィックにポリシー マップ p2 を適用する例を示します。
例 3
次に、ギガビット イーサネット インターフェイス 6/1 上で設定された VLAN 20 のポリシー マップ統計情報を表示する例を示します。
例 4
次に、ギガビット イーサネット インターフェイス 6/1 上で設定されたすべての VLAN のポリシーマップの統計情報を表示する例を示します。
ポリシーの関連付け
Supervisor Engine 7-E は、ポート単位/VLAN 単位ポリシーをサポートします。関連付けられたポリシーは、インターフェイス、VLAN、および指定ポートの特定 VLAN にそれぞれ付加されます。
ポリシーは、さまざまなオブジェクトに関連付けることができます。次の表に、オブジェクトと許可されているアクションを示します。
|
|
|
|---|---|
QoS アクションの制約事項
• 異なるターゲット上で指定した方向に同じアクションを複数回実行することはできません。つまり、入力方向のポートと VLAN の両方でパケットをポリシングすることはできません。ただし、入力ポートと出力 VLAN 上ではポリシングできます。
• キューイング アクションは、物理ポートの出力方向でだけ許可されます。
• ポリサーなどのパーセンテージ ベース アクションは、VLAN、ポートと VLAN（PV）、および EtherChannel 上で設定することができません。
• ポート チャネルまたは VLAN の設定に持たせることができるのは、ポリシングまたはマーキング アクションだけです。キューイング アクションを持たせることはできません。
QoS ポリシーのプライオリティ
• ポートおよび VLAN 上のポリシーが、競合アクション（ポートと VLAN の両方でのポリシングまたはマーキング アクションなど）で設定されている場合、ポート ポリシーが取得されます。
QoS ポリシーの統合
適用可能ポリシーは、指定方向の指定パケットに適用されます。たとえば、出力 VLAN ベース ポリシングおよびマーキングを設定し、さらにそのポートでの選択的キューイングを設定すると、このパケットに対し、両方のポリシーからのアクションが適用されます。
EtherChannel では、ポリシーマップに関して次の制限事項があります。
• EtherChannel レベルでは、ポリシング アクションとマーキング アクションだけがサポートされます。
• 物理メンバ ポート レベルでは、キューイング アクションだけがサポートされます。
パケットは、EtherChannel ポリシーによってマーキングできます（dscp フィールドまたは cos フィールド）。物理メンバ ポート ポリシーで dscp フィールドまたは cos フィールドに基づいた分類を使用している場合、それはマーキングされた（変更された）値に基づいている必要があります。正しい動作を確保するために、EtherChannel には次の制限事項があります。
物理メンバ ポートのポリシーマップの分類基準は、以下のいずれか 1 つのフィールドだけに基づいていなければなりません。
• 任意の非マーキング フィールド（dscp にも cos にも基づかない分類）
物理メンバ ポートのポリシーマップの分類基準は、フィールドの組み合わせにはできません。この制限事項により、EtherChannel ポリシーが dscp または cos をマーキングしている場合に、マーキングされた（変更された）値に基づく分類を確実にハードウェアに実装できます。
（注） 物理メンバー ポート上でのポリシー マップに関する分類基準は、新しいタイプのフィールドを追加するように変更することができません。
Auto-QoS は EtherChannel でもそのメンバ ポートでもサポートされていません。Auto-QoS で設定されている物理ポートは、物理ポートのメンバになることはできません。
ソフトウェア QoS
最高レベルには、スイッチからローカルで送信された（制御プロトコル パケット、ping、Telnet など）2 種類のトラフィックがあります。この 2 種類とは、高プライオリティ トラフィック（通常は、OSPF Hello や STP などの制御プロトコル パケット）と低プライオリティ パケット（他のすべてのパケット タイプ）です。
ローカルで送信されたパケットの QoS 処理は、2 つの種類で異なります。
Supervisor Engine 7-E には、ソフトウェア パスで処理されたパケットに QoS を適用する方法が用意されています。ソフトウェアでこの QoS 処理を受けるパケットは、ソフトウェア スイッチド パケットとソフトウェア生成パケットの 2 種類に分類できます。
受信時には、ソフトウェア スイッチド パケットは、パケットを代わりに別のインターフェイスから送信する CPU に送信されます。そういったパケットの場合、入力ソフトウェア QoS は入力マーキングを提供し、出力ソフトウェア QoS は出力マーキングとキュー選択を提供します。
ソフトウェア生成パケットは、スイッチによりローカルで送信されたパケットです。これらのパケットに適用された出力ソフトウェア QoS 処理のタイプは、ソフトウェア スイッチド パケットに適用されたタイプと同じです。これら 2 つの処理タイプの唯一の違いは、ソフトウェア スイッチド パケットが、出力分類を目的として、パケットの入力マーキングを考慮する点です。
高プライオリティ パケット
高プライオリティ パケットは、次のいずれかとしてマーク付けされます。
• IP Precedence 6 を使用して（IP パケット用）
• これらのパケットは、出力サービス ポリシーのように設定されたポリシング、AQM、ドロップしきい値（またはパケットをドロップすることができる機能）が原因でドロップされることはありません。ただし、ハードウェア リソースの制約（パケット バッファ、キューが満杯など）が原因でドロップされることはあります。
• これらのパケットは、ポートまたは VLAN である出力サービス ポリシーのマーキング設定に従って、分類およびマーク付けされます（「ポリシーの関連付け」を参照）。
• これらの高プライオリティ パケットは、次の基準に従って出力ポートのキューに入れられます。
– ポートに出力キューイング ポリシーがない場合、パケットは、デフォルト キューとは別に設定され、5% のリンク帯域幅が予約されている制御パケット キューに入れられます。
低プライオリティ パケット
高プライオリティ（前述）と見なされないパケットは、重要ではないと見なされます。これらのパケットには、ローカルで送信された ping、Telnet、およびその他のプロトコル パケットが含まれます。これらのパケットは、指定の伝送ポートを通過する他のパケットと同様に（出力分類、マーキングおよびキューイングを含む）、処理されます。
フローベース QoS ポリシーの適用
フローベース QoS を使用すれば、マイクロフロー ポリシングおよびマーキング機能でトラフィック フローを動的に学習することができます。また、フローごとにレートを制限することができます。フローベース QoS は、NetFlow ハードウェアが内蔵された Supervisor Engine 7-E 上で使用できます。
詳細については、「フローベース QoS」を参照してください。
次に、フローベース QoS ポリシーを QoS ターゲットに適用する手順を示します。
ステップ 1 一意のフローを識別するキー フィールドを指定して、FNF フロー レコードを作成します。FNF モニタに関連付けられた任意の FNF フロー レコードを使用することができます。
ステップ 2 一致基準のセットを指定するためのクラス マップを作成します。ステップ 1 で作成した FNF フロー レコードを match flow record コマンドを使用して、クラス マップ一致基準に含めます。その後で、class-map match-all class_name を使用して、すべての一致基準と一致するようにクラス マップを設定します。
ステップ 3 ポリシー マップを作成して、ステップ 2 で作成したクラス マップに関連付けるアクションを定義します。
ステップ 4 ポリシーを 1 つ以上の QoS ターゲットに対応付けます。
例
例 1
この例では、サブネット 192.168.10.* 上に複数のユーザ（送信元 IP アドレスで識別される）が存在することを前提とします。下のコンフィギュレーションは、マクロ ポリシングを使用して、送信元アドレスが 192.168.10.* の範囲内のユーザ単位トラフィックに制限するフローベース QoS ポリシーの設定方法を示しています。マイクロフロー ポリサーは、CIR が 1Mbps に、「適合アクション」が transmit に、「超過アクション」が drop に設定されます。
ステップ 1：指定された送信元アドレスとトラフィックが一致するように ACL を定義します。
ステップ 2：送信元アドレスをキーとして使用してフローを作成するためのフロー レコードを定義します。
ステップ 3：UserGroup1 に対して一致するようにクラス マップを設定し、フロー作成用のフロー レコード定義を指定します。
ステップ 4：一致するトラフィックに関するマイクロフロー ポリシング アクションでフローベース QoS ポリシー マップを設定します。
ステップ 5：フロー QoS ポリシーをインターフェイスに対応付けます。
ポリシー マップ設定とインターフェイス固有のポリシー マップ統計情報を表示するには、show コマンド（この章のポリシーとマーキングに関するセクションを参照）を使用します。
例 2
この例では、サブネットの 192.168.10.* と 172.20.55.* 上に複数のユーザ（送信元 IP アドレスで識別される）が存在することを前提とします。最初にすべきことは、192 ネットワークから任意の宛先に送信されるすべての TCP トラフィックに対して、常に、500Kbps の CIR と 650Kbps の PIR でポリシングすることです。exceed action キーワードは、dscp 値を 32 に下げます。次にすべきことは、172 ネットワークから送信されるユーザ単位のトラフィックを 2Mbps の CIR でポリシングして、トラフィックの dscp 値を無条件に 10 にすることです。
ステップ 1：指定された送信元アドレスとトラフィックが一致するように ACL を定義します。
ステップ 2：送信元アドレスをキーとして使用してフローを作成するためのフロー レコードを定義します。
ステップ 3：UserGroup1 に対して一致するようにクラス マップを設定し、フロー作成用のフロー レコード定義を指定します。
ステップ 4：一致するトラフィックに関するマイクロフロー ポリシング アクションでフローベース QoS ポリシー マップを設定します。
ステップ 5：フロー QoS ポリシーをインターフェイスに対応付けます。
ポリシー マップ設定とインターフェイス固有のポリシー マップ統計情報を表示するには、QoS セクションで説明した show コマンドを使用します。
例 3
ファスト イーサネット インターフェイス 6/1 上に 2 つのアクティブ フローが存在するとします。
|
|
|
|
|
|
|---|---|---|---|---|
次の設定では、各フローが、許可可能な 9,000 のバースト値を使用して 1,000,000 bps にポリシングされます。
設定時の注意事項
フローベース QoS ポリシーの作成、設定、変更、削除と、フローベース QoS ポリシーのサポートされているターゲットへの対応付け（および対応付け解除）に関する一般的なガイドラインは、QoS セクションで説明したものと同じです。以降の説明と制限が、フローベース QoS ポリシーに適用されます。
• クラス マップには複数の match 文を含めることができますが、1 つのクラス マップで指定できる FNF フロー レコードは 1 つだけです。
• フロー レコードにキー フィールドが含まれていない場合は、クラス マップ内で使用することができません。非キー フィールドをフロー レコード内に含めることができます。ただし、すべてが非キー フィールドの場合はマイクロフロー QoS で無視されます。キー フィールドのみがフロー作成に使用されます。
• FNF フロー レコードがいずれかのクラス マップで参照されている場合は、そのフロー レコードを変更することができません。フロー レコードを変更するには、すべてのクラス マップから削除してください。
• FNF フロー レコードを含むクラス マップは、match-all として設定する必要があります。クラス マップでヒットするトラフィックは、クラス マップ内のすべての一致基準を満たす必要があります。
• ポリシーには複数のクラスを含めることができ、クラス マップごとに同じ FNF フロー レコードを含めることも、別々の FNF フロー レコードを含めることもできます。
• フローベース QoS ポリシーと FNF モニタの両方を同時に同じターゲットに適用することはできません。
• インターフェイス モードがスイッチポートからルーテッド ポートにまたはその逆に変更された場合は、そのポートに対応付けられたすべてのフロー QoS ポリシーがモード変更後も適用されたままになります。
• pv4、ipv6、およびデータリンクの 3 種類の FNF フロー レコードがあります。データリンク フロー レコードは、ipv4 および ipv6 フロー レコードと相互排他的です。データリンク フロー レコードを含むクラス マップは、ipv4 または ipv6 フロー レコードを含むクラス マップと同じポリシー内で共存させることができません。逆も同じです。
• クラス マップの class-default は編集することができません。また、一致フロー レコードを使用して設定することもできません。代わりに、match any フィルタとフロー レコードを使用するクラス マップとフロー レコードを使用して、ポリシーを設定できます。
• トラフィックは、クラス マップがポリシー内で定義されたときと同じ順序で分類されます。そのため、FNF フロー レコードがクラス マップ内の唯一の match 文の場合は、分類基準がフロー レコードで識別されるすべてのパケット タイプと一致します。つまり、同じポリシー内で同じトラフィック タイプと一致するクラス マップは冗長であり、決してヒットすることがありません。
• フロー レコードを含むクラス マップに関連付けられたポリサーはマイクロフロー ポリサーと呼ばれます。マイクロフロー ポリサーの CIR レートと PIR レートは、% キーワードで設定することができません。
• 同じポリシー内のフロー レコードには、別のクラス マップから作成され、フローが一意で区別できることを保証する適切なキー フィールドを含める必要があります。そうでない場合は、別のクラス マップから生成されたフローと区別できません。このような場合は、ハードウェア内で最初のフローを生成したクラス マップに対応するポリシー アクションが適用され、その結果は必ずしも予想どおりになるとは限りません。
• 別々の QoS ターゲット上で受信されたトラフィックからのフローは、それらのターゲットに同じポリシーが適用されている場合でも、区別されます。
• フローが 5 秒を超えて非アクティブだった場合はドロップされます。5 秒より長くフローと一致するトラフィックは存在しません。
• フローがドロップされると、そのフローに関連付けられたポリサー ステート情報も削除されます。新しいフローが作成されると、そのフローのポリサー インスタンスが再初期化されます。
• フローベース QoS ポリシーによって作成されたフローは、ハードウェアにしか存在せず、エクスポートすることができません（FNF モニタと同様）。
• フローベース QoS ポリシーによって作成されたフローに関するフロー単位統計情報は入手できません。
• クラス マップ統計情報には、分類基準と一致するパケット数が表示されます。個別のフロー統計情報は表示されません。
• ポリサー統計情報には、個々のフローの集約ポリサー統計情報が表示されます。
• ハードウェアによって生成されたフローに関する情報は入手できないため、QoS ポリシー マップに関連付けられた show コマンドに表示されません。クラス マップとポリサー統計情報のみが show policy-map コマンドの出力に表示されます。
auto-QoS の設定
（注） auto-QoS は、EtherChannel インターフェイスおよび VLAN には適用できません。
Supervisor Engine II-Plus から V-10GE までの auto-QoS とは異なり、Supervisor Engine 7-E の auto-QoS は MQC モデルを採用しています。これは、特定のグローバル コンフィギュレーション（qos や qos dbl など）を使用する代わりに、Supervisor Engine 7-E を使用したスイッチ上のインターフェイスに適用された auto-QoS によって、いくつかのグローバル クラス マップおよびポリシー マップが設定されることを意味します。
クラス マップの目的は、制御トラフィックとデータ（ベアラ）音声トラフィックがレイヤ 2 インターフェイスかレイヤ 3 インターフェイスかを特定することです。
• policy-map AutoQos-VoIP-Input-Dscp-Policy
このポリシー マップは、Auto-QoS がポート上で設定されるとき、レイヤ 3 インターフェイス（ネイバー スイッチへのアップリンク接続など）に入力サービス ポリシーとして適用されます。
• policy-map AutoQos-VoIP-Input-Cos-Policy
このポリシー マップは、アップリンク接続または Cisco IP Phone にフックされたポートのいずれかの、レイヤ 2 インターフェイスに入力サービス ポリシーとして適用されます。
• policy-map AutoQos-VoIP-Output-Policy
このポリシー マップは、Auto-QoS が設定されている任意のポートの出力ポリシーとして適用され、トラフィックが音声データか制御トラフィックかに従ってポート上で出力トラフィックを管理するポリシーを確立します。
入力ポリシー マップの目的は、音声データまたは制御トラフィック識別し、マーク付けしながらスイッチを通過させることです。出力ポリシー マップは、入力時に発生するマーク付けでパケットに一致させ、帯域幅、ポリシングまたはプライオリティ キューイングなどの出力パラメータを適用します。
Supervisor Engine 7-E を採用しているスイッチ上で auto-QoS を呼び出す場合は、Supervisor Engine II-Plus から V-10GE で使用されていたものと同じ config コマンドを使用します。
スイッチ対スイッチの接続の場合、インターフェイス上での入力および出力サービス ポリシーの適用には、[no] auto qos voip trust コマンドが使用されます。
入力ポリシーの選択は、ポートがレイヤ 2 かレイヤ 3 かに依存します。レイヤ 2 の場合、ポリシーは、受信したパケットの Cos 設定を信頼します。レイヤ 3 ポートの場合、パケットに含まれる DSCP 値に依存します。
電話接続ポートの場合、ポートへの次のサービス ポリシーの適用には、[no] auto qos voice cisco-phone コマンドが使用されます。
ここでは、Cisco IP Phone を認識する信頼境界が確立され、電話からのパケットの CoS 設定を信頼します。Cisco IP Phone が検出されない場合、CoS フィールドは無視され、パケットは音声トラフィックとして分類されません。Cisco Phone が検出されると、パケット内の CoS 値に基づいて入力パケットにマークが付けられます。このマーキングは、出力で適切なトラフィック分類と処理のために使用されます。
フィードバック