Cisco の QoS 設定｜MQC で構成する優先制御の設計のポイント

はじめに

Cisco の機器で QoS を設定する際、かつては機能ごとにコマンド体系が異なり、設定が複雑になりがちでした。現在は MQC（Modular QoS CLI）という共通の枠組みに整理され、ルータ／スイッチを通じて同じ考え方で設定できるようになっています。

一方で、MQC の「型」を理解しないまま設定例だけを真似ると、優先制御が意図どおりに効かない、確認方法が分からない、といった状況になりがちです。本記事では、MQC の構成を起点に、Cisco での QoS の設計・設定・確認・トラブル対処までを整理します。

なお、QoS そのものの全体像（分類・マーキング・キューイング・帯域制御の役割や、優先制御の設計の考え方）は、関連記事『QoS とは｜優先制御の仕組みと製品共通で押さえる設計のポイント』で扱っています。本記事は、その考え方を Cisco の設定に落とし込む位置づけです。

Cisco の QoS と MQC（Modular QoS CLI）の基礎

MQC は、Cisco 機器で QoS を設定するための共通の枠組みです。「通信を分類する → 分類した通信への動作を定義する → インターフェースに適用する」という 3 つのステップで構成され、ルータ・スイッチを通じて一貫した手順で設定できます。

MQC の 3 ステップ（class-map → policy-map → service-policy）

MQC の設定は、次の 3 ステップで進めます。Cisco の公式ガイドでも、この 3 つの基本ステップで構成されると説明されています。

参考: Cisco — QoS: Modular QoS Command-Line Interface Configuration Guide (IOS 15M&T)
“The MQC structure consists of the following three high-level steps”
（MQC の構造は、次の 3 つの基本ステップで構成される）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/15-mt/qos-mqc-15-mt-book/qos-mqc.html

全体像をコマンドの骨格で示すと、次のような構造になります（各機能の詳細は後続のセクションで扱います）。

! ステップ1: 分類（class-map）
class-map match-any VOICE
 match dscp ef
!
! ステップ2: 動作の定義（policy-map）
policy-map QOS-POLICY
 class VOICE
  priority percent 10
!
! ステップ3: インターフェースへの適用（service-policy）
interface GigabitEthernet0/1
 service-policy output QOS-POLICY

1 つの policy-map を作成すれば、複数のインターフェースに適用できる点が MQC の利点です。クラスとポリシーを部品として再利用できるため、設定の一貫性を保ちやすくなります。

なお、対応する機能やオプションは機種・IOS／IOS-XE のバージョンによって異なります。実際の設定にあたっては、対象機種の公式リファレンスでの確認を推奨します。

設計時に押さえるポイント（信頼境界・クラス設計）

設定に入る前に、設計の方針を決めておくと、class-map や policy-map の構成がぶれにくくなります。Cisco に限らず共通する要点ですが、特に次の 2 点を押さえておくことを推奨します。

1 点目は、信頼境界（Trust Boundary）をどこに置くかです。端末が付けた DSCP / CoS をそのまま信頼するか、機器側で分類し直して付け直すかを決めます。信頼境界より外から来た通信は、境界で再分類・再マーキングする設計が基本です。

2 点目は、クラス設計です。守りたい通信を 3〜4 クラス程度に整理し、各クラスにどの DSCP 値を割り当て、どれだけの帯域を確保するかを決めます。クラスを増やしすぎると運用が複雑になるため、優先するクラスを絞り込むことを推奨します。具体的なクラスの考え方（音声・映像・業務・ベストエフォート）は、前述のハブ記事も参考にしてください。

この設計方針が決まっていれば、次のセクション以降の class-map（分類）と policy-map（動作）の構成に、そのまま落とし込めます。

トラフィックの分類とマーキング

MQC の最初の 2 ステップにあたるのが、分類とマーキングです。class-map で通信を見分け、policy-map の中でマーキング（set）を行います。特に信頼境界の入口で、通信を分類し直して付け直す場面が中心になります。

class-map による分類（match 条件）

class-map は、match 条件によって通信を見分けます。複数の match 条件を書く場合、すべてに一致させる match-all と、いずれかに一致すればよい match-any を選びます。

参考: Cisco — QoS: Modular QoS Command-Line Interface Configuration Guide (IOS XE 16.10)
“Create class-maps – Classify your traffic (applications) into classes that you will work on”
（class-map を作成し、扱う通信（アプリケーション）をクラスに分類する）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-16-10/qos-mqc-xe-16-10-book/qos-intro.html

代表的な match 条件には、match dscp（DSCP 値）、match access-group（ACL 参照）、match protocol（NBAR によるアプリケーション識別）、match cos（レイヤ 2 の CoS）などがあります。

class-map match-any VOICE
 match dscp ef
!
class-map match-any CALL-SIGNALING
 match dscp cs3
!
class-map match-any BUSINESS
 match access-group name BIZ-APPS

上記の BUSINESS クラスは、別途定義した名前付き ACL BIZ-APPS に一致する通信をまとめています。match protocol を使う場合は、対象機種で NBAR が利用できることを公式リファレンスで確認してください。

policy-map でのマーキング（set dscp / set cos）

分類したクラスに対しては、policy-map の中で set dscp や set cos を使って優先度の値を書き込みます。信頼境界の入口で、端末が付けた値を信頼せずに付け直す、という使い方が代表的です。

policy-map MARKING-IN
 class VOICE
  set dscp ef
 class CALL-SIGNALING
  set dscp cs3
 class BUSINESS
  set dscp af31
 class class-default
  set dscp default

このポリシーは、後述する service-policy input でインターフェースの入力方向に適用します。端末のマーキングを信頼しない設計では、信頼境界の入口で分類し直し、set で付け直すことで、ネットワーク内部のマーキングを一貫させられます。L2 区間で CoS を扱う場合は、set cos で対応する値を割り当てます。

キューイングと帯域制御の設定

マーキング済みの通信を、出力インターフェースのキューにどう振り分けるかを policy-map で定義します。最低帯域を保証する CBWFQ、音声などを優先する LLQ、帯域の上限を扱うシェーピング／ポリシングを組み合わせます。

CBWFQ による帯域保証（bandwidth）

CBWFQ は、クラスごとに最低帯域を保証する方式です。policy-map のクラス設定モードで bandwidth を指定します。指定方法には、bandwidth（kbps 指定）、bandwidth percent（インターフェース帯域に対する割合）、bandwidth remaining percent（残余帯域に対する割合）があります。

policy-map WAN-QOS
 class BUSINESS
  bandwidth percent 30
 class class-default
  fair-queue

bandwidth で指定するのは輻輳時の最低保証であり、回線に余裕があるときは各クラスがこれを超えて送信できます。

LLQ による音声の優先（priority）

LLQ は、CBWFQ に厳格優先キューを加えた方式です。クラスに priority を指定すると、そのクラスは他のキューより先に送出されます。

参考: Cisco — QoS: Congestion Management Configuration Guide (IOS 12.4T)
“LLQ provides strict priority queueing for CBWFQ, reducing jitter in voice conversations”
（LLQ は CBWFQ に厳格な優先キューイングを提供し、音声通話のジッタを低減する）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_conmgt/configuration/12-4t/qos-conmgt-12-4t-book.pdf

policy-map WAN-QOS
 class VOICE
  priority percent 10
 class CALL-SIGNALING
  bandwidth percent 5
 class BUSINESS
  bandwidth percent 30
 class class-default
  fair-queue

priority で指定したクラスは、輻輳時には指定したレートにポリシングされます。優先クラスに割合（上限）を設けることで、輻輳時に音声が他の通信を圧迫しないように制御できる点が、LLQ を使う際の要点です。priority は kbps（例: priority 1000）でも、割合（例: priority percent 10）でも指定できます。

シェーピングとポリシング（shape / police）

シェーピングとポリシングは、帯域の上限を扱う機能です。挙動の違い（シェーピングは遅延させて平滑化、ポリシングは破棄または再マーキング）は、ハブ記事でも整理しています。

シェーピングは、クラスベースのトラフィックシェーピングとして shape average で設定します。Cisco はクラスベースのシェーピングを推奨しています。

policy-map SHAPER
 class class-default
  shape average 50000000

ポリシングは police で設定し、CIR（規定レート）に対して、適合（conform）・超過（exceed）・違反（violate）時の動作を指定します。

policy-map INGRESS-POLICE
 class BUSINESS
  police cir 10000000 conform-action transmit exceed-action drop

参考: Cisco — QoS: Regulating Packet Flow Configuration Guide（Class-Based Traffic Shaping）
“Class-Based Traffic Shaping is the Cisco-recommended traffic shaping mechanism”
（クラスベースのトラフィックシェーピングは、Cisco が推奨するシェーピング方式である）
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/qos/b-quality-of-service/m_qos-regpkt-cls-0.html

なお、回線速度より低いレートに整えたうえでクラス別のキューイングを行う場合は、親ポリシー（shape average）の下に子ポリシー（CBWFQ）を適用する階層型ポリシーを用います。シェーピングは送出側でレートを平滑化したいとき、ポリシングは境界で上限を強制したいとき、という使い分けが基本です。

設定の適用と確認

class-map と policy-map を作成したら、service-policy でインターフェースに適用し、show policy-map interface で動作を確認します。MQC の 3 ステップ目（適用）と、その確認にあたる部分です。

インターフェースへの適用（service-policy input / output）

service-policy は、ポリシーをインターフェースの入力（input）または出力（output）方向に適用します。

参考: Cisco — QoS: Modular QoS Command-Line Interface Configuration Guide (IOS 15S)
“Attach the traffic policy (policy map) to the interface by using the service-policy command”
（service-policy コマンドを使って、トラフィックポリシー（policy map）をインターフェースに適用する）
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/15-s/qos-mqc-15-s-book/qos-mqc.html

適用方向には基本的な考え方があります。マーキングやポリシングによる境界での制御は入力方向（input）、CBWFQ・LLQ などのキューイングやシェーピングは出力方向（output）に適用します。

interface GigabitEthernet0/1
 description LAN-side
 service-policy input MARKING-IN
!
interface GigabitEthernet0/2
 description WAN-side
 service-policy output WAN-QOS

ここで注意したいのが、キューイング（bandwidth や priority）は出力方向でのみ機能する点です。優先キューや帯域保証のポリシーを入力方向に適用しても意図どおりには動作しないため、適用方向の誤りはよくあるつまずきの一つです。

show policy-map interface による確認

適用したポリシーの動作は、show policy-map interface で確認します。クラスごとのマッチしたパケット数、キューのドロップ、優先・帯域の統計などを参照できます。

Router# show policy-map interface GigabitEthernet0/2

 GigabitEthernet0/2

  Service-policy output: WAN-QOS

   Class-map: VOICE (match-any)
     12345 packets, 1234567 bytes
     Match: dscp ef
     Priority: 10% (...), bytes output ...
   Class-map: BUSINESS (match-any)
     6789 packets, 678901 bytes
     Match: access-group name BIZ-APPS
     Queueing
       bandwidth 30% (...)
       (queue depth/total drops/...) 0/0/...
   Class-map: class-default (match-any)
     ...

確認の着眼点は次のとおりです。各クラスの Match のパケット数が増えているか（＝分類できているか）、Queueing の drops がどのクラスで発生しているか、priority や police の超過（exceed）統計が想定どおりか、を見ます。show policy-map interface での確認手順は、公式ガイドでも QoS の動作確認方法として案内されています（https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-16-10/qos-mqc-xe-16-10-book/qos-intro.html ）。

よくあるトラブルと対処

QoS を設定したのに効果が見えない場合、原因は設定値よりも前提や整合にあることが少なくありません。show policy-map interface の出力を起点に切り分けると、原因を絞り込みやすくなります。

優先制御が効かないときの確認ポイント

代表的な原因と、確認方法は次のとおりです。

• 適用方向の誤り。キューイングのポリシーを入力方向に適用していないかを show running-config や show policy-map interface で確認します。
• そもそも輻輳していない。優先制御は輻輳時にはじめて効くため、平常時の確認では差が現れません。負荷をかけた状態で測定します。
• 分類できていない。show policy-map interface で該当クラスの Match が 0 のままなら、class-map の match 条件か、その手前のマーキングを見直します。
• マーキングが信頼境界で消えている、または書き換わっている。入力側で意図した DSCP に分類・再マーキングできているかを確認します。
• 帯域配分の不整合。priority に上限がなく他クラスが送出されにくい、あるいは各クラスの bandwidth の合計が過大、といった配分を見直します。

マーキング・キュー・適用方向の見直し

切り分けは、「分類 → マーキング → 適用方向 → キュー統計」の順に確認すると進めやすくなります。

• マーキングの確認: 設定値だけでなく、実際にパケットへ付与された DSCP / CoS 値をパケットキャプチャで確認します。流れている値と設定上のマーキングが一致しているかを確かめられます。キャプチャでの絞り込み方法は、関連記事『Wireshark のフィルタ書き方と複数条件の使い分け｜TCP 再送と HTTP エラーの追跡』で扱っています。
• キューの確認: show policy-map interface の drops を見て、どのクラスで破棄が起きているかを把握します。優先したいクラスでドロップが多い場合は、priority や bandwidth の配分を見直します。
• 適用方向の確認: service-policy が input / output のどちらに適用されているかを確認します。キューイングは出力方向でのみ機能します。

これらを順に確認することで、設定そのものの誤りなのか、適用方向や前提（輻輳の有無）の問題なのかを切り分けられます。

まとめ

• Cisco の QoS は、MQC（class-map → policy-map → service-policy）の 3 ステップで構成します。
• class-map で通信を分類し、policy-map 内の set dscp / set cos でマーキングします。
• CBWFQ（bandwidth）で、クラスごとに輻輳時の最低帯域を保証します。
• LLQ（priority）で音声を優先し、割合の上限で他クラスの圧迫を防ぎます。
• 帯域制御は shape average（平滑化）と police（上限の強制）を用途で使い分けます。
• キューイングは出力方向、マーキングやポリシングは境界の入力方向に適用します。
• 効かないときは「分類 → マーキング → 適用方向 → キュー統計」を show policy-map interface で確認します。

以上、最後までお読みいただきありがとうございました。