この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
パケット分類は、データ パス上で輻輳管理または輻輳回避を必要とするトラフィック フローを識別し、マーキングします。 モジュラ Quality of Service(QoS)コマンドライン インターフェイス(MQC)は、分類する必要のあるトラフィック フローを定義するために使用します。このとき、各トラフィック フローをサービス クラス、またはクラスと呼びます。 その後、トラフィック ポリシーを作成し、クラスに適用します。 定義されたクラスに該当しないトラフィックは、すべてデフォルト クラスのカテゴリに分類されます。
このモジュールでは、QoS パケット分類の概念および設定情報について説明します。
パケットの分類には、特定のグループ(またはクラス)内のパケットを分類し、これにトラフィック記述子を割り当てて、ネットワークで QoS 処理用にアクセスできるようにする処理が含まれます。 トラフィック記述子には、パケットが受ける転送処理(Quality of Service)に関する情報が含まれます。 パケット分類を使用すると、複数のプライオリティ レベルまたは CoS にネットワーク トラフィックを区分できます。 発信元が契約された条項に従うことに同意し、ネットワークが QoS の実行を約束します。 トラフィック ポリサーとトラフィック シェーパーは、契約を順守するために、パケットのトラフィック記述子を使用します。
トラフィック ポリサーおよびトラフィック シェーパーは、IP precedence などのパケット分類機能を使用して、さまざまなタイプの QoS サービスに対して、ルータを通過するパケット(またはトラフィック フロー)を選択します。 たとえば、IP パケット ヘッダーのタイプ オブ サービス(ToS)フィールドの 3 つの precedence ビットを使用すると、最大 8 種類のトラフィック クラスで構成される限定的な設定にパケットを分類できます。 パケットを分類した後、他の QoS 機能を使用して、輻輳管理、帯域幅割り当て、および遅延限度などの適切なトラフィック処理ポリシーを、各トラフィック クラスに割り当てることができます。
(注) |
IPv6 ベースの分類は、レイヤ 3 インターフェイスでのみサポートされています。 |
トラフィック クラスの目的は、ルータのトラフィックを分類することです。 class-map コマンドを使用して、トラフィック クラスを定義します。
トラフィック クラスに含まれる 3 つの主な要素は、名前、一連の match コマンド、そしてトラフィック クラスに複数の match コマンドが存在する場合に match コマンドを評価する方法です。 トラフィック クラスの名前は、 class-map コマンドで指定します。 たとえば、 class-map コマンドで cisco を使用すると、トラフィック クラスの名前は cisco になります。
match コマンドは、パケット分類のためのさまざまな基準を指定するために使用します。 パケットは、 match コマンドで指定された基準に合っているかどうかを判断するために、チェックされます。 指定された基準に合っていれば、パケットはクラスのメンバーと見なされ、トラフィック ポリシーで設定された QoS 仕様に従って転送されます。 一致基準を満たさないパケットは、デフォルトのトラフィック クラスのメンバーとして分類されます。 18 ページの「デフォルト トラフィック クラス」の項を参照してください。
複数の一致基準をトラフィック クラスに指定する場合は、これらの match コマンドを評価する方法の説明を指定する必要があります。 評価の説明は、 class-map match-any コマンドで指定します。 match-any オプションを評価の説明として指定した場合、トラフィック クラスによって評価されるトラフィックは、指定した条件のうち少なくとも 1 つを満たす必要があります。 match- all オプションを指定した場合、トラフィックはすべての一致基準を満たす必要があります。
これらのコマンドの機能については、『Cisco ASR 9000 Series Aggregation Services Routers Modular Quality of Service Command Reference』でより詳細に説明します。 トラフィック クラスの設定作業については、32 ページの「Creating a Traffic Class」の項で説明されています。
トラフィック ポリシーの目的は、ユーザが指定したトラフィック クラスまたはクラスに分類されたトラフィックに関連付ける QoS 機能を設定することです。 トラフィック ポリシーを作成するには、 policy-map コマンドを使用します。 トラフィック ポリシーには、名前、トラフィック クラス( class コマンドで指定)、および QoS ポリシーという 3 つの要素が含まれます。 トラフィック ポリシーの名前は、ポリシー マップの Modular Quality of Service(MQC)で指定します(たとえば、 policy-map policy1 コマンドによって policy1 という名前のトラフィック ポリシーを作成できます)。 指定したトラフィック ポリシーにトラフィックを分類するために使用するトラフィック クラスは、クラス マップ コンフィギュレーション モードで定義します。 トラフィック ポリシーにトラフィックを分類に使用するトラフィック クラスを選択した後で、この分類されたトラフィックに適用する QoS 機能を入力できます。
MQC では、必ずしも 1 つのトラフィック クラスだけを 1 つのトラフィック ポリシーに関連付ける必要はありません。 パケットが複数の一致基準に一致する場合、1 つのトラフィック ポリシーに 1024 のトラフィック クラスを関連付けることができます。 1024 のクラス マップには、デフォルト クラスと子ポリシーのクラスが含まれます(存在する場合)。
クラスをポリシー マップで設定する順序が重要です。 クラスの一致規則は、クラスをポリシー マップで指定した順序で TCAM にプログラミングされます。 したがって、あるパケットが複数のクラスと一致する場合は、最初に一致したクラスだけが返され、対応するポリシーが適用されます。
これらのコマンドの機能については、『 Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Command Reference』でより詳細に説明します。
トラフィック クラスの設定作業については、38 ページの「Creating a Traffic Policy」の項で説明されています。
未分類のトラフィック(トラフィック クラスで指定された一致条件を満たさないトラフィック)は、デフォルト トラフィック クラスに属するものとして扱われます。
ユーザがデフォルト クラスを設定しない場合でも、パケットはデフォルト クラスのメンバとして扱われます。 ただし、デフォルトでは、デフォルト クラスにイネーブルな機能はありません。 そのため、機能が設定されていないデフォルト クラスに属するパケットには QoS 機能は適用されません。 この後、これらのパケットは、ファーストイン ファーストアウト(FIFO)キューに配置され、使用可能な下位リンクの帯域幅で決められたレートで転送されます。 この FIFO キューは、テール ドロップと呼ばれる輻輳回避技術で管理されます。 テール ドロップなどの輻輳回避技術の詳細については、 このマニュアルの「Configuring Modular QoS Congestion Avoidance on Cisco ASR 9000 Series Routers」モジュール を参照してください。
ポリシーがバンドルにバインドされている場合、各バンドル メンバ(ポート)で同じポリシーがプログラミングされます。 たとえば、ポリサーまたはシェーパー レートがある場合、各ポートに同じレートが設定されます。 トラフィックはロード バランシング アルゴリズムに基づいてメンバをバンドルするようスケジュールされます。
入力および出力トラフィックの両方がサポートされています。 パーセントベースのポリシーと絶対レートベースのポリシーがサポートされています。 ただし、使いやすさのため、パーセントベースのポリシーを使用することを推奨します。
トラフィック クラスとトラフィック ポリシーを作成した後、任意で共有ポリシー インスタンス(SPI)を使用して、QoS リソースを 1 つ割り当て、これをサブインターフェイス、複数のイーサネット フロー ポイント(EFP)、またはバンドル インターフェイスで共有することができます。
SPI を使用して、QoS ポリシーの 1 つのインスタンスを複数のサブインターフェイスで共有し、サブインターフェイスのシェーピングを 1 つのレートに集約できます。 QoS ポリシーのインスタンスを共有するサブインターフェイスは、すべて同じ物理インターフェイスに属する必要があります。 QoS ポリシーのインスタンスを共有するサブインターフェイスの数は、2 からポートのサブインターフェイスの最大数までです。
バンドル インターフェイスの場合、ハードウェア リソースはバンドル メンバごとに複製されます。 共通の共有ポリシー インスタンスを使用し、Link Aggregation Control Protocol(LAG)バンドルで設定されたサブインターフェイスは、すべて同じメンバ リンクにロード バランシングされる必要があります。
バンドル EFP にポリシーが設定されている場合、バンドルのメンバ リンクごとにポリシーのインスタンスが 1 つ設定されます。 同じバンドルの複数のバンドル EFP 間で SPI を使用する場合、バンドルのメンバ リンクごとにポリシーの共有インスタンスが 1 つ設定されます。 デフォルトでは、バンドルのロード バランシング アルゴリズムでは、ハッシュを使用して(バンドル EFP から送信される必要のある)トラフィックをバンドル メンバ間に分散させます。 1 つまたは複数の EFP のトラフィックを、複数のバンドル メンバ間に分散させることができます。 複数の EFP に、SPI を使用して一緒にシェーピングまたはポリシングを実行しなければならないトラフィックがある場合は、同じ共有ポリシーのインスタンスに属するすべての EFP へのトラフィックに対して、バンドル ロード バランシングで同じバンドル メンバを選択する(ハッシュ選択)ように設定する必要があります。 これによって、同じポリシーの共有インスタンスを持つすべての EFP に向かうトラフィックで、同じポリサー/シェーパー インスタンスが使用されます。
これは通常は同じ加入者が多数の EFP を持つ場合(たとえば、各サービス タイプに対して 1 つの EFP を持つなど)や、プロバイダーですべての加入者の EFP に対してシェーピングおよびキューイングを一緒に実装することが求められる場合に使用されます。
ポリシー マップを物理ポートに適用すると、ポリシーは、その物理ポートのすべてのレイヤ 2 およびレイヤ 3 サブインターフェイスに適用されます。
ポート シェーピング ポリシーをメイン インターフェイスに適用するときには、個々の通常のサービス ポリシーをそのサブインターフェイスに適用できます。 ポート シェーピング ポリシー マップには、次の制限事項があります。
上記の制限のいずれかに違反した場合、設定したポリシー マップはポート シェーピング ポリシーではなく、通常のポリシーとして適用されます。
クラスベースの無条件パケット マーキング機能は、ユーザが指定したマーキングに基づいてパケットを区別できる効率的なパケット マーキング機能です。
クラスベースの無条件パケット マーキングでは、次の作業を行うことができます。
(注) |
qos-group および discard-class はルータの内部変数であり、送信されません。 |
無条件パケット マーキングにより、次のようにネットワークを複数のプライオリティ レベルまたはサービス クラスに区切ることができます。
(注) |
QoS グループ ID を設定しても、パケットを送信する優先順位が自動的に決まるわけではありません。 最初に QoS グループを使用する出力ポリシーを設定する必要があります。 |
設定作業については、46 ページの「クラスベース無条件パケット マーキングの設定」で説明されています。
(注) |
特に明記されていないかぎり、レイヤ 3 物理インターフェイスのクラス単位の無条件パケット マーキングがバンドル インターフェイスに適用されます。 |
IP precedence を使用すると、パケットの CoS を指定できます。 この目的には、IP Version 4(IPv4)ヘッダーの ToS フィールドの 3 つの precedence ビットを使用します。 図 1 に、ToS フィールドを示します。
ToS ビットを使用して、最大 8 つのサービス クラスを定義できます。 その後、ネットワーク全体で設定された他の機能によって、これらのビットを使用して、ToS の付与に関するパケットの処理方法を決定します。 これらの他の QoS 機能では、輻輳管理戦略や帯域幅の割り当てなど適切なトラフィック処理ポリシーを割り当てることができます。 たとえば、 などのパケットの IP 優先順位設定を使用してトラフィックのプライオリティを設定できます。
着信トラフィックに precedence レベルを設定し、Cisco IOS XR QoS キューイング機能と一緒に使用することで、ディファレンシエーテッド サービスを作成できます。
後続の各ネットワーク要素が決定されたポリシーに基づいてサービスを提供できるように、できるだけ IP precedence は、通常ネットワークの端または管理ドメインの近くに配置します。 これによって、他のコアまたはバックボーンにおいて、優先順位に基づいて QoS を設定できます。
設定作業については、46 ページの「クラスベース無条件パケット マーキングの設定」の項で説明されています。
IP ヘッダーの ToS フィールドにある 3 つの IP precedence ビットを使用して、各パケットの CoS 割り当てを指定します。 前述したように、最大 8 個のクラスにトラフィックを分類した後、ポリシー マップを作成して、各クラスの輻輳処理、帯域幅割り当てといったネットワーク ポリシーを定義できます。
歴史的な理由から、各優先度はある名前に対応します。 これらの名前は RFC 791 で定義されています。 表 5 に、重要度のより小さいものから大きいものへの順序で、番号とそれに対応する名前を表示します。
(注) |
IP precedence ビットの設定 6 と 7 は、ルーティング アップデートなどのネットワーク制御情報用に予約されています。 |
デフォルトでは、Cisco IOS XR ソフトウェアは、IP precedence 値をそのまま残します。 これによって、ヘッダーの precedence 値セットが維持され、すべての内部ネットワーク デバイスが IP precedence の設定に基づいてサービスを提供できるようになります。 このポリシーは、ネットワークのエッジでネットワーク トラフィックをさまざまなタイプのサービスにソートすること、またこれらのサービス タイプをネットワーク コアで設定することを指定する標準的な方法に従っています。 その後、ネットワークのコアにあるルータは、precedence ビットを使用して、送信順やパケット ドロップの可能性などを決定できるようになります。
ネットワークに入ってくるトラフィックには外部デバイスで設定された precedence が設定されている可能性があるので、ネットワークに入るすべてのトラフィックの precedence をリセットすることを推奨します。 IP precedence の設定を制御することによって、すでに IP precedence を設定したユーザが、自身のすべてのパケットに高い優先度設定を設定して、自身のトラフィックに対してより高いサービスを得ることを禁止します。
クラスベースの無条件パケット マーキング、LLQ、および WRED 機能では、IP precedence ビットを使用できます。
802.1ad フレームと 802.1ah フレームに含まれる Drop Eligible Indicator(DEI)ビットに基づいて、トラフィックを分類できます。 デフォルトの DEI マーキングがサポートされています。 ポリシー マップの set dei アクションは、802.1ad パケットで次の項目に対してサポートされています。
ネットワークでパケットをマークする必要があり、すべてのデバイスで IP DSCP マーキングがサポートされている場合は、IP DSCP マーキングの方が無条件パケット マーキングのオプションが多いため、IP DSCP マーキングを使用してください。 IP DSCP によるマーキングが好ましくない場合、またはネットワークにあるデバイスで IP DSCP 値がサポートされているかどうか不明な場合は、パケットのマーキングに IP precedence 値を使用してください。 IP precedence 値は、おそらくネットワーク内のすべてのデバイスでサポートされています。
パケット分類は、データ パス上で輻輳管理または輻輳回避を必要とするトラフィック フローを識別し、マーキングします。 ボーダー ゲートウェイ プロトコルを使用した Quality of Service ポリシー伝搬(QPPB)では、アクセス リスト(ACL)、ボーダー ゲートウェイ プロトコル(BGP)コミュニティ リスト、BGP 自律システム(AS)パス、送信元プレフィックス アドレス、または宛先プレフィックス アドレスに基づいて、パケットを QoS グループ ID で分類できます。 パケットを分類しておくと、ポリシングや重み付けランダム早期検出(WRED)などの他の QoS 機能を使用して、ビジネス モデルに適合するようにポリシーを指定し、実行できます。
BGP を使用した QoS ポリシー伝搬(QPPB)では、トラフィック ポリシングの適用に使用できるシスコ エクスプレス フォワーディング(CEF)パラメータに BGP プレフィックスおよび BGP 属性をマッピングできます。 QPPB を使用すると、ネットワークのある場所で設定した BGP ポリシーを、BGP を使用してネットワークの別の場所に伝搬し、そこで適切な QoS ポリシーを作成できます。
分類は、トラフィックの送信元または宛先アドレスに基づいて実行できます。 BGP および CEF は、サポートされている QPPB 機能に対して有効にする必要があります。
QoS 機能の一貫した展開を自動化する自動 QoS は、衛星システムで有効化されています。 すべてのユーザ設定のレイヤ 2 およびレイヤ 3 機能が ASR9000 で適用され、衛星システムに対する個別の QoS 設定は必要ありません。 自動 QoS は、ICL リンクのオーバーサブスクリプションを処理します。 通常のポート上のその他すべての QoS 機能(ブロードバンド QoS を含む)は、衛星ポートでもサポートされています。 ASR9000 シリーズ ルータと衛星ポート間のシステムの輻輳処理は、プライオリティと保護を維持するように設定されます。 自動 QoS は、ASR9000 シリーズ ルータと衛星間の衛星 ICL で流れるトラフィックの異なるクラス間に対する十分な区別を提供します。
システムは、1G ポート シェーパーに対して、最大 14 個の一意のシェーピング レートをサポートできます。 1G ポートは、トラフィック マネージャ(TM)階層の L0 エンティティを使用して表されます。 ポート シェーパーは、このレベルで適用されます。 衛星ポートで速度が変更された場合、QoS EA は、基本となる衛星ポートの速度に基づいてポリシーマップを自動的に再設定します。 ただし、ポリシーが存在ない場合、ポリシー マネージャ(PM)は、ポート シェーパー API(アプリケーション プログラミング インターフェイス)を呼び出すことによってポートの速度を設定する必要があります。 システムは、AN によって基本となるポートの速度が変更された場合に、パーセンテージベースのポリシーを変更します。 ASR9000 シリーズ ルータ上のポリシーに自動ネゴシエーションされた速度を伝播すると、時間差が発生する場合があります。この期間中は、衛星デバイスでパケット ドロップが発生することが想定されます。
(注) |
入力サービス ポリシーでのキューイングは、衛星インターフェイスではサポートされていません。 |
衛星システムの QoS の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide』を参照してください。
衛星システムから Cisco IOS XR ASR9000 シリーズ ルータへのトラフィック、および ASR9000 シリーズ ルータから衛星システムへのトラフィックについて説明します。
衛星から ASR9000 シリーズ ルータ
ASR9000 シリーズ ルータから衛星
疑似配線ヘッド エンド(PWHE)上の QoS は、サービス プロバイダーのエッジ ルータの拡張 L3VPN サービスをイネーブルにします。
PWHE-QoS の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Configuration Guide』を参照してください。
PWHE での QoS の機能:
異なる PW HE 仮想インターフェイスの QoS ポリシー、および物理インターフェイスの QoS ポリシーに対応するキューイング リソースは、すべて TM 内の同一のポート下にあります。 スケジューリングの観点から、物理インターフェイス QoS ポリシーおよび PW HE インターフェイス QoS ポリシーで設定されたキューイング パラメータ(minimum bandwidth、maximum bandwidth/shape、weight/bandwidth remaining)は、互いに影響します。 物理インターフェイスの帯域幅は、すべての QoS ポリシーによって共有されます。
Bandwidth remaining コマンドを PW-HE ポリシーの親デフォルト クラスで使用して、さまざまな PW-HE インターフェイスと物理インターフェイス間の超過帯域幅の分配を制御できます。
QoS アカウンティング
PW ether:入力と出力
通常の L3 インターフェイスでサポートされているすべてのポリシング機能は、PW-HE でもサポートされます。
キューイング
入力および出力キュー | 入力および出力ポリサー | |
---|---|---|
ポリシー マップのない PW-HE インターフェイス | 各 PW-HE メンバには、ポートごとにデフォルト キューがあります。 入力および出力の両方のトラフィックは、メンバ ポートのデフォルト キューを使用します。 |
N/A |
ポリシー マップ付きの PW-HE インターフェイス | ポリシー マップの入力および出力キューは、各 PW-HE メンバで複製されます。 |
ポリシー マップの入力および出力ポリサーは、各 PW-HE メンバごとに複製されます。 |
(注) |
PW-HE メンバがバンドルの場合、ポリシー マップはバンドル メンバで複製されます。 |
統計
PW HE 仮想インターフェイス QoS ポリシーの show コマンドは、入力/出力の統計情報を次の条件で提供します。
ここでは、PW-HE の QoS のさまざまなシナリオについて説明します。
(注) |
PWHE インターフェイスが作成された場合で、PWHE QoS ポリシーが適用されない場合、PW-HE と非 PW-HE の両方のトラフィックがメンバ インターフェイスのデフォルト キューを介して渡されます。
|
次の 2 つのケースは、疑似配線ヘッドエンド インターフェイスのデフォルト動作を表します。
policy-map pw_child_in class voip priority level 1 police rate 1 percent 1 class video police rate percent 10 priority level 2 class data police rate percent 70 peak-rate-percent 100 exceed-action transmit violate action drop end-policy-map ! policy-map pw_child_out class voip priority level 1 police rate 1 mbps ! ! class data bandwidth remaining percent 70 random-detect discard-class 3 40 ms 50 ms ! class video priority level2 police rate 10 mbps ! 1 class class-default random-detect discard-class 1 20 ms 30 ms ! end policy-map policy-map pw_child_out class voip priority level 1 police rate 1 mbps ! ! class data bandwidth remaining percent 70 random-detect discard-class 3 40 ms 50 ms ! class video priority level 2 police rate 10 mbps ! ! class class-default random-detect discard-class 1 20 ms 30 ms ! end-policy-map ! policy-map pw_parent_out class class-default service-policy pw_child_out shape average 100 mbps ! end-policy-map ! interface pw-ether 1 service-policy input pw_parent_in service-policy output pw_parent_out
その他の PW-HE の関連情報については、 『Cisco ASR 9000 Series Aggregation Services Router L2VPN and Ethernet Services Configuration Guide』を参照してください。
In-Place ポリシーの変更機能では、QoS ポリシーが 1 つ以上のインターフェイスに付加されている場合でも QoS ポリシーを変更できます。 1 つ以上のインターフェイスに付加されている QoS ポリシーを変更すると、その QoS ポリシーが付加されているすべてのインターフェイスで QoS ポリシーが自動的に変更されます。 変更されたポリシーは、新しいポリシーをインターフェイスにバインドするときと同じチェックを受けます。
ポリシー変更が成功した場合、変更されたポリシーは、ポリシーが付加されているすべてのインターフェイスに対して有効になります。 コンフィギュレーション セッションはポリシーの変更が完了するまでブロックされます。
ただし、ポリシーの変更がいずれかのインターフェイスで失敗した場合には、すべてのインターフェイスに対して変更前のポリシーが有効になるように、自動ロール バックが開始されます。 コンフィギュレーション セッションは、影響を受けるすべてのインターフェイスでロール バックが完了するまでブロックされます。
In-Place ポリシーの変更時に回復不可能なエラーが発生した場合は、ポリシーは対象のインターフェイスに対して矛盾した状態になります。 各場所における矛盾を表示するには、 show qos inconsistency コマンドを使用してください。 (このコマンドは、ASR 9000 イーサネット ラインカードでのみサポートされています)。 コンフィギュレーション セッションは、変更されたポリシーが、ポリシーを使用するすべてのインターフェイスで有効になるまでブロックされます。 コンフィギュレーション セッションのブロックが解除されるまで、新たな設定を行うことはできません。
インターフェイスに付加されている QoS ポリシーを変更したとき、変更されたポリシーを使用するインターフェイスでは、短期間、有効なポリシーがない場合が生じる可能性があります。
(注) |
インターフェイスに付加されているポリシーの QoS 統計情報は、ポリシーを変更すると失われます(0 にリセット)。 |
QoS ポリシーを変更している間の短期間、変更するポリシーを使用するインターフェイスでは、有効なポリシーがない状態が生じることがあります。 このため、同時に最小限のインターフェイスに影響する QoS ポリシーを変更します。 ポリシー マップの変更時に影響するインターフェイスの数を確認するには、 show policy-map targets コマンドを使用します。
一致基準が含まれるトラフィック クラスを作成するには、 class-map コマンドを使用してトラフィック クラス名を指定し、必要に応じて、次の match コマンドをクラスマップ コンフィギュレーション モードで使用します。
概念の情報については、16 ページの「トラフィック クラスの要素」の項を参照してください。
この設定作業で指定するすべての match コマンドの使用は任意ですが、1 つのクラスに少なくとも 1 つの一致基準を設定する必要があります。
1. configure
2. class-map [ type qos] [ match -any] [ match -all] class-map-name
3.
match access-group [
ipv4 |
ipv6]
access-group-name
4.
match [
not]
cos [
cos-value] [
cos-value0 ... cos-value7]
5. match [ not] cos inner [ inner-cos-value] [ inner-cos-value0... inner-cos-value7]
6.
match destination-address mac
destination-mac-address
7.
match source-address
mac
source-mac-address
8. match [ not] discard-class discard-class-value [ discard-class-value1 ... discard-class-value6]
9. match [ not] dscp [ ipv4 | ipv6] dscp-value [ dscp-value ... dscp-value]
10.
match [
not]
mpls experimental topmost
exp-value [
exp-value1 ... exp-value7]
11.
match [
not]
precedence [
ipv4 |
ipv6]
precedence-value [
precedence-value1 ... precedence-value6]
12. match [ not] protocol protocol-value [ protocol-value1 ... protocol-value7]
13. match [ not] qos-group [ qos-group-value1 ... qos-group-value8]
14. match vlan [ inner ] vlanid [vlanid1 ... vlanid7]
トラフィック ポリシーを作成するには、 policy-map グローバル コンフィギュレーション コマンドを使用して、トラフィック ポリシーの名前を指定します。
トラフィック クラスは、 class コマンドを使用したときにサービス ポリシーと関連付けられます。 class コマンドは、ポリシー マップ コンフィギュレーション モードを開始した後に実行しなければなりません。 class コマンドを入力すると、ルータは自動的にポリシー マップ クラス コンフィギュレーション モードを開始します。ここでトラフィック ポリシーの QoS ポリシーを定義します。
一致基準として入力できるその他のコマンドについては、『 Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Command Reference』を参照してください。
概念の情報については、17 ページの「トラフィック ポリシーの要素」の項を参照してください。
トラフィック クラスとトラフィック ポリシーの作成後、service-policy インターフェイス コンフィギュレーション コマンドを使用して、トラフィック ポリシーをインターフェイスに付加し、ポリシーを適用する方向を指定します(インターフェイスに着信するパケットまたはインターフェイスから送信されるパケット)。
ポリシー マップ クラス コンフィギュレーション モードで入力できるその他のコマンドについては、『 Cisco ASR 9000 Series Aggregation Services RoutersModular Quality of Service Command Reference .』を参照してください。
インターフェイスにトラフィック ポリシーを付加する前に、トラフィック クラスとトラフィック ポリシーを作成する必要があります。
1. configure
2.
interface
type
interface-path-id
3.
service-policy {
input |
output}
policy-map
5.
show policy-map interface
type
interface-path-id [
input |
output]
トラフィック クラスとトラフィック ポリシーの作成後、任意で service-policy(インターフェイス)コンフィギュレーション コマンドを使用して、共有ポリシー インスタンスを複数のサブインターフェイスに付加し、ポリシーを適用する方向を指定します(サブインターフェイスに着信するパケットまたはサブインターフェイスから送信されるパケット)。
(注) |
共有ポリシーには、レイヤ 2 とレイヤ 3 のサブ インターフェイスの組み合わせを含めることができます。 |
ポリシー マップ クラス コンフィギュレーション モードで入力できるその他のコマンドについては、『Cisco ASR 9000 Series Aggregation Services Routers Modular Quality of Service Command Reference』を参照してください。
共有ポリシーのインスタンスをサブインターフェイスに付加する前に、トラフィック クラスとトラフィック ポリシーを作成する必要があります。
1. configure
2.
interface
type
interface-path-id
3. service-policy { input | output} policy - map [ shared -policy-instance instance-name]
5.
show policy-map shared-policy-instance
instance-name [
input |
output]
location
rack/slot/module
トラフィック クラスとトラフィック ポリシーの作成後、任意で service-policy(インターフェイス)コンフィギュレーション コマンドを使用して、共有ポリシー インスタンスをバンドル インターフェイスやバンドル EFP に付加し、ポリシーを適用する方向を指定します(サブインターフェイスに着信するパケットまたはサブインターフェイスから送信されるパケット)。
ポリシー マップ クラス コンフィギュレーション モードで入力できるその他のコマンドについては、『 Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Command Reference』を参照してください。
共有ポリシー インスタンスをバンドル インターフェイスまたは EFP バンドルに付加する前に、トラフィック クラスとトラフィック ポリシーを作成する必要があります。
1. configure
2.
interface Bundle-Ether
bundle-id
3. service-policy { input | output} policy-map [ shared-policy-instance instance-name]
5.
show policy-map shared-policy-instance
instance-name [
input |
output]
location
location-id
この設定作業では、以下のクラスベースの無条件パケット マーキング機能をルータに設定する方法を説明します。
(注) |
MPLS タグ付きパケットに適用される IPv4 および IPv6 QoS アクションはサポートされていません。 設定は受け入れられますが、アクションは実行されません。 |
(注) |
1. configure
6.
set qos-group
qos-group-value
9.
set mpls experimental {
imposition |
topmost}
exp-value
10.
set srp-priority
priority-value
11.
set discard-class
discard-class-value
15. interface type interface-path-id
16.
service-policy {
input |
output]}
policy-map
18. show policy-map interface type interface-path-id [ input | output]
ここでは、ボーダー ゲートウェイ プロトコル(BGP)コミュニティ リスト、BGP 自律システム パス、アクセス リスト、送信元プレフィックス アドレス、または宛先プレフィックス アドレスに基づいて、BGP を使用したポリシー伝搬をルータ上で設定する方法について説明します。
BGP を使用したポリシー伝搬では、BGP コミュニティ リスト、BGP 自律システム パス、アクセス リスト、送信元プレフィックス アドレス、および宛先プレフィックス アドレスに基づいて、IP precedence または QoS グループ ID(あるいはその両方)でパケットを分類できます。 パケットを分類しておくと、重み付けランダム早期検出(WRED)などの他の QoS 機能を使用して、ビジネス モデルに適合するようにポリシーを指定し、実行できます。
BGP によるポリシー伝搬を設定するには、次の基本作業を実行します。
この作業では、IP precedence または QoS グループ ID による BGP プレフィックスの分類に使用するルート ポリシーを定義します。
前提条件
ルート ポリシーで使用する BGP コミュニティ リストまたはアクセス リストを設定します。
制約事項
この作業では、BGP にルート ポリシーを適用します。
前提条件
BGP および CEF を設定します。
1. configure
2. router bgpas-number
3. address-familyaddress-prefix
4. table-policypolicy-name
この作業では、指定したインターフェイスに QPPB を適用します。 ルート ポリシーでのプレフィックスの一致に基づいて、トラフィックの分類が始まります。 トラフィックの送信元または宛先の IP アドレスを使用して、ルート ポリシーを照合できます。
1. configure
2.
interface
type interface-path-id
3. ipv4 | ipv6 bgp policy propagation input { ip-precedence | qos-group} { destination [ ip-precedence { destination | source }] | source [ ip-precedence { destination | source }] } RP/0/ RSP0/CPU0:router(config)#ipv4 bgp policy propagation input qos-group destination
トラフィックが(単一の)ルータ port1 および port2 を介して Network1 から Network2 に移動する場合について考えます。 QPPB が port1 でイネーブルの場合
次に、2 つのトラフィック クラスを作成し、その一致条件を定義する例を示します。 1 つ目のトラフィック クラス class1 では、ACL 101 を一致基準として使用します。 2 番めのトラフィック クラス class2 では、ACL 102 を一致条件として使用しています。 パケットはこれらの ACL の内容と照合され、そのクラスに属するかどうかが判断されます。
class-map class1 match access-group ipv4 101 exit ! class-map class2 match access-group ipv4 102 exit
not キーワードを match コマンドに使用すると、指定していないフィールド値に基にして照合を行います。 次の例では、DSCP 値が 4、8、10 以外である qos_example クラスのすべてのパケットが含まれます。
class-map match-any qos_example match not dscp 4 8 10 ! end
次の例では、policy1 というトラフィック ポリシーを定義し、class1 と class2 という 2 つのクラスのポリシー設定を含めます。 これらのクラスの一致基準は、68 ページの「定義されたトラフィック クラス:例」の項で作成されたトラフィック クラスで定義されています。
class1 では、帯域幅割り当て要求と、そのクラス用に予約されるキューの最大バイト数の制限がポリシーに含まれています。 class2 に対しては、帯域幅割り当て要求だけがポリシーで指定されています。
policy-map policy1 class class1 bandwidth 3000 queue-limit bytes 1000000000 exit ! class class2 bandwidth 2000 exit policy-map policy1 class class1 bandwidth 3000 kbps queue-limit 1000 packets ! class class2 bandwidth 2000 kbps ! class class-default ! end-policy-map ! end
次に、既存のトラフィック ポリシーをインターフェイスに付加する例を示します(68 ページの「定義されたトラフィック クラス:例」の項を参照)。 policy-map コマンドを使用してトラフィック ポリシーを定義した後、インターフェイス コンフィギュレーション モードで service-policy コマンドを使用して、このポリシーを 1 つ以上のインターフェイスに付加し、これらのインターフェイスのトラフィック ポリシーを指定できます。 同じトラフィック ポリシーは複数のインターフェイスに付加することができますが、各インターフェイスには入力と出力に対してそれぞれトラフィック ポリシーを 1 つだけ付加することができます。
interface gigabitethernet 0/1/0/9 service-policy output policy1 exit ! interface TenGigE 0/5/0/1 service-policy output policy1 exit
次に、複数のサブ インターフェイスに既存のトラフィック ポリシーを付加する例を示します。 policy-map コマンドを使用してトラフィック ポリシーを定義した後、サブインターフェイス コンフィギュレーション モードで service-policy コマンドを使用して、このポリシーを 1 つ以上のサブインターフェイスに付加できます。
interface gigabitethernet 0/1/0/0.1 service-policy input policy1 shared-policy-instance ethernet101 exit ! interface gigabitethernet 0/1/0/0.2 service-policy input policy1 shared-policy-instance ethernet101 exit
次に、既存のトラフィック ポリシーをバンドル インターフェイスに付加する例を示します。 policy-map コマンドを使用してトラフィック ポリシーを定義した後、サブインターフェイス コンフィギュレーション モードで service-policy コマンドを使用して、このポリシーを 1 つ以上のバンドル サブインターフェイスに付加できます。
interface Bundle-Ether 100.1 service-policy tripleplaypolicy shared-policy-instance subscriber1 exit ! interface Bundle-Ether 100.2 service-policy output tripleplaypolicy shared-policy instance subscriber1 exit
次に、SPI が実装されている場合に EFP に対してロード バランシングを設定する例を示します。 リンク バンドルの EFP ロード バランシングの詳細については、『Cisco IOS XR Interface and Hardware Component Configuration Guide』を参照してください。
interface Bundle-Ether 50 interface gigabitethernet 0/1/0/5 bundle id 50 mode active interface gigabitethernet 0/1/0/8 bundle id 50 mode active
次の例では、同じ物理メンバ リンクを通過する 2 つのバンドル EFP 宛てのトラフィックを設定します。
interface Bundle-Ether 50.25 l2transport encapsulation dot1q 25 bundle load-balance hash-select 2 ! interface Bundle-Ether 50.36 l2transport encapsulation dot1q 36 bundle load-balance hash-select 2
次に、トラフィック ポリシー policy1 のデフォルト クラスに対してトラフィック ポリシーを設定する例を示します。 デフォルト クラスの名前は class-default で、他のすべてのトラフィックから構成され、インターフェイスの帯域幅の 60 パーセントでシェーピングされます。
policy-map policy1 class class-default shape average percent 60
次の例では、一致基準が複数ある場合に、パケットがどのように評価されるかについて説明します。 class-map match-any コマンド中のパケットがトラフィック クラスのメンバであると見なされるためには、一致基準が 1 つだけが満たされる必要があります(論理的な OR 演算子)。 この例では、プロトコル IP OR QoS グループ 4 OR アクセス グループ 101 が成功する一致基準になる必要があります。
class-map match-any class1 match protocol ipv4 match qos-group 4 match access-group ipv4 101
トラフィック クラス class1 では、成功する一致条件が見つかるまで連続的に一致基準が評価されます。 各一致基準が評価され、パケットがその基準に一致するかどうかが判断されます。 パケットが指定した条件のうち少なくとも 1 つに一致すると、パケットはトラフィック クラスのメンバとして分類されます。
(注) |
match qos-group コマンドは、出力ポリシーでのみサポートされています。 |
次の例では、 policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用して事前に定義したクラス マップ class1 に関連付けられ、その後、出力 POS インターフェイス 0/1/0/0 に付加されます。 ToS バイトの IP precedence ビットを 1 に設定します。
policy-map policy1 class class1 set precedence 1 ! interface pos 0/1/0/0 service-policy output policy1
次の例では、policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用して事前に定義したクラス マップに関連付けられます。 この例では、class1 というクラス マップが事前に設定されていることを前提としています。
次の例では、ToS バイトの IP DSCP 値を 5 に設定します。
policy-map policy1 class class1 set dscp 5 class class2 set dscp ef
エッジで音声パケットに対して示される設定を行った後、すべての中間ルータは次のように音声パケットに低遅延処理を行うよう設定されます。
class-map voice match dscp ef policy-map qos-policy class voice priority level 1 police rate percent 10
次の例では、 policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用してクラス マップ class1 に関連付けられ、その後 GigabitEthernet インターフェイス 0/1/0/9 の入力方向に付加されます。 qos-group 値は 1 に設定されます。
class-map match-any class1 match protocol ipv4 match access-group ipv4 101 policy-map policy1 class class1 set qos-group 1 ! interface gigabitethernet 0/1/0/9 service-policy input policy1
(注) |
set qos-group コマンドは入力ポリシーでのみサポートされています。 |
次の例では、 policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用してクラス マップ class1 に関連付けられ、その後 10-Gigabit Ethernet インターフェイス TenGigE0/1/0/0 の出力方向に付加されます。 レイヤ 2 ヘッダーの IEEE 802.1p(CoS)ビットは 1 に設定します。
class-map match-any class1 match protocol ipv4 match access-group ipv4 101 policy-map policy1 class class1 set cos 1 ! interface TenGigE0/1/0/0 interface TenGigE0/1/0/0.100 service-policy output policy1
次の例では、 policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用してクラス マップ class1 に関連付けられ、その後 10-Gigabit Ethernet インターフェイス TenGigE0/1/0/0 の入力方向に付加されます。 すべてのインポーズされたラベルの MPLS EXP ビットは 1 に設定します。
class-map match-any class1 match protocol ipv4 match access-group ipv4 101 policy-map policy1 class class1 set mpls exp imposition 1 ! interface TenGigE0/1/0/0 service-policy input policy1
(注) |
set mpls exp imposition コマンドは入力ポリシーでのみサポートされています。 |
次の例では、 policy1 というサービス ポリシーを作成します。 このサービス ポリシーは、 class コマンドを使用してクラス マップ class1 に関連付けられ、その後 10-Gigabit Ethernet インターフェイス TenGigE0/1/0/0 の出力方向に付加されます。 最上位ラベルの MPLS EXP ビットは 1 に設定します。
class-map match-any class1 match mpls exp topmost 2 policy-map policy1 class class1 set mpls exp topmost 1 ! interface TenGigE0/1/0/0 service-policy output policy1
この例では、ポリシーを定義してインターフェイスに付加した後、precedence を 3 から 5 に変更します。
class-map match-any class1 match cos 7 end-class-map
policy-map policy1 class class1 set precedence 3
interface gigabitethernet 0/6/0/1 service-policy output policy1 commit
policy-map policy1 class class1 set precedence 5 commit
(注) |
変更されたポリシー policy1 は、ポリシーが付加されるすべてのインターフェイスに反映されます。 また、ポリシー マップに使用するすべてのクラス マップを変更できます。 クラス マップに対して行った変更は、ポリシーが付加されているすべてのインターフェイスに反映されます。 |
この show policy-map targets コマンドの出力は、ギガ ビット イーサネット インターフェイス 0/1/0/0 に、メイン ポリシーとして付加されているポリシー マップがあることを示しています(階層型 QoS 設定の子ポリシーに付加されるのではなく)。 このインターフェイスの発信トラフィックは、ポリシーが変更された場合に影響を受けます。
show policy-map targets Fri Jul 16 16:38:24.789 DST 1) Policymap: policy1 Type: qos Targets (applied as main policy): GigabitEthernet0/1/0/0 output Total targets: 1 Targets (applied as child policy): Total targets: 0
Cisco IOS XR ソフトウェアを使用して MIB を検索およびダウンロードするには、http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml にある Cisco MIB Locator を使用し、[Cisco Access Products] メニューからプラットフォームを選択します。 |
この機能によりサポートされた新規 RFC または改訂 RFC はありません。またこの機能による既存 RFC のサポートに変更はありません。 |
シスコのテクニカル サポート Web サイトでは、製品、テクノロジー、ソリューション、技術的なヒント、およびツールへのリンクなどの、数千ページに及ぶ技術情報が検索可能です。 Cisco.com に登録済みのユーザは、このページから詳細情報にアクセスできます。 |