この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
フレーム リレーは、物理およびデータリンク層で動作する高性能の WAN プロトコルです。Cisco IOS XE フレーム リレーの実装では、現在 IPv4、IPv6、および MPLS のルーティングがサポートされています。
最新の機能情報と注意事項については、ご使用のプラットフォームとソフトウェア リリースに対応したリリース ノートを参照してください。このモジュールで説明される機能に関する情報、および各機能がサポートされるリリースの一覧については、「フレーム リレーの設定に関する機能情報」を参照してください。
プラットフォームのサポートおよび Cisco IOS XE ソフトウェア イメージのサポートに関する情報を検索するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスします。Cisco.com のアカウントは必要ありません。
Cisco IOS XE ソフトウェアでは、次の機能はサポートされていません。
• マルチポイント Permanent Virtual Circuit(PVC; 相手先固定接続)
• Switched Virtual Circuit(SVC; 相手先選択接続)
• レガシー フレーム リレー トラフィック シェーピング(Cisco IOS XE ソフトウェアのみポリシー マップ ベースの MQC をサポート)
フレーム リレーを設定するには、次の概念を理解しておく必要があります。
フレーム リレー接続は、次のハードウェア構成のいずれかを使用して作成できます。
• Channel Service Unit/Digital Service Unit(CSU/DSU; チャネル サービス ユニット/デジタル サービス ユニット)に直接接続し、そこからリモートのフレーム リレー スイッチに接続しているルータおよびアクセス サーバ
(注) ルータをフレーム リレー ネットワークに接続するには、フレーム リレー スイッチに直接接続するか、POS インターフェイスまたは T1/T3 インターフェイスへの直接接続を経由するか、CSU/DSU を経由します。ただし、フレーム リレー用に設定された 1 つのルータ インターフェイスには、これらの方法のいずれか 1 つだけを設定できます。
CSU/DSU では、V.35 または RS-449 の信号が、フレーム リレー ネットワークで正常に受信されるように適切にコーディングされた T1 伝送信号に変換されます。図 1に、コンポーネント間の接続を示します。
フレームリレー インターフェイスは、実質的にはサービスを提供するネットワーク サーバおよびスイッチ間の 1 つの物理接続で構成されます。この 1 つの物理接続によって、ネットワーク上の各デバイスに直接接続されます。
ネットワークでフレーム リレーをイネーブルにするには、必須の基本手順を実行する必要があります。また、特定のネットワーク要件に合わせてフレーム リレーをカスタマイズし、フレーム リレー接続を監視できます。ここでは、これらの作業の概略を示します。
• インターフェイスでのフレーム リレー カプセル化のイネーブル化(必須)
• ダイナミックまたはスタティック アドレス マッピングの設定(必須)
(注) フレーム リレー カプセル化は、インターフェイスでフレーム リレー コマンドを実行するための前提条件です。
(注) マルチポイント DLCI の設定は、現在サポートされていません。Cisco IOS XE ソフトウェアでは、ポイントツーポイント接続がサポートされています。
次の項で説明する作業によって、フレーム リレーの拡張やカスタマイズを行うことができます。
• LMI の設定(任意)
• MQC ベースのフレーム リレー トラフィック シェーピングの設定(任意)
• 実際のネットワークに合わせたフレーム リレーのカスタマイズ(任意)
• フレーム リレー接続の監視と保守(任意)
ネットワーク上にフレーム リレーを設定する方法については、この章の末尾にあるフレーム リレーの設定例の項を参照してください。次の作業で使用するフレーム リレー コマンドの詳細については、『 Cisco IOS Wide-Area Networking Command Reference 』の「Frame Relay Commands 」 の章を参照してください。その他のコマンドのマニュアルについては、インデックスを使用するか、オンラインで検索してください。
インターフェイス レベルでフレーム リレー カプセル化をイネーブルにするには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
フレーム リレーでは、RFC 1490 に適合するサポート対象のすべてのプロトコルのカプセル化をサポートし、複数のベンダー間の相互運用性を実現します。ルータまたはアクセス サーバをフレーム リレー ネットワーク上の別のベンダーの機器に接続する場合は、フレーム リレー カプセル化の Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)形式を使用します。IETF カプセル化は、インターフェイス レベルと VC 単位のいずれかでサポートされます。
カプセル化のタイプを変更する前に、インターフェイスをシャットダウンします。インターフェイスのシャットダウンは必須ではありませんが、シャットダウンすることで、新しいカプセル化に合わせてインターフェイスをリセットできます。
インターフェイスでフレーム リレー カプセル化をイネーブルにする例については、後述の「IETF カプセル化の例」の項を参照してください。
ダイナミック アドレス マッピングでは、既知の DLCI がある場合、フレーム リレーの Inverse ARP を使用して、特定の接続に関するネクスト ホップのプロトコル アドレスを要求します。Inverse ARP 要求に対する応答は、ルータまたはアクセス サーバ上の address-to-DLCI マッピング テーブルに入力されます。また、そのテーブルは、送信トラフィックに関するネクスト ホップのプロトコル アドレスまたは DLCI を提供するために使用されます。
Inverse ARP は、サポートするすべてのプロトコルについてデフォルトでイネーブルになりますが、特定のプロトコルと DLCI のペアに対してディセーブルにできます。そのため、一部のプロトコルにはダイナミック マッピングを使用し、同じ DLCI の別のプロトコルにはスタティック マッピングを使用できます。接続の相手側でサポートされないプロトコルであることがわかっている場合、そのプロトコルと DLCI のペアに対して Inverse ARP を明示的にディセーブルにできます。詳細については、後述のフレーム リレーの Inverse ARP のディセーブル化または再イネーブル化の項を参照してください。
Inverse ARP は、物理インターフェイスでイネーブルになっているすべてのプロトコルについて、デフォルトでイネーブルになります。インターフェイスでイネーブルになっていないプロトコルについては、パケットは送信されません。
Inverse ARP はデフォルトでイネーブルになるので、インターフェイスでダイナミック マッピングを設定するためのコマンドを追加する必要はありません。
スタティック マップは、指定したネクスト ホップのプロトコル アドレスを指定した DLCI にリンクします。スタティック マッピングによって、Inverse ARP 要求は不要になります。スタティック マップを指定すると、指定した DLCI 上の指定したプロトコルについては、Inverse ARP が自動的にディセーブルになります。
相手側のルータで Inverse ARP がまったくサポートされていない場合、またはフレーム リレーで使用する特定のプロトコルについて Inverse ARP がサポートされていない場合は、スタティック マッピングを使用する必要があります。
ネットワークの要件に従ってスタティック マッピングを設定するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config-if)# frame-relay map protocol protocol-address dlci [ broadcast ] [ ietf ] [ cisco ] |
Open Shortest Path First(OSPF)プロトコルの設定時にオプションの broadcast キーワードを追加すると、設定作業が大幅に簡素化されます。 broadcast キーワードの使用の詳細については、『 Cisco IOS Wide-Area Networking Command Reference 』の frame-relay map コマンドの説明と、このモジュールの最後にある例を参照してください。
スタティック アドレス マッピングの設定例については、後述の「スタティック アドレス マッピングの例」の項を参照してください。
Cisco IOS XE ソフトウェアでは、Local Management Interface(LMI; ローカル管理インターフェイス)の自動検知をサポートしており、スイッチがサポートする LMI タイプをインターフェイスで判断することができます。LMI の自動検知がサポートされるようになったため、LMI を明示的に設定する必要がなくなりました。
• ルータに電源が投入されたか、インターフェイスでアップ状態に変わった場合。
• 回線のプロトコルがダウン状態で、回線がアップ状態の場合。
LMI の自動検知のアクティブ化に関する追加情報については、次の項を参照してください。
• ステータス要求
• 設定オプション
LMI の自動検知がアクティブになると、3 つの LMI タイプすべてで、スイッチにフル ステータス要求が送信されます。この処理は、ANSI、ITU、cisco の順番で、途切れることなく迅速に実行されます。Cisco IOS XE ソフトウェアには、DLCI 1023(cisco LMI)および DLCI 0(ANSI と ITU)の両方を同時にリッスンする機能があります。
1 つまたは複数のステータス要求によって、スイッチから応答(ステータス メッセージ)が返されます。ルータは応答のフォーマットをデコードし、ルータ自体を自動的に設定します。ルータは、複数の応答を受信した場合、最後に受信した応答のタイプを使用してルータ自体を設定します。これによって、複数のフォーマットを同時に処理できるインテリジェント スイッチに対応できます。
LMI の自動検知に失敗した場合、インテリジェント リトライ スキームが組み込まれます。N391 インターバル(デフォルトは 60 秒で、10 秒ごとに 6 回キープアライブを交換)で、LMI の自動検知によって LMI タイプの確認が試行されます。N391 の詳細については、『 Cisco IOS Wide-Area Networking Command Reference 』の「Frame Relay Commands 」 の章にある frame-relay lmi-n391dte コマンドを参照してください。
LMI の自動検知が処理中かどうかを視覚的に確認する唯一の方法は、 debug frame lmi を有効にすることです。それによって N391 インターバルごとに、シリアル インターフェイスから 3 つの高速なステータスの問い合わせ(ANSI、ITU、および cisco の LMI タイプごとに 1 つずつ)が送信されることを確認できます。
設定オプションはありません。LMI の自動検知は、ユーザに対して透過的に実行されます。LMI の自動検知を無効にするには、LMI タイプを明示的に設定します。次にルータに電源を投入したときに、LMI の自動検知が非アクティブになるようにするには、LMI タイプを NVRAM に書き込む必要があります。自動インストールの最後に、 frame-relay lmi-type xxx 文がインターフェイス設定に組み込まれます。この設定は NVRAM に自動的に書き込まれないため、 copy system:running-config コマンドまたは copy nvram:startup-config コマンドを使用して、明示的に NVRAM に設定を書き込む必要があります。
フレーム リレー ソフトウェアは、シスコ仕様など、LMI に対応するために業界で承認されている標準をサポートしています。LMI を設定するため、LMI の自動検知を非アクティブにするには、次の項の作業を実行します。
• LMI タイプの設定(必須)
• LMI キープアライブ インターバルの設定(必須)
ルータまたはアクセス サーバが Public Data Network(PDN; 公衆データ網)に接続されている場合、LMI タイプはその公衆データ網で使用されているタイプと一致する必要があります。一致しない場合は、専用のフレーム リレー ネットワークの要件に合わせて LMI タイプを設定できます。
シスコ デバイスでは、ANSI T1.617 Annex D、Cisco、および ITU-T Q.933 Annex A という 3 つの LMI タイプのいずれかを設定できます。そのためには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config-if)# frame-relay lmi-type { ansi | cisco | q933a } |
||
LMI を設定するには、キープアライブ インターバルを設定する必要があります。デフォルトでは、このインターバルは 10 秒になりますが、LMI プロトコルに従って、スイッチ上で対応するインターバルよりも短くする必要があります。キープアライブ インターバルを設定するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
LMI を利用しないネットワークでキープアライブをディセーブルにするには、 no keepalive インターフェイス コンフィギュレーション コマンドを使用します。LMI のキープアライブ インターバルを指定する例については、後述の「スタティック モードの 2 つのルータの例」の項を参照してください。
LMI DTE デバイスと DCE デバイスの動作を微調整するには、さまざまなオプションのカウンタ、インターバル、およびしきい値を設定します。このようなアトリビュートを設定するには、インターフェイス コンフィギュレーション モードで次のコマンドの 1 つまたは複数を使用します。
|
|
|
---|---|---|
DCE および Network-to-Network Interface(NNI; ネットワーク間インターフェイス)エラーのしきい値を設定します。 |
||
ポーリングおよびタイミング インターバル コマンドについては、『 Cisco IOS Wide-Area Networking Command Reference 』の「Frame Relay Commands 」 の章を参照してください。
レガシー フレームリレー トラフィック シェーピングはサポートされていません。Cisco IOS XE ソフトウェアでサポートしているのは、ポリシー マップ ベースの MQC だけです。
メイン インターフェイスにフレーム リレー マップ クラスを指定すると、そのクラスに定義されたすべてのトラフィックシェーピング パラメータが、サブインターフェイス上のすべての VC に継承されます。
指定のインターフェイスのマップ クラスを指定するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
特定のサブインターフェイスの特定の DLCI についてデフォルト値を無効にするには、 class VC コンフィギュレーション コマンドを使用して、DLCI を明示的に異なるクラスに割り当てます。サブインターフェイスの設定については、「フレーム リレー サブインターフェイスの設定」の項を参照してください。
一部のサブインターフェイスの DLCI をデフォルト クラスに割り当て、その他を明示的に異なるクラスに割り当てる例については、後述の「フレーム リレー トラフィック シェーピングの例」の項を参照してください。
フレーム リレーのマップ クラスを定義する場合、そのマップ クラスに関連付けられた VC で許容される平均レートとピーク レートを(ビット/秒で)指定できます。また、カスタム キュー リスト または プライオリティ キュー グループを指定して、マップ クラスに関連付けられた VC で使用することもできます。
マップ クラスを定義するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
マップ クラスの下位互換性と相互運用性の例については、後述の「下位互換性の例」の項を参照してください。
アクセス リストを指定し、それらを任意のマップ クラスに定義されたカスタム キュー リストと関連付けることができます。この場合、アクセス リストとカスタム キュー リストに指定されたリスト番号が関連付けられます。フレーム リレー ネットワークで伝送するプロトコルに対するアクセス リストの定義については、該当するプロトコルの章を参照してください。
プロトコル用のプライオリティ リストとデフォルトのプライオリティ リストを定義できます。特定のプライオリティ リストに使用される番号によって、特定のマップ クラスに定義されているフレーム リレー プライオリティ グループにリストが関連付けられます。
たとえば、マップ クラス「fast_vcs」について frame relay priority-group 2 コマンドを入力してから、 priority-list 2 protocol decnet high コマンドを入力すると、そのプライオリティ リストが「fast_vcs」マップ クラスに使用されます。「fast_vcs」マップ クラスに定義された平均およびピークのトラフィック レートが、DECnet トラフィックに使用されます。
プロトコル用のキュー リストとデフォルトのキュー リストを定義できます。また、任意のサイクルで送信される最大バイト数も指定できます。特定のキュー リストに使用される番号によって、特定のマップ クラスに定義されているフレーム リレー カスタム キュー リストにリストが関連付けられます。
たとえば、マップ クラス「slow_vcs」について frame relay custom-queue-list 1 コマンドを入力してから、 queue-list 1 protocol ip list 100 コマンドを入力すると、そのキュー リストが「slow_vcs」マップ クラスに使用されます。 access-list 100 の定義も、そのマップ クラスとキューに使用されます。「slow_vcs」マップ クラスに定義された平均およびピークのトラフィック レートは、 access list 100 基準を満たす IP トラフィックに使用されます。
フレーム リレーをカスタマイズするには、次の項の作業を実行します。
• フレーム リレーの Inverse ARP のディセーブル化または再イネーブル化
• フレーム リレー カプセル化を使用したリアルタイム ヘッダー圧縮の設定
• 廃棄適性の設定
フレーム リレー サブインターフェイスの全般的な説明については、後述のフレーム リレー サブインターフェイスの概要の項を参照してください。
フレーム リレー サブインターフェイスを設定し、サブインターフェイスのアドレッシングを定義するには、次の項の作業を実行します。
• サブインターフェイス アドレッシングの定義(必須)
• サブインターフェイス用のバックアップ インターフェイスの設定(任意)
サブインターフェイスの設定例については、後述の「サブインターフェイスの例」の項を参照してください。
フレーム リレー サブインターフェイスには、部分的にメッシュ化されたフレーム リレー ネットワークをサポートするメカニズムがあります。ほとんどのプロトコルでは、論理ネットワーク上の推移性を前提としています。つまり、ステーション A がステーション B と通話でき、ステーション B がステーション C と通話できる場合、ステーション A はステーション C と直接通話できると見なされます。推移性は LAN には適用されますが、A が C と直接接続されていなければ、フレーム リレー ネットワークには適用されません。
また、AppleTalk やトランスペアレント ブリッジングなどの特定のプロトコルは、 スプリット ホライズン を必須としているため、部分的にメッシュ化されたネットワークではサポートできません。スプリット ホライズンとは、異なる VC で送受信された場合でも、インターフェイスで受信したパケットを同じインターフェイスから送信できないようにするルーティング技術です。
フレーム リレー サブインターフェイスの設定によって、単一の物理インターフェイスが複数の仮想インターフェイスとして扱われます。この扱いによって、スプリット ホライズン規則に対処できます。同じ物理インターフェイスに設定されている場合でも、1 つの仮想インターフェイスで受信したパケットを別の仮想インターフェイスに転送できます。
サブインターフェイスの利用により、部分的にメッシュ化されたフレーム リレー ネットワークを、完全にメッシュ化された(またはポイントツーポイントの)さらに小規模のサブネットワークに分割することで、フレーム リレー ネットワークの制限に対処できます。各サブネットワークには固有のネットワーク番号が割り当てられるため、プロトコルからは、個別のインターフェイス経由で到達可能であるかのように認識されます (IP で使用する場合には、ポイントツーポイントのサブインターフェイスに番号を指定しないことで、番号を指定する場合にかかるアドレッシングの負荷を減らすこともできます)。
図 2に、部分的にメッシュ化された 5 ノードのフレーム リレー ネットワークを示します(ネットワーク A)。ネットワーク全体を(単一のネットワーク番号が割り当てられた)単一のサブネットワークとして見た場合、実際にはノード C と D を経由してリレーする必要があっても、ほとんどのプロトコルはノード A がノード E に直接パケットを送信できると見なします。このネットワークは、特定のプロトコル(IP など)では機能しますが、それ以外のプロトコルではまったく機能しません(AppleTalk など)。これは、ノード C と D が、パケットを受信した同じインターフェイスからパケットをリレーしないためです。このネットワーク全体が機能するための 1 つの方法は、完全にメッシュ化されたネットワーク(ネットワーク B)を作成することですが、それには多数の PVC が必要になり、経済的に実現できない場合があります。
図 2 部分的にメッシュ化されたフレーム リレー ネットワークでのサブインターフェイスを使用したフル接続の実現
サブインターフェイスを使用すると、フレーム リレー ネットワークを、個別のネットワーク番号を持つ 3 つの小規模なサブネットワーク(ネットワーク C)に分割できます。ノード A、B、および C は完全にメッシュ化されたネットワークに接続され、ノード C と D、およびノード D と E はポイントツーポイント ネットワークを介して接続されます。この構成では、ノード C と D は 2 つのサブインターフェイスにアクセスできるため、スプリット ホライズン規則に違反することなく、パケットを転送できます。トランスペアレント ブリッジングが使用されている場合、各サブインターフェイスは個別のブリッジ ポートとして認識されます。
Cisco IOS XE ソフトウェアでは、ポイントツーポイント サブインターフェイスの設定をサポートしています。フレーム リレー ネットワークにサブインターフェイスを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config)# interface type number . subinterface-number { multipoint | point-to-point } |
||
フレーム リレー サブインターフェイスの設定例については、後述のサブインターフェイスの例の項を参照してください。
ポイントツーポイント サブインターフェイスの場合、宛先は既知であると推定され、frame-relay interface-dlci コマンドで識別または暗示されます。
サブインターフェイス アドレッシングの詳細については、次の項を参照してください。
• ポイントツーポイント サブインターフェイスでのアドレッシング
サブインターフェイス アドレッシングの例については、後述の「スタティック アドレス マッピングの例」の項を参照してください。
前の手順でポイントツーポイント サブインターフェイスを指定した場合、サブインターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
(注) このコマンドは通常、サブインターフェイスで使用されますが、メイン インターフェイスにも適用できます。frame-relay interface-dlci コマンドは、Inverse ARP を使用するように設定されたメイン インターフェイス上でルーティング プロトコルをイネーブルにするために使用されます。このコマンドは、マルチポイント サブインターフェイス上の単一の PVC に特定のクラスを割り当てる場合にも役立ちます。
このコマンドに使用できる多数のオプションについては、『 Cisco IOS Wide-Area Networking Command Reference 』を参照してください。
ポイントツーポイント通信用のサブインターフェイスを定義する場合、最初にルータまたはアクセス サーバをリブートせずに、マルチポイント通信に使用されている同じサブインターフェイス番号を再割り当てすることはできません。その代わりに、同じサブインターフェイス番号を使用せずに、異なるサブインターフェイス番号を使用できます。
ポイントツーポイントおよびマルチポイントのフレーム リレー サブインターフェイスはいずれも、バックアップ インターフェイスを使用して設定できます。この手法によって、フレーム リレー接続全体に失敗してからバックアップを実行するのではなく、障害が発生したときに個々の PVC をバックアップできます。サブインターフェイスは、回線の負荷に基づくバックアップ用ではなく、障害発生時のバックアップ用にのみ設定できます。
フレーム リレー ネットワークとの接続が完全に失われた場合、メイン インターフェイスにバックアップ インターフェイスがあれば、サブインターフェイスのバックアップ インターフェイスよりも優先されます。結果として、サブインターフェイスのバックアップがアクティブになるのは、メイン インターフェイスがアップ状態の場合か、メイン インターフェイスがダウン状態でバックアップ インターフェイスが定義されていない場合だけです。バックアップ インターフェイスの使用中にサブインターフェイスに障害が発生し、メイン インターフェイスがダウン状態になると、バックアップ サブインターフェイスは接続されたままになります。
フレーム リレー サブインターフェイスのバックアップ インターフェイスを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config)# interface type number . subinterface-number point-to-point |
||
Router(config-subif)# backup delay enable-delay disable-delay |
フレーム リレーの Inverse ARP は、DECnet、IP、および Novell IPX を実行するフレーム リレー ネットワークで、ダイナミック アドレス マッピングを構築する方法です。Inverse ARP を使用すると、ルータまたはアクセス サーバは、VC に関連付けられたデバイスのプロトコル アドレスを検出できるようになります。
特定のプロトコル アドレスと特定の DLCI 間にスタティック マッピングを定義する frame-relay map コマンドとは対照的に、Inverse ARP ではダイナミック アドレス マッピングが作成されます(詳細については、前述のダイナミックまたはスタティック アドレス マッピングの設定の項を参照してください)。
Inverse ARP はデフォルトでイネーブルになりますが、特定のプロトコルと DLCI のペアに対して明示的にディセーブルにできます。Inverse ARP は、次のような場合にディセーブルまたは再イネーブルにします。
• 選択したプロトコルが接続先でサポートされないことがわかっている場合は、そのプロトコルと DLCI のペアに対して Inverse ARP をディセーブルにします。
• 条件や機器が変わり、接続先でプロトコルがサポートされるようになった場合、そのプロトコルと DLCI のペアに対して Inverse ARP を再イネーブル化します。
(注) ポイントツーポイント サブインターフェイスからマルチポイント サブインターフェイスに変更した場合、サブインターフェイス番号を変更します。フレーム リレーの Inverse ARP はデフォルトで有効になるので、それ以上必要な操作はありません。
ポイントツーポイント インターフェイスがある場合、宛先は単一で、検出は不要なので、Inverse ARP をイネーブルまたはディセーブルにする必要はありません。
Inverse ARP を選択するかディセーブルにするには、インターフェイス コンフィギュレーション モードで次のコマンドのいずれかを使用します。
|
|
|
---|---|---|
特定のプロトコルと DLCI のペアに対して、フレーム リレーの Inverse ARP を以前にディセーブルにした場合のみイネーブルにします。 |
||
Cisco IOS XE ソフトウェアでは、次のタイプのフレーム リレー フラグメンテーションをサポートしています。詳細については、次の項で説明します。
エンドツーエンド FRF.12 フラグメンテーションの目的は、リアルタイム データに過度の遅延を引き起こさずに、低速リンクでリアルタイム データおよび非リアルタイム データのパケットをサポートすることです。FRF.12 フラグメンテーションは、FRF.12 実装合意によって定義されています。この標準は、長いデータ フレームを小さい部分(フラグメント)にフラグメント化し、リアルタイム フレームと交互に送信するために開発されました。この方法によって、リアルタイム トラフィックの過度な遅延を引き起こすことなく、リアルタイムと非リアルタイムのデータ フレームを低速のリンクで同時に送信できます。
音声を伝送する他の Permanent Virtual Circuit(PVC; 相手先固定接続)とリンクを共有する PVC や、Voice over IP(VoIP)を送信する PVC には、エンドツーエンド FRF.12 フラグメンテーションの使用が推奨されます。VoIP パケットはフラグメント化すべきではありませんが、フラグメント化したパケットと交互に送信できます。
FRF.12 はフレーム リレー マップ クラスを使用して PVC ごとに設定されます。このマップ クラスは 1 つの PVC にも、多数の PVC にも適用できます。フラグメンテーションが機能するには、インターフェイスでフレーム リレー トラフィック シェーピングがイネーブルである必要があります。
エンドツーエンド FRF.12 フラグメンテーションを設定するには、次の項の作業を実行します。作業ごとに必須であるか、任意であるかが示されています。
フレーム リレー マップ クラスで FRF.12 フラグメンテーションを設定するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
このマップ クラスは 1 つの PVC にも、多数の PVC にも適用できます。
(注) フレーム リレー フラグメンテーションを設定する場合、WFQ または LLQ は必須です。フレーム リレー フラグメンテーションについてマップ クラスを設定し、そのマップ クラス上のキューイング タイプが WFQ または LLQ ではない場合、設定したキューイング タイプは、WFQ のデフォルト値に自動的に上書きされます。フレーム リレー用の LLQ を設定するには、『Cisco IOS XE Quality of Service Solutions Configuration Guide』を参照してください。
FRF.12 フラグメンテーションの設定例については、後述の「FRF.12 フラグメンテーションの例」の項を参照してください。
音声パケットがフラグメント化されないように、また 20 ms を超えるシリアル化の遅延が発生しないように、フラグメント サイズを設定します。
フラグメント サイズを設定するには、リンク速度を考慮する必要があります。フラグメント サイズは音声パケットよりも大きく、また音声パケットの遅延を最小限に抑えられる程度に小さくする必要があります。フラグメンテーションは、低速リンク(768 kb/s 未満)に対して有効にします。
ルータ間の最低のポート速度に基づいて、フラグメント サイズを設定します。たとえば、ハブ アンド スポーク フレーム リレー トポロジがあり、ハブが T1 の速度でリモート ルータが 64 kb/s のポート速度である場合、フラグメント サイズは、両方のルータで 64 kb/s の速度に設定する必要があります。同じ物理インターフェイスを共有するその他すべての PVC には、音声 PVC が使用するサイズにフラグメンテーションを設定します。
パス内の最低のリンク速度が 64 kb/s の場合、推奨されるフラグメント サイズ(シリアル化の遅延が 10 ms の場合)は 80 バイトです。最低のリンク速度が 128 kb/s の場合、推奨されるフラグメント サイズは 160 バイトです。
詳細については、『VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority)』の「 Fragmentation (FRF.12) 」の項を参照してください。
FRF.12 フラグメンテーションを確認するには、次の EXEC コマンドの 1 つまたは複数を使用します。
|
|
|
---|---|---|
Router# show frame-relay fragment [ interface interface ] [ dlci ] |
||
Router# show frame-relay pvc [ interface interface ] [ dlci ] |
TCP/IP ヘッダー圧縮は、RFC 1144 に記述されているとおり、低速のシリアル リンクで帯域利用率の効率を高めるために設計されています。一般的な TCP/IP パケットには、40 バイトのデータグラム ヘッダーが含まれます。接続が確立した後は、ヘッダー情報は冗長であるため、送信されるすべてのパケットで繰り返す必要はありません。接続を識別し、変更されたフィールドと変更の量を示す小さなヘッダーを再構築することで、送信バイト数が減少します。平均的な圧縮ヘッダーの長さは 10 バイトです。
このアルゴリズムが機能するには、パケットが順序どおりに受信される必要があります。パケットが順序どおりに受信されないと、再構築によって通常の TCP/IP パケットが作成されたように見えても、元のパケットとは一致しません。プライオリティ キューイングによって、パケットの送信順序は変わるため、インターフェイスでプライオリティ キューイングをイネーブルにすることは推奨されません。
TCP/IP ヘッダー圧縮の設定またはディセーブル化については、次の項を参照してください。
• TCP/IP ヘッダー圧縮に対する個別の IP マップの設定
(注) シスコ独自のカプセル化および TCP/IP ヘッダー圧縮を使用してインターフェイスを設定する場合、フレーム リレー IP マップは、インターフェイスの圧縮特性を継承します。ただし、IETF カプセル化とのインターフェイスを設定する場合、圧縮に関してインターフェイスを設定できません。TCP/IP ヘッダー圧縮をサポートするには、フレーム リレー マップを個別に設定する必要があります。
(注) TCP/IP ヘッダー圧縮をサポートするように設定されたインターフェイスは、プライオリティ キューイングまたはカスタム キューイングをサポートできません。
TCP/IP ヘッダー圧縮には、シスコ独自のカプセル化が必要です。全体としてインターフェイスに IETF カプセル化を設定する必要がある場合でも、シスコ独自のカプセル化と TCP ヘッダー圧縮を使用するように特定の IP マップを設定できます。さらに、TCP/IP ヘッダー圧縮を実行するインターフェイスを設定する場合でも、TCP/IP ヘッダーを圧縮しないように特定の IP マップを設定できます。
TCP/IP ヘッダー圧縮がアクティブかパッシブかを指定できます。アクティブ圧縮では、すべての発信パケットに TCP/IP ヘッダー圧縮が適用されます。パッシブ圧縮では、受信したパケットに圧縮済みの TCP/IP ヘッダーがある場合のみ、発信 TCP/IP パケットにヘッダー圧縮が適用されます。
シスコ独自のカプセル化および TCP/IP ヘッダー圧縮を使用するように IP マップを設定するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
IP マップで TCP ヘッダー圧縮を設定する例については、後述のTCP/IP ヘッダー圧縮を上書きする IP マップの使用例の項を参照してください。
アクティブまたはパッシブの TCP/IP ヘッダー圧縮を使用して、インターフェイスを設定できます。デフォルトのアクティブ圧縮では、すべての発信 TCP/IP パケットにヘッダー圧縮が適用されます。パッシブ圧縮では、そのインターフェイスで受信したパケットに圧縮済みの TCP/IP ヘッダーがある場合のみ、発信パケットにヘッダー圧縮が適用されます。
インターフェイスに TCP/IP ヘッダー圧縮を適用するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config-if)# frame-relay ip tcp header-compression [ passive ] |
(注) シスコ独自のカプセル化で設定したインターフェイスを、後から IETF カプセル化で設定すると、すべての TCP/IP ヘッダー圧縮の特性は失われます。IETF カプセル化で設定したインターフェイスで TCP/IP ヘッダー圧縮を適用するには、TCP/IP ヘッダー圧縮に対する個別の IP マップの設定の項の説明に従って、個別の IP マップを設定する必要があります。
インターフェイスで TCP ヘッダー圧縮を設定する例については、後述のTCP/IP ヘッダー圧縮を上書きする IP マップの使用例の項を参照してください。
TCP/IP ヘッダー圧縮をディセーブルにするには、異なる効果を持つ 2 つのコマンドのいずれかを使用します。使用するコマンドは、フレーム リレー IP マップが TCP/IP ヘッダー圧縮用に明示的に設定されているか、またはインターフェイスから圧縮特性を継承しているかどうかによって決定します。
TCP/IP ヘッダー圧縮を明示的に設定したフレーム リレー IP マップでは、TCP/IP ヘッダー圧縮を明示的にディセーブルにすることも必要です。
TCP/IP ヘッダー圧縮をディセーブルにするには、インターフェイス コンフィギュレーション モードで次のコマンドのいずれかを使用します。
TCP/IP ヘッダー圧縮を無効にする例については、後述の継承した TCP/IP ヘッダー圧縮をディセーブルにする例および明示的な TCP/IP ヘッダー圧縮をディセーブルにする例の項を参照してください。
Real-time Transport Protocol(RTP; リアルタイム転送プロトコル)は、パケット化した音声およびビデオ トラフィックを IP ネットワーク上で伝送するために使用され、リアルタイム トラフィック アプリケーションおよびマルチキャストまたはユニキャスト ネットワーク サービス用のエンドツーエンド ネットワーク転送機能を提供します。RTP については、RFC 1889 に記述されています。RTP は、TCP または UDP を使用するデータ トラフィック用ではありません。
フレーム リレー カプセル化を使用する RTP ヘッダー圧縮の設定作業と設定例については、『 Cisco IOS XE IP Multicast Configuration Guide 』を参照してください。
この機能を設定するコマンドについては、『 Cisco IOS IP Multicast Command Reference 』を参照してください。
フレーム リレー パケットによっては、優先度または時間感度が低く設定されている場合があります。フレーム リレー スイッチで輻輳が発生すると、このようなパケットから先にドロップされます。フレーム リレー スイッチがこのようなパケットを識別できるようにするメカニズムが Discard Eligibility(DE; 廃棄適性)ビットです。
廃棄適性を利用するには、フレーム リレー ネットワークが DE ビットを解釈できる必要があります。DE ビットを設定した場合、何も処理しないネットワークと、DE ビットを使用して廃棄するパケットを決定するネットワークがあります。最適な解釈は、DE ビットを使用して最初にドロップするパケットを決定し、さらに時間感度の低いパケットを決定することです。
廃棄適性があるパケットの特性を識別する DE リストを作成することができます。また、影響を受ける DLCI を識別する DE グループを指定することもできます。
フレーム リレー スイッチで輻輳が発生したときにドロップできるパケットを指定する DE リストを定義するには、グローバル コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
Router(config)# frame-relay de-list list-number { protocol protocol | interface type number } characteristic |
プロトコルまたはインターフェイスに基づいて、また、パケットのフラグメンテーション、特定の TCP ポートや User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ポート、アクセス リスト番号、またはパケット サイズなどの特性に基づいて、DE リストを作成できます。詳細については、『 Cisco IOS Wide-Area Networking Command Reference 』の frame-relay de-list コマンドを参照してください。
影響を受ける DE リストと DLCI を指定する DE グループを定義するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
|
|
|
---|---|---|
DLCI プライオリティ レベルを使用すると、異なるタイプのトラフィックを区別でき、次の状況で発生する輻輳の問題に対応できるトラフィック管理ツールを利用できます。
• 同じ DLCI にバッチおよびインタラクティブ トラフィックが混在している。
• 低速アクセスの宛先サイトで高速アクセスのサイトからのトラフィックをキューイングしている。
DLCI プライオリティ レベルを設定する前に、次の作業を実行します。
• 前述の「インターフェイスでのフレーム リレー カプセル化のイネーブル化」の項に従って、フレーム リレー カプセル化をイネーブルにします。
• 前述の「ダイナミックまたはスタティック アドレス マッピングの設定」の項に従って、ダイナミックまたはスタティック アドレス マッピングを定義します。
• レベルを適用する各 DLCI を定義していることを確認します。プライオリティ レベル DLCI は、サブインターフェイスに関連付けることができます。
• 前述の「LMI の設定」の項に従って、LMI を設定します。
(注) DLCI プライオリティ レベルには、異なるタイプのトラフィックについて複数のパラレル DLCI を定義する方法が用意されています。DLCI プライオリティ レベルでは、ルータまたはアクセス サーバ内にプライオリティ キューは割り当てられません。実際、これらはデバイスのプライオリティ キューとは関係がありません。ただし、キューイングをイネーブルにし、キューイングに同じ DLCI を使用する場合、高優先順位の DLCI を高優先順位のキューに配置できます。
DLCI プライオリティ レベルを設定するには、インターフェイス コンフィギュレーション モードで次のコマンドを使用します。
(注) 各プライオリティ レベルについて DLCI を明示的に指定しない場合、コマンド ラインで最後に指定した DLCI が、残りの引数の値として使用されます。最低でも、高優先順位および中優先順位の DLCI を設定する必要があります。
フレーム リレー接続を監視するには、EXEC モードで次のいずれかのコマンドを使用します。
|
|
|
---|---|---|
• 下位互換性の例
次の例では、インターフェイス レベルで IETF カプセル化を設定します。キーワード ietf によって、すべてのマップに関するデフォルトのカプセル化方式を IETF に設定します。
encapsulation frame-relay ietf
frame-relay map ip 131.108.123.2 48 broadcast
frame-relay map ip 131.108.123.3 49 broadcast
次の例では、DLCI 別に IETF カプセル化を設定します。この設定は、最初の設定例と同じ結果になります。
次に、スタティック モードの 2 つのルータを設定する例を示します。
ここでは、異なるルーティングのプロトコルおよびブリッジングに適したフレーム リレー サブインターフェイスの例と種類を示します。
次の例では、サブインターフェイス 1 はポイントツーポイント サブネットとして設定され、サブインターフェイス 2 はマルチポイント サブネットとして設定されます。
次に、FRTS を使用した Class-Based Weighted Fair Queueing(CBWFQ; クラスベース重み付け均等化キューイング)の設定例を示します。
class-map voice
match ip dscp ef
policy-map llq
class voice
priority 32
policy-map shape-policy-map
class class-default
shape average 64000
shape adaptive 32000
service-policy llq
map-class frame-relay shape-map-class
service-policy output shape-policy-map
interface serial 0/0
encapsulation frame-relay
interface serial 0/0.1 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 100
class shape-map-class
次に、FRTS を使用した CBWFQ とフラグメンテーションの設定例を示します。この設定例は、「クラスベース重み付け均等化キューイングの例」の項で示した例と同一であり、フラグメンテーションを設定するために frame-relay fragment コマンドを追加しています。
class-map voice
match ip dscp ef
policy-map llq
class voice
priority 32
policy-map shape-policy-map
class class-default
shape average 64000
shape adaptive 32000
service-policy llq
map-class frame-relay shape-map-class
frame-relay fragment 80
service-policy output shape-policy-map
interface serial 0/0
encapsulation frame-relay
interface serial 0/0.1 point-to-point
ip address 192.168.1.1 255.255.255.0
frame-relay interface-dlci 100
class shape-map-class
次の設定は、RFC 1490 との互換性がないバージョンとの下位互換性と相互運用性を実現しています。RFC 1490 トラフィックの生成には、 ietf キーワードを使用します。各マップ エントリを個別に定義することで柔軟性が向上するため、この設定が可能になります。
フレーム リレー上の TFTP サーバから起動する場合、ブロードキャスト経由ではネットワーク サーバから起動できません。特定の TFTP ホストから起動する必要があります。また、起動するホストに対して frame-relay map コマンドを使用する必要があります。
たとえば、ファイル「gs3-bfx」が IP アドレス 131.108.126.2 のホストから起動している場合、次のコマンドを設定に含める必要があります。
IP アドレスを DLCI アドレスにマッピングするには、 frame-relay map コマンドを使用します。フレーム リレーで起動するには、起動するネットワーク サーバのアドレスを明示的に指定する必要があり、そのサイトに対する frame-relay map エントリが必要です。たとえば、ファイル「gs3-bfx.83-2.0」が IP アドレス 131.108.126.111 のホストから起動している場合、次のコマンドを設定に含める必要があります。
この場合、100 はホスト 131.108.126.111 に接続できる DLCI です。
このエントリによって、リモート ルータはフレーム リレー上で起動するルータに対して、(ネットワーク サーバからの)ブート イメージを返すことができます。ここで、101 は起動するルータの DLCI です。
次に、「frag」というマップ クラスで、エンドツーエンド FRF.12 だけのフラグメンテーションと重み付け均等化キューイングを設定する例を示します。フラグメントのペイロード サイズは 40 バイトに設定されます。「frag」マップ クラスは、シリアル インターフェイス 1 上の DLCI 100 に関連付けられます。
router(config)#
interface serial 1
router(config)#
map-class frame-relay frag
ここでは、多様な組み合せの TCP/IP ヘッダー圧縮の設定例、インターフェイスでのカプセル化の特性、およびフレーム リレー IP マップでのその特性の継承に関する影響を示します。
• 継承した TCP/IP ヘッダー圧縮による IP マップの例
• TCP/IP ヘッダー圧縮を上書きする IP マップの使用例
• 継承した TCP/IP ヘッダー圧縮をディセーブルにする例
• 明示的な TCP/IP ヘッダー圧縮をディセーブルにする例
(注) 圧縮技術を追加または変更する前に、インターフェイスまたはサブインターフェイスをシャットダウンします。シャットダウンは必須ではありませんが、シャットダウンすることで、新しいデータ構造に合わせてインターフェイスをリセットできます。
次に、TCP/IP ヘッダー圧縮用に設定したインターフェイス、および圧縮特性を継承する IP マップの例を示します。フレーム リレー IP マップはヘッダー圧縮用に明示的に設定されていません。
show frame-relay map コマンドを使用すると、結果の圧縮およびカプセル化の特性が表示されます。IP マップはパッシブ TCP/IP ヘッダー圧縮を継承しています。
この例は、フレーム リレー マップが設定されていないポイントツーポイント サブインターフェイスで、Inverse ARP を使用して実行されるダイナミック マッピングにも適用されます。
次に、インターフェイスに設定されている圧縮を上書きするフレーム リレー IP マップを使用する例を示します。
show frame-relay map コマンドを使用すると、結果の圧縮およびカプセル化の特性が表示されます。IP マップは TCP ヘッダー圧縮を継承していません。
(注) 圧縮技術を追加または変更する前に、インターフェイスまたはサブインターフェイスをシャットダウンします。シャットダウンは必須ではありませんが、シャットダウンすることで、新しいデータ構造に合わせてインターフェイスをリセットできます。
継承した TCP/IP ヘッダー圧縮をイネーブルにするには、次のコマンドを入力します。
show frame-relay map コマンドを使用すると、結果の圧縮とカプセル化の特性が表示されます。
結果として、最初のマップ(および DLCI 177)についてヘッダー圧縮がディセーブルになり、インターフェイスからヘッダー圧縮特性が継承されます。ただし、2 番目のマップ(および DLCI 178)に対するヘッダー圧縮は、明示的に設定されているためディセーブルになりません。
次の例の最初の設定は前の例と同じですが、次の一連のコマンドを入力して、明示的な TCP/IP ヘッダー圧縮をイネーブルにする必要があります。
show frame-relay map コマンドを使用すると、結果の圧縮とカプセル化の特性が表示されます。
このコマンドの結果、インターフェイスからヘッダー圧縮特性を継承している最初のマップ(および DLCI 177)のヘッダー圧縮がディセーブルになり、ヘッダー圧縮が明示的に設定されていた 2 番目のマップ(および DLCI 178)のヘッダー圧縮も明示的にディセーブルになります。
ここでは、フレーム リレーに関する関連資料について説明します。
|
|
---|---|
『Cisco IOS XE Wide-Area Networking Configuration Guide, Release 2』 |
|
|
|
---|---|
|
|
---|---|
この機能によってサポートされる新しい MIB または変更された MIB はありません。またこの機能による既存 MIB のサポートに変更はありません。 |
選択したプラットフォーム、Cisco IOS XE ソフトウェア リリース、およびフィーチャ セットの MIB の場所を検索しダウンロードするには、次の URL にある Cisco MIB Locator を使用します。 |
|
|
---|---|
表 1 に、このモジュールで説明した機能をリストし、特定の設定情報へのリンクを示します。
プラットフォーム サポートとソフトウェア イメージ サポートに関する情報を入手するには、Cisco Feature Navigator を使用します。Cisco Feature Navigator を使用すると、特定のソフトウェア リリース、フィーチャ セット、またはプラットフォームをサポートする Cisco IOS XE のソフトウェア イメージを判別できます。Cisco Feature Navigator には、 http://www.cisco.com/go/cfn からアクセスします。Cisco.com のアカウントは必要ありません。
(注) 表 1 に、特定の Cisco IOS XE ソフトウェア リリース群で特定の機能をサポートする Cisco IOS XE ソフトウェア リリースだけを示します。特に明記されていない限り、Cisco IOS XE ソフトウェア リリース群の後続のリリースでもこの機能をサポートします。