WAN : フレーム リレー

フレームリレー トラフィック シェーピングの設定

2016 年 6 月 18 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2010 年 12 月 10 日) | 英語版 (2015 年 12 月 19 日) | フィードバック


目次


概要

このドキュメントでは、フレームリレー トラフィック シェーピングの設定例を紹介します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

フレーム リレー トラフィック シェーピングは Cisco IOS 以来サポートされていましたか。 ソフトウェア リリース 11.2。

これは、Cisco 7200 ルータとその下位のプラットフォームでサポートされています。 分散型トラフィック シェーピングは、Cisco 7500 ルータ、7600 ルータ、FlexWAN モジュールでサポートされています。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

フレームリレー トラフィック シェーピングの一般的な実装には次のものがあります。

  1. 高速から低速への回線ミスマッチ: 次の 2 つの場合があります。

    • ハブ サイトにはクラウドへの T1 回線があり、一方でリモート サイトはそれよりも低い速度(56 Kbps)になっています。 この場合、ハブ サイトのレートに制限を設け、リモート側のアクセス レートを超過しないように設定する必要があります。

    • ハブ サイトにはクラウドへの単一の T1 回線があり、一方でリモート サイトにもクラウドへの 1 つのフル T1 回線があって、同じハブ サイトに接続されています。 この場合は、ハブをオーバーランさせないようにリモート サイトのレートを制限する必要があります。

  2. オーバーサブスクリプション(加入過多): たとえば、Permanent Virtual Circuit(PVC; 相手先固定接続)の保証レートが 64 Kbps であり、アクセス レートが両端で 128 Kbps である場合、輻輳がないときには保証レートを超えてバーストする可能性があり、輻輳があるときには保証レートにフォール バックする可能性があります。

  3. 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 ツールを使用してください。

ネットワーク図

このドキュメントでは、次のネットワーク構成を使用しています。

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151.gif

上記の例では、次の値が設定されています。

  • 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 ルータから外部に送信されるトラフィックを示しています。

http://www.cisco.com/c/dam/en/us/support/docs/wan/frame-relay/6151-traffic-shaping-6151a.gif

トラフィックが 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 コマンドは、Output Interpreter Tool登録ユーザ専用)によってサポートされています。このツールを使用すると、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

shaping inactive / active

これは、トラフィック シェーピング メカニズムが起動されているかどうかをリアルタイムで示します。 トラフィック シェーピングは次のシナリオでアクティブになります。

  1. BECN が受信され、BECN をシェーピングするために DLCI が設定されている。

  2. インターフェイスから送信されるデータ バイト数は、指定された間隔(Tc)で利用可能なクレジット(バイト制限)を超えている。

  3. FRF.12 フラグメンテーションが設定され、パケットがフラグメント化されるのを待機している。

pkts delayed / bytes delayed

これは、トラフィック シェーピング メカニズムの起動のために遅延されたパケット数とバイト数を示します。 これは主に送信予定のバイト数が間隔ごとの利用可能なクレジットを上回る場合や、パケットがフラグメント化(FRF.12)される必要がある場合に適用されます。 これらのパケットやバイトはシェーピング キュー(VC によって割り当てられる)に格納された後、十分に利用可能なクレジットがあるときにはその後の間隔で送信されます。

traffic shaping drops

これはシェーピング キューにおける廃棄数を示します。 バイトはまずシェーピング メカニズムによって遅延され、このキューに格納されます。 キューがいっぱいになると、パケットは廃棄されます。 デフォルトでは、キュー タイプは First Come First Serve(FCFS; 先着順処理)または FIFO ですが、WFQ、PQ、CQ、CBWFQ、または LLQ に変更することもできます。 フレーム リレー PVC の豪華なキューイング メカニズムの設定の文書については「関連情報」セクションを参照して下さい。

設定可能なパラメータ

frame relay cir

指定された PVC にトラフィックを送信する bps 単位の平均レートです。 これは、一般に保証レートよりも速いものの、Access Rate(AR; アクセス レート)よりは遅くなります。 これは次の場合にだけ保証レートと同じになります。

  1. サービス プロバイダーが保証レート以上の速さでの送信を認めていない場合。

  2. インターフェイスでの物理回線のレートが保証レートに等しい場合。

  3. この PVC に Voice(Voice over IP(VOIP)または Voice over Frame Relay(VOFR))パケットが存在するため、QoS 用に廃棄したパケットを持つ余裕がない。

CIR のデフォルト値は 56000 bps です。

frame relay mincir

サービス プロバイダーから得られた実際の保証レート(bps 単位)。 この値は、輻輳が発生した際に減速する場合の最低レートです(このレート以下に減速すると、料金に見合う帯域幅が供給されていないことを意味します)。 特定の場合(前述の場合)、mincir 値と cir 値を同じにする必要があります。 mincir の値は、デフォルトで bps 単位で CIR 値の半分です。

frame relay bc

各 Tc 間隔ごとにビット単位で送信するデータ量です。 Tc = 125 ミリ秒になるには、理想的にはデータ PVC に対して Bc = CIR/8 です。 Cisco IOS は、Bc が 10,000 バイトよりも多いときに FRTS パラメータを再計算します。 PVC 上で音声を扱っている場合、Bc = CIR/100 が望ましいので、間隔は Tc = 10 ミリ秒になります(音声パケットが長い遅延を許容できないため)。 デフォルトの Bc の値は、show traffic-shape コマンドの出力でビット単位の CIR として示されます。 ただし、内部では、最適のパフォーマンスを確実にするために異なる値が割り当てられます。 この値は show traffic-shape 出力の「Increment Bytes」カラムに示されます。 bc=CIR の値は 1 秒の Tc と同じです。 シェーパーにトラフィックがどのように到着するかに従い、間隔の開始時に即座にバーストが枯渇した場合、ルータは 1 に近い送信を停止しなければならなくなります。 つまり、シェーパーは設定された Bc に対してオリジナルの Tc 経由で許容する異なる間隔を割り当て、1 つの大きなバーストではなく、小さないくつものバースト内で行うだけになります。

frame relay be

クレジットが構築された後、最初の Tc 間隔中に送信することを許可される過剰データの量です。 フレームリレー CIR の値が AR より小さい場合にだけ、Be を設定してください。 音声パケットを伝送する最良音声クオリティを確認するために PVC に関してはあはゼロに設定する必要があります。 ルータは、トークン バケット内にトークンが存在するときにだけバースト(Be)します。 トークン バケットは、送出されるトラフィックの量が CIR よりも少なくなる場合を除いて、トークンを発生させません。 ルータは、トークン バケットが空になる最初の Tc に対してだけバーストできます。 Be のデフォルト値は 0 ビットです。

frame relay adaptive-shaping becn

受信された BECN に応答して PVC が送信レートを採用することを示します。 その動作は次のとおりです。

  • 現在の時間間隔中に PVC が BECN を受信した場合(これが 1 であるか 1000 であるかは問題にならない)、送信レートが 25% 下がるか mincir まで下がり、mincir の設定された値が回線の値の 75% よりも上である場合は停止します。

  • トラフィック レートが停止した場所で mincir(保証レート)を取得するまで、各 BECN(時間間隔ごとの 1 つの廃棄の制限)での廃棄を続行します。

  • トラフィック レートが下げられると、再度トラフィック レートを上げ始める前には BECN を受信しない時間間隔を 16 回許可する必要があります。 増加単位の量は、16 で割られる show frame pvc x 出力に示されるバイト制限です。 この増加は、トラフィック シェーピングがアクティブな場合にだけ発生します。 したがって、CIR に再び達するには、mincir まで下げられたときよりも長い時間がかかります。

設定不可能なパラメータ

interval (Tc)

CIR の秒単位の平均レートを維持するために Bc ビットを送信する間の間隔です。

Tc = Bc/CIR in seconds

Tc の範囲は、10 ミリ秒から 125 ミリ秒の間です。 ルータは、マップ クラスの CIR 値と Bc 値に基づいて、この値を内部で計算します。 Bc/CIR が 125 ミリ秒以上の場合、内蔵されている Tc の値が使用されます。 Bc/CIR が 125 ミリ秒よりも小さい場合は、この式から算出された Tc が使用されます。

byte increment

Tc ごとに送信されるコミットされている実際のバイト数です。 次の式を使って計算できます。

Cir * Tc / 8

バイト制限

最初の Tc で送信される実際のバイト数です。 次の式を使って計算できます。

byte increment + Be/8 (measured in bytes)

トラブルシューティング

現在のところ、この設定に関する特定のトラブルシューティング情報はありません。

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

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


関連情報


Document ID: 6151