Cisco IOS-XEのQoS Shaping動作実験
はじめに
Cisco機器でQoS Shapingを行う場合、IOSとIOS-XEで動作が異なるので、違いを整理するとともに、IOS-XEで実際にトラフィックを流して動作確認してみました。
1. 事前準備
1-1. NW構成
CSR1000v(IOS-XE)2台のWAN側を互いに接続し、LAN側にトラフィックジェネレーターTRexを接続しました。TRexのeth1からeth2宛てにトラフィックを流し、QoS動作確認を行います。eth0は物理環境PCにインストールしたTRex GUIアプリケーションからのアクセス用です。
1-2. ルータ選定
ちょっと試行錯誤したので書き残しておきます。
CSR1000vのスループットは、デフォルトで1000kpsとなります。今回は10Mbps以上流したいので、ライセンスを追加して値を引き上げる必要があります。
csr1000v-1#show platform hardware throughput level
The current throughput level is 1000 kb/s
CML2.1に付属しているCSR1000v 16.11.01b はスマートライセンス方式が採用されています。(16.10.1aから変更されたようです。)
本方式の場合、Cisco Software Centralからダウンロードした評価版ライセンス(xxx.lic)をlicense install bootflash:xxx.licコマンドで適用できないので、代わりに16.07.07のイメージをCML2.1に追加し、ライセンス適用して2.5Gbpsに引き上げています。
csr1000v-2#show platform hardware throughput level
The current throughput level is 2500000 kb/s
iosv(IOS)の実験もしたかったのですが、こちらもデフォルトで1.5Mbps程度に制限されているようです。
1-3. TRexの設定
以下ブログの通り設定しています。
プロファイル作成時、全体のトラフィック量はL2 bps（L2ヘッダまでをトラフィック計算に含める）で「20Mbps」としています。
その中で、さらに3つのストリームを作成し、実験内容に応じて適宜トラフィックをミックスしています。
| No. | ストリーム名 | Protocol | Source | Destination | Frame Length | Rate |
|---|---|---|---|---|---|---|
| 1 | test_udp_101 | UDP | 10.1.1.101 | 10.2.2.100 | 500 | 10.0M |
| 2 | test_udp_102 | UDP | 10.1.1.102 | 10.2.2.100 | 500 | 10.0M |
| 3 | test_udp_103 | UDP | 10.1.1.103 | 10.2.2.100 | 500 | 10.0M |
1-4. QoSの設定
以下URLを参考に、階層化シェーピングを設定しています。
- 親ポリシー
P-PARENTで全体の帯域を10Mbpsにシェーピング(設定1) - 子ポリシー
P-CHILDでLLQ(PQとCBWFQのキューイング方式を合わせたもの)を用い、クラスC-VOICE(PQ、輻輳時の最大帯域30%)、C-DATA2(WFQ、最低保証帯域40%)、C-DATA3(WFQ、最低保証帯域10%)、Default Classを定義(設定2) - 各ユーザ定義クラスがTRexで作成したストリームNo.1～3にマッチするよう、クラスマップでACLを設定(設定3)
- WAN側インターフェースへ親ポリシーを適用(設定4)
! 設定3
access-list 101 permit ip host 10.1.1.101 host 10.2.2.100
access-list 102 permit ip host 10.1.1.102 host 10.2.2.100
access-list 103 permit ip host 10.1.1.103 host 10.2.2.100
!
class-map C-VOICE
match access-group 101
class-map C-DATA2
match access-group 102
class-map C-DATA3
match access-group 103
! 設定2
policy-map P-CHILD
class C-VOICE
priority percent 30
class C-DATA2
bandwidth percent 40
class C-DATA3
bandwidth percent 10
class class-default
fair-queue
! 設定1
policy-map P-PARENT
class class-default
shape average 10000000
service-policy P-CHILD
! 設定4
int GigabitEthernet1
ip address 192.168.100.221 255.255.255.0
service-policy output P-PARENT
!
int GigabitEthernet2
ip address 10.1.1.1 255.255.255.0
!
ip route 10.2.2.0 255.255.255.0 192.168.100.222
2. 輻輳時のPQ動作
非輻輳時、PQのパケットは他のWFQのパケットよりも優先して処理されます。一方輻輳時は、PQのパケットはポリシーマップで設定した最大帯域までに制限されます。
実際にTRexでクラスC-VOICEとC-DATA3にマッチするパケットを10Mbpsずつ、合計20Mbps分流し、TRexで受信パケットをキャプチャしてみました。Tx 20Mbpsに対し、Rxが10Mbpsになっているので、親ポリシーのシェーピングは問題なく機能していそうです。
Wiresharkで入出力グラフを出力しました。黒は全パケット、緑はC-VOICE、青はC-DATA3のパケットです。1ミリ秒オーダーで見ると、赤で囲った箇所(50ミリ秒強の間隔)でなぜかC-VOICEが全帯域を消費していました。ただ、それ以外はC-VOICEが30%に帯域制限されていました。
3. 輻輳時のCBWFQ動作
以下の通り、IOS(2 parameter schedulers)とIOS-XE(3 parameter schedulers)で輻輳時の動作が異なります。前者の場合、最低保証帯域(Minimum guarantee)以外の余剰帯域(Excess bandwidth)は、各クラスの最低保証帯域に応じて按分されます。後者の場合、余剰帯域は等分されます。
※参考URL1 p12から抜粋
3-1. IOS-XE、Bandwidth設定の場合
TRexでC-DATA2とC-DATA3にマッチするパケットを10Mbpsずつ、合計20Mbps分流して確認してみます。想定結果は、10Mbpsの帯域をC-DATA2が(最低保証帯域40%) + (余剰分50% / 2) = 65%、C-DATA3が(最低保証帯域10%) + (余剰分50% / 2) = 35%の比率で分配することです。
黒は全パケット、赤はC-DATA2、青はC-DATA3のパケットです。1ミリ秒オーダーで見た結果ですが、想定通りになっていそうです。
3-2. IOS-XE、Bandwidth Remaining設定の場合
余剰帯域の分配方法をデフォルトから変更したい場合、ポリシーマップ設定で各クラスにbandwidth remaining ratio xもしくはbandwidth remaining percent xコマンドを設定します。(デフォルトは各クラスとも「1」のため等価になる。)
※参考URL1 p13から抜粋
C-DATA2、C-DATA3、Default Classで帯域が4:1:2に分配されるよう、以下の通り設定しました。なお、PQを利用しているC-VOICEでは、本コマンドはサポートされていません。
policy-map P-CHILD
class C-VOICE
priority percent 30
class C-DATA2
no bandwidth percent 40
bandwidth remaining ratio 4
class C-DATA3
no bandwidth percent 10
bandwidth remaining ratio 1
class class-default
bandwidth remaining ratio 2
fair-queue
赤のC-DATA2、青のC-DATA3を比較すると、想定通り4:1になっていそうです。
4. BcとBeの値
シェーピングでは、CIR(bps) = Bc(bit) / Tc(sec)の式に従い、Tc時間毎に送信可能なデータ量Bcを設定することで、結果的にシェーピングレートCIRを満たす動作となります。そのため設定によっては、Tc時間開始直後にデータを送信し切って、次のTc時間が来るまで何もパケットが流れない動きになることもあります。
shape average <CIR> <Bc> <Be>コマンドで設定可能ですが、IOS-XEの場合、Bc/Beを明示的に指定しても無視されます。（ポリシングではIOS、IOS-XEともに明示的に指定可能。）
※参考URL1 p72から抜粋
ちなみに、今回のIOS-XE環境では以下の通り、cir=10000000、bc=40000、be=40000となっていました。設定を変えるとshowコマンド結果も変わりましたが、入出力グラフの波形は変化なしでした。
csr1000v-1#show policy-map interface
GigabitEthernet1
Service-policy output: P-PARENT
Class-map: class-default (match-any)
78494473 packets, 38933223576 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/34359567/0
(pkts output/bytes output) 44090737/21868970520
shape (average) cir 10000000, bc 40000, be 40000
target shape rate 10000000
(省略)
Discussion