ヤマハネットワーク技術者認定試験（YCNE）受験⑫・帯域警察24時
はじめに
皆さんも、ムカつく上司の通信だけ制限かけられないかな、と思ったことがあると思います。そうです、ふんぞり返ってネットニュースばっかりみてる全然仕事しないアイツです。
そんな陰徳を毎日スタックされている皆様に福音です。それが今回検討するQoSという技術になります。これによって憎らしいアイツも突然のネット遅延にビビり、我々の安寧も保たれるってもんですよ。
では、今回はアイツのPCをサンプルに考えていきます。
QoSの仕組み
最初に、Quality of Service（サービス品質）についてです。大枠としては、優先順位やルールに基づいて通信を律する行為と言えます。このサービス品質のコントロールを帯域制御及び優先制御で実施します、が今回の話です。詳細には、①ルールを決め、②それに基づいて分類し、③分類ごとの通信待ち（キュー）に格納、④キュー毎の順番を決める、となります。以下に、この一連の一つ一つをヤマハのSWX2200のページを参考に確認していきます。
①ルール決め・クラス分け
これは優先・非優先の順序を決める印を決めます。主に
・送信元／宛先 IPアドレス
・VLAN ID
などがあります。これらは分かりやすいんですが
・VLAN タグヘッダの CoS値
・IPヘッダの Precedence値
・IPヘッダの DSCP
などはフレームやパケットのヘッダで確認できる奴で少し分かりにくい。CoS値はVLAN使う時に追加される奴で、DSCPは宛先や生存時間以外のIPヘッダにあるよく分からん奴ですね。ヘッダ先だとよく分からんくても、QoS先で確認すると少し分かりやすいかも。そもそも、間違えなければ良し、届けば良しのイーサネットフレームやらIPパケットは、主軸となるコンセプトが違くて馴染みがないだけですね。
②分類・マーキングorリマーキング
①によって何を指標とするか（トラストモード）を決めたら、分類表を確認します。値がこれならタイプはこれ、みたいな対応表です。八段階で分類値は数が多くなるほど優先度が高くなります。なんですが、指標と対応値は一部一致しません。
指標値：12345678
分類値：20134567
下段に指標を対応させます。指標値1は分類値2、指標値2は分類値0、指標値3は分類値1となります。
簡易的に運用する際は、とりあえず優先度高or低でやるでしょうから、低のものを指標値2にすればデフォルトの、つまり設定いらずで他が高になるという計らいでしょうか。アイツですか？ もちろん指標値2ですよ。
で、さらに自主的に指標値を変える行為をリマーキングと呼びます。これは、ポート毎に変更する際に利用します。我々的には、アイツのPCが直接結線されている場合に使います。
③通信待ち・キュー格納
分類値ごとに用意された受付にフレームやパケットを行列させます。
YAMAHAでは、これらのキューに対し、さらなる混雑緩和対策を用意しています。これをテール・ドロップ方式と呼びます。え、何？
あ、つまりキュー制御だけではなく、そのキューの中でもさらにクオリティ・コントロールしているということですね。
で、このテール・ドロップは最後列（しっぽ）が来たら破棄（ドロップ）する漢仕様。受付室がいっぱいなら最後列に受付番号渡すなんて温い対応は致しません。「ゴメンね、スープ切れちゃったから！」
④順番決め・スケジューリング
では、各送信待ち情報が指定のキューに並んでいますので、QoSの仕上げにキューをどの順番で送信するかを決めましょう。
・絶対優先方式
カッコ良い響きですが、キューの優先度順に送るだけの接近パワー型のようなシンプルかつ融通の利かない動作です。
・重み付きラウンドロビン
各キューに重みを設定し、その重みに基づいて送信していく搦め手タイプです。融通は利きますが、複雑でめんどくさい系ですね。
DNSなどのロードバランサならここに最小レスポンスが乗りますが、今回は受け手のサーバーもいない一方通行なのでこれで十分。私なら脳死で絶対優先方式を採用しますね。力こそパワー。
QoSの方法
と書いてて思いましたが、仕組みで紹介したのは優先制御ですね。帯域制御とハッキリ区別ついていないからQoSはマスターしにくい。なので、QoSの手法として二つ、シェーピングとポリシングを考えます。
シェーピングは流れをシェイプする方法です。動作のモデル・イメージとしては穴あきバケツを想定します。これは簡単。いくら大量の水を入れても、穴あきバケツならば一定の量した出ていきません。同様に、バーチャルバケツに送信情報を送ってもあらかじめ決めておいた適切な値にシェイピングされて出ていきます。
もう一つは、ポリシーに基づいてバーチャルバケツを操作するトークン・バケット方式です。穴あきにしろトークンにしろバケツを使いますが、この方法では、バケツでは直で送信情報は入れません。
トークン・バケットは一定時間で、一定量の通信を許可するトークンを発行します。バーチャルバケツには、トークンが溜まっていき、通信時に同量を示すトークンを使用します。そして、①トークンはバケツに指定した数以上は溢れて収容できません（バケツなので）、②トークンを使用できない通信は破棄されます。この為、キューに辿り着いた際に、許容したバースト量をバーチャルバケツの収容量や、トークン毎の利用可能な通信量といった形でポリシーを生成し運用します。
いずれの方法でも、キューに到着する順（優先制御）と「共に」利用することでQoSを実現します、ということか。やはりゼロトラストなんかもそうですがアーキテクチャというか、概念の体系というかは一つ一つちゃんと理解していないと全体が把握しにくいですね。
破棄をポリシーに含むトークン・バケットに対して、穴あきによるシェーピングでは、一定量を必ず通信させるのでパケットロスが起こりにくいのですが調整による遅延が発生しやすく、トークン・バケットはその逆の特徴となります。
YAMAHAスイッチのトークン・バケットアルゴリズム
では、実践。今回はYAMAHAスイッチ（以下、スイッチといいます）を用いて分かりにく過ぎる穴あきバケツのトークン・バケットを実現します。
スイッチでは、バケツのトークンを利用するために、①誰が、②どのようにを設定します。①をクラスマップと呼び、②をポリシーマップと呼びます。これらを利用するポートに割当て、QoSってなわけです。
今回は懲らしめることが目的なので1Mbpsに制限します。そして、アイツのPCはすでにdhcp scope bindによって払い出されるIPアドレスは把握済！
では、設定
#QoS を有効にする
qos enable
#アクセスリスト （対象）の設定 今回は192.168.100.2から0.0.0.0（全て）の通信
access-list 1 permit any 192.168.100.2 0.0.0.0 any
#クラスマップをcmapAと設定とコンフィグの移動
class-map cmapA
#アクセスリストとcmapAを一致させる
match access-list 1
exit
#ポリシーマップ作成
policy-map pmap1
#上記クラスマップをポリシーマップに割当て
class cmap-A
#詳細後述
police single-rate 1000 64 11 yellow-action drop red-action drop
exit
バーチャルバケツには64kbyte分のトークンが貯められ、一秒間に1000kbyteの通信時ごとにトークンは追加されていきます。64の次の数字11はトークンがない状態の時に追加で送信できる次のトークン分です。これによりバースト状態でもある程度送信は可能となります。
またイエローだのレッドだのとありますが、これはイエローがバケットにトークンがない状態の行動ですが、当然ドロップ（削除）。レッドは二つ目の11kbyteの閾値超えの操作ですがこちらも然り、ドロップです。
以上は、いつもの参考書からのアウトプットとなります。でもこの「1000kbyteの通信時ごと」だけの説明だと、トークンは常に1000kbpsでなくなるはずなんですよね。なので、帯域制御としては、トークンは「1000kbyteの通信時ごと」と「定期的に」、の二つの供給がないと説明がつかないんですよね。なんだか消化不良です。いや、違うか。「1000kbyteの通信時ごと」に64kbyteは送信可能、かつそれを超えてキューにある場合は破棄、いややっぱりトークンの供給は「定期的」にもないとキューの情報は破棄されっぱなしですね。よく分からん。
まとめ
というわけで、やや消化不良なQoSです。そもそも帯域制御と優先制御が一緒くたに説明されることが多いのでよくわかりません。ですが、なんとなく動きのまとめはつかめたと思います。
その上で、今度クライアントからのQoSのオーダーがあった場合は、「よく分からないのでやめましょう」とは言わずに、GUIで実行可能なZOOMのトラフィック最優先！のみを実施しようと思います。君子危うきに近寄らず。