概要
この章では、モジュラ QoS CLI(MQC)の概要、Cisco ASR 1000 シリーズ アグリゲーション サービス ルータですべての QoS 機能を設定する方法を説明します。MQC は、シスコのルーティングおよびスイッチング プラットフォームで QoS を有効にするための標準化されたアプローチです。
この章では、あらゆる QoS 設定に必要な設定作業の概要について説明します。個々の機能については、適切なモジュールで説明します。
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、モジュラ QoS CLI(MQC)の概要、Cisco ASR 1000 シリーズ アグリゲーション サービス ルータですべての QoS 機能を設定する方法を説明します。MQC は、シスコのルーティングおよびスイッチング プラットフォームで QoS を有効にするための標準化されたアプローチです。
この章では、あらゆる QoS 設定に必要な設定作業の概要について説明します。個々の機能については、適切なモジュールで説明します。
MQC では、QoS を有効にして検証するための 4 つの簡単なステップを実行します。各ステップで例が示されます。(機能の説明については各章を参照してください)
クラスマップの作成:トラフィック(アプリケーション)を使用するクラスに分類します。
class-map voice
match dscp ef
class-map video
match dscp AF41 AF42
ポリシーマップの作成:各クラスで必要とされる処理を定義します。
policy-map simple-example
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
ポリシーマップの適用:ポリシーを物理インターフェイスまたは論理インターフェイスにバインドし、ポリシーを動作させるトラフィックを特定します。そのインターフェイスを介してルータに入るトラフィック(入力)と、そのインターフェイスを介してルータから出るトラフィック(出力)のどちらにポリシーを適用するかを指定する必要があります。
interface gigabitethernet1/0/0
service-policy out simple-example
QoS ポリシーの動作の確認:show policy-map interface
コマンドを発行して、MQC で設定されたすべての QoS 機能の動作を確認します。
show policy-map interface gigabitethernet1/0/0
クラスマップの作成時に、同様に処理される必要があるアプリケーションのグループを定義します。グループの名前を指定し、後に必要な処理を定義するときにその名前を使用します。
1 つまたは複数のフィルタ(分類ルール)を定義し、特定のパケット(アプリケーション)が指定したグループに属していることを確認します。クラスマップを作成するとき、そのグループの一部とみなされるには、パケットが 1 つのフィルタのみ (match-any) またはすべてのフィルタ (match-all) に一致させるかどうかを指定することができます。
次のようにクラスマップを作成します。
class-map [match-all|match-any] <traffic-class-name>
match…. Filter1
match….. Filter2
次の例は、パケットが単一のフィルタにのみ一致する必要があるクラスを示しています。パケットが DSCP ef 値を持っている、または Cisco NBAR がそのパケットが skype アプリケーションを伝送していることを認識しているいずれかの場合に、パケットは音声クラスに属するものとみなされます。. ポリシーマップで音声という名前を使用して、このクラスに属すると分類されたパケットの処理方法を定義します。
class-map match-any voice
match dscp ef
match protocol skype
次の例では、match-all セマンティクスを使用しています。 パケットはクラスに属するためにすべてのフィルタと一致する必要があります。. トラフィックは MAPI として認識される必要があり(Cisco NBAR を使用)、アクセス リストで指定されたアドレスとの間で送受信される必要があります。
ip access-list extended mail-server-addr
permit ip any host 10.10.10.1
permit ip host 10.10.10.1 any
!
class-map match-all work-email
match protocol mapi
match access-group name mail-server-addr
前の例では、ASR 1000 シリーズプラットフォームのフィルター定義の柔軟性を示します。フィルタは、パケット ヘッダー(precedence、DSCP、Exp、またはCOS)内のマーク、アクセスリスト、 Cisco NBAR(match protocolxxx)または qos-group などの内部マーキングに基づいています。(利用可能な場合、サポートされているフィルタにおけるさらに完全な説明については、分類に関する章を参照してください)
便宜上、他の class-map を class-map にフィルタとして含めることもできます。:
class-map broadcast-video
match dscp cs5
class-map multimedia-streaming
match dscp af31 af32 af33
class-map multimedia-conferencing
match dscp af41 af42 af43
class-map realtime-interactive
match dscp cs4
!
class-map match-any all-video
match class broadcast-video
match class multimedia-streaming
match class multimedia conferencing
match class realtime-interactive
!
class-map match-any interactive-video
match class multimedia conferencing
match class realtime-interactive
この例では、nested class-map を クラス all-video と interactive-videoの定義に使用します。
定義上、特定のパケットは、クラスマップ内の複数のクラスの分類基準と一致する場合があります。その場合、ポリシーマップでクラスが定義されている順序によって、パケットが属するクラスが決まります。 パケットは、一致する最初のクラスに属します。
ポリシーマップとは作成するトラフィックの各クラスに適用するアクションを指定する方法です。
上記の簡単な例を再度見てみましょう。
policy-map simple-example
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
ポリシーマップの名前は simple-example です。後でポリシーを 1 つ以上のインターフェイスに適用するときに使用されます。ポリシー自体は非常に読みやすくなっています。音声とビデオの 2 つのクラスのトラフィックを定義しました。音声トラフィックはスケジュールにおいて優先(低遅延)される必要がありますが、そのクラスのスループットはインターフェイス帯域幅の 10% に制限されています。ビデオ トラフィックの場合、専用のキューがあり、音声の処理後に残っているものの 30% を保証します。
上記のポリシーマップには、3 番目の暗黙的クラスがあります。class-default は、明示的に設定されているかどうかにかかわらず、ポリシーの最後のクラスです。これは、ユーザ定義クラスと一致しないすべてのトラフィックすべてを捕捉します。イーグレス ポリシーの class-default では、独自のキューがあり、暗黙の帯域幅余剰比率が 1 になります。帯域幅の値がパーセントで指定されている場合、class-default は未割り当てのパーセントを受け取ります (アスタリスクを参照)。これを踏まえ、上記のポリシーマップは実際には次のようになります。
class-map class-default
match any
!
policy-map simple-example
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
class class-default
bandwidth remaining percent 70 ****
(注) |
class-default のクラスマップを作成する必要はありません。ここでは、ポリシーのしくみについての理解を深めるために、これを視覚化します。パケットが音声クラスまたはビデオクラスと一致しない場合は、常に class-default と一致させます。 |
上記のポリシーのアクションの例には priority 、 police 、および bandwidth コマンドが含まれています。アクションはコントロール ノブとして機能し、トラフィックのクラスがどのように扱われるかを区別します。
アクションを見るときの 1 つの非常に重要な差別化は、キューイングと非キューイングです。ここで、simple-example policy-map にもう 1 つのクラスを追加すると、次のようになります。
class-map youtube
match protocol youtube
!
policy-map simple-example
class voice
priority
police cir percent 10
class youtube
police cir percent 5
class video
bandwidth remaining percent 30
YouTube には、リンク容量の 5% を超えることがないように YouTubeトラフィックのレートを制限し、3 番目のユーザー定義クラスが追加されました。このクラスにはキューイング アクションが設定されていないため、キューは作成されません(キューを作成するアクションのリストについては下記を参照)。このクラスと一致するパケット(プロトコルが YouTube のクラス)は、ポリサーを通過した後、class-default キューにエンキューされます。
ポリシー定義でビデオ クラスの前に YouTube クラスを配置したことに気付きましたか。YouTube のトラフィックが、ビデオ クラスではなく、常にこのクラスの一部であることを確認する必要があります。このクラスを policy-map を先に定義することで、ビデオ クラスの条件を確認する前に、このクラスとの一致をチェックします。
キューを作成する特定のアクションは、priority、bandwidth、bandwidth remaining、shapeです。fair-queue、queue-limit、および random-detect などのその他のアクションは、キューを作成するアクションの 1 つが既に含まれているクラスでのみ使用できます。policing と set のアクションではキューは作成されませんが、キュー アドミッション コントロールの police コマンドを使用することができます。
キューイング アクションと非キューイング アクションを区別する主な理由の 1 つは、入力トラフィックに適用されるポリシーマップに ASR 1000 シリーズ ルータのキューイング アクションが含まれていない可能性があるからです。それでは、どのアクションがキューイングであり、どれが非キューイングであるかをまとめます。
キューイングおよび非キューイング アクション |
アクション |
|
---|---|---|
キューイング アクション |
||
スケジューリング |
||
priority |
||
bandwidth |
||
bandwidth remaining |
||
shape |
||
fair-queue |
||
キュー管理/輻輳回避 |
||
queue-limit |
||
random-detect |
||
非キューイング アクション |
||
レート制限/アドミッション コントロール |
||
police |
||
マーキング |
||
set |
階層型ポリシーマップ は、別のポリシーマップのクラス内にポリシーマップを埋め込むことによって作成できます。
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map parent-vlan
class class-default
shape average 100m
service-policy child
よく使用されるのは、「親ポリシーでのシェーピング/子ポリシー上のキューイング」ポリシーを作成することです。 このポリシーは、VLAN やトンネルなどの論理インターフェイスに接続できます。
分類の観点からすると、パケットは、特定の子クラスのメンバーと見なされるためには、親クラスと同様に子の分類基準にも準拠する必要があります。この例では、親クラスは class-default であり、定義により、トラフィックはこのクラスと一致します。
階層型ポリシーを定義するときには、利便性を考慮して、ポリシーマップを再利用できます。
次の例では、parent-vlan100 と parentvlan200 の両方で「子」という名前のポリシーマップを使用します。インスタンス化(インターフェイスに接続)すると、 parent-vlan100 の音声クラスは 10 Mbps(100m の親シェーパーの 10%)に制限され、parent-vlan200 の音声クラスは 5 Mbps(50m の親シェーパーの 10%)に制限されます。
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map parent-vlan100
class class-default
shape average 100m
service-policy child
!
policy-map parent-vlan200
class class-default
shape average 50m
service-policy child
!
int gigabitethernet1/0/0.100
service-policy out parent-vlan100
int gigabitethernet1/0/0.200
service-policy out parent-vlan200
この例は、定義は共有される場合もありますが、異なるインターフェース上のポリシーのインスタンスは真に一意であることを示しています。
また、ユーザ定義クラスで使用されるポリシーマップを使用して階層型ポリシーを作成することもできます。
次の例は、ASR 1000 シリーズ ルータで現在サポートされている 3 レベルの階層型ポリシーを示しています。パケットがアプリケーション レベルでクラスと一致するには、子の音声またはビデオの分類子、vlan-sharing policy-map の vlan 分類子、および物理レベル policy-map の class-default(すべて)の要件 3 つを満たす必要があります。
class-map vlan100
match vlan 100
class-map vlan200
match vlan 200
!
policy-map child
class voice
priority
police cir percent 10
class video
bandwidth remaining percent 30
!
policy-map vlan-sharing
class vlan100
shape average 100m
service-policy child
class vlan200
shape average 50m
service-policy child
!
policy-map physical-policy
class class-default
shape average 500m
service-policy vlan-sharing
!
interface gigabitethernet1/0/0
service-policy out physical-policy
ポリシーマップを作成すると、IOS はポリシーに対してエラー チェックを実行します。たとえば、制約のないプライオリティ キューイングを使用してポリシーを作成してから別のキューへの帯域幅を保証すると、IOS では切断が認識されます。 制約のない優先度キューがインターフェイスの帯域幅全体を占有する可能性がある場合、明らかにその帯域幅のいずれかを別のキューに保証することはできません。
policy-map create-error-example
class unconstrained-priority
priority
class bandwidth-guarantee
bandwidth percent 50
IOS で作成中にポリシーのエラーが検出された場合は、設定が拒否され、その時点でエラーが表示されます。
Cisco MQC を使用する 3 番目の手順は、ポリシーマップをインスタンス化することです(つまり、ポリシーをインターフェイスに適用し、トラフィックの制御を開始します)。service-policy コマンドを使用して、ポリシーを適用し、そのインターフェイスに入ってくるトラフィックとそのインターフェイスから出て行くトラフィックのどちらで動作するかを指定します。
interface gigabitethernet1/0/0
service-policy out simple-example
キューイング ポリシーは出力トラフィック(service-policy out policy-name )でサポートされていますが、非キューイング アクションのみを含むポリシーは、入力トラフィック(service-policy in policy-name )または出力トラフィックに適用される場合があります。
service-policy コマンドを適用するインターフェイスのことを接続点と呼びます。. この接続点は、(イーサネット インターフェイスや T1 インターフェイスなどの)物理インターフェイス、または VLAN サブインターフェイスやトンネル インターフェイスなどの論理インターフェイスである場合もあります。
ポリシーマップにキューイング アクションが含まれているが、階層ポリシーがない場合は、そのポリシーをフラット ポリシーと呼びます。フラット ポリシーは、物理インターフェイスにのみ適用できます。
キューイング ポリシーを論理インターフェイスに適用するには、子スタイルポリシー親ポリシーでの階層型シェーピング/子ポリシー上のキューイングを使用する必要があります。
先ほど学習したように、ポリシーを作成するとエラー チェックが行われます。2 回目のエラー チェックは、ポリシーをインターフェイスに適用したときに発生します。たとえば、特定の種類のインターフェイスでは実現できない帯域幅の保証を含むポリシーを作成する可能性があります。ポリシーマップは、定義されている場合は有効である可能性がありますが、適用対象のインターフェイスに関する情報と組み合わせると、IOS では次の例にあるようなエラーが認識されます。
policy-map attach-error-example
class bulk-data
bandwidth 200000
このポリシーでは、バルクデータ用に 200 Mbps を予約する必要があることが規定されています。このポリシーを GigabitEthernet インターフェイスに適用した場合、正常に動作します。しかし、このポリシーを POS OC3 インターフェイスに適用すると、適用時に拒否されます。OC3 インターフェイスの公称帯域幅は 155 Mbps です。特定のトラフィック クラスに対して 200 Mbps を予約することはできません。
1 つのコマンドは常に、QoS ポリシーの動作を確認するために使用できます。
show policy-map interface interface-name
このコマンドの出力には、ポリシーマップの各クラスのセクションが表示されます。また、そのクラスに属していると分類されたパケットとバイト、およびそのクラスに設定されている各アクションの統計も表示されます。
(注) |
このコマンドで使用可能な統計情報は、CISCO-CLASSBASED-QOS-MIB で SNMP を介して使用することもできます。 |
QoS ポリシーが DMVPN などのマルチポイント インターフェイスに適用されている場合は、コマンドの show policy-map multipoint tunnel トンネル番号 バリアントを使用します。同様に、ポリシーがブロードバンド セッションに適用されている場合は、コマンドの show policy-map session uid セッション番号 バリアントを使用します。