シリアルインターフェイスでの出力ドロップ：キューイングまたは出力キューサイズの改善

eBGPを複数のキャリアに、iBGPを相互に通信するインターネットエッジルーターでは、LANおよびWAN側のすべてのインターフェイスはGEです。ただし、各ルーターに1つのシリアルフルDS3（〜45Mbps）があります。シリアルインターフェイス（3〜10 Mbpsの範囲）で多くのトラフィックを送信することはほとんどないと思いますが、一定の出力キュードロップ（OQD）が発生します。 負荷間隔が30秒の最小値であり、SNMPポーリングが5分間のトラフィックを平均化しているため、バースト性を明らかにしないため、実際にはバースト性のトラフィックが存在しないという説明はありますか？

プラットフォームはCisco 7204VXR NPE-G2です。シリアルキューイングはfifoです。

Serial1 / 0はアップ、ラインプロトコルはアップ
  ハードウェアはM2T-T3 + pa
  説明：-removed-
  インターネットアドレスはabcd / 30です
  MTU 4470バイト、BW 44210 Kビット、DLY 200 usec、
     信頼性255/255、txload 5/255、rxload 1/255
  カプセル化HDLC、CRC 16、ループバックが設定されていません
  キープアライブセット（10秒）
  再起動遅延は0秒です
  最後の入力00:00:02、出力00:00:00、出力がハングすることはありません
  「show interface」カウンターの最後のクリア00:35:19
  入力キュー：0/75/0/0（サイズ/最大/ドロップ/フラッシュ）; 総出力低下：36
  キューイング戦略：fifo
  出力キュー：0/40（サイズ/最大）
  30秒の入力レート260000ビット/秒、208パケット/秒
  30秒の出力レート939000ビット/秒、288パケット/秒
     410638パケット入力、52410388バイト、0バッファーなし
     212個のブロードキャスト、0個のラント、0個のジャイアント、0個のスロットルを受信しました
              パリティなし
     入力エラー0、CRC 0、フレーム0、オーバーラン0、無視0、中止0
     515752パケット出力、139195019バイト、0アンダーラン
     0出力エラー、0アップリケ、0インターフェイスリセット
     0出力バッファ障害、0出力バッファ交換
     0キャリア遷移
   rxLOS非アクティブ、rxLOF非アクティブ、rxAIS非アクティブ
   txAIS非アクティブ、rxRAI非アクティブ、txRAI非アクティブ

24時間後、何千ものOQDが表示されます。毎日午前3時頃にトラフィックを増やしているので、ここにバースト性のトラフィックがあるかもしれません。

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

DS3でより多くのアウトバウンドトラフィックをプッシュしたいのですが、OQDに関する心配はしません。DS3の背後にあるティア2 ISPには、6つ以上のティア1とのピアリングポイントを兼ねたPOPがあります。そのため、そのトラフィックは、ティア1であるGEのプライマリISPとは対照的に、クライアントのできるだけ早くオンネットでトラフィックを取得することです、ただし、ピアリング交換に向けて努力する必要があります。着信トラフィックは問題になりません。

この状況でfifoよりも優れたキューイング戦略はありますか？ 入力および出力キュードロップに関するシスコのドキュメントを見ると、パケットがすでにルーター上にあるため、送信キューサイズを増やすことはお勧めできません。GEリンクには十分な帯域幅があるため、入力を実際に調整する必要はありません。 これらのルーターにはポリシーマップがありません。アウトバウンドトラフィックの90％はHTTPレスポンスからのものです。残りのほとんどはFTPとSMTPからのものです。GEリンクは50-200 + Mbpsをプッシュします。

出力キューサイズバッファの調整を推奨しますか？これらのシリアルインターフェースはバックアップリンクであり、前述の理由（有効な場合）でより多く利用しますが、そのシリアルインターフェースに負荷をかけないようにするBGPポリシーで調整します（ほとんどの場合、負荷が非常に低いようです）。

あなたは正しい、あなたは実際にSNMPでバースト性を簡単に見ることはないだろう。1GEは1.48Mppsを送信できるため、75Mbps未満を処理できる45Mbpsを輻輳させるのにごくわずかな時間しかかかりません。

入力が1GEで出力が45Mbpsの場合、明らかに45Mbpsの輻輳ポイントはパケットをドロップする必要があります。これは正常で予想されることです。バッファを増やすと、遅延が増えます。
1GEが40個の1500B IPフレームを送信するのに0.45msかかります。これは現在、処理可能なバースト量です。ただし、それらを45Mbpsでデキューするには、すでに10ミリ秒かかります。

深刻な問題がない場合は、おそらく何もしません。ただし、一部のトラフィックが他のトラフィックよりもドロップに適している場合は、FIFOをクラスベースのキューイングに置き換える必要があります。より多くのftpがドロップされ、voipが少なくなるように優先順位を付けたいと思うかもしれません。
また、実際には遅延の影響を受けにくいため、ftpトラフィックにバッファリングを追加することも意味があります。

より深いバッファで運試しをしたい場合は、次のようなもので十分です。

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

これにより、Serial1で50ミリ秒のバッファーが発生し、単一のGigeインターフェイスから最大2.25ミリ秒のバーストを処理できます。

OQDは通常、次の2つのいずれかによって発生します。

1. リンクを使いすぎています。一定の高い使用率またはバーストトラフィックのいずれか。

2. ポリシングまたはトラフィックの一部またはすべてのシェーピングなどを行うように設定されたインターフェイスにポリシーマップが適用されている

3. インターフェイスに何らかのエラーがあります。エラーカウンター（show interface Serial1/0 counters errors）を見て、エラーが原因でパケットがドロップされていないことを確認してください。

ポリシーマップを配置して、ミッションクリティカルなトラフィックに独自のキューを与えたり、通常のトラフィックの輻輳回避（WRED）を有効にしたり、トラフィックのフェアキューイングを有効にしたりすることもできます（まだ取得していない場合）。インターフェイスを送信するフロー間で帯域幅が共有されること。

既に述べたように、別のオプションはインターフェイスの出力キューサイズを増やすことですが、ポリシーマップを使用する場合、ポリシーは他のサブキューを作成するため、とにかくこれは必要ありません。