この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、フレーム リレーと ATM 間のインターワーキング(IWF)でリンク フラグメンテーション アンド インターリービング(LFI)を接続する技術的概要(フレーム リレー フォーラムまたは FRF.8 実装協定に基づく)のほか、WAN クラウドで LS1010 または Catalyst 8500 を IWF デバイスとして使用するための設定例について説明します。LFI は ATM とフレーム リレー上でマルチリンク PPP(MLPPP)カプセル化の組み込みフラグメンテーション機能を使用して、帯域幅が最大 768 kbps の低速リンクにエンドツーエンド フラグメンテーションおよびインターリービング ソリューションを提供します。
このドキュメントを読むには、次の内容を理解している必要があります。
一般的な FRF.8 環境と FRF.8 のトランスペアレント モードおよび変換モード。『FRF.8 のトランスペアレント モードと変換モードについて』を参照してください。
LS1010 および Catalyst 8500 のコンフィギュレーション コマンドに精通しており、チャネル化 E1 フレーム リレー ポート アダプタまたはチャネル化 DS3 フレーム リレー ポート アダプタがフレーム リレーのエンドポイントと ATM エンドポイント間で動作する仕組みについて理解していること。
シリアライゼーション遅延とジッター。『QoSを実装したPPPリンクでのVoIP(LLQ/IP RTPプライオリティ、LFI、cRTP)』および『QoSを実装したフレームリレーでのVoIP(フラグメンテーション、トラフィックシェーピング、IP RTPプライオリティ)』を参照してください。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
フラグメンテーションは、シリアライゼーション遅延のほか、リアルタイムおよび非リアルタイムのトラフィック両方を伝送する低速リンクの遅延変動を制御するための主要な技術です。シリアライゼーション遅延とは、ネットワーク インターフェイス上に音声またはデータのフレームを送出するのに必要な固定遅延であり、トランク上のクロック レートに直接関連しています。クロック速度が低く、フレーム サイズが小さい場合には、フレームを分割するための追加フラグが必要になります。
LFI は、MLPPP に実装されたフラグメンテーション機能を使用して、比較的小さな音声パケット間でキューイングされたさまざまなサイズの大きいパケットによって生じる遅延やジッター(遅延の種類)を防止します。LFI によって、設定されたフラグメント サイズよりも大きいパケットは MLPPP ヘッダー内でカプセル化されます。RFC 1990 では、MLPPP ヘッダーのほか、以下についても定義されています。
最初のフラグメント ビット(B)は 1 ビットのフィールドであり、PPP パケットから派生した最初のフラグメントでは 1 に設定され、同じ PPP パケットのその他すべてのフラグメントでは 0 に設定されます。
最後のフラグメントビット(E)は、最後のフラグメントで1に設定され、他のすべてのフラグメントで0に設定される1ビットフィールドです。
シーケンスフィールドは24ビットまたは12ビットの数値で、フラグメントが送信されるたびに増分されます。デフォルトでは、シーケンスフィールドの長さは24ビットですが、次に説明するLCP設定オプションを使用すると、12ビットのみにネゴシエートできます。
フラグメンテーション以外でも、遅延に影響されやすいパケットの場合は、大きいパケットのフラグメントとの間で適切な優先度に基づいたスケジュール設定をする必要があります。フラグメンテーションでは、重み付け均等化キューイング(WFQ)によってパケットがフラグメントされているのか、されていないのかが「認識」されます。WFQ は着信パケットごとにシーケンス番号を割り当てて、その番号に基づきパケットのスケジュールを設定します。
レイヤ 2 フラグメンテーションは、「大きいパケットの問題」を解決するその他すべてのアプローチと比べて優れた解決策を提供します。 次の表は、その他の考えられる解決策の長所と短所を示しています。
考えられる解決策 | 長所 | 短所 |
---|---|---|
大きいパケットの送信を中断して、遅延の影響を受けやすいトラフィックの後に再度キューイングします。 |
|
|
ネットワーク レイヤ フラグメンテーション技術を使用して大きいパケットをフラグメント化します。 |
|
|
リンク レイヤ技術でパケットをフラグメント化します。 |
|
|
マルチリンク PPP over ATM(MLPPPoATM)の最適なフラグメント サイズは、ATM セルのちょうど 2 倍のサイズのフラグメントが許可される大きさである必要があります。フラグメンテーション値の選択方法については、『フレームリレーおよびATM仮想回線のためのリンク断片化およびインターリービング』を参照してください。
FRF.8 の標準的なコンフィギュレーションは、次のとおりです。
フレーム リレー エンドポイント
ATMエンドポイント
インターワーキング(IWF)デバイス
各エンドポイントは、レイヤ 2 カプセル化ヘッダー内でデータおよび音声パケットをカプセル化し、フレームまたはセル内にカプセル化されて転送されるプロトコルと通信します。フレーム リレーおよび ATM のいずれもネットワーク レイヤ プロトコル ID(NLPID)のカプセル化ヘッダーをサポートします。国際電気標準会議(IEC)の TR 9577 ドキュメントでは、いくつかのプロトコルで既知の NLPID 値が定義されています。0xCF は PPP に割り当てられています。
RFC 1973 はフレーム リレーおよび MLPPPoFR ヘッダー内の PPP を定義し、RFC 2364 は PPP over AAL5 および MLPPPoA ヘッダーを定義します。どちらのヘッダーも、NLPID値0xCFを使用して、カプセル化プロトコルとしてPPPを識別します。
図 1 に、これらのヘッダーを示します。
図 1. PPP over AAL5 ヘッダー、NLPID カプセル化を用いる MLPPPoA ヘッダー、VC 多重化を用いる MLPPPoA ヘッダー
注:MLPPPoFRヘッダーには、1バイトのフラグフィールドである0x7eも含まれています(図1には示されていません)。ヘッダーに続いて、バイト番号 5 から PPP または MLPPP プロトコル フィールドが開始されます。
表1:FRF.8トランスペアレントとFRF.8トランスレーショナルの比較。
図2. NLPIDを使用したMLPPPoATMパケットのフラグメント化方法
図 3: VC 多重化を使用した MLPPPoATM パケットをフラグメント化する方法
バイト値の意味は、次のとおりです。
0xFEFE:論理リンク制御(LLC)ヘッダー内の宛先と送信元サービス アクセス ポイント(SAP)を示します。0xFEFE の値は、続く値が短い形式の NLPID ヘッダーであることを示しています。このヘッダーは、定義された NLPID 値を持つプロトコルで使用されます。
0x03:ハイレベル データ リンク コントロール(HDLC)を含む多くのカプセル化で使用する制御フィールドです。このほか、パケット コンテンツが非番号制情報で構成されていることを示しています。
0xCF:PPP の既知の NLPID 値です。
FRF.8 実装協定では、IWF デバイスの 2 つの動作モードが定義されています。
トランスペアレント:IWF デバイスはカプセル化ヘッダーを変更せずに転送します。プロトコルヘッダーのマッピング、フラグメンテーション、または再構成は実行されません。
変換:IWF デバイスは、カプセル化タイプのわずかな違いも考慮できるように、2 つのカプセル化ヘッダー間でプロトコル ヘッダー マッピングを実行します。
IWFデバイスで設定されたモードは、インターワーキングリンクのATMセグメントとフレームリレーセグメントのレイヤ2ヘッダーバイト数を変更します。このモードは、Cisco ATMキャンパススイッチまたはPA-A3 ATMポートアダプタを搭載した7200シリーズルータで可能です。次に、このオーバーヘッドの詳細について取り上げます。
次の2つの表に、データパケット(VoIP)およびVoice over IP(VoIP)パケットのオーバーヘッドバイトを示します。
表 2. FRF.8 リンク上のデータ パケットにおけるデータ リンク オーバーヘッド(バイト)
FRF.8モード | トランスペアレント | 変換 | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
トラフィック方向 | フレーム リレーから ATM | ATM からフレーム リレー | フレーム リレーから ATM | ATM からフレーム リレー | |||||||||
PVC のフレーム リレー区間または ATM 区間 | フレーム リレー | ATM | ATM | フレーム リレー | フレーム リレー | ATM | ATM | フレーム リレー | |||||
フレーム フラグ(0x7e) | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | |||||
フレーム リレー ヘッダー | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | |||||
LLC DSAP/SSAP(0xfefe) | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | |||||
LLC制御(0x03) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||
NLPID(PPP は 0xcf) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||
MLPプロトコルID(0x003d) | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | |||||
MLP シーケンス番号 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | 4 | |||||
PPP プロトコル ID(最初のフラグのみ) | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | |||||
ペイロード(レイヤ 3+) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |||||
ATM アダプテーション層(AAL)5 | 0 | 8 | 8 | 0 | 0 | 8 | 8 | 0 | |||||
フレーム チェック シーケンス(FCS) | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | |||||
オーバーヘッド合計(バイト) | 15 | 18 | 20 | 17 | 15 | 20 | 20 | 15 |
表 3. FRF.8 リンク上の VoIP パケットにおけるデータ リンク オーバーヘッド(バイト)
FRF.8 モード | トランスペアレント | 変換 | フレーム リレーからフレーム リレー | ||||||
---|---|---|---|---|---|---|---|---|---|
トラフィック方向 | フレーム リレーから ATM | ATM からフレーム リレー | フレーム リレーから ATM | ATM からフレーム リレー | |||||
PVC のフレーム リレー区間または ATM 区間 | フレーム リレー | ATM | ATM | フレームリレー | フレーム リレー | ATM | ATM | フレーム リレー | |
フレーム フラグ(0x7e) | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |
フレーム リレー ヘッダー | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 |
LLC DSAP/SSAP(0xfefe) | 0 | 0 | 2 | 2 | 0 | 2 | 2 | 0 | 0 |
LLC 制御(0x03) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
NLPID(PPPの0xcf) | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
PPP ID | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 0 |
ペイロード(IP+ユーザデータグラムプロトコル(UDP)+RTP+音声) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
AAL5 | 0 | 8 | 8 | 0 | 0 | 8 | 8 | 0 | 0 |
FCS | 2 | 0 | 0 | 2 | 2 | 0 | 0 | 2 | 2 |
総オーバーヘッド(バイト) | 9 | 12 | 14 | 11 | 9 | 14 | 14 | 9 | 7 |
上記の表では、次の点を確認します。
指定したフラグメント化サイズよりも小さいパケットは、MLPPP ヘッダーではなく PPP ヘッダーでのみカプセル化されます。同様に、指定したフラグメント化サイズよりも大きいパケットは、PPP ヘッダーと MLPPP ヘッダーの両方でカプセル化されます。よって、VoIP パケットのオーバーヘッドは最大でも 8 バイト少なくなります。
最初のマルチリンク PPP(MLPPP)フラグメントにのみ、PPP プロトコル ID フィールドが含まれます。このため、最初のフラグメントは追加で 2 バイトのオーバーヘッドを持っています。
トランスペアレント モードの場合、カプセル化ヘッダーは変更されないまま IWF デバイスを通過します。このことから、オーバーヘッドは方向およびセグメントごとに異なります。具体的には、MLPPPoA ヘッダーは短い形式の NLPID ヘッダーである 0xFEFE で始まります。トランスペアレント モードの場合、このヘッダーは変更されないまま IWF デバイスを通過し、ATM セグメントからフレーム リレー セグメントへと渡されます。ただし、フレーム リレーから ATM の方向では、いずれのセグメントでもトランスペアレント モードのこのようなヘッダーは存在しません。
変換モードの場合、IWF デバイスはカプセル化ヘッダーを変更します。このため、双方向の各セグメントのオーバーヘッドは同一になります。具体的には、ATM からフレーム リレー方向では、ATM エンドポイントが MLPPPoA ヘッダーのパケットをカプセル化します。IWF デバイスは、残りのフレームをフレーム リレー セグメントへ渡す前に NLPID ヘッダーを削除します。フレーム リレーから ATM 方向の場合、IWF は再度フレームを変更し、セグメント化フレームを ATM エンドポイントへ渡す前に NLPID ヘッダーを付加します。
MLP を使用する FRF リンクを設計するときは、データ リンクの オーバーヘッド バイトが正しい値になっていることを必ず確認してください。このようなオーバーヘッドは、各 VoIP コールによって消費される帯域幅の量に影響を与えます。また、最適な MLP フラグメント サイズの決定にも関与します。ATM セルの整数と一致するようにフラグメント サイズを最適化することは重要です。特に低速の PVC では、最後のセルを倍の 48 バイトへパディングするために大量の帯域幅を消費することもあることから、とても重要です。
明確にするために、パケットがトランスペアレント モードでフレーム リレーから ATM 方向へ流れる場合のパケット カプセル化プロセスについて見て行きます。
フレーム リレー エンドポイントが MLPPPoFR ヘッダー内のパケットをカプセル化します。
IWF が Data Link Connection Identifier(DLCI)を使用する 2 バイトのフレーム リレー ヘッダーを削除します。次に、残りのパケットは IWF の ATM インターフェイスへと転送され、そこでパケットはセルにセグメント化されて ATM セグメントへと転送されます。
ATM エンドポイントは受信パケットのヘッダーを検証します。受信パケットの最初の 2 バイトが 0x03CF であれば、ATM エンドポイントにより、それが有効な MLPPPoA パケットであると判断されます。
ATM エンドポイントの MLPPP 機能によって、さらに処理が実行されます。
次に、パケットがトランスペアレント モードで ATM からフレーム リレー方向へと流れる場合のパケット カプセル化プロセスについて見て行きます。
ATMエンドポイントは、パケットをMLPPPoAヘッダーにカプセル化します。次に、パケットをセルにセグメント化して ATM セグメントへ転送します。
IWF で受信されたパケットはフレーム リレー インターフェイスへ転送され、そこで 2 バイトのフレーム リレー ヘッダーが付加されます。
フレーム リレー エンドポイントは受信パケットのヘッダーを検証します。2 バイトのフレーム リレー ヘッダーに続く最初の 4 バイトが 0xfefe03cf であれば、IWF により正規の MLPPPoFR パケットとして扱われます。
フレームリレーエンドポイントのMLPPP機能は、さらに処理を実行します。
次の図は、MLPPPoA パケットと MLPPPoFR パケットの形式を示しています。
図6.MLPPPoA オーバーヘッド最初のフラグメントだけがPPPヘッダーを伝送します。
図 7MLPPPoFR オーバーヘッド(最初のフラグメントのみが PPP ヘッダーを搬送)
VoIP の帯域幅をプロビジョニングする際は、帯域幅の計算にデータ リンク オーバーヘッドを含める必要があります。表4に、コーデックおよびCompressed Real-time Transport Protocol(RTP)の使用に応じた、コールごとのVoIP帯域幅要件を示します。表 4 の計算は、RTP ヘッダー圧縮(cRTP)の最良のシナリオを想定しています。言い換えると、UDP チェックサムや送信速度は考慮されていません。この場合、ヘッダーは常に 40 バイトから 2 バイトに圧縮されます。
表 4. VoIP あたりのコール帯域幅要件(kbps)
FRF.8 モード | トランスペアレント | 変換 | フレーム リレーからフレーム リレー | ||||||
---|---|---|---|---|---|---|---|---|---|
トラフィック方向 | フレーム リレーから ATM | ATMからフレームリレー | フレーム リレーから ATM | ATM からフレーム リレー | |||||
PVC のフレーム リレー区間または ATM 区間 | フレーム リレー | ATM | ATM | フレーム リレー | フレーム リレー | ATM | ATM | フレーム リレー | |
G729 - 20ミリ秒サンプル – cRTPなし | 27.6 | 42.4 | 42.4 | 28.4 | 27.6 | 42.4 | 42.4 | 27.6 | 26.8 |
G729 - 20 ミリ秒サンプル - cRTP | 12.4 | 21.2 | 21.2 | 13.2 | 12.4 | 21.2 | 21.2 | 12.4 | 11.6 |
G729 - 30ミリ秒サンプル – cRTPなし | 20.9 | 28.0 | 28.0 | 21.4 | 20.9 | 28.0 | 28.0 | 20.9 | 20.3 |
G729 - 30ミリ秒サンプル – cRTP | 10.8 | 14.0 | 14.0 | 11.4 | 10.8 | 14.0 | 14.0 | 10.8 | 10.3 |
G711 - 20ミリ秒サンプル – cRTPなし | 83.6 | 106.0 | 106.0 | 84.4 | 83.6 | 106.0 | 106.0 | 83.6 | 82.8 |
G711 - 20 ミリ秒 サンプル - cRTP | 68.4 | 84.8 | 84.8 | 69.2 | 68.4 | 84.8 | 84.8 | 68.4 | 67.6 |
G711 - 30 ミリ秒 サンプル - cRTP なし | 76.3 | 97.9 | 97.9 | 76.8 | 76.3 | 97.9 | 97.9 | 76.3 | 75.8 |
G711 - 30 ミリ秒サンプル - cRTP | 66.3 | 84.0 | 84.0 | 66.8 | 66.3 | 84.0 | 84.0 | 66.3 | 65.7 |
オーバーヘッドは PVC のレッグごとに異なるため、最悪のシナリオを想定して設計することを推奨ます。たとえば、トランスペアレント PVC での G.279 コールは 20 ミリ秒のサンプリングと cRTP がかかると想定します。フレーム リレーのレッグでは、一方向の帯域幅要件は 12.4 Kbps で、逆方向の帯域幅要件は 13.2 Kbps です。よって、コールあたり 3.2 Kbps に基づいてプロビジョニングすることを推奨します。
比較のため、この表では、FRF.12フラグメンテーションが設定されたエンドツーエンドフレームリレーPVCのVoIP帯域幅要件も示しています。表にあるとおり、PPP はコールあたりの帯域幅に加えて 0.5 ~ 0.8 Kbps を消費します。これは、追加のカプセル化ヘッダー バイトをサポートするためです。このため、エンドツーエンド フレーム リレー VC では FRF.12 の使用を推奨します。
ATM で圧縮 RTP(cRTP)を使用するには、Cisco IOS® ソフトウェア リリース 12.2(2)T が必要です。cRTP で MLPoFR および MLPoATM が有効化されている場合、TCP/IP ヘッダー圧縮は自動で有効化され、無効化することはできません。この制約は RFC 2509 によるもので、この規約では TCP ヘッダー圧縮のネゴシエーションなしに RTP ヘッダー圧縮の PPP ネゴシエーションを実行することを許可していません。
もともと LFI には、トランスペアレント モードで動作する IWF デバイスが必要です。最近、フレーム リレー フォーラムは FRF.8.1 で変換モードをサポートすると発表しました。シスコでは、次の Cisco IOS ソフトウェアのバージョンで FRF.8.1 および変換モードをサポートしています。
LS1010 の 12.0(18)W5(23) と、4CE1 FR-PAM(CSCdt39211)の Catalyst 8500 シリーズ
APA-A3(CSCdt70724)など、TM インターフェイス対応の Cisco IOS ルータ 12.2(3)T および 12.2(2)
サービス プロバイダーの中には、まだ自社の FRF.8 デバイスで PPP 変換をサポートしていないところがあります。その場合は、プロバイダー側で PVC をトランスペアレント モードに設定する必要があります。
この設定では、次のハードウェアとソフトウェアを使用します。
ATMエンドポイント:Cisco IOSソフトウェアリリース12.2(8)Tを実行している7200シリーズルータのPA-A3-OC3(LFIはPA-A3-OC3およびPA-A3-T3でのみサポートされています。IMA と ATM OC-12 ポート アダプタではサポートされません)
IWF デバイス:チャネライズド T3 ポート アダプタ モジュールと Cisco IOS ソフトウェア リリース 12.1(8)EY を使用する LS1010
フレーム リレー エンドポイント:Cisco IOS ソフトウェア リリース 12.2(8)T が稼働する 7200 シリーズ ルータの PA-MC-T3
このセクションでは、トランスペアレント モードの FRF.8 リンクで LFI 機能を設定する方法について説明します。2 つのルータ エンドポイントでは仮想テンプレートが使用され、MLP バンドルの仮想アクセス インターフェイスがクローニングされています。LFIは、MLPPPのプロトコル層パラメータを指定するためのダイヤラインターフェイスと仮想テンプレートをサポートしています。Cisco IOS ソフトウェア リリース 12.2(8)T では、ルータあたりに設定できる固有の仮想テンプレート数が 200 に増えています。以前のバージョンでは、ルータあたり 25 の仮想テンプレートしかサポートされていませんでした。こうした制限があると、PVC それぞれが固有の IP アドレスを必要とする場合に、ATM ディストリビューション ルータは拡張できなくなります。回避策は、非番号 IP を使用するか、または番号付きリンクで仮想テンプレートをダイヤラ インターフェイスと置き換えます。
Cisco IOSリリース12.1(5)Tでは、MLPPPバンドルごとに1つのメンバーリンクを介したLFIのサポートが導入されました。よって、このコンフィギュレーションの各エンドポイントで使用する VC は 1 つだけになります。今後の Cisco IOS のリリースで、バンドルあたり複数の VC をサポートする予定です。
フレーム リレー エンドポイント |
---|
|
LS1010の設定 |
---|
|
ATMエンドポイント |
---|
|
ATM エンドポイントで次のコマンドを実行し、LFI が正常に稼働していることを確認します。debugコマンドを発行する前に、『debugコマンドの重要な情報』を参照してください。
show ppp multilink:LFI は、2 つの仮想アクセス インターフェイスを使用します。1 つは PPP 用で、もう 1 つは MLP バンドル用です。show ppp multilink コマンドで両方を区別します。
ATMside#show ppp multilink Virtual-Access2, bundle name is FRAMEside !--- The bundle interface is assigned to VA 2. Bundle up for 01:11:55 Bundle is Distributed 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x1E received sequence, 0xA sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 01:11:55, last rcvd seq 00001D 187 weight !--- The PPP interface is assigned to VA 1.
show interface virtual-access 1:仮想アクセス インターフェイスが up/up の状態であることを確認し、入力パケット カウンタと出力パケット カウンタを増分します。
ATMside#show int virtual-access 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Internet address is 1.1.1.1/24 MTU 1500 bytes, BW 150 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation PPP, loopback not set DTR is pulsed for 5 seconds on reset LCP Open, multilink Open Bound to ATM1/0/0.1 VCD: 1, VPI: 1, VCI: 100 Cloned from virtual-template: 1 Last input 01:11:30, output never, output hang never Last clearing of "show interface" counters 2w1d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 878 packets input, 13094 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 255073 packets output, 6624300 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
show policy-map int virtual-access 2:QoS サービス ポリシーが MLPPP バンドル インターフェイスにバインドされていることを確認します。
ATMside#show policy-map int virtual-access 2 Virtual-Access2 Service-policy output: example queue stats for all priority classes: queue size 0, queue limit 27 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Class-map: call-control (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group 103 queue size 0, queue limit 3 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Bandwidth: 10%, kbps 15 Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16384 16383 Priority: kbps 110, burst bytes 4470, b/w exceed drops: 0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any queue size 0, queue limit 5 packets output 0, packet drops 0 tail/random drops 0, no buffer drops 0, other drops 0 Fair-queue: per-flow queue limit 2
debug ppp packet および debug atm packet:これらのコマンドですべてのインターフェイスが up/up の状態であることを確認します。ただし、エンドツーエンドで ping は実行できません。このほか、次に示すとおり、これらのコマンドで PPP キープアライブをキャプチャできます。
2w1d: Vi1 LCP-FS: I ECHOREQ [Open] id 31 len 12 magic 0x52FE6F51 2w1d: ATM1/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03 Length:0x16 2w1d: CFC0 210A 1F00 0CB1 2342 E300 0532 953F 2w1d: 2w1d: Vi1 LCP-FS: O ECHOREP [Open] id 31 len 12 magic 0xB12342E3 !--- This side received an Echo Request and responded with an outbound Echo Reply. 2w1d: Vi1 LCP: O ECHOREQ [Open] id 32 len 12 magic 0xB12342E3 2w1d: ATM1/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x64 DM:0x0 SAP:FEFE CTL:03 Length:0x16 2w1d: CFC0 2109 2000 0CB1 2342 E300 049A A915 2w1d: Vi1 LCP-FS: I ECHOREP [Open] id 32 len 12 magic 0x52FE6F51 2w1d: Vi1 LCP-FS: Received id 32, sent id 32, line up !--- This side transmitted an Echo Request and received an inbound Echo Reply.
フレーム リレー エンドポイントで次のコマンドを実行し、LFI が正常に稼働していることを確認します。debug コマンドを発行する前に、「debug コマンドの重要な情報」を参照してください。
show ppp multilink:LFI は、2 つの仮想アクセス インターフェイスを使用します。1 つは PPP 用で、もう 1 つは MLP バンドル用です。show ppp multilink コマンドで両方を区別します。
FRAMEside#show ppp multilink Virtual-Access2, bundle name is ATMside Bundle up for 01:15:16 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 1/255 load 0x19 received sequence, 0x4B sent sequence Member links: 1 (max not set, min not set) Virtual-Access1, since 01:15:16, last rcvd seq 000018 59464 weight
show policy-map interface virtual-access :QoS サービス ポリシーが MLPPP バンドル インターフェイスにバインドされていることを確認します。
FRAMEside#show policy-map int virtual-access 2 Virtual-Access2 Service-policy output: example Class-map: voice (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip rtp 16384 16383 Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 110 (kbps) Burst 2750 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 27 packets, 2578 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0
debug frame packet および debug ppp packet:これらのコマンドですべてのインターフェイスが up/up の状態であることを確認します。ただし、エンドツーエンドで ping は実行できません。
FRAMEside#debug frame packet Frame Relay packet debugging is on FRAMEside# FRAMEside#ping 1.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/40 ms FRAMEside# 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 28 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52 2w1d: Serial3/0/1:1.1(o): dlci 20(0x441), NLPID 0x3CF(MULTILINK), datagramsize 52
MLPPPoA と MLPPPoFR は、ダイヤラ インターフェイスまたは仮想テンプレートから、仮想アクセス インターフェイスを 2 つクローニングします。1 つは PPP リンクのインターフェイスで、もう 1 つは MLP バンドル インターフェイスとなります。show ppp multilink コマンドを使用し、各機能で使用する特定のインターフェイスを決定します。このドキュメントでは、バンドルあたり 1 つの VC のみをサポートするため、show ppp multilink の出力結果のバンドル メンバ リストには仮想アクセス インターフェイスが 1 つだけ表示されます。
仮想アクセス インターフェイス以外にも、各 PVC はメイン インターフェイスおよびサブインターフェイスと関連付けられています。これらの各インターフェイスは、何らかのキューイングを提供します。ただし、適用された QoS サービス ポリシーによって高度なキューイングをサポートできるのは、バンドル インターフェイスを表す仮想アクセス インターフェイスのみです。その他 3 つのインターフェイスには、FIFO キューイングが必要です。仮想テンプレートにサービスポリシーを適用すると、ルータは次のメッセージを表示します。
cr7200(config)#interface virtual-template 1 cr7200(config)#service-policy output Gromit Class Base Weighted Fair Queueing not supported on interface Virtual-Access1
注:クラスベース重み付け均等化キューイング(CBWFQ)は、MLPPPバンドルインターフェイスでのみサポートされています。
これらのメッセージは異常を表すものではありません。最初のメッセージは、サービスポリシーは PPP 仮想アクセス インターフェイスではサポートされないことを警告しています。2 つ目のメッセージは、MLP バンドル仮想アクセス インターフェイスにサービス ポリシーが適用されていることを確認するものです。MLP バンドル インターフェイスのキューイング方法を確認するには、show interface virtual-access、show queue virtual-access、show policy-map interface virtual-access のコマンドを使用します。
MLPPPoFRでは、フレームリレートラフィックシェーピング(FRTS)を物理インターフェイスで有効にする必要があります。FRTS は VC キューごとに有効化されます。7200、3600、および2600シリーズなどのプラットフォームでは、FRTSは次の2つのコマンドで設定されます。
メインインターフェイスでのframe-relay traffic-shaping
map-class(どのシェーピング コマンドでも実行可能)
Cisco IOS の最新バージョンでは、FRTS なしで MLPPoFR が適用された場合に、次の警告メッセージが表示されます。
"MLPoFR not configured properly on Link x Bundle y"
この警告メッセージが表示されたら、FRTS が物理インターフェイスに設定されており、仮想テンプレートに QoS サービス ポリシーが付加されていることを確認してください。設定を確認するには、show running-config serial interface コマンドと show running-config virtual-template コマンドを使用します。MLPPPoFR が設定されると、次に示すとおり、インターフェイス キューイング方法がデュアル FIFO に変更されます。優先度の高いキューでは、音声パケットやローカル管理インターフェイス(LMI)のような制御パケットが処理され、優先度の低いキューではデータまたは非音声パケットなどのフラグメント化パケットが処理されます。
Router#show int serial 6/0:0 Serial6/0:0 is up, line protocol is down Hardware is Multichannel T1 MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation FRAME-RELAY, crc 16, Data non-inverted Keepalive set (10 sec) LMI enq sent 236, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down LMI enq recvd 353, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 Last input 00:00:02, output 00:00:02, output hang never Last clearing of "show interface" counters 00:39:22 Queueing strategy: dual fifo Output queue: high size/max/dropped 0/256/0 !--- high-priority queue Output queue 0/128, 0 drops; input queue 0/75, 0 drops !--- low-priority queue 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 353 packets input, 4628 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 353 packets output, 4628 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions no alarm present Timeslot(s) Used:12, subrate: 64Kb/s, transmit delay is 0 flags
LFI は 2 つのレイヤのキューイングを使用します。1 つは MLPPP バンドル レベルで、高度なキューイングをサポートし、もう 1 つは PVC レベルで、FIFO キューイングのみをサポートします。バンドル インターフェイスは自身のキューを維持します。すべての MLP パケットは、フレーム リレーまたは ATM レイヤの前に、まず MLP バンドルと仮想アクセス レイヤに渡されます。LFI はメンバ リンクのハードウェア キューのサイズをモニタし、しきい値(元の値は 2)を下回る場合はパケットを取り出してハードウェア キューに渡します。それ以外の場合、パケットはMLPバンドルキューにキューイングされます。
次の表に、LFI over FRFリンクに関する既知の問題を示し、症状を解決済みのバグに切り分けるために実行するトラブルシューティング手順を中心に説明します。
症状 | トラブルシューティング手順 | 解決済みのバグ |
---|---|---|
ATM レッグまたはフレーム リレー レッグでのスループット低下 |
|
CSCdt59038:1500 バイトのパケットでフラグメンテーションが 100 バイトに設定されると、フラグメント化パケットは 15 になります。遅延は、さまざまなレベルのキューイングによって発生しました。CSCdu18344:FRTS では、パケットは予想よりも遅く取り出されます。MLPPP バンドルの取り出し機能によって、トラフィック シェーパー キューのキュー サイズが確認されます。FRTS で、このキューのクリアに時間がかかりすぎています。 |
パケットの順序が入れ替わる |
|
CSCdv89201:ATM 物理インターフェイスが輻輳すると、リモート エンドで MLP フラグメントが破棄されるか、順序が入れ替わって受信されることがあります。この問題に該当するのは、2600および3600シリーズのATMネットワークモジュールだけです。これは、インターフェイス ドライバが高速パス(高速スイッチングまたはシスコ エクスプレス フォワーディングなど)のパケットを正しくスイッチングしなかったことが原因です。具体的には、あるパケットの 2 つめのフラグメントが、続くパケットの最初の フラグメントのあとに送信された場合などです。 |
3600 シリーズで IWF がトランスペアレント モードで実行されるとき、エンドツーエンド接続が切断される |
|
CSCdw11409:CEFがMLPPPパケットのカプセル化ヘッダーの処理を開始する際に、バイトの正しい位置を検索することを確認します |
改定 | 発行日 | コメント |
---|---|---|
1.0 |
28-May-2002 |
初版 |