はじめに
このドキュメントでは、Catalyst 9000 シリーズ プラットフォームでの出力ドロップをトラブルシュートする方法について説明します。
前提条件
要件
Catalyst 9000 シリーズ プラットフォームで Quality of Service(QoS)をトラブルシュートするには、次のことを理解しておく必要があります。
- 標準 QoS の概念
- モジュラ QoS コマンド ライン インターフェイス(CLI)
使用するコンポーネント
このドキュメントの情報は、次のハードウェアおよびソフトウェアバージョンに基づいていますが、手法とコマンドの大部分は、他のコードの他の Catalyst 9000 シリーズ スイッチにも適用できます。
- Cisco Catalyst 9300
- Cisco IOS® XE 16.12.3
注:シスコの他のプラットフォームでこれらの機能を有効にするために使用されるコマンドについては、該当するコンフィギュレーション ガイドを参照してください。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
デフォルトの QoS 設定、キューの構造、バッファの説明を含む、Catalyst 9000 シリーズ プラットフォームの QoS の詳細については、Catalyst 9000 の QoS および Queueing White Paper を参照してください。推奨リリースガイドを確認し、そのプラットフォームに推奨されている最新のソフトウェアを使用していることを確認します。これらの推奨事項によって、ソフトウェアが確実にサポートされるようにし、古いコードの既知のバグを回避できます。 Catalyst の推奨リリース
出力ドロップとは
バッファの割り当てに関する知識は、バッファ輻輳がどのように出力ドロップを引き起こすかを理解するのに役立ちます。輻輳は、宛先インターフェイスのパケット数が出力レートを超えると発生します。これらのパケットは、送信できるようになるまでバッファに保存する必要があります。これらのスイッチには、特定用途向け集積回路(ASIC)ごとに最大 36 MB のバッファがあり、ASIC 上のすべてのポートで共有されることを考慮してください。出力インターフェイスは回線レートでそのバッファを空にすることができますが、パケットがより高いレートでバッファリングされるシナリオでは、輻輳が発生する可能性があります。トラフィックバーストが 1 秒未満の場合でも輻輳が発生する場合があり、トラフィックの遅延や、バッファが完全にいっぱいであった場合には出力ドロップを引き起こす可能性があります。
注:show interface に表示される出力ドロップカウンタは、デフォルトではバイト単位で示されます。リリース 16.9.3 以降では、これらのカウンタはデフォルトでパケットです。
輻輳の種類
図 1 に示すように、輻輳には 2 つの種類があります。

画像 1.輻輳の種類
図 1 に示す輻輳には、次の 2 つの種類があります。
- 多対 1:複数の送信元ポートが同時に 1 つの宛先にトラフィックを送信する場合、宛先ポートは複数の送信元から受信したトラフィックの量で輻輳する可能性があります。
- 速度の不一致:高速のポートが低速のポートに送信する場合(10 Gbps から 1 Gbps など)、パケットが出力ポートから排出されるのに時間がかかるため、遅延やパケットのドロップが発生する可能性があります。
低スループットでの輻輳
トラフィック バーストにより、インターフェイスの出力率が最大インターフェイス容量よりもかなり低い場合でも、出力がドロップされることがあります。デフォルトでは、show interface コマンドの出力レートは 5 分間の平均です。これは、短期間のすべてのバーストをキャプチャするために十分ではありません。平均で 30 秒以上が最適ですが、このシナリオでも、数ミリ秒のトラフィックのバーストにより、30 秒の平均レートを増加させない出力ドロップが発生する可能性があります。このドキュメントは、Catalyst 9000 シリーズ スイッチで発生するその他の種類の輻輳のトラブルシュートに使用できます。
バッファ輻輳の検証
バッファ輻輳を検証するために使用されるコマンドは 2 つあります。最初のコマンドは show platform hardware fed switch active qos queue config interface <interface>です。このコマンドを使用すると、図 2 に示すように、ポートの現在のバッファ割り当てを確認できます。
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:2 - 1800
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 7 800 19 475 0 0 3 2400
1 1 5 0 8 1200 19 712 8 300 3 2400
2 1 5 0 6 0 0 0 0 0 3 2400
3 1 5 0 6 0 0 0 0 0 3 2400
4 1 5 0 6 0 0 0 0 0 3 2400
5 1 5 0 6 0 0 0 0 0 3 2400
6 1 5 0 6 0 0 0 0 0 3 2400
7 1 5 0 6 0 0 0 0 0 3 2400
図 2. キューバッファの割り当て
特に、キューで使用可能なバッファの数を示す [Hardmax] および [Softmax] 列を確認する必要があります。これらのバッファの内容とデフォルトでの割り当て方法については、Catalyst 9000 の QoS および Queueing White Paper を参照してください。
2 番目のコマンドは show platform hardware fed switch active qos queue stats interface <interface>です。このコマンドを使用すると、インターフェイスのキューごとの統計を確認できます。これには、バッファにキューイングされたバイト数や、使用可能なバッファの不足が原因でドロップされたバイト数が含まれます。
9300#show platform hardware fed switch active qos queue stats interface Gig 1/0/1
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 384251797 0
1 0 0 0 488393930284 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 192308101 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
画像 3.ドロップを含むキューバッファ統計
図 3 に示すように、キュー 0 とキュー 1 の両方にキューイングされたバイトがありますが、[Drop-TH2] 列でドロップが発生しているのはキュー 1 です。この情報は、キュー 0 のトラフィックはこの輻輳の影響を受けておらず、輻輳の原因は特にキュー 1 のトラフィックであることを示しています。
出力ドロップを解決するためのバッファの変更
SoftMax 乗数
各キューが共有プールから要求できるバッファの数を増やすには、qos queue-softmax-multiplier <100 – 1200> の設定で SoftMax しきい値を増やします。 最大値は 1200 で、12 の倍数で増加します。これは単一のポートキューがマイクロバーストを吸収する能力です。このコマンドは、ポートキューのしきい値を増やし、ポートキューが共有プールから追加のバッファユニットを消費できるようにします。図 4 に示すのは、設定とバッファ割り当ての増加です。
9300(config)#qos queue-softmax-multiplier 1200
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 14400
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 9 9600 2 600 0 0 1 15000
1 1 5 0 10 14400 2 900 1 450 1 15000
2 1 5 0 6 0 0 0 0 0 1 15000
3 1 5 0 6 0 0 0 0 0 1 15000
4 1 5 0 6 0 0 0 0 0 1 15000
5 1 5 0 6 0 0 0 0 0 1 15000
6 1 5 0 6 0 0 0 0 0 1 15000
7 1 5 0 6 0 0 0 0 0 1 15000
図 4.SoftMax 乗数が 1200 のキュー設定
これは、出力ドロップを解決するための簡単な方法として使用される一般的な設定です。図 4 では、この設定はすべてのインターフェイスのすべての非プライオリティキューに適用されます。バッファ割り当て自体は、スイッチのすべてのポートで同時にマイクロバーストが発生しないことを前提としています。マイクロバーストがランダムな瞬間に発生した場合、共有バッファはそれらを吸収するために追加のバッファユニットを専用にすることができます。
キューごとのバッファ変更
キューごとのバッファ変更は、SoftMax 乗数を使用できないシナリオ、またはトラフィックプロファイルに合わせてバッファを微調整しようとするシナリオで利用できます。スイッチのキューバッファ割り当てをインターフェイスごとに変更するには、ポリシーマップを使用する必要があります。 ほとんどの場合、インターフェイスの現在のポリシーマップを変更し、クラスごとにバッファを変更します。
この例では、インターフェイス GigabitEthernet1/0/48 で出力ドロップが発生しています。図 5 に示すのは、このインターフェイスに適用される出力ポリシーマップです。
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
class class-default
図 5.ポリシーマップの例
このポリシーマップには 5 つのクラスマップがあるため、インターフェイスには合計 5 つの出力キューがあります。各クラスには、優先順位に基づいて割り当てられるデフォルトのバッファ数があります。
図 6 は、現在のバッファ割り当てを示しています。
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 600
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 100 9 100 0 0 0 0 3 800
1 1 7 100 10 400 19 237 0 0 3 800
2 1 5 0 10 400 19 237 8 100 3 800
3 1 5 0 10 400 19 237 8 100 3 800
4 1 5 0 10 400 19 237 8 100 3 800
5 1 5 0 6 0 0 0 0 0 3 800
6 1 5 0 6 0 0 0 0 0 3 800
7 1 5 0 6 0 0 0 0 0 3 800
図 6.サンプルポリシーを使用したキューバッファ設定
このインターフェイスでは出力ドロップが発生しているため、インターフェイスのキューイング統計を調べて、輻輳が発生している場所を確認します。
9300#show platform hardware fed switch active qos queue stats interface gigabitEthernet 1/0/48
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 489094 0
1 0 0 0 4846845 0
2 0 0 0 89498498 0
3 0 0 0 21297827045 0
4 0 0 0 74983184 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 3854484 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
図 7. サンプルポリシーによるドロップを含むキューバッファ統計
図 7 は、キュー 3 に他のどのキューよりも多くのトラフィックがキューイングされており、キュー 3 は出力ドロップが発生した唯一のキューであることを示しています。キュー番号は 0 から始まるため、キュー 3 は 4 番目のクラスマップである Data クラスにマッピングされます。
このキューでのドロップを軽減するには、キュー 3 により多くのバッファを割り当てます。このバッファ割り当てを変更するには、ポリシーマップで queue-buffers ratio <0-100> 設定を使用します。ポリシーの各クラスで設定されている場合は、合計で 100 になる必要があります。このコマンドで 1 つのクラスだけを設定すると、システムは他のキューからバッファを均等に差し引こうとします。
図 8 では、Data クラスは queue-buffers ratio 40 で設定されています。
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
queue-buffers ratio 40
図 8. キューバッファが変更されたポリシーマップの例
画像 9 では、Data クラスにインターフェイスバッファの 40%、合計 800 のバッファがあることがわかります。
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 1200
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 75 9 75 0 0 0 0 3 1600
1 1 7 75 10 300 19 178 0 0 3 1600
2 1 5 0 10 300 19 178 8 75 3 1600
3 1 5 0 7 800 19 475 8 200 3 1600
4 1 5 0 10 300 19 178 8 75 3 1600
5 1 5 0 6 0 0 0 0 0 3 1600
6 1 5 0 6 0 0 0 0 0 3 1600
7 1 5 0 6 0 0 0 0 0 3 1600
図 9. 更新されたサンプルポリシーを使用したキューバッファ設定
これにより、他のキューの Softmax バッファも少なくなります。変更によって他のキューで出力ドロップが発生しないように、これらのバッファの変更は少しずつ行うことが重要です。
変更後、キューの統計をチェックし、このキューまたは他のキューでドロップがまだ増加しているかどうかを確認します。ドロップが続く場合は、出力ドロップが解決されるまで queue-buffer 設定をさらに変更します。
輻輳を管理するための代替メソッド
QoS は主にトラフィックに優先順位を付けるメソッドであり、すべての出力ドロップシナリオのソリューションではありません。キューバッファを変更しても、すべての出力ドロップを解決できないシナリオもあります。そのようなシナリオでは、他のいくつかの方法で輻輳を管理できます。
これには、ポートチャネルや Equal Cost Multipath(ECMP; 等コストマルチパス)などの出力帯域幅を増やすメソッドが含まれますが、トラフィック エンジニアリングなどのより複雑な設定が必要になる場合もあります。
- キューイングスケジューラを使用して、トラフィックに優先順位を付ける。
キュースケジューラによって輻輳が停止することはありませんが、重要なトラフィックが輻輳の影響を受けなくなります。
- 重み付けランダム早期廃棄(WRED)や重み付けテールドロップ(WTD)などの輻輳管理アルゴリズムを使用して、トラフィックの一部を早期にドロップする。
- 入力のトラフィックをポリシングして、出力のトラフィックを減らす。
Wireshark を使用した出力ドロップの分析
Wireshark は、バッファの輻輳やドロップの原因となるトラフィックのバーストを特定するのに役立つツールです。 ドロップが発生しているときに出力方向のインターフェイスに対して Switched Port Analyzer(SPAN; スイッチドポートアナライザ)を実行すると、Wireshark が出力レートをグラフ化し、ドロップのトリガーとなったトラフィックとそのタイミングを確認できます。これは特に、低スループットのシナリオで出力ドロップを特定する場合に役立ちます。
入出力(I/O)レートの表示
Wireshark で SPAN キャプチャを開いたら、図 10 に示すように、[統計(Statistics)] を選択して [I/Oグラフ(I/O Graph)] を選択します。

図 10.I/O グラフの選択
これを選択すると、Wireshark はトラフィックのグラフを 1 秒あたりのビット数で生成します。図 11 は、出力ドロップが発生したインターフェイスのグラフの例を示しています。

図 11.I/O グラフ ビット/ミリ秒
図 11 のグラフは、インターフェイスの最大スループットが 80 Mbps をわずかに超えていたことを示しています。デフォルトのグラフビューは、パケットドロップの原因となるトラフィックの小さなバーストを特定できるほど詳細ではありません。これは、1 秒あたりのトラフィック レートの平均です。このレートがバッファの輻輳をどのように引き起こすかを理解するために、ミリ秒スケールでのスループットを考えてみましょう。
ギガビットインターフェイスは、1,000,000,000 ビット/秒で転送できます。ミリ秒に変換すると、1,000,000(または 10^6)ビット/ミリ秒に相当します。
インターフェイスのレートがインターフェイスの転送速度を超えると、スイッチはこれらのパケットをバッファリングする必要があり、輻輳と出力ドロップが発生します。
ミリ秒単位での入出力(I/O)レートの表示
Wireshark を使用すると、ユーザーは入出力(I/O)レートを 1 ミリ秒あたりのビット数としてグラフ化できます。これを行うには、[間隔(Interval)] を 1 秒から 1 ミリ秒に短縮し、[リセット(Reset)] をクリックしてグラフを適切に表示します。この手順を図 12 に示します。

図 12.間隔を 1 ミリ秒に短縮し、グラフをリセットする
更新されたグラフは、インターフェイスの実際の入出力(I/O)レートをより正確に表示します。レートが 10^6 ビット/ミリ秒以上の場合、スイッチで輻輳または出力ドロップが発生します。 図 13 は、出力ドロップが発生したインターフェイスの更新された入出力(I/O)グラフを示しています。

図 13.I/O グラフ ビット/ミリ秒
図 13 は、10^6 のしきい値以上のトラフィックのピークが複数あることを示しています。トラフィックはバッファリングの対象となり、出力バッファサイズを超えるとドロップされます。
注:SPAN の宛先が 1 Gbps インターフェイスで接続されている場合、送信元インターフェイスのレートに関係なく、Wireshark の入出力(I/O)レートは 10^6 ビット/ミリ秒を超えることはできません。SPAN の宛先インターフェイスは、代わりにこれらのパケットをバッファリングまたはドロップします。入出力(I/O)グラフがその最大スループットで横ばいになることや、平均トラフィックレートが上昇していくように見えることはよくあります。