シェーピングによるパケットドロップ

Hiromasa Kakehashi · ‎2016-05-18

PC等で動作するフリーのトラフィックジェネレータを使用してシェーピングの試験を行うと通信量がシェーピングレートに達していないにも関わらずパケットドロップが見られることがあります。

本ドキュメントではシェーピングによってパケットドロップが発生する仕組みと、なぜフリーのトラフィックジェネレータを使用した場合にパケットドロップが見られることがあるかを実際の試験結果を使って説明します。

シェーピングとシェーピングによるパケットドロップの仕組み

ルータのシェーピングは 1秒をより短い単位時間(Tc)に分割して、各単位時間あたりに送信可能なデータ量(Bc)を送信、そのデータ量(Bc)をこえるトラフィックをキューイングすることで、シェーピングレート(CIR)を満たすように動作します。

例えばインタフェースに CIR = 8 Kbps, Bc = 1 Kbps としたポリシマップを設定した場合は、単位時間 125 ms 毎に 1 Kbps のデータを送信し、1 Kbps をこえるトラフィックを次のインターバルまでキューイングすることで 8 Kbps のシェーピングを実現しています。

キューイングされたパケットの数がキュー長(queue-limit) の上限に達すると、ルータは以降のパケットを次のインターバルがくるまでドロップします。その為、パケットドロップの妥当性を判断するためには、シェーピング対象の通信がどの程度ルータに流れ込んできているかを、1秒あたりではなく、単位時間(Tc)あたりの観点から 調査する必要があります。

試験の概要

ルータの Output側インタフェースに 30 Mbps のシェーピングを設定し、有償のトラフィックジェネレータ IxN2X とフリーのトラフィックジェネレータ( on PC )から、それぞれ 29M のトラフィックを流します。その他の条件は以下の通りです。

Cisco3925/15.5(3)M2 を使用する。
Bc と Tc はデフォルト値を使う( それぞれ Bc = 120 Kbps, Tc = 4 ms )
キュー長はデフォルト値とする( queue-limit = 64 )
テストトラフィックのフレーム長は一律 128 bytes とする。

試験結果はルータの show コマンドと、ルータの Input側で採取したパケットキャプチャを使って解析します。

試験結果

1. 有償のトラフィックジェネレータ ( パケロスなし )

show policy-map interface

Offered Rate は 30Mbps以下におさまっており、キューイングやパケットドロップは発生していません。

パケットキャプチャ / Wireshark の Summary 機能

Wireshark のサマリ機能も平均の通信量が 30 Mbps以下におさまっていることを示しています。

パケットキャプチャ / Wireshark の IO Graph 機能

Wireshark のIO Graph を 1/1000 のスケールにした結果です。
送信されるパケット数は定常的に 25～27 パケットを推移しています。

2. フリーのトラフィックジェネレータ( パケロスあり )

show policy-map interface

Offered Rate は 30Mbps以下ですが、パケットドロップが発生しています。
キューイングされているパケット数( queue depth )は、showコマンドをたたくタイミングによって 0 になったり、64 になったりします。このことからバースト性のトラフィックパタンになっていることが推測されます。

パケットキャプチャ / Wireshark の Summary 機能

Wireshark のサマリ機能は平均の通信量が 30 Mbps以下におさまっていることを示しています。

パケットキャプチャ / Wireshark の IO Graph 機能

Wireshark のIO Graph を 1/1000 のスケールにした結果からは、バースト性のトラフィックパタンが確認できます。ピーク時の送信パケット数は約270パケットに達している一方、パケットを全く送信していない時間帯があります。

バーストした瞬間のパケットキャプチャ / Wireshark の Summary 機能

ピーク時のパケットのみを抽出して作成したキャプチャファイルを Summary 機能で確認した結果です。
ピーク時の通信量は、347 Mbps 相当に達していました。

この試験の条件でルータが単位時間(Tc)あたりに送信可能なパケット数は、以下の計算結果から 117パケットであることが分かります。


120,000 / 128 * 8 = 117.1875
※Bc / パケット長 * 8 bit = Tc あたりに送信可能なパケット数
※輻輳がはじまった直後は Be 分を考慮 ⇒ 240,000 / 128 * 8 = 234.375

118 パケット目以降はキューイングされてキュー長の上限 64 に達すると以降のパケットはドロップされます。前述のとおりフリーのトラフィックジェネレータからは、ピーク時に約 270パケットが送信されますので、パケットドロップの発生は妥当な結果といえます。

バースト性のトラフィックによるパケットドロップは、Bc を大きい値に設定する、queue-limit を変更してキューを長くすることで、ある程度緩和することができます。

3. フリーのトラフィックジェネレータ / Tc = 1 ( パケロスなし )

ここではルータに Bc を CIR と同じ値に変更したポリシマップを適用した上で、同じフリーのトラフィックジェネレータを使って試験を行った結果を記載します。

この場合、Tc は 1s となり、ルータは 1秒おきにシェーピングレート相当のデータを送信するように動作します。

show policy-map interface

この設定ではパケットドロップが発生しないことが確認できました。

バースト耐性と遅延の関係

Tc あたりに送信可能なデータ量は、Bc を変更することで調整可能です。
各パラメータの関係は以下の式によって表されます。


Tc = Bc / CIR

試験3 の結果からも分かるように、Bc の値を大きくすることでバーストトラフィックへの耐性は上がりますが、Tc の値も大きくなるためキューイングされるパケットの遅延時間は長くなります。

以下の図は 8 Kbps のシェーピングを 64 Kbps のインタフェースに適用し、Tc がそれぞれ 1s, 500ms, 125ms となるように Bc を設定した場合のバースト耐性と遅延時間の関係を示しています。

Tc = 1s の場合 1秒毎にシェーピングレート相当のデータを送信。データ送信後の待ち時間は最大 875 ms
Tc = 500ms の場合 500ms毎に4Kbpsのデータを送信。データ送信後の待ち時間は最大 437.5ms
Tc = 125ms の場合 125ms毎に1Kbpsのデータを送信。データ送信後の待ち時間は最大 109.4ms

バースト性のトラフィックのパケットドロップ対策は、バースト耐性と遅延時間がトレードオフの関係にあることを考慮した上で実施することが大切です。