Ciscoスイッチインターフェイスで合計出力ドロップが発生する原因は何ですか？

ios 12.2（58）SE1を実行しているCisco 3120XおよびCisco 3120Gスイッチを含むHP c7000ブレードシャーシがあります。ブレード自体の負荷は非常に軽いのですが、シャーシ内の異なるブレードスイッチの多くのインターフェイスでは、かなりの数の出力ドロップが発生しています。出力ドロップの数を繰り返し確認すると、カウンターが増加するだけでなく、減少することもあります。番号は、インターフェイスに記録されたパケットとは相関しません。QoS設定はプラットフォームのデフォルトです。

次のサンプルはすべて30秒以内に取得されました。

bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力ドロップ：2255550
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：451110
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：451110
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：902220
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：1353330
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：1804440
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：1804440
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：1804440
bc1019-3120-stack> sh int gi2 / 0/7 | 出力が落ちる
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：451490

bc1019-3120-stack> sh int gi2 / 0/7 | 出力レート
  5分間の出力レート301000ビット/秒、119パケット/秒

1）サーバーnicが十分に速くフレームを受信しないことに加えて、出力ドロップを引き起こす可能性のあるものは他にありますか？

2）インターフェイスカウンターが記録できる出力ドロップの最大数は？最大値に達するとロールオーバーしますか？

3）健全な出力低下率とは何ですか？

誰かがカウンターをクリアしていない限り、走行距離計タイプのカウンター（パケットアクションに基づいて増加するもの）が減少することはありません。常に増加するはずです。その部分はバグのように聞こえます。

特に出力が低下する原因については、非常に多くの異なる原因があるため、正確に特定することは非常に困難です。スイッチのバックプレーン内で輻輳が発生する場合があり、出力インターフェイスで出力が低下するとそれらが表示される場合があります。まれに、1分間隔でポーリングしても表示されないマイクロバーストが発生し、インターフェイスがすぐに過負荷になりますが、その後すぐにドロップダウンします。出力ドロップのSNMP OIDを取得してグラフ化し、CLIカウンターに対応する方法を確認することをお勧めします。

一般的に、宛先に到達しなかったパケットを示すため、出力ドロップは望ましくありません。ただし、リンクをホットに実行している場合（そうではないと言います）は、主に内部スイッチのバッファリングなどにより、ある程度回避できません。

私の最初の考えはユニキャストフラッディングです。特に、同じVLAN内の複数のポートでカウンタが同時に増加する場合です。私は、カウンターのデクリメントがバグのように聞こえるという点でアーロンに同意します。カウンタはおそらく2 ^ 64でロールオーバーしますが、それは数秒以内には起こりません。出力ドロップの健全なレートはゼロであると考えますが、これは現実的ではありません。データセンターでもです。10Gアップリンクを実行していますか？

バグCSCtq86186がヒットしているようです。このバグは3750、2960で発見されましたが、ブレードスイッチにも影響している可能性があります。

ユニキャストフラッディングが発生している場合、ホストの1つでWiresharkを実行するか、ポートの1つにスパンすると、すぐにそれが表示されます。

スクエアトポロジに冗長コアがあるようですね。その場合、このコマンドをVLANインターフェイスに追加してみてください。

arp timeout 300

CAMテーブルはエントリを5分間保持し、ARPテーブルは4時間保持されます（デフォルト）。ARPをCAMと一致するように設定すると、CPUがわずかに増加する代わりに、ユニキャストフラッディングが解消される場合があります。 Catalyst 6500/6000スイッチのARPまたはCAMテーブルの問題のトラブルシューティング

出力ドロップは、バーストによってバッファが枯渇するため、小さなバッファを持つ小さなスイッチではかなり一般的です。私は3120にあまり詳しくないので、そのバッファーのサイズについて話すことはできませんが、少なくともそれが出力ドロップを得るまでの一般的な理由です。

具体的な理由は、複数の送信元ポートが1つの宛先に送信するため、輻輳が発生するヘッドオブラインブロッキング（HOLB）です。もう1つの一般的な理由は、より高いポート速度からより低いポート速度、つまり10Gから1Gまたは40Gから10Gに移行する場合です。

Xがポートであるshow controllers ethernet-controller Xを実行することをお勧めします。ネットワーク全体で一貫したMTUが存在しない場合に発生する可能性がある、大きなフレームへの出力の試行など、出力ドロップに関する情報を取得する必要があります。