QoSは、通信を分類し、混雑する出口でどれを先に送り、どれを待たせ、制限するかを決める仕組みです。物理回線や契約帯域を増やす機能ではありません。DSCPを付けただけで、経路全体が同じ優先処理をするとも限りません。
この記事では分類・marking・キュー・shaping・policingを分け、装置のカウンターと利用者の処理で効果を確かめます。図は出口のキューの概念で、処理の位置や順序は機器の実装により変わります。
この記事でわかること
- まず混雑する場所と、守りたい処理を決める
- 分類・marking・キューは、別の仕事をしている
- shapingは待たせ、policingは超過分を制御する
まず混雑する場所と、守りたい処理を決める
音声の途切れ、操作の待ち時間、大容量転送の競合など、利用者が困る処理を遅延・揺らぎ・損失・必要帯域へ対応させます。出口の帯域、契約側の制限、上流の混雑、端末やサーバーの性能も区別します。
| 確認すること | 設計へつなげるもの |
|---|---|
| 混雑するリンク・方向 | ポリシーを適用する出口や制限位置 |
| 守るサービス | 分類条件と必要な遅延・損失の範囲 |
| 同時に流れる他の通信 | 残す帯域、待ち・損失への許容 |
| 契約・相手側の制限 | 必要なshapingと上流の扱い |
| 端末のmarking | 信頼する境界と付け直す位置 |
自装置が空いていても上流が混雑していれば、ここだけのキュー変更で結果が改善しないことがあります。非混雑時の平均RTTだけで効果を判定せず、ボトルネックと条件を確定します。負荷を増やす試験はラボまたは合意した作業枠で行い、rate・期間・停止条件を決めます。
分類・marking・キューは、別の仕事をしている
| 機能 | 何をするか | 確認するもの |
|---|---|---|
| classification | どの通信をどのclassへ入れるか | ACL、DSCP、対応するアプリ条件、match |
| marking | DSCP等の値を付ける・変更する | 前後のパケット、trust境界 |
| queuing | 送信できないパケットを保持 | depth、drop、送出した量 |
| scheduling | どのキューから送るか決める | 優先・帯域配分と非優先の結果 |
DiffservのDSCPはDSフィールド内の6ビットで、装置ごとの処理へ分類するために使います。値を設定したこと自体でEnd-to-Endの品質を保証するわけではありません。途中で再markingされる、扱いが違う、そもそも混雑が別の場所にある、といった条件を確認します。
参考：RFC 2474：DSフィールド（2026年10月5日確認）
参考：RFC 2475：Diffservの分類と制御（2026年10月5日確認）
端末が付けた優先値を無条件に信頼すると、大容量転送も優先classへ入る可能性があります。どの接続先で値を信頼し、どこで付け直すかを決めます。分類条件が広すぎないかは、実際のmatchと取得した通信で検証します。
shapingは待たせ、policingは超過分を制御する
| 機能 | 基本的な動き | 起き得る影響 |
|---|---|---|
| shaping | 一時的に保持し、設定レートに合わせて送る | 待ち時間増加、buffer上限で損失 |
| policing | レート等を測り超過分をdrop・remark等 | 損失や扱いの変更、TCP等への影響 |
単位がMbpsでもburst条件や階層、評価する場所で結果が変わります。shapingとpolicingを同じ設定として並べず、必要な動作と対象機種の実装を確認します。policingは必ずキューの後という順序ではなく、egress policyでもenqueue前に評価する実装があります。
参考：Cisco IOS XE 17.x：Packet Policing（2026年10月5日確認）
優先キューにも利用量の上限を設計します。全通信を最優先にすれば、守りたい処理の区別が消えます。音声が正常でも、非優先の業務が使えなくなるなら、ポリシー全体の成功とは判定しません。
設定名、適用方向、実カウンターを分けて確認する
Cisco IOS XE系：確認の例
show class-map
show policy-map
show policy-map interface GigabitEthernet0/1
show interfaces GigabitEthernet0/1上は実行確認の例で、IF名や出力項目は機種・版によります。policy-mapが存在しても、対象IFへ想定する方向で適用されていなければ、その通信を制御しません。物理IF、サブIF、親子policy、hardwareの制約を確認してください。
| カウンター・情報 | 読み方 | 追加の確認 |
|---|---|---|
| match・offered | classへ入る通信があるか | 分類条件・DSCP・取得点 |
| queue depth | 待ちの状態 | 瞬間値と期間、サンプリング |
| drop | どのclass・機能で落ちたか | policy、policer、物理IF等の位置 |
| 送出量・rate | その期間に送った量 | 集計期間、単位、契約帯域 |
| IFエラー | QoS以外の障害候補 | CRC等と物理状態 |
累積dropが24と表示されたことだけでは、今回の試験で24落ちたとは言えません。変更前後の値と取得時刻を保存し、再起動やclearでリセットされていないかも確認します。ログやカウンターを消してから原因を探すと、比較する基準を失います。
平常・混雑・適用後を、同じ入力で比較する
- 同じ送信元・宛先・サービスと、優先/非優先の負荷を決める。
- 正常な平常時の処理、marking、カウンターを保存する。
- 決めた負荷で混雑を再現し、両classの結果を測る。
- 同じ条件で適用後を測り、遅延・揺らぎ・損失・業務結果を比較する。
- 負荷を止め、通常通信・監視・カウンターの安定を確認する。
数値は平均だけでなく、ばらつきや最大、失敗した処理も残します。優先側と非優先側を同時に評価し、許容する待ち・損失を合意した基準へ照合します。DSCPの前後を取得する際も、ミラー自体の取りこぼしをネットワークの損失へ混ぜないようにします。
改善しない場合は、混雑・分類・上限・実経路へ戻る
classに入っていないなら分類、正しく入っているのにdropなら上限や負荷、ポリシーに問題が見えないなら他の出口やアプリを確認します。QoSという名前だけで、DNS・サーバー待ち・物理エラーまで説明しないでください。
負荷、適用IFと方向、class条件、前後カウンター、実通信の結果がそろうと、変更理由を第三者が確認できます。取得方法はミラーとWireshark、試験の期待値はポリシーテスト、IFの異常確認はshow interfacesで補ってください。
筆者の関連ポスト：Xで読む
