非同期転送モード(ATM) : IP-ATM 間サービス クラス

ATM での均等化キューイングについて

2003 年 3 月 5 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 10 月 5 日) | フィードバック

目次


概要

この文書では、weighted fair queuing(WFQ; 均等化キューイング)テクノロジーを使用したトラフィック キューイングの概要について説明します。

WFQ は、シリアル回線などの低速リンクで、すべての種類のトラフィックを均等に処理できるようにするために導入されました。 これを実現するために、WFQ では、IP アドレスや TCP ポートなどのレイヤ 3 およびレイヤ 4 の情報をベースとして、トラフィックをさまざまなフローに分類します(会話とも呼ばれます)。 これには、アクセスリストを定義する必要はありません。 高帯域幅のトラフィックは割り当てられている重みに応じて送信メディアを共有するため、低帯域幅のトラフィックが高帯域幅のトラフィックより高い優先順を効率的に得られるようになります。

ただし、WFQ にはいくつかの制限があります。

  • フローの量がかなり多くなると、拡張性がなくなります。

  • ATM インターフェイスなどの高速インターフェイスでは、ネイティブ WFQ は使用できません。

Class-based weighted fair queuing(CBWFQ; クラスベース重み付け均等化キューイング)では、これらの制限に対する解決策が提供されています。

標準の WFQ とは異なり、CBWFQ ではトラフィック クラスを定義できます。 また、クラスを定義する他に、帯域幅やキュー制限などのパラメータを適用できます。 クラスに割り当てた帯域幅は、そのクラスの「重み」を計算するために使用されます。 また、この値からクラスの基準を満たす各パケットの重みも計算されます。 そして、WFQ は、フロー自体ではなく、クラス(複数のフローを包むことが可能)に割り当てられます。

CBWFQ の設定の詳細は、次のリンクを参照してください。

ATM インターフェイスでは、fair-queue コマンドでインターフェイス上に直接設定された「ネイティブ」のフローベース WFQ をサポートしていません。 しかし、CBWFQ(上記のリンクを参照)をサポートしているソフトウェアがあれば、次に示すように、フローベースの WFQ をデフォルトのクラスに設定できます。

policy-map test
  
   class class-default
  
    fair-queue
  
  !         
  
  interface ATMx/y.z point-to-point
  
   ip address a.b.c.d M.M.M.M
  
   pvc A/B 
  
    service-policy output test
  
  

ネットワーク ダイアグラム

WFQ の動作を詳しく説明するために、次の設定を使用します。

Network Diagram

この設定では、パケットは次の 2 つのキューのいずれかに格納することができます。

  • ポート アダプタまたはネットワーク モジュールにあるハードウェアの first in first out(FIFO; 先入れ先出し)キュー。

  • CBWFQ などの Quality of Service(QOS)機能が適用されている場合の Cisco IOS(R) ソフトウェアにあるキュー(ルータの入出力 [I/O] メモリ上)。

ポート アダプタにある FIFO キューには、パケットが送信用にセルにセグメント化される前に格納されます。 このキューがいっぱいになると、ポート アダプタまたはネットワーク モジュールから IOS ソフトウェアに対して、キューが輻輳しているという信号が出されます。 このメカニズムは、バックプレッシャと呼ばれます。 この信号を受信すると、ルータはこのインターフェイスの FIFO キューへのパケットの送信を停止し、キューの輻輳状態が緩和されるまでこのパケットを IOS ソフトウェアに保存します。 パケットが IOS に保存されているときには、システムは QOS を適用できます。

送信リングの制限の設定

このキューイング メカニズムに関連する問題の 1 つは、インターフェイス上の FIFO キューが大きいほど、このキューの最後にあるパケットが送信されるまでの遅延時間が長くなることです。 これにより、音声トラフィックなどの遅延に敏感なトラフィックには、重大なパフォーマンス問題が生じます。

permanent virtual circuit(PVC; 相手先固定接続)の tx-ring-limit コマンドを使用すると、FIFO キューの大きさを小さくすることができます。

interface ATMx/y.z point-to-point
  
   ip address a.b.c.d M.M.M.M
  
   PVC A/B 
  
    tx-ring-limit <size>
  
    service-policy output test
ここで指定できる <size> は、パケットの数(Cisco 2600 および 3600 ルータの場合)またはパーティクルの量(Cisco 7200 および 7500 の場合)になります。

送信リングのサイズを小さくすることには、次の 2 つの利点があります。

  • パケットがセグメント化されるまでの FIFO キューでの待ち時間が短くなります。

  • IOS ソフトウェアでの QOS の使用が促進されます。

送信リングの制限の影響

上記のネットワーク ダイヤグラムで示した設定を使用して、送信リングの制限の影響について説明します。 次の項目を想定します。

  • トラフィック ジェネレータからシンク デバイスにトラフィック(1500 バイトのパケット)が送られ、このトラフィックはルータ 1 とルータ 2 との間の PVC 0/102 に対して過負荷状態をもたらしています。

  • ルータ 3 からルータ 1 に ping が送られます。

  • ルータ 2 では WFQ が有効にされています。

ここで、異なる送信リングの制限を使用している 2 つの設定を調べ、その影響を見てみましょう。

例 A

この例では、送信リングを 3 に設定しています(tx-ring-limit=3)。 ここでは、ルータ 1 からルータ 3 に ping を送ったときの結果を表しています。

pound#ping ip
  
  Target IP address: 6.6.6.6
  
  Repeat count [5]: 100000
  
  Datagram size [100]: 
  
  Timeout in seconds [2]: 
  
  Extended commands [n]: 
  
  Sweep range of sizes [n]: 
  
  Type escape sequence to abort.
  
  Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
  
  Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms
  
     router2#show queue atm 4/0.102 
  
     Interface ATM4/0.102 VC 0/102 
  
     Queuing strategy: weighted fair 
  
     Total output drops per VC: 1505772 
  
     Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
  
      Conversations  2/3/16 (active/max active/max total)    
  
      Reserved Conversations 0/0 (allocated/max allocated)  
  (depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
  
     Conversation 2, linktype: ip, length: 58 
  
     source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
  
     !--- ping  
  (depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
  
     Conversation 15, linktype: ip, length: 1494 
  
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 
  
     !--- トラフィック ジェネレータからのトラフィック 
  
  

例 B

この例では、送信リングを 40 に設定しています(tx-ring-limit=40)。 例 A と同じ ping を実行したときの結果を次に示します。

pound#ping ip
  
  Target IP address: 6.6.6.6
  
  Repeat count [5]: 10000
  
  Datagram size [100]: 36
  
  Timeout in seconds [2]: 10
  
  Extended commands [n]: 
  
  Sweep range of sizes [n]: 
  
  Type escape sequence to abort.
  
  Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
  
  !!!!!!!!!!!!.
  
  Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488 ms
ここで見たように、送信リングの制限値が大きいと、ping の round-trip time(RTT; ラウンドトリップ時間)が長くなります。 このことから、送信リングの制限が大きいことにより、転送に著しい遅延が生じる場合があることが分かります。

重みの計算

上記、例 A での show queue atm の出力では、各会話に重みが割り当てられていることが分かりました。 これをさらに詳細に調べてみましょう。
   router2#show queue ATM 4/0.102 
  
     Interface ATM4/0.102 VC 0/102 
  
     Queuing strategy: weighted fair 
  
     Total output drops per VC: 1505772 
  
     Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
  
      Conversations  2/3/16 (active/max active/max total)    
  
      Reserved Conversations 0/0 (allocated/max allocated)  
  (depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
  
     Conversation 2, linktype: ip, length: 58 
  
     source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
  (depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
  
     Conversation 15, linktype: ip, length: 1494 
  
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

WFQ を使用している場合は、各会話の重みを次の式で計算できます。

重み = 32384 / (優先順位 + 1) - Cisco IOS ソフトウェア リリース 12.0(5)T 以降の場合。

重み = 4096 / (優先順位 + 1) - Cisco IOS ソフトウェア リリース 12.0(5)T 以前の場合。

スケジュール時間の計算

これらの重みを使用して、各パケットのスケジューリング時間、つまり、このパケットが IOS キューからポート アダプタまたはネットワーク モジュールの FIFO キューに転送される時間を計算することができます。–

出力のスケジューリング時間は、次の式を使って計算できます。ここで、queue_tail_time は現在のスケジューリング時間です。

出力スケジューリング時間 = queue_tail_time + パケットサイズ * 重み

WFQ の動作の仕組み

これまでに、ハードウェア FIFO キューのサイズの影響を見てきました。ここでは、WFQ が動作する仕組みについて詳しく説明します。 WFQ の原理は、小さな重みを持つパケット、すなわち「小さな」パケットが、送信されるときに優先順位を取得するというものです。

これを確認するために、10 個のパケットで構成される大きなパケットのフローと、4 つの小さなパケット(82 バイト)のフローを、トラフィック ジェネレータを使用して作成します。

この例では、ルータ 2 は PA-A3(ATM ポート アダプタ)搭載 Cisco 7200 ルータです。ポート アダプタ上の出力 FIFO キューのサイズが、パケットではなくパーティクルで表されていることは重要です。 詳細は、次の項を参照してください。

パーティクルの概要

パーティクルは、連続したメモリの一区画をバッファに割り当てるのではなく、パーティクルと呼ばれる不連続(分散した状態)なメモリ区画のいくつかをバッファに割り当てます。そしてこれらをつなぎ合わせ、論理的な 1 つのパケット バッファを形成します。 これがパーティクル バッファと呼ばれます。 このような方法では、1 つのパケットが複数のパーティクルに分けられます。

ここで使用している 7200 ルータでは、パーティクル サイズは 512 バイトになっています。

show buffers コマンドを使用すると、Cisco 7200 ルータがパーティクルを使用しているかどうかを調べることができます。

router#show buffers
  
  [snip]
  
  Private particle pools: 
  
  FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
  
    0 in free list (0 min, 400 max allowed)
  
    400 hits, 0 fallbacks
  
    400 max cache size, 271 in cache
  
  ATM2/0 buffers, 512 bytes (total 400, permanent 400): 
  
    0 in free list (0 min, 400 max allowed)
  
    400 hits, 0 fallbacks
  
    400 max cache size, 0 in cache

テスト A

いくつかのテストを行って、WFQ の機能を説明します。 最初のテストでは、個々の会話の間で帯域幅が共有されているかどうかを調べます。

このテストでは、トラフィック ジェネレータから、ルータ 1 とルータ 2 の間の PVC 0/102 が直ちに過負荷になるようなトラフィックを送信させます。 ここで、ルータ 3 からルータ 1 へ、同じ PVC を経由して ping を実行します。

pound#ping ip
  
  Target IP address: 6.6.6.6
  
  Repeat count [5]: 100000
  
  Datagram size [100]: 
  
  Timeout in seconds [2]: 
  
  Extended commands [n]: 
  
  Sweep range of sizes [n]: 
  
  Type escape sequence to abort.
  
  Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
  
  ......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]
  
  Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

ここで示した出力から分かるように、このインターフェイスで WFQ が有効にされるまで、トラフィックによって回線は占領され、他のトラフィックが通過できないようになっています。 WFQ が有効にされると、直ちに ping は成功します。

このことから、WFQ を使用すると、異なる会話の間で帯域幅が共有され、1 つの会話によって他がブロックされないことが分かります。

テスト B

次に、帯域幅が共有される仕組みを調べてみましょう。

トラフィック ジェネレータによって送信されるフローは、大きなパケット 10 個で構成されたバーストと、その後に続く 82 バイトから成る 4 つの小さなパケットです。 これをルータ 2 に対して 100 Mbps の速度で送信します。 バーストが送信されると、ルータ 2 の ATM インターフェイスの出力キューは空になります。 ルータ 2 は、これらのパケットを 10 KB の PVC(非常に低速の PVC)経由で送信するので、出力キューでは確実に輻輳が発生します。

このプロセスを分かりやすくするために、このテストを複数の段階で実行します。

第 1 段階

大きなトラフィックには、482 バイトのパケットが 10 個含まれています。 PA-A3 のパーティクルは 512 バイトであるため、各パケットは、大きなものでも小さなものでも、ポート アダプタの出力キューに格納されるときには 1 つのパーティクルを使用します。 ルータの送信リングの制限は 3 です(tx-ring-limit=3)。 次の内容が、シンク デバイス上で表示されます。

   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4 
  
     .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
  
  
     !--- この箇所で輻輳が発生しています(以下の説明とキューイング出力をご覧ください)。
  
  
  
     .Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol  

82 バイトのパケット(通常は優先権を取得)の前に、482 バイトのパケット 4 個が送信されているのが分かります。 この現象が起きる原因を見てみましょう。

まず、このバーストは 482 バイトのパケット 10 個で構成されているため、ルータに最初に到達し、その後に 82 バイトのパケットが続きます。 482 バイトのパケットは、輻輳が発生していない(トラフィックが何もない)状態では一度に到達するため、1 つのパケットは直ちにキューに入れられてポート アダプタの segmentation and reassembly(SAR)処理を受け、セルに分割されてワイヤー上に送信されます。 すなわち、送信リングはまだ空のままです。

482 バイトのパケットを送信するのにかかる時間は、トラフィック ジェネレータからすべてのバーストを送信するのにかかる時間より長いことが計算できます。 したがって、最初の 482 バイトのパケットがポート アダプタでキューされているとき、その他の 482 バイトのバーストのパケットは既にルータ上に到達しています。 よって、その他の 482 バイトのパケットは、送信リングにキューされます。 ルータ上にある 3 つの空きパーティクルを使用して、482 バイトのパケット 3 つがキューされます。

注:パケットの格納に複数のパーティクルが必要とされている場合でも、空きパーティクルが 1 つでもあれば、直ちに送信リングにパケットがキューされます。

この時点で 3 つのパーティクルがいっぱいになったため、輻輳状態になります。 したがって、IOS でのキューイングが始まります。 4 つの 82 バイトのパケットがようやくルータに到達した時点では、輻輳が発生しています。 これらの 4 つのパケットはキューイングされて、この 2 つのフローに対して WFQ が使用されます。 show queue ATM コマンドを使用して ATM キューを調べると、このことが分かります。

   router2#show queue ATM 4/0.102 vc 0/102 
  
     Interface ATM4/0.102 VC 0/102 
  
     Queuing strategy: weighted fair 
  
     Total output drops per VC: 0 
  
     Output queue: 10/512/64/0 (size/max total/threshold/drops) 
  
       Conversations  2/4/16 (active/max active/max total)    
  
       Reserved Conversations 0/0 (allocated/max allocated)  
  (depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0    
  
     Conversation 6, linktype: ip, length: 82 
  
     source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  
  (depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0    
  
     Conversation 15, linktype: ip, length: 482 
  
     source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

482 バイトの最初の 4 つのパケットの後に 82 バイトのパケットが続いていることが、このデバッグから分かります。 これらの小さなパケットは、大きなパケットより先にルータから送信されます。 このことは、輻輳が発生すると、直ちに小さなパケットに対して大きなパケットより高い優先順位が与えられることを意味しています。

必要であれば、先に示した重みやスケジューリング時間の式を使用して、これを確認することができます。

第 2 段階

送信リングの制限を 5 に増やし、大きなパケットは 482 バイトにしておくと、上で説明したように、輻輳が発生する前に 482 バイトのパケットが 6 個現れて、次に 82 バイトのパケットが 4 個続き、その後に他の 482 バイトのパケット 4 個が続くようになるはずです。

   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
  
     .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
  
     .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol  

この出力で分かるように、実際、このような現象が発生します。

第 3 段階

パーティクル サイズは 512 バイトです。 したがって、送信リングがパーティクルで表され、パーティクル サイズよりもわずかに大きいパケットを使用している場合は、各パケットによって 2 つのパーティクルが使用されます。 このことを、582 バイトのパケットと、3 つの送信リングを使用して説明します。 これらのパラメータを使用すると、582 バイトの 3 つのパケットが表示されます。 1 つはトラフィックがない状態で ATM インターフェイスに送られ、3 つのパーティクルは空のままになります。 したがって、その他の 2 つのパケットがキューイングされて、その後に 82 バイトのパケット 4 つが続き、さらにその後に 582 バイトのパケット 7 つが続きます。

   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
  
     .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
  
     .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol  

第 4 段階

ここでは、パケットのサイズを 1482(パーティクル 3 つ分)にして、5 つの送信リングを定義します。 送信リングがパーティクルで定義されている場合は、次のように表示されます。

  • 1 つのパケットが直ちに送信されます。

  • 1 つのパケットによって 5 つのパーティクルのうちの 3 つが占有されます。

  • パーティクルの空きが 2 つあるため、1 つのパケットがキューイングされます。
   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
  
     .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
  
     .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
  
     .Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
  
     .Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol  

要約

実行したテストから、次の結論が得られます。

  • WFQ のない低速の PVC では、大規模なトラフィックによって小さなトラフィックに影響が出る(ping などは WFQ が有効になるまで停止状態となるなど)。

  • 送信リングのサイズ(tx-ring-limit)により、キューイング メカニズムが動作するまでの時間が変化する。 この影響は、送信リングの制限値を上げたときに ping の RTT が増加することで分かります。 したがって、WFQ または LLQ を実装する必要がある場合は、送信リングの制限を小さくする方が合理的です。

  • CBWFQ を使用している WFQ では、小さなトラフィックに対して大きなトラフィックよりも高い優先順位が与えられる。

関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 10049