5-5 Policing と Shaping — 超過を捨てるか待たせるか

1. 前節の振り返りと本節の内容

前節 5-4 Classification と Marking では、class-map の match で複数のクラスに分類し、policy-map の set でクラス別に DSCP を書き込む MQC の作り込みを Cat9000v の実機で扱いました。音声・映像・その他を 3 クラスに切り分け、set dscp でクラス別にマーキングした結果を、受信側 PC2 の tcpdump が示す ToS の分布で確かめました。

5-3 から 5-4 まで扱ってきたのは、パケットに 印をつける (marking) 段階でした。信頼するか付け直すか、どのクラスにどの DSCP を割り当てるか、という判断です。印そのものは、パケットの流れる速さには手を触れません。

本節はここから一歩進み、印をつけたトラフィックに帯域の契約を課す 段階を扱います。契約帯域を超えた分をどうするかには、大きく 2 通りあります。超過分を 捨てる (drop) のがポリシング (policing)、超過分をいったんバッファに溜めて 待たせて均す (buffer) のがシェーピング (shaping) です。両者は「同じレート契約に対して、溢れた分を捨てるか待たせるか」という行き先だけが異なります。本節では、この違いをトークンバケツ (token bucket) という 1 つのモデルで統一的に見たうえで、csr1000v の実機に police と shape を投入し、受信側 PC2 の実測レートと show カウンタの両方で検証します。1R2C・2R3C・three-color marker という 3 つの形も、すべて同じモデルの縮退と拡張として扱います。

2. トークンバケツモデル — police と shape に共通の土台

policing も shaping も、内部では同じ トークンバケツ という仕組みでレートを計量します。バケツにはトークンが cir (committed information rate) の速さで補充され続け、深さは bc (committed burst) で決まります。パケットが 1 つ来るたびに、そのサイズ分のトークンをバケツから取り出します。トークンが足りればそのパケットは契約内 (conform)、足りなければ契約超過 (exceed) と判定します。cir が平均の補充レート、bc がバケツの深さ = 瞬間的なバーストの許容量です。

このトークン残量による判定を、色で表すのが慣例です。トークンが足りた分を conform (緑)、committed バケツは空だが後述の peak バケツにトークンが残る分を exceed (橙)、どちらのバケツも空になった分を violate (赤) と呼びます。バケツが 1 個 (cir/bc) だけなら緑と橙の 2 色、後述の peak バケツ (pir/be) を足して 2 個にすると緑・橙・赤の 3 色になります。

policing と shaping の違いは、この色判定の 後 にあります。判定は同じトークンバケツで行い、溢れた分をどう扱うか = action だけが違います。ポリシングは溢れを捨て (drop)、シェーピングは溢れをバッファに溜めて後から送り (buffer)、後述の three-color marker は溢れを捨てずに DSCP を付け替えます。この関係を整理すると次のとおりです。

トークンバケツ (cir で補充・bc=深さ・be=peak バケツ)
   ↓  トークン残量で color 判定
conform(緑) / exceed(橙) / violate(赤)
   ↓  color 別 action
policing = 溢れを drop  /  shaping = 溢れを buffer で遅延  /  marker = drop せず DSCP を付け替え

この「トークンバケツ → color 判定 → action」のパイプラインを 1 枚に描くと、下図のようになります。同じバケツの上で、溢れの行き先だけが policing (捨てる) と shaping (待たせる) に分かれる様子を示します。

3. 検証ラボ — 入口で捨てる / 出口で待たせる

本節の検証は、5-4 の同一 VLAN のフラットな L2 構成と違い、R1 (csr1000v) を挟んだ L3 の 2 セグメント で組みます。送出端 PC1 が 192.168.10.0/24、受信端 PC2 が 192.168.20.0/24 にいて、R1 が両者をルーティングします。レート契約は R1 のインタフェースに当てます。ポリシングは入口の Gi2 (service-policy input)、シェーピングは出口の Gi3 (service-policy output) に当てるため、トポロジの配置そのものが「入口で捨てる / 出口で待たせる」と物理的に一致します。

ポリシングは入口・出口のどちらの向きにも当てられますが、シェーピングは出力キューにパケットを溜めて遅延させる仕組みなので、出口 (output) 方向にしか当てられません。本節ではポリシングを入口 Gi2 に、シェーピングを出口 Gi3 に配置します。

送出のトラフィックは UDP で作ります。ポリシングの効き目は「送ったレートに対してどれだけ落ちたか」で測るため、送出レートを -b で固定できる UDP が適します。TCP は輻輳制御が自律で送出を絞るため、「policing が頭打ちにした」のか「TCP が自分で絞った」のかを区別できません。PC2 で iperf -s -u を待ち受け、PC1 から iperf -c 192.168.20.20 -u -b 1200k -t 8 を送ります。

まず使用した機器と IOS-XE を確認します。

R1# show version | include Cisco IOS-XE Software|CSR|Version
Cisco IOS XE Software, Version 17.03.08a
Cisco IOS Software [Amsterdam], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.3.8a, RELEASE SOFTWARE (fc3)

機種は csr1000v (仮想の CSR 1000V ルータ)、ソフトウェアは IOS-XE 17.03.08a です。この csr1000v はデモ用にスループットの上限が設けられており、その天井を先に確認します。

R1# show platform hardware throughput level
The current throughput level is 1000 kb/s

スループット天井は 1000 kb/s (1 Mbps) です。この天井があるため、レート契約 (cir) はこれより十分に低い 500 kbps に置きます。天井と cir が近いと、頭打ちが「policing が効いた」のか「デモ天井に当たった」のか切り分けられなくなるためです。

契約を何も課さない状態で、PC1 から 1.2 Mbps の UDP を送ったときの PC2 の受信レートが baseline です。ポリシング適用後との差分を取るための基準になります。

[  1] 0.00-8.89 sec  1.15 MBytes  1.08 Mbits/sec   1.069 ms 0/820 (0%)

契約が無いため、送出 1.2 Mbps はスループット天井 (1 Mbps) 付近の 1.08 Mbps まで素通りし、パケットロスは 0/820 = 0% です。この「素通りの 1.08 Mbps・loss 0%」を基準に、以降のレート契約が受信レートをどう変えるかを見ます。

4. 1R2C ポリシング — cir で頭打ちにして超過を捨てる

ここからが本節の核です。まず最も基本的な 1R2C (single-rate two-color) のポリシングを組みます。バケツを 1 個 (cir/bc) 使い、契約内 (conform) は transmit、超過 (exceed) は drop する 2 色のポリシングです。R1 の入口 Gi2 に当てます。

policy-map PM-POLICE-1R2C
 class class-default
  police cir 500000 conform-action transmit exceed-action drop
!
interface GigabitEthernet2
 service-policy input PM-POLICE-1R2C

police cir 500000 が「トークンを毎秒 500000 bit 分補充する」契約です。conform-action transmit は契約内のパケットを転送し、exceed-action drop は超過分を捨てます。この状態で baseline と同じ 1.2 Mbps を送り、PC2 の受信レートを撮ります。

[  1] 0.00-8.04 sec   491 KBytes   500 Kbits/sec   0.070 ms 479/821 (58%)

受信レートは、baseline の 1.08 Mbps から 500 Kbits/sec へ頭打ち になりました。ポリシングを外せば 1.08 Mbps に戻り、当てれば 500 Kbps に落ちる、というポリシング有無の差分が、cir で頭打ちにする効果の証拠です。同時にパケットロスが 479/821 = 58% に達しています。送った 1.2 Mbps のうち cir (500 kbps) を超えた分がすべて drop されたためです。ジッタは 0.070 ms で、baseline (1.069 ms) と比べても遅延の増加はほとんどありません。ポリシングは超過分を溜めずにその場で捨てるため、通過したパケットには遅延が乗らないのが特徴です。

インタフェースのカウンタも見ておきます。

R1# show policy-map interface GigabitEthernet2
 GigabitEthernet2

  Service-policy input: PM-POLICE-1R2C

    Class-map: class-default (match-any)
      758 packets, 1144626 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
      police:
          cir 500000 bps, bc 15625 bytes
        conformed 317 packets, 477834 bytes; actions:
          transmit
        exceeded 441 packets, 666792 bytes; actions:
          drop
        conformed 0000 bps, exceeded 0000 bps

cir 500000 bps, bc 15625 bytes の行が、契約レートとバケツ深さです。bc は明示しなかったため IOS-XE が cir から既定値を計算しており、15625 バイト = cir を 8 で割った毎秒バイト数の 0.25 秒分に相当します。その下の conformed 317 packets が契約内で transmit された分、exceeded 441 packets が超過して drop された分です。317 と 441 を足すと 758 で、offered の 758 packets と一致します。契約内より超過のほうが多く、契約帯域が送出の半分以下であることをカウンタも裏づけています。

5-4 の Cat9000v ではマーキングのカウンタが増えませんでしたが、この csr1000v ではポリシングの conform/exceed カウンタが動きます。とはいえ効き目の正本は、あくまで 受信側 PC2 の実測レート に置きます。仮想機のカウンタが常に信頼できるとは限らないためです。

バケツ深さの bc は、明示して調整することもできます。

policy-map PM-POLICE-BC
 class class-default
  police cir 500000 bc 15000 conform-action transmit exceed-action drop

bc 15000 はトークンバケツの深さを 15000 バイトに指定するものです。cir が平均レート、bc が瞬間的なバーストの許容量で、bc を大きくすると短時間のバーストをより多く通します。省略時は上の show で見たとおり IOS-XE が cir から既定 bc を自動計算します。

5. Shaping — 超過を捨てずにバッファで待たせる

次にシェーピングを組み、ポリシングとの違いを見ます。同じ超過分を、捨てずにバッファへ溜めて後から送る のがシェーピングです。R1 の出口 Gi3 に当てます。

policy-map PM-SHAPE
 class class-default
  shape average 400000
!
interface GigabitEthernet3
 service-policy output PM-SHAPE

shape average 400000 が「出力を平均 400 kbps に均す」契約です。超過分は drop せず、R1 の出力キューにいったん溜めて後で送出します。この状態で PC1 から同じ 1.2 Mbps を送り、PC2 の受信レートを撮ります。

[  1] 0.00-9.96 sec   478 KBytes   393 Kbits/sec   7.058 ms 488/821 (59%)

受信レートは 393 Kbits/sec で、target の 400 kbps 付近に均されています。ここで注目すべきは ジッタ (遅延のばらつき) が 7.058 ms で、ポリシング時の 0.070 ms の約 100 倍に増えている点です。シェーピングは超過分をキューに溜めて後から送るため、通過するパケットにはキューでの待ち時間 = 遅延が乗ります。ポリシング (loss 大・遅延ほぼ無し) とシェーピング (遅延増) の対比が、この 2 つの実測に表れています。

一方で、パケットロスは 488/821 = 59% で、ポリシングの 58% とほとんど変わりません。「シェーピングは捨てないから無損失」というのは誤解で、実機ではこれだけの loss が出ました。理由は、次の show でわかるバッファの有限性にあります。

R1# show policy-map interface GigabitEthernet3
 GigabitEthernet3

  Service-policy output: PM-SHAPE

    Class-map: class-default (match-any)
      1018 packets, 1528500 bytes
      5 minute offered rate 13000 bps, drop rate 6000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/613/0
      (pkts output/bytes output) 405/601644
      shape (average) cir 400000, bc 1600, be 1600
      target shape rate 400000

queue limit 64 packets が、このシェーピングが使えるバッファの上限です。Queueing の行があるとおり、シェーピングはポリシングと違ってキューイングを伴います。(queue depth/total drops/no-buffer drops) 0/613/0 の真ん中、total drops が 613 で、613 パケットがキューに入りきらずに落ちています。送出 1.2 Mbps を 400 kbps に均そうとすると超過が持続的に発生し、64 パケットの有限キューがすぐに埋まって溢れるためです。shape (average) cir 400000 が target のレート、target shape rate 400000 が実際に均している目標値です。

シェーピングは超過分を バッファが空いている間は 待たせて均しますが、送出が持続的に契約を超え続けるとバッファが溢れ、そこからは drop します。したがって「捨てるか待たせるか」は絶対的な二分ではなく、待たせるバッファには限りがある ことを押さえておく必要があります。ポリシングは即座に捨てるので遅延が乗らず loss が大きい、シェーピングはバッファで均すので遅延は乗るがバッファが尽きるまでは loss を抑える、という性格の違いとして理解します。

6. 2R3C — cir と pir の 2 レートで 3 色に分ける

1R2C はバケツ 1 個で緑・橙の 2 色でした。ここに peak 用のバケツ (pir/be) をもう 1 個足すと、2R3C (two-rate three-color) = 2 レート・3 色になります。cir 内を conform (緑)、cir を超えて pir 内を exceed (橙)、pir も超えた分を violate (赤) の 3 段階に分けます。橙と赤で別々の action を書けるのが 1R2C との違いです。

policy-map PM-POLICE-2R3C
 class class-default
  police cir 500000 pir 750000
   conform-action transmit
   exceed-action set-dscp-transmit af11
   violate-action drop
!
interface GigabitEthernet2
 service-policy input PM-POLICE-2R3C

police cir 500000 pir 750000 で 2 つのレートを指定します。conform-action transmit は cir 内をそのまま転送、exceed-action set-dscp-transmit af11 は cir を超えて pir 内の分を AF11 に降格して転送、violate-action drop は pir も超えた分を捨てます。2 バケツ (two-token-bucket) 動作になるのは、pir を指定して cir と pir の 2 レートを与えたためです。violate-action は pir 超過分の扱いを決める action であって、これ自体が 2 バケツ化の主因ではありません。橙の分を捨てずに AF11 へ降格させて流すことで、混雑したときに下流で優先的に落とす候補として印をつけておく、という設計です。

この 2R3C に、cir・pir の両方を超える 1.5 Mbps を送ってカウンタを撮ります。

R1# show policy-map interface GigabitEthernet2
 GigabitEthernet2

  Service-policy input: PM-POLICE-2R3C

    Class-map: class-default (match-any)
      1032 packets, 1553064 bytes
      5 minute offered rate 5000 bps, drop rate 2000 bps
      Match: any
      police:
          cir 500000 bps, bc 15625 bytes
          pir 750000 bps, be 23437 bytes
        conformed 348 packets, 518856 bytes; actions:
          transmit
        exceeded 171 packets, 258552 bytes; actions:
          set-dscp-transmit af11
        violated 513 packets, 775656 bytes; actions:
          drop
        conformed 2000 bps, exceeded 1000 bps, violated 2000 bps

cir 500000 bps, bc 15625 bytes の下に pir 750000 bps, be 23437 bytes が加わり、バケツが 2 個になっています。カウンタは 3 色すべてが実機で見えました。conformed 348 packets が緑 (transmit)、exceeded 171 packets が橙 (AF11 へ降格して transmit)、violated 513 packets が赤 (drop) です。348・171・513 を足すと 1032 で、offered の 1032 packets と一致します。cir/pir の両方を超える 1.5 Mbps を送ったため、pir を超えた violate (赤・513 パケット) が最も多くなっています。受信側でも、送出 1.5 Mbps に対して loss は 513/1025 = 50% でした。

三色のうち橙の set-dscp-transmit af11 は、5-4 の set dscp と表面上は似ていますが意味が異なります。5-4 の set dscp は トラフィックの内容 (どのクラスか) による無条件のマーキング でした。ここでの set-dscp-transmit af11 は レート計量の結果 (cir を超えたという条件) に応じた条件付きの降格 です。同じ DSCP を書く操作でも、「レート契約に紐づくか否か」で位置づけが違います。

7. Three-color marker — 捨てずに全色を付け替える

2R3C では violate を drop していました。この drop を すべて set-dscp-transmit に置き換える と、three-color marker (三色マーカー) になります。緑・橙・赤のいずれも捨てず、色ごとに別の DSCP を付けて流すモードです。

policy-map PM-3COLOR-MARK
 class class-default
  police cir 500000 pir 750000
   conform-action set-dscp-transmit af11
   exceed-action set-dscp-transmit af12
   violate-action set-dscp-transmit af13

conform を AF11、exceed を AF12、violate を AF13 に付け分けます。AF11・AF12・AF13 は、いずれも同じ AF1 クラスの中で drop precedence (廃棄の優先度) だけが違う DSCP です。RFC 2597 の Assured Forwarding は、同じ AF クラス内で AF13 (高 drop precedence) が AF11 (低 drop precedence) より捨てられにくくならないこと、つまり AF13 のほうが先に落とされる関係を定義します。実際にどの閾値でどれだけ落とすかは、下流の輻輳回避 (WRED など) の実装と設定しだいです。three-color marker は境界では何も捨てず、「どの色をどれだけ先に落とすかは下流に委ねる」ための色付け器です。定義を show で確認します。

R1# show run policy-map PM-3COLOR-MARK
Building configuration...

Current configuration : 210 bytes
!
policy-map PM-3COLOR-MARK
 class class-default
  police cir 500000 pir 750000
   conform-action set-dscp-transmit af11
   exceed-action set-dscp-transmit af12
   violate-action set-dscp-transmit af13
!
end

3 つの action がすべて set-dscp-transmit で、どこにも drop がありません。同じトークンバケツの色判定 (cir/pir) の上で、action を「捨てる」から「印を替えて流す」に差し替えただけの姿です。DSCP と ToS バイトの対応は、AF11 が 0x28、AF12 が 0x30、AF13 が 0x38 です。ToS バイトは上位 6 bit が DSCP、下位 2 bit が ECN なので、ECN が 0 のときは DSCP 値を 4 倍 (2 bit 左シフト) したものが ToS バイトになります。境界のルータで色を付け、実際にどれを落とすかは混雑した下流のキューに任せる、という役割分担になります。

8. 落とし穴・補足

ポリシングとシェーピングは、トークンバケツという共通の土台の上で action だけが違う機構ですが、仮想機の天井やバッファの有限性を取り違えると、効いていないのに効いたつもりになったり、その逆になったりします。本節の実機に関わる注意点をまとめます。

デモ天井と cir の関係。 この csr1000v はスループット天井が 1000 kb/s に絞られており (§3)、cir をこの天井に近い値に置くと、頭打ちが「policing が効いた」のか「天井に当たった」のか切り分けられません。本節は cir を天井の十分下 (500 kbps) に置き、契約を外した baseline (天井付近の 1.08 Mbps・loss 0%) と、契約を当てた状態 (500 kbps・loss 58%) の差分で効果を判定しました。物理機やライセンスで天井を上げた機器では、この配慮は不要です。

シェーピングの「無損失」は有限キューまで。 シェーピングは超過分をバッファで待たせて均しますが、バッファ (本節では queue limit 64 packets) には上限があります (§5)。送出が持続的に契約を超え続けると有限キューが溢れ、そこからは drop します。実機でも total drops が 613 出ました。「シェーピング = 捨てない」は、バッファが溢れない範囲でのみ正しい理解です。バースト的な超過はバッファで吸収できますが、平均そのものが契約を超え続けると、シェーピングでも落ちます。

ポリシングは入口・出口、シェーピングは出口のみ。 ポリシングは service-policy input でも output でも当てられますが、シェーピングは出力キューを使う仕組みなので output 方向にしか当てられません (§3)。同じ向きの同じインタフェースに service-policy は 1 つだけなので、別のポリシーを当て直すときは no service-policy で先に剥がしてから当てます。

UDP で計量する。 ポリシングの drop を実測するときは UDP で送ります (§3)。TCP は輻輳制御が自律で送出を絞るため、「policing が頭打ちにした」のか「TCP が自分で絞った」のかを区別できません。送出レートを -b で固定できる UDP なら、契約に対してどれだけ落ちたかを素直に測れます。

仮想機のカウンタは正本にしない。 この csr1000v ではポリシングの conform/exceed カウンタが動きましたが (§4)、仮想機は QoS のデータプレーンを完全にはエミュレートしないことがあります。5-4 の Cat9000v ではマーキングカウンタが 0 のままでした。効き目の正本は受信側 PC2 の実測レートに置き、show のカウンタは補助として扱うのが安全です。

最後に、本節で組んだ QoS 定義を running-config から抜き出すと次のようになります。1R2C・2R3C のポリシングとシェーピングの policy-map が、記事で見てきた形でまとまっています。

R1# show running-config | section policy-map PM-|class-map
policy-map PM-POLICE-2R3C
 class class-default
  police cir 500000 pir 750000
   conform-action transmit
   exceed-action set-dscp-transmit af11
   violate-action drop
policy-map PM-SHAPE
 class class-default
  shape average 400000
policy-map PM-POLICE-1R2C
 class class-default
  police cir 500000 conform-action transmit  exceed-action drop

9. 次節

本節では、レート契約を課す 2 つの機構を csr1000v の実機で組み立てました。police も shape も同じトークンバケツ (cir で補充・bc で深さ) の上に立ち、違いは溢れの action だけ = ポリシングは超過を drop (受信 500 kbps へ頭打ち・loss 58%・遅延ほぼ無し)、シェーピングは超過を buffer で平準化 (受信 393 kbps・遅延 7 ms) であることを、受信側 PC2 の実測レートと show カウンタで確かめました。1R2C から peak バケツを足した 2R3C で 3 色 (conform/exceed/violate) を実機で観察し、violate を drop から set-dscp-transmit へ差し替えた three-color marker で、境界では捨てずに AF11/AF12/AF13 へ色を付け分ける形も扱いました。

ここで一つ、本節では踏み込まなかった論点が残っています。シェーピングはパケットをキューに溜めて待たせましたが、その キューをどう並べ、どの順で送り出すか は「均す」だけでは決まりません。音声を先に、バルク転送を後に、といった優先度をつけて送出する仕組みが必要です。次節 5-6 Queuing では、キューイングの機構 (PQ・CWFQ・CBWFQ・LLQ) を実機で組み、混雑時にどのトラフィックを優先して送り出すかを見ていきましょう。