本書では、フレーム リレー トラフィック シェーピングの設定例を示します。
このドキュメントに関しては個別の前提条件はありません。
フレームリレー トラフィック シェーピングは、Cisco IOS® ソフトウェア リリース 11.2 からサポートされています。
これは、Cisco 7200 ルータとその下位のプラットフォームでサポートされています。分散型トラフィック シェーピングは、Cisco 7500 ルータ、7600 ルータ、FlexWAN モジュールでサポートされています。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
フレームリレー トラフィック シェーピングの一般的な実装には次のものがあります。
高速から低速への回線ミスマッチ:次の 2 つの場合があります。
ハブ サイトにはクラウドへの T1 回線があり、一方でリモート サイトはそれよりも低い速度(56 Kbps)になっています。 この場合、ハブ サイトのレートに制限を設け、リモート側のアクセス レートを超過しないように設定する必要があります。
ハブ サイトにはクラウドへの単一の T1 回線があり、一方でリモート サイトにもクラウドへの 1 つのフル T1 回線があって、同じハブ サイトに接続されています。この場合は、ハブをオーバーランさせないようにリモート サイトのレートを制限する必要があります。
オーバーサブスクリプション(加入過多):たとえば、Permanent Virtual Circuit(PVC; 相手先固定接続)の保証レートが 64 Kbps であり、アクセス レートが両端で 128 Kbps である場合、輻輳がないときには保証レートを超えてバーストする可能性があり、輻輳があるときには保証レートにフォール バックする可能性があります。
Quality of Service:より良い QoS を達成するために FRF.12 フラグメンテーションまたは低遅延キューイング機能を実装するには、『QoS(フラグメンテーション、トラフィック シェーピング、LLQ / IP RTP プライオリティ)が備わった VoIP over Frame Relay』を参照してください。
注:アクセスレートは、フレームリレーに接続するインターフェイスの物理回線速度です。保証レートとは、電話会社が PVC に提供している Committed Information Rate(CIR; 認定情報レート)です。CIR または minCIR をアクセス レートに設定することは、出力廃棄になる可能性があり、トラフィックを抑制させる原因になるので、回避します。この理由は、シェイプ レートがフラグ フィールドと Cyclic Redundancy Check(CRC; 巡回冗長検査)フィールドのオーバーヘッド バイトを考慮していないためです。そのため、回線レートでのシェーピングが実際にオーバーサブスクライブ(加入過多)しており、それがインターフェイス輻輳の原因になります。アクセス レートのシェーピングは推奨されません。トラフィックは、常にアクセス レートの 95% にシェーピングする必要があります。さらに、一般的に、集約シェーピング レートは、アクセス レートの 95% を超えないようにします。
このセクションでは、このドキュメントで説明する機能を設定するために必要な情報を提供しています。
注:このドキュメントで使用されているコマンドの詳細を調べるには、IOS Command Lookup toolを使用してください
このドキュメントでは、次のネットワーク セットアップを使用します。
上記の例では、次の値が設定されています。
HUB:アクセス レート = 192 Kbps、保証レート = 32 Kbps
REMOTE:アクセス レート = 64 Kbps、保証レート = 32 Kbps
ここでは、平均送信レートが 64 Kbps になるように、両端でトラフィック シェーピングを実装しています。必要な場合は、HUB はこれよりも上でバーストできます。輻輳が発生した場合、最低で 32 Kbps まで低速にすることができます。クラウドからの輻輳通知は、Backward Explicit Congestion Notification(BECN; 逆方向明示的輻輳通知)経由になります。 つまり、シェーピングは BECN に適合するように設定されています。
注:フレームリレートラフィックシェーピングはメインインターフェイスで有効になっており、そのインターフェイスの下にあるすべてのData Link Connection Identifier(DLCI;データリンク接続識別子)に適用されます。メインインターフェイスの下にある特定の DLCI またはサブインターフェイスだけに対してトラフィック シェーピングを有効にすることはできません。特定の DLCI にマップ クラスが何も添付されておらず、トラフィック シェーピングがメイン インターフェイスで有効になっている場合、DLCI には CIR = 56000 のデフォルト マップ クラスが割り当てられます。
このドキュメントでは、次の構成を使用します。
ハブ
Remote
ハブ |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping !--- Apply traffic shaping to main interface (step 3). interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco !--- Apply map class to the DLCI / subinterface (step 2). ! ! !--- Configure map class parameters (step 1). map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 frame-relay be 16000 ! |
Remote |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.1.1.2 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco ! map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 ! |
次の図は、HUB ルータから外部に送信されるトラフィックを示しています。
トラフィックが 80000 ビットのバーストで送信されると仮定すると、これは 8 Tc 間隔(それぞれ 125 ミリ秒)で PVC から送信されます。 最初の間隔で利用可能なクレジットが Bc + Be = 8000 + 16000 = 24000 ビットなので、これは達成できます。つまり、レートが 24000 ビット / 125 ミリ秒 = 192 Kbps であることを意味します。
次の 7 つの間隔では、処理可能量は Bc = 8000 ビットだけになります。したがって、レートは 8000 / 125 ミリ秒 = 64 Kbps です。
たとえば、88000 ビットのバーストを受信する場合、8 Tc 間隔でこのトラフィックすべてを送信することはできません。最後の 8000 ビットは 9 番目の Tc 間隔で送信されます。したがって、このトラフィックは、トラフィック シェーピングのメカニズムによって遅延が生じます。
ここでは、設定が正しく機能していることを確認するために使用する情報を示します。
一部の show コマンドはアウトプット インタープリタ ツールによってサポートされています(登録ユーザ専用)。このツールを使用することによって、show コマンド出力の分析結果を表示できます。
次のように、show frame relay pvc <dlci> コマンドを使用して設定の詳細を表示します。
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
これは、トラフィック シェーピング メカニズムが起動されているかどうかをリアルタイムで示します。トラフィック シェーピングは次のシナリオでアクティブになります。
BECN が受信され、BECN をシェーピングするために DLCI が設定されている。
インターフェイスから送信されるデータ バイト数は、指定された間隔(Tc)で利用可能なクレジット(バイト制限)を超えている。
FRF.12 フラグメンテーションが設定され、パケットがフラグメント化されるのを待機している。
これは、トラフィック シェーピング メカニズムの起動のために遅延されたパケット数とバイト数を示します。これは主に送信予定のバイト数が間隔ごとの利用可能なクレジットを上回る場合や、パケットがフラグメント化(FRF.12)される必要がある場合に適用されます。 これらのパケットやバイトはシェーピング キュー(VC によって割り当てられる)に格納された後、十分に利用可能なクレジットがあるときにはその後の間隔で送信されます。
これはシェーピング キューにおける廃棄数を示します。バイトはまずシェーピング メカニズムによって遅延され、このキューに格納されます。キューがいっぱいになると、パケットは廃棄されます。デフォルトでは、キュー タイプは First Come First Serve(FCFS; 先着順処理)または FIFO ですが、WFQ、PQ、CQ、CBWFQ、または LLQ に変更することもできます。詳細については、「関連情報」を参照してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
31-May-2005 |
初版 |