QoSの問題調査およびログ取得方法

Takashi Higashimura · ‎2014-01-07

本ドキュメントでは、QoS の問題を解析するにあたり調査に必要なログの取得方法を説明します。

また、本ドキュメントでは検証環境での解析方法をメインとしており、実環境での解析においては必ずしも有効でない場合がございますが、予めご了承ください。

1. 本ドキュメントのネットワーク構成

L2 125bytes の Frame を 10000pps で測定器から矢印の方向で送出。

10000pps * (125*8) = 10000000bps(=10Mbps)

上記計算式の通り、10Mbps のトラフィックとなり R１の Gi0/2 で受信、Gi0/1 で送信されますが、Gi0/1 で 5Mbps のシェーピングを設定しています。

2. 取得ログ

QoS の設定や機種により、取得するコマンドが異なってくる場合はございますが、最低限必要なものは下記となります。

show policy-map interface ※
show hqf interface ※
show interface ※
show tech
show logging
※ : トラフィックを流している状態で複数回3-5回程度取得

3. 解析にあたり必要な事（ログ取得の注意含む)

前述の項目2.で記載しているログを取得する際の注意点となります。下記が実施されていない場合は、QoS の調査は困難となります。

1) QoS制御されるトラフィックの情報

どのようなトラフィックを流していて、QoS がうまく動作していないかを把握/整理する。

CBFWQ などで、複数の Class にそれぞれ 3つのトラフィックを流している場合は下記のような形で整理する。

Traffic#1 for Class#1 : IP  L2 100bytes frame (10Mbps/10000pps)
Traffic#2 for Class#2 : TCP L2  50bytes frame (5Mbps/10000pps)
Traffic#3 for Class#3 : UDP L2 100bytes frame (5Mbps/50000pps)

プロトコル種別(IP/TCP/UDP)、パケットサイズ(L2 or L3 なのかも重要)、トラフィック量(bps)、パケット量(pps) の情報は調査を行う上で必要な情報となります。無い場合は、そのトラフィックが破棄されるべきものか否かの判断ができません。

2) 切り分け情報

下記の情報があると解析が非常にスムーズに進む場合があります。

- あるバージョンでは正常に QoS 制御されるが、このバージョンだと制御がおかしい (具体的なバージョン境界が分かると非常に有力な情報)

- QoS の設定を変更してみたら、QoS 制御の問題が解消された (どのように設定を変更したか確認する)

- トラフィック特性を変更したら問題が解消された (Frame サイズを 64bytes -> 1500bytes に変更など)

3) load-interval 30 の設定

下記は設定方法です。

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#int <interface>
Router(config-if)#load-interval 30

4) トラフィックを流している状態でログを取得

これが解析にあたり、最も重要なポイントとなります。弊社 IOS を使っていただいているユーザ様には QoS の確認は show policy-map interface という認識を持っていただいているのですが、事象が発生するトラフィックが流れている状態でログを取得することが重要です。

5) パケットキャプチャ

事象が発生するトラフィックのパケットキャプチャ。QoS 制御前と制御後の両方があると良い。

4. よくある事例

1) バーストトラフィックによる破棄

弊社 IOS では 12.4(20)T 以降で、HQF という QoS 実装になり、Shaping でそれまで Tc 25msec だったものが 4msec へと変更が行われました。

そのため、QoS 制御の粒度が上がった一方でバーストトラフィックを落としてしまう事例が報告されております。

特に HQF 以前から HQF へバージョンアップした場合に報告される事例が多いです。

12.4(20)T より前のバージョンから、HQF 実装の IOS へバージョンアップをした場合には、Tc が変更された影響かどうかは下記のように Bc/Be 値の調整で Tc 値を 4msec -> 25msec へと変更し、従来と同じ値とすることでバースト特性を持ったトラフィックの破棄が解消されるかご確認ください。

2) queue-limit の超過による破棄

Shaping などで Bc 値を越えたことにより次のトークンを待って処理される場合などには、queue-limit にパケットが溜まることなります。

この場合、一時的なバーストにより多くの short frame(or short packet) が来た場合にdefault の 64packets で不足すると破棄されます。

この場合には下記太字部分でのカウントが増加することにより、queue-limit での破棄と推測することが可能です。下記の場合では queue limit 64 packets で、queue depth 64 となっているため、キューが不足していることが確認できます。

Router#show policy-map int

 GigabitEthernet0

  Service-policy output: Shape

    Class-map: class-default (match-any)  
      84880256 packets, 127320118758 bytes
      30 second offered rate 83539000 bps, drop rate 13087000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 64/32749/0
      (pkts output/bytes output) 84847504/127270998258
      shape (average) cir 10000000, bc 40000, be 40000
      target shape rate 10000000

破棄への対策としては queue-limit 値を変更することで可能です。

Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#policy-map Shape
Router(config-pmap)#class class-default
Router(config-pmap-c)#queue-limit 128

3) 遅延について

bandwidth 設定を行っているクラスで遅延が発生しますというお問い合わせがたまにありますが、bandwidth では輻輳時の帯域確保が目的であって遅延を保障するものではございません。そのため、遅延についての議論は PQ(Priority Queuing) クラスであれば可能ですが、bandwidth などすることに意味がありません。

それは QoS をデザインする段階でも理解すべき点となり、その設定がどのような役割を担っているかを把握し何を問題とすべきかを考えることが重要です。

5. 最後に

項目3での上記 1) では Bc/Be の変更による Tc の調整、2) ではバーストトラフィックに対する queue-limit の調整、となり両者とも QoS ではチューニングの範疇となり IOS の不具合などではございません。"あれ？QoS 制御おかしいんじゃないか？" と思った場合にも、まずはトラフィックの特性を理解し、パラメータの変更(=チューニング)で回避可能かをご確認ください。