ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

5-9 LAN QoS / WAN QoS 設計 — 8 クラスモデルと帯域配分のトレードオフ

Cat9000v の Auto-QoS と csr1000v の 8 クラス設計を組む。shape 500 kbps に LLQ priority 10% では EF が 79% 損失し、45% では AF41 が 37% 落ちる配分を実測する第 5 章 QoS 編の統合設計節。

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

前節 5-8 輻輳回避 (Congestion Avoidance) では、キューが溢れる前にパケットを捨てる破棄判定を扱いました。既定の Tail Drop がキュー満杯後に無差別に捨てるのに対し、random-detect による WRED は平均キュー長に応じて確率的に早期破棄します。実測では Tail Drop の total drops 248 に対し、送出条件を揃えた WRED 構成が Random drop 117 と Tail drop 90 を計上しました。

5-4 Classification と Marking から 5-8 までの 5 節は、いずれも 1 つの機構を単体で取り出し、その挙動を実機で確かめるものでした。分類とマーキング、policing と shaping、キューイング、階層 QoS、輻輳回避と、部品は一通り揃っています。実際のネットワークで必要になるのは、この部品をどこに配置し、どういう順番で効かせるかという設計です。

本節は第 5 章で初めての統合設計節にあたります。扱うのは新しい機構ではなく、既に見た機構を LAN 側と WAN 側に配置して 1 つの設計にまとめる手順と、その設計判断が実機の設定としてどう表現されるかです。実機検証の軸足も「新しい機構が動くことの証明」ではなく、設計判断が実機でどう表現され、どこで拒否されるかの観察に置きます。

具体的には、LAN 側で Catalyst 9000v の Auto-QoS が生成するテンプレートを読み、WAN 側で csr1000v に 8 クラスモデルと契約帯域への sub-rate shaping を組みます。そのうえで、帯域配分を間違えた設計が実機でどう壊れるかを実測します。

end-to-end で VoIP を EF にマーキングして LLQ で守る通しのハンズオンは、次節 5-10 の主題であり本節では扱いません。 本節の LAN セグメントと WAN セグメントは同じ CML ラボに置きますが、相互に接続せず、それぞれ独立に観察します。

2. QoS 設計は 4 つの決定でできている

QoS 設計は、機構を並べる作業ではなく、4 つの決定を順に埋める作業です。どれか 1 つを決め忘れると、他の 3 つがどれだけ精密でも結果は崩れます。

1 つ目は どこまで信じるか です。端末が付けてきた DSCP は自己申告で、正しいという保証はありません。アクセス端で「どの機器の印なら信じるか」を決めるのが信頼境界の設計です。ここを決めないと、端末が自分で付けた優先度がそのまま網の奥まで通ります。

2 つ目は 何をどの印にするか です。信じない印は付け直します。業務上の重要度を DSCP という共通語に翻訳する作業で、ここで決めた対応表が下流すべての前提になります。決めないまま流せば、下流の機器は何が重要かを区別できません。

3 つ目は どの速度に絞るか です。WAN 側で絞る速度は、インタフェースの物理速度ではなく事業者との契約速度です。物理速度のまま送ると、契約を超えた分は事業者側の設備で捨てられ、どのクラスが失われるかを自網で制御できません。

4 つ目は 絞った中をどう分けるか です。絞った帯域をいくつのクラスに分け、それぞれに何割を割り当てるかを決めます。クラスを増やすほど設計と運用の手間が増え、減らすほど区別が粗くなります。

この図を大きく開く ↗

QoS 設計を構成する 4 つの決定と、その連鎖。左から順に、①アクセス端で「どの端末の印を信じるか」を決める信頼境界、②信じない印を業務上の重要度に対応する DSCP へ付け直すマーキング、③WAN 側の出口で物理速度ではなく契約速度に絞る sub-rate shaping、④絞った帯域を何クラスに分け何割ずつ割り当てるかを決めるクラス設計、と続く。各段の下の吹き出しには「設計者が決めること」と「決めないと何が起きるか」を対にして置いてある。①と②が LAN 側 (本節 §4・§5)、③と④が WAN 側 (本節 §7・§8) の担当で、この 4 つが 1 本に繋がって初めて 1 つの設計になる。

この 4 つのうち、①と②は LAN 側のアクセススイッチ、③と④は WAN 側のルータが担当します。本節はこの担当分けの順に、LAN 側から WAN 側へ進みます。

3. 検証ラボの構成

本節の検証ラボは、1 つの CML ラボの中に 2 つのセグメントを置き、相互に接続しない構成にしています。LAN セグメントは Catalyst 9000v (cat9000v-uadp) のアクセスポート Gi1/0/1 を観測点にして、信頼境界とマーキングを決める側を見ます。WAN セグメントは csr1000v の出口 Gi3 を観測点にして、契約帯域に絞った中をクラスへ落とす側を見ます。

この図を大きく開く ↗

検証ラボの 2 セグメント構成。上段の LAN セグメントは PC1 と SW1 (cat9000v-uadp) で、観測点はアクセスポート Gi1/0/1、見るのは端末が付けてきた印をどう扱うか (信頼境界とマーキング) の側。下段の WAN セグメントは PC2 — R1 (csr1000v) — PC3 で、観測点は出口 Gi3、見るのは親 shape で契約帯域に絞ってから 8 クラスへ落とす側。2 つのセグメントは物理的にも論理的にも接続していない。end-to-end で通して守る話は次節 5-10 の主題であり、本節は LAN 側と WAN 側で設計者が何を決めるかを独立に観察することに絞るため。両機とも管理は Mgmt-vrf 経由で、SW1 が 172.16.1.211、R1 が 172.16.1.221。

2 つを接続しない理由は 2 つあります。1 つ目は主題の切り分けで、LAN 側から WAN 側まで通して優先制御を実証するのは次節 5-10 の主題にあたるため、本節では意図的に行いません。2 つ目は障害切り分けの単純化で、起動の重い Catalyst 9000v と csr1000v を独立に扱えるようにするためです。

使用した機器と IOS-XE を確認します。LAN 側の SW1 は次のとおりです。

snippet 
SW1# show version | include Cisco IOS-XE Software|C9KV|Version
Cisco IOS XE Software, Version 17.15.03
Cisco IOS Software [IOSXE], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.15.3, RELEASE SOFTWARE (fc1)
(GPL ライセンス表記の 3 行を省略)
cisco C9KV-UADP-8P (VXE) processor (revision VXE) with 743842K/3075K bytes of memory.
Switch Ports Model              SW Version        SW Image              Mode   
*    1 24    C9KV-UADP-8P       17.15.03          CAT9K_IOSXE           INSTALL

WAN 側の R1 は、5-6 から 5-8 で使ったものと同じ csr1000v です。

snippet 
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)
(GPL ライセンス表記の 3 行を省略)
cisco CSR1000V (VXE) processor (revision VXE) with 1104920K/3075K bytes of memory.

この csr1000v はデモ用にスループットの上限が絞られており、本節で契約帯域に見立てる 500 kbps は、この天井の内側に置いた値です。

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

送出側の PC2 に入っている測定ツールは classic 系の iperf 2.2.0 だけで、iperf3 は存在しません。5-8 と同じ状況で、本節の送出もすべて iperf 2.2.0 で行っています。

snippet 
PC2 $ iperf --version
iperf version 2.2.0 (10 April 2024) pthreads
PC2 $ iperf3 --version
-sh: iperf3: not found

PC2 から PC3 まで、R1 のルーティングを経由して到達できることも確認しておきます。

snippet 
PC2 $ ping -c 3 -W 2 192.168.30.20
PING 192.168.30.20 (192.168.30.20): 56 data bytes
64 bytes from 192.168.30.20: seq=0 ttl=42 time=1.272 ms
64 bytes from 192.168.30.20: seq=1 ttl=42 time=1.093 ms
64 bytes from 192.168.30.20: seq=2 ttl=42 time=1.102 ms

--- 192.168.30.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.093/1.155/1.272 ms

4. LAN 側 (1) — 信頼境界をどこに置くか

5-3 Trust Boundary では、印を信じる・信じないを切り替える機構そのものを扱いました。本節で扱うのは機構の復習ではなく、その境界をネットワークのどこに置くかという配置の判断です。

信頼境界を端末に最も近いアクセスポートに置くと、境界の内側に入った時点で印が確定します。網の奥にある機器は印を信頼して処理でき、設計がそこで閉じます。代わりに、印を判定して付け直す設定をアクセスポートの数だけ用意する必要があります。境界を配布層や WAN 側の入口まで下げると、設定する箇所は減りますが、信じてよい印と端末の自己申告が混ざったまま網の中を流れる区間が生まれます。信頼境界の設計とは、この「設定する箇所の数」と「印が確定していない区間の長さ」の取引です。

Catalyst 9000v では、この判断がインタフェース設定の 1 行として表れます。インタフェース config モードでの auto qos のヘルプが、その選択肢を示しています。

snippet 
SW1(config-if)# auto qos ?
  classify  Configure classification for untrusted devices
  trust     Trust the DSCP/CoS marking
  video     Configure AutoQoS for video devices
  voip      Configure AutoQoS for VoIP

classify は信頼しない機器のために分類を設定する側、trust は付いてきた印を信じる側です。信頼境界の 2 つの答えが、そのまま 2 つのキーワードに対応しています。trust を選んだ場合は、どの層の印を信じるかをさらに選びます。

snippet 
SW1(config-if)# auto qos trust ?
  cos   Trust the CoS marking
  dscp  Trust the DSCP marking
  <cr>  <cr>

cos はイーサネットフレームの L2 の印、dscp は IP ヘッダの L3 の印です。本検証では、L3 を跨いで WAN 側まで一貫して残る dscp を選びます。

5. LAN 側 (2) — Auto-QoS が生成するテンプレートを読む

Auto-QoS は、1 行のコマンドから QoS 設定一式を自動生成する機能です。生成物は完成品ではなく、ベンダが推奨する構成の手本として読むのが本節の立場です。自分でクラス設計を書き起こす前に、ベンダがどの印をどのキューに入れ、どういう配分を既定にしているかを読み取ります。

アクセスポート Gi1/0/1 に投入したのは次の 1 行だけです。

snippet 
SW1(config)# interface GigabitEthernet1/0/1
SW1(config-if)#  auto qos trust dscp

この 1 行の前後で show running-config を取得し、差分を取ったものが Auto-QoS の生成物です。まず table-map が 1 本と、出力キュー用の class-map が 7 本生成されます。

snippet 
--- running-config (auto qos 適用前)
+++ running-config (auto qos 適用後)
(既存の system-cpp-* class-map など、変化していない行は省略)
+table-map AutoQos-4.0-Trust-Dscp-Table
+ default copy
+class-map match-any AutoQos-4.0-Output-Multimedia-Conf-Queue
+ match dscp af41  af42  af43 
+ match cos  4 
+class-map match-any AutoQos-4.0-Output-Bulk-Data-Queue
+ match dscp af11  af12  af13 
+ match cos  1 
+class-map match-any AutoQos-4.0-Output-Priority-Queue
+ match dscp cs4  cs5  ef 
+ match cos  5 
+class-map match-any AutoQos-4.0-Output-Multimedia-Strm-Queue
+ match dscp af31  af32  af33 
+class-map match-any AutoQos-4.0-Output-Trans-Data-Queue
+ match dscp af21  af22  af23 
+ match cos  2 
+class-map match-any AutoQos-4.0-Output-Scavenger-Queue
+ match dscp cs1 
+class-map match-any AutoQos-4.0-Output-Control-Mgmt-Queue
+ match dscp cs2  cs3  cs6  cs7 
+ match cos  3

生成された 7 本の class-map は、印とキューの対応表そのものです。

生成された class-mapmatch dscpmatch cos
AutoQos-4.0-Output-Priority-Queuecs4 cs5 ef5
AutoQos-4.0-Output-Control-Mgmt-Queuecs2 cs3 cs6 cs73
AutoQos-4.0-Output-Multimedia-Conf-Queueaf41 af42 af434
AutoQos-4.0-Output-Multimedia-Strm-Queueaf31 af32 af33—
AutoQos-4.0-Output-Trans-Data-Queueaf21 af22 af232
AutoQos-4.0-Output-Bulk-Data-Queueaf11 af12 af131
AutoQos-4.0-Output-Scavenger-Queuecs1—

ほとんどの class-map が match dscp と match cos の両方を持ちます。L3 の印が付いていないフレームでも L2 の印で同じキューへ入れられる構成です。match-any なので、どちらか一方が一致すれば該当します。

続いて、この class-map を使う出力ポリシーと、入力ポリシーが生成されます。

snippet 
(既存の policy-map system-cpp-policy の行は省略)
+policy-map AutoQos-4.0-Output-Policy
+ class AutoQos-4.0-Output-Priority-Queue
+  priority level 1 percent 30
+ class AutoQos-4.0-Output-Control-Mgmt-Queue
+  bandwidth remaining percent 10 
+  queue-limit dscp cs2 percent 80
+  queue-limit dscp cs3 percent 90
+  queue-limit dscp cs6 percent 100
+  queue-limit dscp cs7 percent 100
+  queue-buffers ratio 10
+ class AutoQos-4.0-Output-Multimedia-Conf-Queue
+  bandwidth remaining percent 10 
+  queue-buffers ratio 10
+ class AutoQos-4.0-Output-Trans-Data-Queue
+  bandwidth remaining percent 10 
+  queue-buffers ratio 10
+ class AutoQos-4.0-Output-Bulk-Data-Queue
+  bandwidth remaining percent 4 
+  queue-buffers ratio 10
+ class AutoQos-4.0-Output-Scavenger-Queue
+  bandwidth remaining percent 1 
+  queue-buffers ratio 10
+ class AutoQos-4.0-Output-Multimedia-Strm-Queue
+  bandwidth remaining percent 10 
+  queue-buffers ratio 10
+ class class-default
+  bandwidth remaining percent 25 
+  queue-buffers ratio 25
+policy-map AutoQos-4.0-Trust-Dscp-Input-Policy
+ class class-default
+  set dscp dscp table AutoQos-4.0-Trust-Dscp-Table

入力ポリシーは 3 行しかありません。set dscp dscp table AutoQos-4.0-Trust-Dscp-Table は、到着したパケットの DSCP を table-map 経由で書き換える指定です。参照される table-map は default copy の 1 行だけです。

snippet 
SW1# show table-map
 Table Map AutoQos-4.0-Trust-Dscp-Table
 default copy

default copy は、対応表に明示的な行が無い値をそのまま写すという意味です。変換表を持たない変換、つまり「入ってきた DSCP をそのまま採用する」という信頼の宣言が、この table-map の中身です。§4 で選んだ「L3 の印を信じる」という設計判断が、実機では table-map という形で表現されています。

生成物はインタフェースにも自動で適用されます。1 行だけ書いたはずのインタフェース設定には、入力と出力の 2 本の service-policy が増えています。

snippet 
SW1# show running-config interface GigabitEthernet1/0/1
Building configuration...

Current configuration : 258 bytes
!
interface GigabitEthernet1/0/1
 description PC1 (LAN edge = Auto-QoS / trust boundary apply point)
 switchport mode access
 auto qos trust dscp
 service-policy input AutoQos-4.0-Trust-Dscp-Input-Policy
 service-policy output AutoQos-4.0-Output-Policy
end

ここで生成物の構造そのものに注目します。優先キューが 1 本、名前付きの非優先キューが 6 本、そして class-default で、合計 8 つのキューになっています。ベンダが 1 行のコマンドから展開する既定のテンプレートも、後述する 8 クラスモデルと同じクラス数を採っているということです。ただし中身は別物で、Auto-QoS 側は CS3 と CS6 を 1 つのクラス (Control-Mgmt) にまとめ、§6 の 8 クラスモデルには無い Bulk-Data (AF1x) のキューを持ちます。

適用状態は show policy-map interface で確認できます。パーセント指定が実値に解決されている点が読み取れます。

snippet 
SW1# show policy-map interface GigabitEthernet1/0/1
 GigabitEthernet1/0/1 

  Service-policy input: AutoQos-4.0-Trust-Dscp-Input-Policy

    Class-map: class-default (match-any)  
      0 packets
      Match: any 
      QoS Set
         dscp dscp table AutoQos-4.0-Trust-Dscp-Table

  Service-policy output: AutoQos-4.0-Output-Policy

    queue stats for all priority classes:
      Queueing
      priority level 1
      
      (total drops) 0
      (bytes output) 0

    Class-map: AutoQos-4.0-Output-Priority-Queue (match-any)  
      0 packets
      Match:  dscp cs4 (32) cs5 (40) ef (46)
      Match: cos  5 
      Priority: 30% (300000 kbps), burst bytes 7500000, 
      
      Priority Level: 1 
(以降の 7 クラスの表示を省略)

priority level 1 percent 30 が、1 Gbps のポートに対する 300000 kbps として解決されています。

この出力で本節が主張できるのは、ここまでです。 すべてのクラスの packets が 0 と表示されていますが、これは 本節が LAN セグメントにトラフィックを一切流していないためです。§3 で述べたとおり LAN 側の観測点は設定の生成物であり、送出は行っていません。したがってこの 0 は仮想機の制約を示すものではなく、LAN 側のデータプレーンの挙動は本節の証拠範囲の外です。

なお、5-3 Trust Boundary と 5-4 Classification と Marking では、同じ仮想 Catalyst 9000v で match の分類カウンタは実際に増えることを確認しています (5-3 で 200 packets、5-4 で 3 クラス合計 400 packets 超)。一方で QoS Set (マーキング) の行にはパケット数が付かないという制約も、その 2 節で観測されています。分類が数えられることと、マーキングが数えられることは別です。

本節の LAN 側の証拠は設定面に限られ、「カウンタが増えたから効いている」という主張は行いません。

6. クラス設計 — 12 クラスの標準と 4 / 8 / 12 クラスの実装

クラス設計の出発点は RFC 4594 (Configuration Guidelines for DiffServ Service Classes) です。RFC 4594 は 12 の service class を定義し、それぞれに推奨する DSCP を与えています。これは何をどう扱うべきかの共通語彙であって、機器に 12 個のキューを作れという要求ではありません。

#サービスクラス (RFC 4594)RFC 4594 の DSCPCisco の実装での DSCP
1Network ControlCS6CS6
2Telephony (音声)EFEF
3Signaling (呼制御)CS5CS3
4Multimedia ConferencingAF41 / AF42 / AF43AF41
5Real-Time InteractiveCS4CS4
6Multimedia StreamingAF31 / AF32 / AF33AF31
7Broadcast VideoCS3CS5
8Low-Latency Data (Transactional Data)AF21 / AF22 / AF23AF21
9OAM (運用管理)CS2CS2
10High-Throughput Data (Bulk Data)AF11 / AF12 / AF13AF11
11Standard (Best Effort)DF (0)DF
12Low-Priority Data (Scavenger)CS1CS1

Cisco の設計指針は RFC 4594 に変更を加えており、Signaling と Broadcast Video の DSCP を入れ替えています。 RFC 4594 が Signaling に CS5、Broadcast Video に CS3 を割り当てているのに対し、Cisco は Signaling を CS3、Broadcast Video を CS5 としています。標準と実装ガイドで同じクラス名が別の DSCP を指すため、他社機器や事業者網と印を突き合わせるときは、どちらの割り当てを前提にしているかを先に確認します。

実装側は、この 12 クラスをそのまま実装するのではなく、キュー数と運用の都合で縮約します。Cisco の QoS 設計ガイドは 4 クラス・8 クラス・12 クラスという階段を示しており、拠点の規模や機器のキュー数に応じて段を選びます。4 クラスは音声・呼制御・重要データ・ベストエフォート程度の最小構成、12 クラスは RFC 4594 の 12 service class に一対一で対応する最も細かい構成です。8 クラスはその中位に位置し、映像を対話系と配信系に分けられる程度の解像度を保ちながら、大半の機器のキュー数に収まる実務解として使われます。

この図を大きく開く ↗

12 クラスの標準語彙から 8 クラスへの縮約。左列が RFC 4594 の 12 service class (marking は Cisco 版を採っており、Signaling が CS3、Broadcast Video が CS5)、右列が Cisco の設計指針が示す 8 クラスモデルで、各クラスの帯域配分も添えてある。音声 (EF 10%) と対話系映像 (AF41 23%) の 2 つが優先キューに置かれる二段構成である点に注意。橙の太い線は「束ねられる」経路の一例で、OAM (CS2) をネットワーク制御へ、Real-Time Interactive (CS4) を対話系映像へ、Broadcast Video (CS5) を配信系映像へ寄せる場合を描いてある。どのクラスをどこへ寄せるかは標準が決めるものではなく設計判断である。Bulk Data (AF1) から Best Effort へ向かう破線は、束ねる先が標準では決まらず設計者が決める箇所であることを示す。縮約は「同じ扱いで足りる」と判断して情報を捨てる作業であり、束ねた区別は下流で復元できない。★この図が示すのは設計モデルであり、本節の実機構成 (§8) は優先キューを音声 1 つに絞り、1 クラス 1 DSCP に簡略化した別物である。

縮約で行うのは、別々に扱う必要があるかを判断して束ねるという作業です。運用管理トラフィックを制御系と同じ扱いで足りると判断すればネットワーク制御のクラスへまとめ、映像は対話系と配信系の 2 つに畳みます。バックアップのような大量転送をベストエフォート側に寄せるか業務データ側に残すかは、その組織で何を守りたいかによって変わり、標準は答えを与えません。

縮約は情報を捨てる作業であり、束ねた区別は下流で戻りません。 束ねた 2 種類のトラフィックを WAN の先で別扱いしたくなっても、印が同じになっている以上、区別する手がかりは残っていません。クラスを減らす判断は、運用の手間を減らすと同時に、将来の選択肢を減らします。

Cisco の設計指針が示す 8 クラス構成は次のとおりです。

#クラス名DSCP帯域スケジューラ
1VoiceEF (46)10%LLQ (strict priority)
2Multimedia conferencing (対話系映像)AF41 (34)23%LLQ (strict priority)
3Multimedia streaming (配信系映像)AF31 (26)10%CBWFQ
4Network controlCS6 (48)5%CBWFQ
5Signaling (呼制御)CS3 (24)2%CBWFQ
6Transactional dataAF21 (18)24%CBWFQ
7ScavengerCS1 (8)1%CBWFQ
8Default (best-effort)DF (0)25%class-default

合計は 100 % です。Best Effort に 25 % を明示的に残す点が、この配分の特徴です。ベストエフォートは「余ったら通す枠」ではなく、業務システムの多くが実際に乗るクラスであり、削りすぎれば日常の業務が遅くなります。

このモデルは優先キューを 2 つ持ちます。 音声だけでなく対話系映像も strict-priority queue に置き、それぞれ 10 % と 23 % で上限を切る構成です。優先キューを 2 段にできるのは IOS-XE の priority level 1 / priority level 2 に対応し、§11 で見るとおり 3 段目は作れません。

なお、8 クラスの配分値と各クラスのスケジューラは、参照する Cisco 資料によって異なります。 上表は Cisco の QoS 設計ガイドが示す 8 クラス構成の値です。製品側のテンプレートでは同じ AF41 の配分やキュー種別が変わることがあります。どの資料のどのモデルを採ったかを設計書に書き残さないと、後から見た人が「Cisco 標準をそのまま入れた」と誤解します。

本節の実機構成は、このモデルをそのまま投入したものではありません。 次の 2 点を意図的に簡略化しています。

  • 優先キューを 1 つ (音声のみ) に絞り、対話系映像は bandwidth percent 23 の CBWFQ に置いた。 §9 で観察する「優先クラスの割り当てを超えたときに何が起きるか」を 1 系統で読めるようにするためです。
  • 1 クラス 1 DSCP で分類した。 モデル側は 1 つのクラスに複数の DSCP を束ねます (§5 の Auto-QoS 生成物がまさにその形で、対話系映像のキューが af41 af42 af43 と cos 4 を拾っています)。

この簡略化の結果、本節の実機構成では CS2・CS4・CS5 が付いたパケットはどのクラスにも一致せず、class-default に落ちます。 図が示す縮約は設計モデルの話で、実機に落とすときは「そのクラスに集めたい DSCP をすべて match に書く」必要があります。

7. WAN 側 (1) — 契約帯域に絞る sub-rate shaping

WAN 側の最初の決定は、どの速度に絞るかです。事業者から 500 kbps の帯域を買っていても、ルータのインタフェース自体は 1 Gbps で動きます。この物理速度と契約速度の差が、WAN QoS の出発点になります。

自網で絞らずに送ると、契約を超えた分は事業者側の設備で捨てられます。事業者の装置が自網のクラス設計を知っている保証はないため、そこで何が捨てられるかを制御できません。音声が落ちるかバックアップが落ちるかを決めるのは自網ではなくなります。自分で契約速度まで絞れば、超過分の破棄が自網のルータの中で起き、どのクラスから捨てるかを自分のポリシーで決められます。 これが sub-rate shaping の目的です。

絞る値には設計上の余裕を見ます。契約帯域ちょうどに shape すると、事業者側の計測点で見た速度が L2 ヘッダやカプセル化のオーバーヘッド分だけ契約を上回り、超過分が事業者側で捨てられることがあります。設計指針としては 契約帯域の 95 % 程度に絞るのが目安とされます。必要な余裕はカプセル化とパケットサイズで変わるため、値そのものより「ちょうどではなく少し下げる」という考え方が要点です。

本検証の親 shaper は 500 kbps ちょうどで、この 95 % の目安を適用した値ではありません。 csr1000v のデモ天井 1000 kb/s の半分という、観測を単純にするための丸めた値です。実測値と設計指針は別のものとして読み分けます。

絞り方は 5-7 HQoS (階層 QoS) で組んだ階層と同じで、親ポリシーが shape average で契約速度まで絞り、その配下の子ポリシーが 8 クラスへ分配します。8 クラスの bandwidth percent は、この親 shaper の 500 kbps を分母として解決されます。

8. WAN 側 (2) — 8 クラスを実機に落とす

ここから投入するのは、§6 の末尾で述べたとおり優先キューを音声 1 つに絞り、1 クラス 1 DSCP に簡略化した検証用の構成です。Cisco のモデルそのものではない点を踏まえて読み進めます。

まず 8 クラスのうち、class-default を除く 7 つの class-map を DSCP で定義します。1 クラス 1 DSCP なので match-all で足ります。実務では 1 つのクラスに複数の DSCP を束ねるため、match-any の class-map に match dscp af41 af42 af43 のように並べます (§5 の Auto-QoS 生成物がその形です)。

snippet 
class-map match-all CM-VOICE
 match dscp ef
class-map match-all CM-INT-VIDEO
 match dscp af41
class-map match-all CM-STR-VIDEO
 match dscp af31
class-map match-all CM-NET-CTRL
 match dscp cs6
class-map match-all CM-SIGNALING
 match dscp cs3
class-map match-all CM-CRITICAL
 match dscp af21
class-map match-all CM-SCAVENGER
 match dscp cs1

子ポリシー PM-WAN-8CLASS に §6 の帯域配分を落とし、親ポリシー PM-WAN-PARENT で契約帯域に絞ります。投入時の CLI 応答は次のとおりです。

snippet 
R1(config)#policy-map PM-WAN-8CLASS
R1(config-pmap)# class CM-VOICE
R1(config-pmap-c)#  priority percent 10
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-INT-VIDEO
R1(config-pmap-c)#  bandwidth percent 23
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-STR-VIDEO
R1(config-pmap-c)#  bandwidth percent 10
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-NET-CTRL
R1(config-pmap-c)#  bandwidth percent 5
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-SIGNALING
R1(config-pmap-c)#  bandwidth percent 2
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-CRITICAL
R1(config-pmap-c)#  bandwidth percent 24
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-SCAVENGER
R1(config-pmap-c)#  bandwidth percent 1
R1(config-pmap-c)# exit
R1(config-pmap)# class class-default
R1(config-pmap-c)#  bandwidth percent 25
R1(config-pmap-c)# exit
R1(config-pmap)#exit
R1(config)#end
R1#
R1(config)#policy-map PM-WAN-PARENT
R1(config-pmap)# class class-default
R1(config-pmap-c)#  shape average 500000
R1(config-pmap-c)#  service-policy PM-WAN-8CLASS
R1(config-pmap-c)# exit
R1(config-pmap)#exit
R1(config)#end
R1#
R1(config)#interface GigabitEthernet3
R1(config-if)# service-policy output PM-WAN-PARENT
R1(config-if)#end

投入から適用まで、エラーも警告も出ていません。8 クラスの構成が IOS-XE 17.03 の MQC にそのまま収まったことになります。定義を表示すると、優先クラスだけが priority、残り 7 クラスが bandwidth で並びます。

snippet 
R1# show policy-map PM-WAN-8CLASS
  Policy Map PM-WAN-8CLASS
    Class CM-VOICE
      priority 10 (%)
    Class CM-INT-VIDEO
      bandwidth 23 (%)
    Class CM-STR-VIDEO
      bandwidth 10 (%)
    Class CM-NET-CTRL
      bandwidth 5 (%)
    Class CM-SIGNALING
      bandwidth 2 (%)
    Class CM-CRITICAL
      bandwidth 24 (%)
    Class CM-SCAVENGER
      bandwidth 1 (%)
    Class class-default
      bandwidth 25 (%)
snippet 
R1# show policy-map PM-WAN-PARENT
  Policy Map PM-WAN-PARENT
    Class class-default
      Average Rate Traffic Shaping
      cir 500000 (bps)   
      service-policy PM-WAN-8CLASS

インタフェースに適用すると、パーセント指定が親 shaper の 500 kbps を分母にして実値へ解決されます。

snippet 
R1# show policy-map interface GigabitEthernet3
 GigabitEthernet3 

  Service-policy output: PM-WAN-PARENT

    Class-map: class-default (match-any)  
      0 packets, 0 bytes
(親 class-default の queue 統計行を省略)
      shape (average) cir 500000, bc 2000, be 2000
      target shape rate 500000

      Service-policy : PM-WAN-8CLASS
(各クラスの queue 統計行を省略し、配分が解決された行だけを抜粋)
        Class-map: CM-VOICE (match-all)  
          Priority: 10% (50 kbps), burst bytes 1500, b/w exceed drops: 0
        Class-map: CM-INT-VIDEO (match-all)  
          bandwidth 23% (115 kbps)
        Class-map: CM-STR-VIDEO (match-all)  
          bandwidth 10% (50 kbps)
        Class-map: CM-NET-CTRL (match-all)  
          bandwidth 5% (25 kbps)
        Class-map: CM-SIGNALING (match-all)  
          bandwidth 2% (10 kbps)
        Class-map: CM-CRITICAL (match-all)  
          bandwidth 24% (120 kbps)
        Class-map: CM-SCAVENGER (match-all)  
          bandwidth 1% (5 kbps)
        Class-map: class-default (match-any)  
          bandwidth 25% (125 kbps)

8 クラスの解決値を足すと 50 + 115 + 50 + 25 + 10 + 120 + 5 + 125 で 500 kbps になり、親 shaper の契約帯域と一致します。§6 の表に書いた帯域配分の割合が、そのまま実機の kbps に翻訳されました (スケジューラは §6 末尾のとおり、対話系映像を CBWFQ に置き換えた簡略版です)。

9. 配分を間違えると何が起きるか — 守るはずの音声だけが壊れる

ここまでで設計は形になりました。この設計には、実際に流すまで表に出ない誤りが 1 つ含まれています。 音声に割り当てた 10 % は 50 kbps で、この帯域に対して音声の実需要が上回る場合に何が起きるかを実測します。

PC2 から PC3 へ、EF・AF41・AF21・BE の 4 系統を 各 200 kbps・15 秒・同時に送出します。合計 800 kbps の需要に対し、親 shaper は 500 kbps しか通しません。輻輳した状態でクラス別の扱いを観察するための条件です。本検証で実際に流したのはこの 4 クラスだけで、残る AF31・CS6・CS3・CS1 のクラスは分類の一致を観察していません (カウンタは 0 のままです)。受信側の PC3 で 4 つのポートに iperf サーバを立て、送信側の PC2 から 4 本を同時に起動します。

snippet 
PC3 $ nohup iperf -s -u -p 5001 -i 1 >/tmp/s5001.log 2>&1 &   (5002 / 5003 / 5004 も同様)
PC2 $ iperf -c 192.168.30.20 -u -p 5001 -S 0xb8 -b 200k -t 15 >/tmp/cef.log 2>&1 &     (EF)
PC2 $ iperf -c 192.168.30.20 -u -p 5002 -S 0x88 -b 200k -t 15 >/tmp/caf41.log 2>&1 &   (AF41)
PC2 $ iperf -c 192.168.30.20 -u -p 5003 -S 0x48 -b 200k -t 15 >/tmp/caf21.log 2>&1 &   (AF21)
PC2 $ iperf -c 192.168.30.20 -u -p 5004 -S 0x00 -b 200k -t 15 >/tmp/cbe.log 2>&1 &     (BE)

-S に渡す ToS バイトは、DSCP を 4 倍 (2 ビット左シフト) した値です。EF (46) が 0xb8、AF41 (34) が 0x88、AF21 (18) が 0x48、BE (0) が 0x00 になります。受信側 PC3 のサーバが記録した結果が次のものです。

snippet 
## EF (tos 0xb8, port 5001) 受信側 PC3 iperf サーバレポート
[  1] 0.00-15.11 sec  79.0 KBytes  42.8 Kbits/sec   0.098 ms 204/259 (79%)
## AF41 (tos 0x88, port 5002) 受信側 PC3 iperf サーバレポート
[  1] 0.00-19.94 sec   359 KBytes   147 Kbits/sec  32.512 ms 9/259 (3.5%)
## AF21 (tos 0x48, port 5003) 受信側 PC3 iperf サーバレポート
[  1] 0.00-19.77 sec   366 KBytes   152 Kbits/sec  28.815 ms 4/259 (1.5%)
## BE (tos 0x00, port 5004) 受信側 PC3 iperf サーバレポート
[  1] 0.00-19.42 sec   372 KBytes   157 Kbits/sec  28.444 ms 0/259 (0%)

結果を並べると、優先度と損失の関係が逆転しています。

クラスToS受信スループット損失
EF (音声)0xb842.8 Kbits/sec204/259 (79 %)
AF410x88147 Kbits/sec9/259 (3.5 %)
AF210x48152 Kbits/sec4/259 (1.5 %)
BE0x00157 Kbits/sec0/259 (0 %)

最優先に置いた音声が 79 % 失われ、優先度を持たないベストエフォートが 1 パケットも落ちていません。 逆転しているのは EF だけで、残る 3 クラスは保証帯域 (115 / 120 / 125 kbps) の順にそのまま受信しています。ルータ側のカウンタが理由を示しています。

snippet 
R1# show policy-map interface GigabitEthernet3
(親 class-default の表示を省略)
      Service-policy : PM-WAN-8CLASS

        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/192/0
          (pkts output/bytes output) 52/78624

        Class-map: CM-VOICE (match-all)  
          244 packets, 368928 bytes
          5 minute offered rate 10000 bps, drop rate 9000 bps
          Match:  dscp ef (46)
          Priority: 10% (50 kbps), burst bytes 1500, b/w exceed drops: 192
          
(中略)
        Class-map: CM-CRITICAL (match-all)  
          244 packets, 368928 bytes
          5 minute offered rate 10000 bps, drop rate 0000 bps
          Match:  dscp af21 (18)
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 63/0/0
          (pkts output/bytes output) 244/368928
          bandwidth 24% (120 kbps)

b/w exceed drops: 192 が答えです。LLQ の priority は、指定した帯域を守るだけの仕組みではなく、輻輳時にその帯域を超えた分を叩き落とすポリサでもあります。 優先キューが他のクラスを飢えさせないよう、割り当てを超えた優先トラフィックはキューイングされずに破棄されます。

このポリサは 条件付きです。priority に明示的な police を併記しない場合、超過分が捨てられるのは輻輳が起きているときだけで、競合が無く帯域に余裕がある間は割り当てを超えて送れます。本節の実測は合計 800 kbps を 500 kbps の親 shaper に流し込む輻輳条件なので、この条件付きポリサが実際に効いた場面にあたります。逆に、常時上限として効かせたい場合は priority に police を明示的に併記します。

200 kbps 送り込んだ EF のうち通ったのは 42.8 Kbits/sec で、割り当ての 50 kbps とほぼ一致します。

一方、AF41・AF21・BE は割り当て (115 / 120 / 125 kbps) を上回る 147 / 152 / 157 Kbits/sec を受け取りました。CBWFQ の bandwidth は最低保証であって上限ではないためです。EF が叩き落とされて空いた帯域を、残りの 3 クラスが分け合っています。なお、4 クラスの受信スループットの単純和 (約 499 Kbits/sec) を親 shaper の 500 kbps と突き合わせることはできません。集計窓が 15.11 秒から 19.94 秒までばらけた平均値の和であることに加え、iperf が測るのは UDP ペイロードで、shaper が数えるのは L2 ヘッダを含むフレーム長だからです。両者は別の量を測っています。

設計で優先クラスの必要量を見誤ると、優先クラスに入れたトラフィックだけが壊れ、ベストエフォートが無傷で通ります。 「重要だから priority に入れる」という判断は、同時に「この帯域を超えたら捨てる」という宣言でもあります。

10. 直すには他を削るしかない

音声の実需要が 200 kbps なら、割り当てを増やせば直ります。まず、音声だけを 10 % から 45 % へ上げてみます。

snippet 
R1(config)#policy-map PM-WAN-8CLASS
R1(config-pmap)# class CM-VOICE
R1(config-pmap-c)#  priority percent 45
Sum total of class bandwidths exceeds 100 percent
R1(config-pmap-c)# exit

拒否されます。既に 8 クラスの合計が 100 % に達しているため、どこも削らずに 1 クラスだけを増やす余地はありません。拒否された行は反映されず、定義は元のままです。

snippet 
R1# show policy-map PM-WAN-8CLASS
  Policy Map PM-WAN-8CLASS
    Class CM-VOICE
      priority 10 (%)
    Class CM-INT-VIDEO
      bandwidth 23 (%)
(以降のクラスは変化なしのため省略)

音声を 45 % にするには、先に 35 % 分の原資を他のクラスから作る必要があります。対話系映像を 23 % から 10 %、配信系映像を 10 % から 5 %、重要データを 24 % から 13 %、ベストエフォートを 25 % から 19 % へ削り、そのうえで音声を上げます。

snippet 
R1(config)#policy-map PM-WAN-8CLASS
R1(config-pmap)# class CM-INT-VIDEO
R1(config-pmap-c)#  bandwidth percent 10
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-STR-VIDEO
R1(config-pmap-c)#  bandwidth percent 5
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-CRITICAL
R1(config-pmap-c)#  bandwidth percent 13
R1(config-pmap-c)# exit
R1(config-pmap)# class class-default
R1(config-pmap-c)#  bandwidth percent 19
R1(config-pmap-c)# exit
R1(config-pmap)# class CM-VOICE
R1(config-pmap-c)#  priority percent 45
R1(config-pmap-c)# exit

今度は受理されました。合計は 45 + 10 + 5 + 5 + 2 + 13 + 1 + 19 で 100 % です。

snippet 
R1# show policy-map PM-WAN-8CLASS
  Policy Map PM-WAN-8CLASS
    Class CM-VOICE
      priority 45 (%)
    Class CM-INT-VIDEO
      bandwidth 10 (%)
    Class CM-STR-VIDEO
      bandwidth 5 (%)
    Class CM-NET-CTRL
      bandwidth 5 (%)
    Class CM-SIGNALING
      bandwidth 2 (%)
    Class CM-CRITICAL
      bandwidth 13 (%)
    Class CM-SCAVENGER
      bandwidth 1 (%)
    Class class-default
      bandwidth 19 (%)

同じ送出条件 (各 200 kbps・15 秒・4 系統同時) で再測定します。

snippet 
## EF (tos 0xb8, port 5001) 受信側 PC3 iperf サーバレポート
[  1] 0.00-15.11 sec   372 KBytes   202 Kbits/sec   0.188 ms 0/259 (0%)
## AF41 (tos 0x88, port 5002) 受信側 PC3 iperf サーバレポート
[  1] 0.00-20.49 sec   234 KBytes  93.5 Kbits/sec  81.097 ms 96/259 (37%)
## AF21 (tos 0x48, port 5003) 受信側 PC3 iperf サーバレポート
[  1] 0.00-19.94 sec   261 KBytes   107 Kbits/sec  65.683 ms 82/264 (31%)
## BE (tos 0x00, port 5004) 受信側 PC3 iperf サーバレポート
[  1] 0.00-19.18 sec   314 KBytes   134 Kbits/sec  43.516 ms 43/262 (16%)

修正前後を並べると、音声が直ったこと以上に、直った分の代償がどこに出たかが読み取れます。

クラス修正前の損失修正後の損失
EF (音声)204/259 (79 %)0/259 (0 %)
AF419/259 (3.5 %)96/259 (37 %)
AF214/259 (1.5 %)82/264 (31 %)
BE0/259 (0 %)43/262 (16 %)

音声は 202 Kbits/sec を損失 0 % で受け取り、ジッタも 0.188 ms に収まりました。その代わり、対話系映像は 3.5 % から 37 %、重要データは 1.5 % から 31 %、ベストエフォートは 0 % から 16 % へ損失が増えています。帯域は有限なので、優先クラスへ回した 35 % 分は、必ずどこかのクラスから引き算されています。

QoS 設計とは「誰を守るか」を決める作業ではなく、「誰を守り、その代償として誰を諦めるか」を決める配分の作業です。 守る対象を増やすことはできますが、守る総量を増やすことはできません。契約帯域を増やす以外に、この制約から逃れる方法はありません。

ただし、この 45 % という直し方は Cisco の設計指針を外れています。 Cisco の QoS 設計ガイドは「strict-priority queue に使うのは link 帯域の 1/3 まで」を原則としており、§6 の 8 クラスモデルも音声 10 % と対話系映像 23 % の合計がちょうど 33 % に収まる配分です。本節が 45 % まで上げたのは、割り当てを変えると受信側の損失がどう動くかを 1 つの実験として見せるためであり、実務でそのまま採る値ではありません。優先クラスを 1/3 を超えて広げたくなったときに疑うべきは配分ではなく、「音声の実需要が契約帯域の 4 割を占める」というその前提のほう、つまり契約帯域そのものが足りているかです。

修正後のルータ側カウンタには、読み方の注意が 1 つあります。

snippet 
        Class-map: CM-VOICE (match-all)  
          780 packets, 1179360 bytes
          5 minute offered rate 9000 bps, drop rate 0000 bps
          Match:  dscp ef (46)
          Priority: 45% (225 kbps), burst bytes 5600, b/w exceed drops: 411

Priority: 45% (225 kbps) へ変わった一方で、b/w exceed drops は 411 と修正前より増えています。このカウンタは積分値であり、現在の状態ではありません。 ポリシーを当て直していないため、修正前の測定で発生した破棄がそのまま残り、そこに加算されています。修正が効いたことを読み取るのは、同じ行の drop rate 0000 bps と、受信側で測った損失 0 % のほうです。カウンタの絶対値ではなく、レートと受信側の実測で判断します。

本検証では測定の間にカウンタをクリアしていないため、この表示には本節で行った複数回の送出が積み上がっています (割り当てが 10 % のままだった測定も含みます)。クラスごとに packets の総数が揃っていないのも、各クラスの送出が同じ回数・同じ長さで終わっていないためで、この数字どうしを突き合わせて読むことはできません。同じ比較を厳密に行うなら、測定ごとに clear counters でカウンタを初期化するか、測定区間の offered rate / drop rate を毎回並べて記録します。 本節が受信側 iperf の損失率を主たる判断材料に据えているのは、この累積の混在に影響されない測定点だからです。

11. 落とし穴・補足

設計上の制約は、ベストプラクティス表で語られることが多い一方、実機がどこで拒否するかを見ておくと境界がはっきりします。本節で実測した制約を並べます。

本検証の csr1000v (IOS-XE 17.03.08a) では priority level は 2 段までです。 3 段目を作ろうとすると構文として存在しません。priority level の対応段数はプラットフォームによって異なるため、機種を変えるときは同じように ? で確かめます。

snippet 
R1(config-pmap)# class CM-STR-VIDEO
R1(config-pmap-c)#  priority level 3
                                   ^
% Invalid input detected at '^' marker.

priority level 1 と priority level 2 は受理されるため、優先キューを 2 段に分けることはできます。3 つ目の優先クラスが必要になった設計は、そこで作り直しになります。

本検証の csr1000v (IOS-XE 17.03.08a) では、bandwidth percent の合計が 100 % を超える設定は投入の時点で拒否されます。 60 % のクラスを 2 つ作ろうとすると 2 つ目が弾かれます。予約できる上限は max-reserved-bandwidth で決まり、機種と世代によって既定値が異なります。

snippet 
R1(config-pmap)# class CM-CRITICAL
R1(config-pmap-c)#  bandwidth percent 60
Sum total of class bandwidths exceeds 100 percent

拒否されるのは超過した行だけで、policy-map 自体は残ります。「設定は通ったが意図と違う配分になっている」という状態が作られやすいため、投入後は必ず show policy-map で全クラスの値を確認します。

同一クラスに priority と bandwidth は併記できません。 優先キューと最低保証は排他です。

snippet 
R1(config-pmap)# class CM-VOICE
R1(config-pmap-c)#  priority percent 10
R1(config-pmap-c)#  bandwidth percent 20
Bandwidth not allowed with priority

この場合も先に入った priority percent 10 だけが残ります。

Auto-QoS が生成した bandwidth remaining percent の合計は 100 ではありません。 §5 の生成物を足すと 10 + 10 + 10 + 4 + 1 + 10 + 25 で 70 になります。これは総帯域ではなく残余帯域の配分値です。この合計が 70 である理由を、本節は実機の出力から確定できていません。 生成された設定が実機に受理され、show policy-map interface にそのまま表示されるという事実までを記録します。

カウンタが 0 であることを、機器の制約の証拠に使いません。 本節の Catalyst 9000v の表示は全クラス 0 packets ですが、これは LAN セグメントにトラフィックを流していないためで、機器が数えられないことを意味しません (§5)。5-3 と 5-4 では、同じ仮想 Catalyst 9000v で match の分類カウンタが実際に増え、QoS Set の行だけがパケット数を持たないことを確認しています。0 を見たら、まず「そこに流したか」を確かめます。

LLQ に入れたクラスは、輻輳時に割り当てを超えた分から捨てられる、最も脆いクラスになります。 §9 の実測がそのままの例で、優先クラスの必要量を見誤ると、そのクラスだけが壊れます。輻輳していない間は割り当てを超えて通るため、平常時のテストでは問題が見えず、輻輳した本番でだけ音声が壊れるという形で表面化します。優先クラスへ入れる判断とセットで、そのクラスの実需要を見積もる必要があります。

子ポリシーのパーセント指定の分母は親 shaper です。 §8 の実測では bandwidth 23% が 115 kbps と表示されました。親を持たないポリシーではインタフェース速度が分母になり、§5 の LAN 側では priority level 1 percent 30 が 1 Gbps に対する 300000 kbps へ解決されています。親 shaper を後から変更すると、子ポリシーの全クラスの実値が連動して変わります。契約帯域を変更したときに、各クラスの実帯域が意図した値になっているかは show policy-map interface で確認します。

ベストエフォートを削りすぎません。 §6 の配分が Best Effort に 25 % を明示的に残すのは、業務システムの多くがこのクラスに乗るためです。§10 で 19 % まで削った結果、ベストエフォートの損失は 0 % から 16 % へ増えました。優先クラスの原資をどこから取るかは、そのまま「どの業務を諦めるか」の判断になります。

本節で組んだ WAN 側の最終形は次のとおりです。

snippet 
R1# show running-config | section policy-map
policy-map PM-WAN-8CLASS
 class CM-VOICE
  priority percent 45
 class CM-INT-VIDEO
  bandwidth percent 10 
 class CM-STR-VIDEO
  bandwidth percent 5 
 class CM-NET-CTRL
  bandwidth percent 5 
 class CM-SIGNALING
  bandwidth percent 2 
 class CM-CRITICAL
  bandwidth percent 13 
 class CM-SCAVENGER
  bandwidth percent 1 
 class class-default
  bandwidth percent 19 
policy-map PM-WAN-PARENT
 class class-default
  shape average 500000   
   service-policy PM-WAN-8CLASS

12. 次節

本節では、LAN 側と WAN 側の QoS を 1 つの設計としてまとめる手順を、Catalyst 9000v と csr1000v の実機で扱いました。設計は「どこまで信じるか・何をどの印にするか・どの速度に絞るか・絞った中をどう分けるか」の 4 つの決定でできています。LAN 側では auto qos trust dscp の 1 行が 8 キュー構成のテンプレートを生成し、クラス設計は RFC 4594 の 12 クラスを標準語彙として 4 / 8 / 12 クラスの階段から段を選びます。WAN 側では契約速度に親 shaper で絞り、その中を 8 クラスへ配分しました。

実測の核は帯域配分のトレードオフです。音声に 10 % (= 50 kbps) しか与えない構成では守るはずの EF が 79 % 失われ、他クラスを削って 45 % へ上げると EF は無損失に戻る代わりに、AF41 が 37 %、AF21 が 31 %、BE が 16 % を失いました。守る対象は選べても、守る総量は増やせません。

ここまでで、設計の骨格と配分の考え方は揃いました。残るのは、LAN 側で付けた印が WAN 側の優先制御まで通しで効くことを、1 本のトラフィックで確かめる作業です。次節 5-10 では、端末から出た音声トラフィックをアクセス端で EF にマーキングし、WAN 側の LLQ で守るところまでを end-to-end で通すハンズオンを見ていきましょう。