ネットワークエンジニアの仕事や、CCIE試験で役立つようにQoS技術解説をまとめました。
◆ QoS技術 – Ciscoルータでの実装
⇒ https://www.infraexpert.com/study/study65.html
◆ QoS技術 – Catalystスイッチでの実装（ CCIE対策 ）
⇒ https://www.infraexpert.com/study/study66.html
現在ではL3スイッチの新規導入にはCatalyst3560X/3750Xではなく、Catalyst3650/3850を導入するのが一般的ですが、CCIEラボ試験で使用されるCatalyst3560X IOS15.0 をベースに技術解説をしています。Catalyst3850との違いは、解説ページのリンク先をご参照ください。
上記リンク先の解説に加えて、以下の記事も読むことでQoSについて理解がより深まります。
CiscoルータのQoSを理解する上での根本的な知識
QoSを理解する上で、QoSつまりサービス品質（ Quality of Service ）がどのような技術によって実現しているのかを理解することが重要です。QoSのDiffservモデルではサービス品質を次の処理により実現しています。
1. 分類
2. マーキング
3. キューイング
4. スケジューリング
つまりQoS技術には色々な種類があるわけです。そして、サービス品質をより良くする技術も加えられた結果、QoS技術は以下の大きく4分野に分類することができます。
・ 輻輳管理の技術（ キューイング・スケジューリングの技術 ）
・ 輻輳回避の技術（ そもそも輻輳を発生させないようにする技術 ）
・ 分類とマーキングの技術（トラフィックを分類・マーキングする技術）
・ ポリシングとシェーピングの技術（ 利用可能な通信帯域を制限する技術 ）
上記の点を理解した上で、QoSの技術解説を読み進めていくと理解しやすいと思います。次にキューイングとスケジューリング関する根本的な部分の誤解しやすい点について説明します。
トラフィックが混雑する輻輳ポイントは通信速度差があるポイント、例えばLANリンクからWANリンクへ変わるリンクが輻輳ポイントとなることが多く、LANリンクとWANリンクとを接合するデバイス（ルータ等）で輻輳管理の技術のLLQを実装させることがよくありますが、そもそも、ハードウェアのQueueが一杯でない場合には、ソフトウェアのQueueを発動せずにパケットは転送されていきます。つまり、根本的に下図を理解していることが重要です。
メーカーや機種によってアーキテクチャは異なりますが、パケット転送においてソフトウェアよりもハードウェアのQueueで処理する方が高速であることは共通しており、どのメーカーもハードウェアのQueueに空きがある場合、ソフトウェア処理をバイパスさせます。
ハードウェアのQueueが一杯である場合（つまり輻輳が発生している場合）、ソフトウェアにより管理者が定義したキューイング・スケジューリング技術により処理されていきます。
CatalystスイッチのQoSを実装する上での役立つポイント
先ず、Catalyst QoSの技術解説の最初の3つの記事を理解することが重要です。
◆ Catalyst QoSの仕組み その1（パケットの送出、分類）
◆ Catalyst QoSの仕組み その2（マッピングテーブル）
◆ Catalyst QoSの仕組み その3（キューイング・スケジューリング）
マニュアルの技術解説を見ると多くのコンフィグ解説が紹介されていますが、一般的な企業ネットワークにおいて音声デバイスとPCデバイスが混在するなかで実装されるコンフィグは、それほど多くありません。最小限の設定ならCatalyst3560X/3750Xの場合は以下だけです。
1. QoSを有効化 ⇒ (config)# mls qos
2. どの優先度情報を信頼（trust）するのか定義 ⇒ (config-if)# mls qos trust dscp など
3. 出力キューのプライオリティキュー（PQ）を有効化 ⇒ (config-if)# priority-queue out
これらの基本設定に加えて、例えばDSCP値40～47以外のDSCP値をプライオリティキューを格納したい場合は次の設定で入力キュー、出力キューへのDSCPマッピングの設定をします。音声パケットの場合はDSCP値46がもともと付加されていますが、シグナリングパケットではDSCP40～47以外のDSCP値が付加されているので、それをマッピングしたい時などに設定。
・ mls qos srr-queue input dscp-map queue 1 threshold 1 DSCP値（入力キュー用）
・ mls qos srr-queue output dscp-map queue 1 threshold 1 DSCP値（出力キュー用）
4つある出力キューのなかの「キュー1」をプライオリティキューとして有効化した場合には、srr-queue bandwidth share コマンドや srr-queue shape コマンドの「weight1」は、その比率計算から除外されますが、残りの3つあるキュー（weight2、weight3、weight4）の比率を変更したい場合（そのような要件がある場合、そのような変更をする必要がある場合には、全ての物理ポートにその設定をします。例えば srr-queue bandwidth share 255 30 30 40
・ srr-queue bandwidth share 255 weight2 weight3 weight4
また、Catalystスイッチのポートに「音声通話の録音デバイス」を接続させる場合、全てのキューにおいて「共有モード（share）」とすることを推奨とするデバイスが多いことから、以下の設定を該当ポートにする場合があります。srr-queue bandwidth shapeコマンドで各weight値を「0」とした場合、そのキューでは「共有モード」として動作します。
・ srr-queue bandwidth shape 0 0 0 0
その他のQoS設定については、要件を満たす上で必要な場合のみ変更するようにしましょう。
QoSの正常性確認 – 企業ネットワーク導入時の試験方法
要件、構成、環境やSI工数により実施可能なQoSの試験方法は色々だと思いますが、共通して役立つ基本的な試験方法について紹介したいと思います。
・ Wiresharkでパケットキャプチャして確認しましょう！
設計どおりの優先度情報（ DSCP値、CoS値 ）が付加されているかどうかは、Wiresharkにてパケットキャプチャを行いDSCP値を確認するようにしましょう。そして、それをエビデンスとして残しておくことをお勧めします。QoSを設定した全デバイスで確認をするのではなく、QoS設計パターンが異なるデバイスの分だけで問題ないと思います。
・ 負荷試験は客先への導入前（検証環境）と導入後（本番環境）の2回をお勧めします。
負荷試験によって優先制御が適切に行われているかどうかを確認するだけでなく、導入機器が負荷に耐えられるスペックであるかどうかも確認できます。QoSの負荷試験が成功しない場合そのトラブルシューティングやリカバリーは、時に納品スケジュールの遅延を発生させるほど時間を要することもあり、このような問題は検証時に解決しておくことがきわめて重要です。※ 特に、適切な機種を選定できていなかった場合は色々な対策を講じる必要があります。
なお、ここでいう負荷試験とは、バックボーンが十分な「LANのスイッチドネットワーク」というよりも、ボトルネックが発生する部分（QoSが頻繁に発動する部分）である拠点間通信におけるWANルータやWANスイッチなどが特に重要です。
QoSの実装はCPU消費が激しい技術の1つであることから、そもそも負荷試験の段階ではなく機種選定の段階で豊富な経験を有するエンジニアへの確認と導入実績のしっかりとした確認を強くお勧めします。特に、WANルータの選定には最新の注意を払いましょう。当方が機種選定する場合にはお客様には「今後の拡張性を考慮」を強く主張して、いつも少しだけ余裕のあるスペックをご選定頂いております。ベンダーとお客様ともにWin-Winな導入手法ですね。
・ 本番環境での負荷試験では、可能な限り実トラフィックを生成して負荷をかけましょう！
負荷試験の手法として、負荷ツールを使用した試験方法もありますが、より確実にQoSの実装が適正であることを確認するために、可能な範囲で実トラフィックを流すことが重要です。
例えば、音声トラフィックとデータトラフィックが混在する環境においては、設計通りの音声通話のセッションをはった状態で、バースト性のあるFTPによりデータトラフィックを転送し音声品質に影響がないのか、音声パケットのドロップがないかどうか、LLQなどではPQ部分がが発動しているのかを確認することが大切です。音声品質はお客様にもご確認頂きましょう。
以上です。本記事の内容はCCIE学習でも仕事でも役立つはずです。ご参考頂ければ幸いです。