🐱

Cisco IOS-XEのQoS Shaping動作実験

2021/03/28に公開

はじめに

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から変更されたようです。)
https://community.cisco.com/t5/ネットワークインフラストラクチャ-ドキュメント/ios-xe-16-10-1-における-smart-license-への変更について/ta-p/3793832

本方式の場合、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の設定

以下ブログの通り設定しています。
https://zenn.dev/win_beauty/articles/56628b7a547fc5

プロファイル作成時、全体のトラフィック量は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を参考に、階層化シェーピングを設定しています。
https://www.infraexpert.com/study/qos1.htm

  • 親ポリシー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)
csr1000v-1
! 設定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-VOICEC-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-DATA2C-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-DATA2C-DATA3Default Classで帯域が4:1:2に分配されるよう、以下の通り設定しました。なお、PQを利用しているC-VOICEでは、本コマンドはサポートされていません。

csr1000v-1(修正)
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時間が来るまで何もパケットが流れない動きになることもあります。
https://community.cisco.com/t5/ネットワークインフラストラクチャ-ドキュメント/シェーピングによるパケットドロップ/ta-p/3155455

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
      (省略)

参考URL

  1. QoS Configuration Migrations From Classic IOS to IOS XE

Discussion