1.4QoS 構成の解釈

QoS は「帯域を増やす技術」ではなく、帯域が足りない瞬間に何を犠牲にするかをあらかじめ決めておく技術です。輻輳が起きていない回線では QoS の設定はほとんど何もしません。ENCOR で問われるのは、class-map・policy-map・service-policy という構成を読んで、輻輳時に各トラフィックがどう扱われるかを説明できるか、そして症状（音声の途切れ、TCPの再送増加）から構成のどこが原因かを特定できるかです。

1.4.1分類とマーキング

• 分類＝トラフィックを条件（ACL・プロトコル・入力インタフェース・既存のマーキング値など）で見分ける処理。IOS では class-map で条件を定義する。分類はできる限り信頼境界に近い、発信元に近い場所で行うのが原則で、コア側で毎回L4条件を照合するのは効率が悪い。
• マーキング＝分類結果をパケット/フレームのヘッダに書き込むこと。L3では IP ヘッダの DSCP（6ビット・DiffServ）、L2では 802.1Q タグ内の CoS（3ビット）を使う。一度マークしておけば、以降のホップはマーキング値を見るだけで扱いを決められる——これが「エッジで分類・マーキングし、コアはマーキングを信頼する」という DiffServ の設計思想。代表値は音声の EF（46）、シグナリングの CS3、ベストエフォートの DF（0）。
• 信頼境界（trust boundary）の設計が肝心。ユーザ端末が自分で付けた DSCP をそのまま信じると、誰でも自分のトラフィックを EF にできてしまい優先制御が無意味になる。したがってアクセスポートでは原則としてマーキングを信頼せず（または IP 電話など特定機器に限って信頼し）、信頼できない側から来た値は付け直すのが定石。

1.4.2キューイング

• キューイングは出力インタフェースが輻輳したときにだけ意味を持つ。輻輳していなければパケットはキューに溜まらず、優先度の差も現れない。「QoSを入れたのに変化がない」という相談の多くは、そもそも輻輳が起きていないか、輻輳している場所と設定した場所が違うことに起因する。
• LLQ（Low Latency Queuing）＝CBWFQ（クラス別に帯域を保証する重み付きキューイング）に厳格優先キューを加えたもの。遅延に厳しい音声は優先キューに入れ、他より先に送出する。ただし優先キューには帯域上限（ポリサ）が併設されるのが重要で、これが無いと音声が回線を占有して他クラスを餓死させる。IOS では priority で優先キューと帯域を指定する。
• 輻輳回避は別概念で、WRED のようにキューが満杯になる前から確率的に落として TCP のグローバル同期（全フローが同時に絞り、同時に増やす振動）を防ぐ。何もしないとキューが溢れて末尾から一律に落とすテールドロップとなり、多数のTCPフローが同時に再送・輻輳制御に入る。

1.4.3ポリシングとシェーピング

• ポリシング＝契約速度を超えた分をその場で破棄（またはマーキング降格）する。バッファに溜めないので遅延を増やさないが、超過分は失われる。TCPに対して行うとドロップ→再送→輻輳ウィンドウ縮小という反応を引き起こし、スループットが階段状に落ちる。入力方向にも適用でき、他者からの流入を制限する用途に向く。
• シェーピング＝超過分をバッファに溜めて後で送ることで、出力を契約速度に均す。破棄しないのでTCPの再送を誘発しにくいが、遅延とジッタが増える（バッファが深いほど顕著）。原則として出力方向のみに適用する。相手先の回線速度に合わせて自分の送出を抑える、いわゆるハブ&スポークの速度差対策が典型用途。
• 使い分けの判断軸：遅延に厳しいリアルタイム系（音声/映像）は遅延を増やすシェーピングと相性が悪いため、優先キュー＋上限ポリサで扱う。逆にバルク転送（バックアップ・ファイル同期）は多少遅れても構わないので、シェーピングで滑らかにしたほうが回線全体の再送が減る。「捨ててよいか、遅らせてよいか」を要件から先に決めるのが順序。

あなたは本社と支社を結ぶ50MbpsのWAN回線で、「業務時間帯に音声が途切れる」という申告と、「夜間バックアップの転送が遅く、TCPの再送が異常に多い」という2件の申告を同時に受けました。現行構成は、音声を DSCP EF で分類して LLQ の優先キューに入れ、それ以外を一括してポリシングで 40Mbps に制限しています。まず show policy-map interface を確認すると、業務時間帯に優先キューのドロップカウンタが増加していました。これは優先キューに併設された帯域上限（ポリサ）を音声トラフィックが超過していることを意味します。優先キューの上限は「音声を守る」ためではなく「音声が他を餓死させないため」に存在するので、通話数が想定を超えれば超過分は容赦なく捨てられ、まさに音声の途切れとして現れます。ここで「優先キューの上限を撤廃する」のは危険で、上限を外すと輻輳時に音声が回線を占有して業務トラフィック全体が止まりかねません。妥当なのは同時通話数の実測に基づいて優先キューの帯域を適正化することと、アクセスポートの信頼境界を見直して、EF を勝手に名乗る非音声トラフィックが優先キューに紛れ込んでいないかを検証することです（後者は優先キューのマッチ数が想定通話数に対して過大かどうかで判別できます）。次に夜間バックアップですが、こちらはポリシングで超過分を破棄していることが再送増加の直接原因です。バルク転送はTCPなので、ドロップは即座に再送と輻輳ウィンドウの縮小を招き、実効スループットが階段状に落ちます。バックアップは遅れても構わないが失われると再送で無駄が出る性質なので、ポリシングをシェーピングに置き換えて超過分をバッファし、遅延として吸収するのが適切な判断です。ここで「バックアップも優先キューに入れて速くする」と考えるのは根本的な取り違えで、優先キューは遅延に厳しいトラフィックのためのものであり、バルク転送を入れれば音声の遅延を直接悪化させます。同様に「回線を100Mbpsに増速する」は一見効きますが、輻輳時の優先順位という本質的な設計は未解決のままで、トラフィックが増えれば同じ症状が再現します。QoS の診断は、症状が「捨てられた」結果なのか「遅らされた」結果なのかを見極め、show policy-map interface のクラス別ドロップで裏取りするのが定石です。

1.4.4この節のまとめ

• QoS は帯域を増やさず、輻輳時に何を犠牲にするかを決める。順序は分類（class-map）→マーキング（DSCP/CoS）→キューイングで、信頼境界の外のマーキングは信頼しない
• 音声は DSCP EF(46) で LLQ の優先キューへ。優先キューには帯域上限（ポリサ）が併設され、これは他クラスの餓死を防ぐためのもので撤廃してはならない
• ポリシングは超過を破棄（遅延は増えないがTCP再送を誘発）、シェーピングは超過をバッファ（再送は減るが遅延/ジッタが増え出力方向のみ）。捨ててよいか遅らせてよいかを要件から決める