ダウンロード |
| ライター翻訳版 - June 1, 2002 |
| 機械翻訳版 - May 31, 2005 |
| 英語版 - May 31, 2005 |
| Document ID: 6151 |
目次
概要
この文書では、フレームリレー トラフィック シェーピングの設定例を紹介します。フレームリレー トラフィック シェーピングには、一般的に次のような場合に実装されます。
- 高速回線と低速回線のミスマッチ。次の 2 つの場合があります。
- センターサイトへは T1 回線が敷設されているが、リモート サイトの回線は低速（56 Kbps）である場合。この場合、中心サイトのレートに制限を設け、リモート側のアクセス レートを超過しないように設定する必要があります。
- センターサイトへは T1 回線が 1 本しかないが、複数のリモート サイトが T1 回線を持ち、同じ中心サイトに接続されている場合。この場合、センターサイトがオーバーランの状態にならないように、リモート サイトのレートを制限します。
- Oversubscription。たとえば、ある permanent virtual circuit（PVC、相手先固定接続）で保証されているレートが 64Kbps で、両端でのアクセス レートが 128Kbps である場合、輻輳が発生しないときに上記の保証レートがバースト状態になり、輻輳が発生したときに保証レートに戻る可能性があります。
- QOS。ある特定のパケット フローを確保できるためのより良い QOS を実現するために、FRF.12 フラグメンテーションまたは低遅延キューイング機能を実装。
注：アクセス レートとは、フレームリレーに接続されているインターフェイスの物理回線の速度です。保証帯域とは、通信事業者 が PVC に提供している committed information rate（CIR; 認定情報レート）です。
ハードウェアおよびソフトウェアのバージョン
フレームリレー トラフィック シェーピングは、Cisco IOS(R) Software Release 11.2 からサポートされています。
また、この機能は Cisco 7200 ルータおよびローエンドのプラットフォームでサポートされています（Cisco 7500 ルータの場合、ディストリビューテッドトラフィック シェーピングがサポートされています）。
ネットワーク ダイアグラム
上記の例では、次の値が設定されています。
- HUB - 物理レート = 192Kbps、保証レート = 32Kbps
- REMOTE - 物理レート = 64Kbps、保証レート = 32Kbps
ここで、平均的な送信レートが64kbpsになるように両端でトラフィックシェーピングを実装します。可能であれば、HUB は上記速度を超えたバースト値での送信が可能です。輻輳が発生した場合は、最低で 32Kbps まで減速できます。クラウドからの輻輳通知は、backward explicit congestion notification（BECN; 逆方向明示的輻輳通知）を介して行われます。つまり、シェーピングは BECN に適合するように設定されています。
注：フレームリレー トラフィック シェーピングは、メインインターフェイスで有効にされ、そのインターフェイスの下位にあるすべての DLCI に適用されます。メインインターフェイスの下にある特定の DLCI またはサブインターフェイスだけに対してトラフィック シェーピングを有効にすることはできません。ある DLCI に割り当てられたマップクラスがない場合、トラフィック シェーピングはメインインターフェイスで有効にされ、その DLCI にはデフォルトの CIR = 56000 のマップクラスが割り当てられます。
設定
次の図では、HUB ルータから送信されているトラフィックを示しています。
80000 ビットのトラフィックを送信すると仮定した場合、8 Tc 間隔でPVC から（125 ミリ秒ごとに）送信されます。最初の間隔においては Bc + Be = 8000 + 16000 = 24000 ビットまで使用できるため、この速度が実現されます。これは、レートが 24000 ビット / 125 ミリ秒 = 192Kbps であることを意味しています。
次の 7 つの間隔は、 Bc = 8000 ビットのみ送出されます。したがって、レートは 8000 / 125 ミリ秒 = 64Kbps になります。
たとえば、88000 ビットのバーストトラフィックを受信した場合は、このトラフィックすべてを 8 Tc 間隔で送信できません。最後の 8000 ビットは 9 番目の間隔で送信されます。したがって、このトラフィックは、トラフィック シェーピングのメカニズムによって遅延が生じます。
show コマンド
show frame relay pvc
Hub#show frame relay pvc 16
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 8743 output pkts 5 in bytes 2548330
out bytes 520 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
Shaping adapts to BECN
pvc create time 6d01h, last time pvc status changed 6d01h
cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 mincir 56000 byte increment 1000 Adaptive Shaping BECN pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued
shaping inactive / active
この行では、トラフィック シェーピングのアルゴリズムがアクティブかどうかについて、リアルタイムで表示します。トラフィック シェーピングは次の場合に有効になります。
- BECN が受信され、DLCI が BECN に適合するように設定されている。
- インターフェイスから送信されるデータのバイト数が、設定されている間隔（Tc）で使用可能なバイト数（バイトの制限）を超えている。
- FRF.12 フラグメンテーションが設定され、パケットがフラグメント化されるのを待機している。
pkts delayed / bytes delayed
この行では、トラフィック シェーピング メカニズムがアクティブ化されていることが原因で遅延が生じたパケットの数とバイト数を示しています。これは、間隔ごとに送信されるバイト数が使用可能なバイト数を超過した場合、あるいはパケットをフラグメント化する必要がある場合（FRF.12）に当てはまります。このパケットとバイトは、シェーピング キュー（VC ごとに存在）に保存され、十分なバイト数が使用できる場合に、後続の間隔を使って送信されます。
traffic shaping drops
この行では、シェーピング キューでの廃棄数を示しています。バイトはまずシェーピング メカニズムによって遅延が発生し、キューに保存されます。キューがいっぱいになると、パケットは廃棄されます。このキューのデフォルトのタイプは FCFS（First Come First Serve）または FIFO ですが、WFQ、PQ、CQ または CBWFQ にも変更できます。
設定可能なパラメータ
所定の PVC にトラフィックを送信するときの平均レート（bps 単位）。通常、この値は保証レートよりも高く、access rate（AR; アクセス レート）よりも低くします。次の場合に限り、保証レートに等しくなります。
- サービス プロバイダーが保証レート以上の速さでの送信を認めていない場合。
- インターフェイスでの物理回線のレートが保証レートに等しい場合。
- PVC 上で音声（voice over IP [VOIP] または voice over Frame Relay [VOFR]）パケットが送信されており、QOS のためにパケットを廃棄できない場合。
CIR のデフォルト値は 56000 bps です。
サービス プロバイダーから得られた実際の保証レート（bps 単位）。この値は、輻輳が発生した際に減速する場合の最低レートです（このレート以下に減速すると、料金に見合う帯域幅が与えられていないことを意味します）。ある特定の状況（上記の例）では、mincir と cir の値が等しくなります。デフォルトでは、mincir は CIR 値の半分です。
各 Tc 間隔ごとに送信されるデータの量をビットで表したものです。理想的な値は、データ PVC Bc = CIR/8 で、Tc = 125 ミリ秒です。PVC で音声通信を行っている場合は、Bc = CIR/100 が好ましい値であり、間隔 Tc = 10 ミリ秒になります（音声パケットでは長い遅延が許されないため）。Bc のデフォルト値はビットで表した CIR です。
一定のバイト数が使用可能になった場合に、最初の Tc 間隔で送信する超過データの量（ビット単位）。フレームリレー CIR の値が AR より小さい場合にだけ、Be を設定してください。PVC で音声パケットが送信されている場合、可能な限り最良の音声品質を得るには、Be を 0 に設定します。ルータは、トークン バケットにトークンがある場合にだけバースト（Be）します。トークン バケットは、送出されたトラフィックの量が CIR より小さくならない限り、トークンを蓄積しません。ルータは、トークン バケットが空になった後、最初の Tc でだけバーストできます。Be のデフォルト値は 0 ビットです。
frame relay adaptive-shaping becn
受信した BECN に対応して、PVC が送信レートを調整することを意味しています。この時の動作は次のようになります。
- PVC が最新の時間間隔で BECN を受信すると（1 でも 1000 でも関係なく）、送信レートが 25 % 下げられます。
- トラフィック レートが mincir（保証レート）になるまで、BECN ごとに減速が繰り返されます（1 回の時間間隔で減速 1 回）。
- トラフィック レートが下げられると、再度トラフィック レートを上げ始める前には BECN を受信しない時間間隔を 16 回許可する必要があります。上げられる量は、show frame pvc x の出力で見られるバイト制限値を 16 で割ったものです。レートが上げられるのは、トラフィック シェーピングがアクティブな場合だけです。したがって、CIR に再び達するには、mincir まで下げられたときよりも長い時間がかかります。
設定不可能なパラメータ
CIR の平均レートを維持するために Bc ビットを送信する時間間隔で、秒で表します。
Tc = Bc/CIR（秒）
Tc の範囲は 10 ミリ秒から 125 ミリ秒です。ルータでは、マップクラスの CIR と Bc の値からこの値を内部で計算します。Bc/CIR が 125 ミリ秒以上の場合、内蔵されている Tc の値が使用されます。Bc/CIR の値が 125 ミリ秒より小さい場合は、上記の式で計算された Tc が使用されます。
Tc ごとに送信されるコミットされている実際のバイト数です。次の式を使って計算できます。
Cir * Tc / 8
最初の Tc で送信される実際のバイト数です。次の式を使って計算できます。
byte increment + Be/8（バイト単位で測定）