Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

RSVP の設定

最小RSVP設定

単一のインターフェイスでRSVPを有効にするには、 rsvp ステートメントを含め、 interface ステートメントを使用してインターフェイスを指定します。これが最小RSVP設定です。その他の RSVP 設定ステートメントはすべてオプションです。

以下の階層レベルでこれらのステートメントを含めることができます。

  • [edit protocols]

  • [edit logical-systems logical-system-name protocols]

すべてのインターフェイスでRSVPを有効にするには、interface-name変数をallに置き換えます。

インターフェイスのグループでインターフェイスのプロパティを設定し、そのうちの1つのインターフェイスでRSVPを無効にする場合は、 disable ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp interface interface-name ]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name ]

RSVP と MPLS の設定

Junos RSVP ソフトウェアの主な目的は、ラベルスイッチドパス(LSP)内の動的なシグナリングをサポートすることです。ルーターで MPLS と RSVP の両方を有効にすると、MPLS は RSVP のクライアントになります。MPLSとRSVPを結合するための追加設定は必要ありません。

[edit protocols mpls]階層レベルでlabel-switched-pathステートメントを使用して、シグナル付きパスを設定するようにMPLS設定できます。各LSPは、RSVPセッションを開始するためのRSVPのリクエストに変換されます。このリクエストは、ラベルスイッチとRSVPの間の内部インタフェースを介して渡されます。リクエスト情報を調べ、RSVPの状態を確認し、ローカルルーティングテーブルを確認した後、RSVPはLSPごとに1つのセッションを開始します。セッションはローカルルーターから発信され、LSPのターゲットに向けられます。

RSVP セッションの作成に成功すると、RSVP セッションで作成されたパスに沿って LSP が設定されます。RSVP セッションが失敗した場合、RSVP は MPLS にその状態を通知します。バックアップパスを開始するか、最初のパスを再試行し続けるかはMPLS次第です。

ラベルスイッチング信号情報を渡すために、RSVPはラベルリクエストオブジェクト、ラベルオブジェクト、明示的なルートオブジェクト、レコードルートオブジェクトの4つの追加オブジェクトをサポートします。LSPが正常にセットアップされるためには、パスに沿ったすべてのルーターがMPLS、RSVP、および4つのオブジェクトをサポートしている必要があります。4つのオブジェクトのうち、Record Routeオブジェクトは必須ではありません。

MPLSを設定し、RSVPのクライアントとするには、次のようにします。

  • ラベルスイッチングに参加するすべてのルーター(ラベルスイッチングパスの一部である可能性のあるすべてのルーター)でMPLSを有効にします。

  • すべてのルーターと、LSPを形成するすべてのルーターインターフェイスでRSVPを有効にします。

  • LSPの先頭でルーターを設定します。

パスを計算するにあたり遅延メトリックを使用するように、RSVPラベルスイッチパス(LSP)を設定することができます。設定するには、 [edit protocols mpls label-switched-path name] 階層下に導入したCLIオプションを使用します。

例:RSVP と MPLS の設定

LSPの先頭のルーターの設定例を次に示します。

LSP を形成する他のすべてのルーターの設定例を次に示します。

RSVPインターフェイスの設定

以下のセクションでは、RSVPインターフェイスの設定方法について説明します。

RSVP更新削減の設定

インターフェイス設定に以下のステートメントを含めることで、各インターフェイスでRSVP更新の削減を設定することができます。

  • aggregatereliable - RSVPメッセージバンドリング、RSVPメッセージID、信頼性の高いメッセージ配信、概要の更新など、すべてのRSVP更新削減機能を有効にします。

    更新の削減と信頼性の高い配信を実現するには、 aggregate ステートメントと reliable ステートメントを含める必要があります。

  • no-aggregate- RSVPメッセージのバンドリングと概要の更新を無効にします。

  • no-reliable- RSVPメッセージID、信頼性の高いメッセージ配信、および概要の更新を無効にします。

RSVP更新の削減の詳細については、 RSVP更新の削減を参照してください。

no-reliableステートメントがルーター上に設定されている場合(信頼性の高いメッセージ配信が無効になっている)、ルーターはメッセージIDオブジェクトを含むRSVPメッセージを受け入れますが、メッセージIDオブジェクトは無視され、通常のメッセージ処理を続行します。この場合、エラーは生成されず、RSVPは通常どおり動作します。

しかしながら、更新の削減機能が異なる2つのネイバーの組み合わせがすべて正しく動作するとは限りません。例えば、ルーターは、 aggregate ステートメントと no-reliable ステートメントのいずれかで構成されている場合や、 reliable ステートメントと no-aggregate ステートメントで構成されている場合です。RSVPネイバーがこのルーターにサマリー更新オブジェクトを送信した場合、エラーは生成されませんが、サマリー更新オブジェクトは処理されません。その結果、ネイバーがRSVP状態を更新するためにサマリー更新のみに依存している場合、このルーターでRSVP状態がタイムアウトする可能性があります。

特別な要件がない限り、同様の方法で各RSVPネイバーでRSVP更新の削減を設定することをお勧めします。

インターフェイスですべてのRSVP更新削減機能を有効にするには、 aggregate ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVPメッセージのバンドリングと概要の更新を無効にするには、 no-aggregate ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

インターフェイスでRSVPメッセージIDと信頼性の高いメッセージ配信を有効にするには、 reliable ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVPメッセージID、信頼性の高いメッセージ配信、および概要の更新を無効にするには、 no-reliable ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

RSVPネイバーの更新削減機能の決定

RSVP ネイバーの RSVP 更新の削減機能を確認するには、以下の情報が必要です。

  • ネイバーからアドバタイズされたRRビット

  • RSVPリフレッシュ削減のローカル設定

  • ネイバーから受信した実際のRSVPメッセージ

この情報を取得するには、 show rsvp neighbor detail コマンドを発行します。以下は出力のサンプル例です。

show rsvp neighbor detailコマンドの詳細については、こちらをご覧ください。

RSVP Hello間隔の設定

RSVP は、内部ゲートウェイ プロトコル(IGP)(IS-IS または OSPF)ネイバーの状態を監視し、ノードが故障したときには IGP プロトコルに依存して検出します。IGPプロトコルがネイバーをダウンさせた場合(helloパケットが受信できなくなったため)、RSVPもそのネイバーをダウンさせます。しかし、IGPプロトコルとRSVPは、ネイバーをアップする際に独立して動作します。

ジュニパーネットワークスのルーターの場合、RSVP helloの間隔を短く設定するのであれ長く設定するのであれ、RSVPセッションが停止するかどうかに影響を与えることはありません。RSVP Helloパケットが受信できなくなった場合でも、RSVPセッションは維持されます。RSVP セッションは、ルーターが IGP hello パケットの受信を停止するか、RSVP パスと Resv メッセージがタイムアウトするまで維持されます。しかしながら、Junos OSリリース16.1以降では、RSVPのHelloメッセージがタイムアウトすると、RSVPセッションが停止します。

また、別のベンダーの機器によってRSVPセッションが停止した場合にも、RSVP hello間隔に影響が及ぶ可能性があります。例えば、隣接する非ジュニパーネットワークスルーターが、RSVP helloパケットを監視するように設定されている場合があります。

RSVPがhelloパケットを送信する頻度を変更するには、 hello-interval ステートメントを含めます。

注:

リリース16.1以降、Junosは、利用可能な場合、RSVP HelloメッセージをバイパスLSP経由で送信します。IGPネクストホップ経由でhellosを送信するこれまでの動作に戻す方法については、 no-node-hello-on-bypass をご覧ください。

このステートメントを含めることができる階層レベルの一覧については、ステートメント概要セクションを参照してください。

RSVP認証の設定

すべてのRSVPプロトコル交換を認証することで、信頼できるネイバーのみが予約設定に参加できるようにすることができます。デフォルトでは、RSVP認証は無効になっています。

RSVP認証では、ハッシュメッセージ認証コード(HMAC)-MD5メッセージベースのダイジェストを使用します。このスキームでは、シークレット認証鍵とメッセージの内容に基づいてメッセージダイジェストが生成されます。(メッセージの内容にはシーケンス番号も含まれます。計算されたダイジェストは、RSVPメッセージとともに送信されます。認証を設定すると、すべてのネイバーと送受信されたすべてのRSVPメッセージがこのインターフェイス上で認証されます。

MD5 認証は、偽造やメッセージの改ざんに対する保護を提供します。また、リプレイ攻撃を防止することもできます。ただし、すべてのメッセージがクリアテキストで送信されるため、機密性はありません。

デフォルトでは、認証は無効になっています。認証を有効にするには、 authentication-key ステートメントを含めて各インターフェイスでキーを設定します。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • edit logical-systems logical-system-name protocols rsvp

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Point of Local Repair(PLR)とMerge Point(MP)間のノードhelloまたはリモートメッセージを認証するには、[edit protocols rsvp]階層レベルで認証キーを有効にします。

クラスタイプの帯域幅サブスクリプションを設定する

デフォルトでは、RSVPはクラスタイプの帯域幅の100%をRSVP予約に使用することができます。マルチクラスLSPのクラスタイプをオーバーサブスクライブする場合、すべてのRSVPセッションの総需要は、クラスタイプの実際の容量を超えることができます。

クラスタイプの帯域幅サブスクリプションを設定する方法の詳細については、 LSPの帯域幅サブスクリプション率を設定するを参照してください。

インターフェイスでのRSVP更新しきい値の設定

内部ゲートウェイプロトコル(IGP)はトラフィック制御データベースを維持しますが、トラフィック制御データベースリンク上の現在利用可能な帯域幅はRSVPからのものです。リンクの帯域幅が変更されると、RSVPからIGPに通知されます。IGPはトラフィック制御データベースを更新して、新しい帯域幅情報をすべてのネットワークノードに転送できます。これにより、ネットワークノードは、トラフィック制御データベースリンク(ローカルまたはリモート)で利用可能な帯域幅を把握し、CSPFはパスを正しく計算できます。

しかしながら、IGPのアップデートは過剰なシステムリソースを消費する可能性があります。ネットワーク内のノード数によっては、帯域幅の小さな変更に対してIGP更新を実行することが望ましくない場合があります。[edit protocols rsvp]階層レベルでupdate-thresholdステートメントを設定することで、予約された帯域幅の変更がIGP更新をトリガーするしきい値を調整できます。

IGP更新をトリガーするタイミングには、0.001%から20%(デフォルトは10%)の値を設定できます。予約された帯域幅の変化が、そのインターフェイスの静的帯域幅に対して設定されたしきい値の割合と同じかそれ以上である場合、IGP更新が発生します。例えば、 update-threshold ステートメントを15%に設定しているときに、リンクの予約された帯域幅がリンク帯域幅から10%変更されたことをルーターが発見した場合、RSVPはIGP更新をトリガーしません。ただし、リンクの予約された帯域幅がリンク帯域幅から20%変更された場合、RSVPはIGP更新をトリガーします。

また、update-thresholdステートメントにあるthreshold-valueオプションを使用して、しきい値を絶対値として設定することもできます。

そのリンクの帯域幅より20%を超えるようにしきい値が設定されている場合、しきい値は帯域幅の20%までに制限されます。

例えば、インターフェイスの帯域幅が1Gbpsで、 threshold-value が200Mbps以上に設定されている場合、 threshold-value は200Mbpsに制限されます。 threshold-percent は20.000%、 threshold-value は200Mbpsと表示されます。

注:

threshold-percentthreshold-valueの2つのオプションは相互に排他的です。ある時点で1つのオプションのみを設定して、帯域幅予約を低くするためのIGP更新を生成することができます。その結果、一方のオプションを設定したときに、もう一方のオプションが計算され、CLIに表示されます。

例えば、1Gbpsのリンクで、 threshold-percent が5%に設定されている場合、 threshold-value は計算され、50Mbpsと表示されます。同様に、 threshold-value が50mに設定されている場合、 threshold-percent は計算され、5%と表示されます。

予約された帯域幅の変更により IGP の更新がトリガーされるしきい値を調整するには、 update-threshold ステートメントを含めます。update thresholdがあるため、制限付き最短パスファースト(CSPF)は、リンク上の古いトラフィック制御データベースの帯域幅情報を使用してパスを計算することができます。RSVPがそのパスを介してLSPの確立を試みた場合、そのリンクの帯域幅が不十分であると判断される可能性があります。この場合、RSVPはIGPトラフィック制御データベースの更新をトリガーし、ネットワーク上に更新された帯域幅情報をフラッディングします。その後、CSPFは更新された帯域幅情報を使用してパスを再計算し、混雑しているリンクを避けて別のパスを検索できます。なお、この機能はデフォルトであり、追加の設定は不要です。

[edit protocols mpls]階層レベルまたは[edit logical-systems logical-system-name protocols mpls]階層レベルでrsvp-error-hold-timeステートメントを設定することで、PathErrメッセージから提供される情報を使用して、トラフィック制御データベースの精度(LSPの帯域幅推定の精度を含む)を向上させることができます。RSVP PathErrメッセージによるトラフィック制御データベースの精度向上を参照してください。

番号なしインターフェイスのRSVPの設定

Junos OSは、番号なしインターフェイスを介したRSVPトラフィックエンジニアリングをサポートしています。番号なしリンクに関するトラフィック制御情報は、RFC 4203の「 一般化マルチプロトコルラベルスイッチング(GMPLS)をサポートするOSPF拡張機能」、およびRFC 4205の「一般 化マルチプロトコルラベルスイッチング(GMPLS)をサポートする中間システムから中間システム(IS-IS)への拡張」に記載されているように、OSPFおよびIS-ISのIGPトラフィック制御拡張機能で伝送されます.番号なしリンクは、RFC 3477の「 リソース予約プロトコル内の番号なしリンクのシグナル化 - トラフィックエンジニアリング(RSVP-TE)」に記載されているように、MPLSトラフィックエンジニアリングシグナリングで指定することもできます。この機能により、RSVP信号ネットワークに参加する各インターフェイスに対してIPアドレスを設定する必要がなくなります。

番号なしインターフェイスにRSVPを設定するには、[edit routing-options]階層レベルで指定されたrouter-idステートメントを使用して、ルーター IDでルーターを設定する必要があります。ルーターIDはルーティングで利用できなければなりません(通常はループバックアドレスを使用できます)。番号なしリンクのRSVP制御メッセージは、(ランダムに選択されたアドレスではなく)ルーターIDアドレスを使用して送信されます。

番号なしインターフェイスを有効にしたルーターでリンク保護と高速再ルートを設定するには、少なくとも2つのアドレスを設定する必要があります。ルーターIDの設定に加えて、ループバックでセカンダリインターフェイスを設定することをお勧めします。

RSVPノードID Hellosの設定

ノードIDベースのRSVP hellosを設定することで、ジュニパーネットワークスのルーターを他のベンダーの機器と相互運用することができます。デフォルトでは、Junos OSはインターフェイスベースのRSVP hellosを使用します。ノードIDベースのRSVP helloは、RFC 4558、 ノードIDベースのリソース予約プロトコル(RSVP)hello:明確化ステートメントで指定されています。RSVPノードID hellosは、BFDがRSVPインターフェイス上の問題を検出するように設定されている場合に便利で、これらのインターフェイスに対するインターフェイスhellosを無効にすることができます。また、ノードID hellosをグレースフルリスタート手順に使用することもできます。

ノードID hellosは、すべてのRSVPネイバーに対してグローバルに有効にできます。デフォルトでは、ノードID helloサポートは無効になっています。ルーターでRSVPノードIDを有効にしていない場合、Junos OSはノードID helloパケットを受け入れません。

注:

リリース16.1以降、Junosは、利用可能な場合、RSVP HelloメッセージをバイパスLSP経由で送信します。IGPネクストホップ経由でhellosを送信するこれまでの動作に戻す方法については、 no-node-hello-on-bypass をご覧ください。

ルーターでRSVPノードID hellosをグローバルに有効にするには、以下の階層レベルで node-hello ステートメントを含めます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

また、RSVPインターフェイスhellosをグローバルに明示的に無効にすることもできます。このタイプの設定は、ジュニパーネットワークスのルーターが他のベンダーの機器と多数のRSVP接続を行っているネットワークで必要となる場合があります。ただし、RSVPインターフェイスhellosをグローバルに無効にすると、 hello-interval ステートメントを使用してRSVPインターフェイスでhelloインターバルを設定することもできます。この設定では、RSVPインターフェイスhellosをグローバルに無効にしますが、指定されたインターフェイス( hello-interval ステートメントを設定するRSVPインターフェイス)ではRSVPインターフェイスhellosを有効にします。この設定は、一部のデバイスがRSVPノードID hellosをサポートし、他のデバイスがRSVPインターフェイスhellosをサポートするような異種混合ネットワークで必要となる場合があります。

ルーターでRSVPインターフェイスhellosをグローバルに無効にするには、以下の階層レベルで no-interface-hello ステートメントを含めます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-systems-name protocols rsvp]

例:RSVP シグナル化 LSP の設定

この例では、シグナリング プロトコルとして RSVP を使用して、IP ネットワーク内のルーター間に LSP を作成する方法を示します。

要件

開始する前に、デバイスからセキュリティ サービスを削除します。 例:セキュリティ サービスの削除を参照してください。

概要とトポロジー

RSVP をシグナリング プロトコルとして使用することで、IP ネットワーク内のルーター間で LSP を作成できます。この例では、 図 1 に示すようにサンプル ネットワークを設定します。

トポロジー

図1:典型的なRSVPシグナル化LSP Network topology diagram showing routers R1-R7, C1, C2 within AS 65010 and AS 65020. Arrows indicate data flow.

ルーター間でLSPを確立するには、個別にMPLSファミリーを有効にし、MPLSネットワークの各トランジットインターフェイスでRSVPを設定する必要があります。この例では、ge-0/0/0 トランジット インターフェイスで MPLS を有効にし、RSVP を設定する方法を示します。さらに、ネットワーク内のすべての MPLS インターフェイスで MPLS プロセスを有効化する必要があります。

この例では、R7 のループバック アドレス(10.0.9.7)を使用して、ingressルーター(R1)で R1 から R7 への LSP を定義する方法を示します。設定は、10Mbpsの帯域幅を予約します。さらに、この設定では CSPF アルゴリズムを無効にして、ホスト C1 とホスト C2 がネットワーク IGP の最短パスに対応する RSVP シグナル付き LSP を使用するようにしています。

設定

手順

CLIクイックコンフィグレーション

この例を簡単に設定するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、コマンドを [edit] 階層レベルのCLIにコピー&ペーストしてください。

ステップバイステップの手順

次の例では、設定階層のさまざまなレベルに移動する必要があります。CLIのナビゲーションについては、『CLIユーザーガイド』の「設定モードでのCLIエディターの使用」を参照してください。

RSVP を設定するには:

  1. MPLS ネットワークのすべてのトランジット インターフェイスで MPLS ファミリーを有効にします。

  2. MPLS ネットワークの各トランジット インターフェイスで RSVP を有効にします。

  3. MPLS ネットワークのトランジット インターフェイスで MPLS プロセスを有効にします。

  4. ingressルーターのLSPを定義します。

  5. LSP の帯域幅 10 Mbpsを予約します。

結果

設定モードから show コマンドを入力して、設定を確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

簡潔にするために、この show コマンド出力には、この例に関連する設定のみ含まれています。システム上のその他の設定はすべて省略記号(...)で置き換えられています。

デバイスの設定が完了したら、設定モードから コミット を入力します。

検証

設定が正常に機能していることを確認するには、以下のタスクを実行します。

RSVPネイバーの検証

目的

各デバイスに適切な RSVP ネイバーが表示されていることを確認します( 例えば、図 1 のルーター R1 では、ルーター R3 とルーター R2 の両方が RSVP ネイバーとしてリストされています)。

アクション

CLIから show rsvp neighbor コマンドを入力します。

出力には、隣接するルーターのIPアドレスが表示されます。隣接する各 RSVP ルーター ループバック アドレスがリストされていることを確認します。

RSVP セッションの検証

目的

すべての RSVP ネイバー間で RSVP セッションが確立されていることを確認します。また、帯域幅予約値がアクティブであることも確認します。

アクション

CLIから show rsvp session detail コマンドを入力します。

出力には、確立された各RSVPセッションのセッションID、帯域幅予約、ネクストホップアドレスなどの詳細情報が表示されます。次の情報を確認します。

  • 各RSVPネイバーアドレスには、ループバックアドレスごとにリストされた各ネイバーのエントリがあります。

  • 各 LSP セッションの状態は Up です。

  • Tspecの場合、適切な帯域幅値である10Mbpsが表示されます。

RSVP シグナル化 LSP の存在を検証

目的

エントリー(イングレス)ルーターのルーティングテーブルに、もう一方のルーターのループバックアドレスへのLSPが設定されていることを確認します。例えば、図 1 の R1 エントリー ルーターの inet.3 ルーティングテーブルに、ルーター R7 のループバック アドレスへの LSP が設定されていることを確認します。

アクション

CLIから show route table inet.3 コマンドを入力します。

出力は、 inet.3 ルーティングテーブルに存在する RSVP ルートを示しています。RSVPシグナル付きLSPが、MPLSネットワーク内の出口(エグレス)ルーターR7のループバックアドレスに関連付けられていることを確認します。

例:RSVP 自動メッシュの設定

サービスプロバイダは、収益を上げるサービスを提供しながら、ネットワークを効率的に拡張するために、BGPおよびMPLS VPNをよく使用します。このような環境では、BGP はサービス プロバイダのネットワーク全体に VPN ルーティング情報を配布するために使用され、MPLS はその VPN トラフィックをある VPN サイトから別の VPN サイトへ転送するために使用されます。

BGP および MPLS ルーターに参加する新しい PE ルーターを追加する場合、以前から存在するすべての PE ルーターは、BGP と MPLS の両方で新しい PE ルーターとピアリングするように設定する必要があります。サービスプロバイダのネットワークに新しいPEルーターが追加されるたびに、設定の負担が大きくなっていきます。

BGPピアリングの設定要件は、ルートリフレクタを使用することで軽減できます。RSVP シグナルによる MPLS ネットワークでは、RSVP 自動メッシュにより、ネットワークの MPLS 部分の設定負担を最小限に抑えることができます。すべての PE ルーターで rsvp-te を設定することで、新しい PE ルーターが追加されたときに、RSVP が必要な LSP を自動的に作成できます。

要件

この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。

  • Junos OSリリース10.1以降を実行しているルーター。

  • MPLSラベルスイッチパス(LSP)シグナリングプロトコルとしてRSVPを使用したBGPおよびMPLS VPN。

概要

この例では、 rsvp-te 設定ステートメントを使用して、PE ルーターで RSVP 自動メッシュを設定する方法を示します。RSVP 自動メッシュが正しく機能するためには、フルメッシュ構成内のすべての PE ルーターに rsvp-te ステートメントが設定されている必要があります。これにより、後から追加された新しい PE ルーターも、 rsvp-te ステートメントで設定されていれば、自動メッシュ機能の恩恵を受けることができます。

この要件を考慮して、この例では新たに追加された PE ルーターの設定のみを示しています。既存のPEルーターでは、すでにRSVP自動メッシュが設定されていることを想定しています。

トポロジー

図 2 のトポロジーには、PE1、PE2、PE3 の 3 つの既存の PE ルーターがあります。PE4 を追加し、RSVP 自動メッシュが設定されます。クラウドはサービスプロバイダのネットワークを表しており、図の中央にネットワークアドレス192.0.2.0/24が表示されます。

図2:PEルーターを使用したサービスプロバイダネットワーク Network topology diagram with four Provider Edge routers PE1, PE2, PE3, PE4 connected in a mesh structure using IP range 192.0.2.0/24.

設定

RSVP 自動メッシュを設定するには、以下のタスクを実行します。

  • [edit routing-options dynamic-tunnels dynamic-tunnel-name]階層レベルでrsvp-te設定ステートメントを有効にする。

  • 必要な destination-networks 要素を設定します。

    この設定要素は、宛先ネットワークのIPv4プレフィックス範囲を指定します。指定したプレフィックス範囲内のトンネルのみを作成できます。

  • 必要な label-switched-path-template 要素を設定します。

    この設定要素は、 default-template または事前に設定された LSP テンプレートの名前を引数として取ります。 default-template は、ユーザー設定を必要としないシステム定義テンプレートです。

CLIクイックコンフィグレーション

この例を迅速に設定するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更した後、コマンドを [edit] 階層レベルのCLIにコピー&ペーストしてください。

PE4ルーター

RSVP 自動メッシュの設定

ステップバイステップの手順

次の例では、設定階層のさまざまなレベルに移動する必要があります。その方法の詳細については、『CLIユーザーガイド』の「構成モードでのCLIエディターの使用」を参照してください。

RSVP 自動メッシュを有効にするには。

  1. [edit routing-options dynamic-tunnels]階層レベルでrsvp-teを設定します。

  2. [edit routing-options dynamic-tunnels]階層レベルでdestination-networksを設定します。

結果

[edit routing-options dynamic-tunnels]階層レベルからshowコマンドを発行して、設定の結果を確認します。

検証

ルーター PE4 での RSVP 自動メッシュ トンネルの存在を検証

目的

新しく設定したPE4ルーターの動作を検証するには、運用モードから show dynamic-tunnels database コマンドを発行します。このコマンドは、動的トンネルを作成できる宛先ネットワークを表示します。

アクション

ルーター PE4 での MPLS LSP の存在を検証します。

目的

PE4 ルーターにMPLS LSPが存在することを確認するには、運用モードから show mpls lsp コマンドを発行します。このコマンドは、MPLS LSP の状態を表示します。

アクション

非セッションRSVPネイバーに対するHello応答の設定

hello-acknowledgementsステートメントは、同じセッションにいるかどうかに関わらず、RSVPネイバー間のHello確認動作を制御します。

共通の RSVP セッションに属さない RSVP ネイバーから受信した Hello メッセージは破棄されます。[edit protocols rsvp]階層レベルでhello-acknowledgementsステートメントを設定すると、非セッションネイバーからのhelloメッセージはhello確認メッセージで確認されます。非セッションネイバーからhelloを受信すると、RSVPネイバー関係が作成され、非セッションネイバーから定期的なhelloメッセージを受信できるようになります。hello-acknowledgements ステートメントはデフォルトで無効になっています。このステートメントを設定すると、RSVP対応ルータがhelloパケットを使用して検出され、MPLS LSP設定メッセージを送信する前にインタフェースがRSVPパケットを受信できることが確認されます。

非セッション RSVP ネイバーの Hello 確認を有効にすると、インターフェイス自体がダウンするか、設定を変更しない限り、ルーターは非セッション RSVP ネイバーからの Hello メッセージを確認し続けます。インターフェイスベースのネイバーは、自動的にエージングされません。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

ネットワークノードからのLSPのスイッチング

インターフェイスに対して有効にされたバイパスLSPを使用して、アクティブなLSPをネットワークノードからスイッチするようにルーターを設定できます。この機能は、ネットワークを通過するトラフィックを遮ることなく、デバイスを交換する必要がある場合、アクティブなネットワークを維持するために使用されることがあります。LSP は、静的または動的のいずれかです。

  1. まず、無効化したいネットワークデバイスを迂回する必要があるトラフィックに対して、リンク保護またはノード保護を設定する必要があります。適切に機能させるには、バイパスLSPは、保護されたLSPとは異なる論理インターフェイスを使用する必要があります。
  2. ネットワークノードからトラフィックのスイッチングを開始するためのルーターを準備するには、 always-mark-connection-protection-tlv ステートメントを設定します。

    そして、ルーターは、OAM機能に基づいた代替パスにトラフィックをスイッチするのに備えて、このインターフェイスを通過するすべてのOAMトラフィックをマークします。

    以下の階層レベルでこのステートメントを設定できます。

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

  3. 次に、 switch-away-lsps ステートメントを設定して、保護されたLSPからバイパスLSPにトラフィックをスイッチし、効果的にデフォルトのダウンストリームネットワークデバイスをバイパスする必要があります。実際のリンク自体は、この設定によって停止することはありません。

    ネットワークノードからトラフィックをスイッチするルーターを設定するには、 switch-away-lsps ステートメントを設定します。

    以下の階層レベルでこのステートメントを設定できます。

    • [edit protocols mpls interface interface-name]

    • [edit logical-systems logical-system-name protocols mpls interface interface-name]

ネットワークノードからアクティブなLSPをスイッチするのに関連する、以下の制限にご留意ください。

  • スイッチアウェイ機能は、MXシリーズルーターのみで対応されています。

  • スイッチアウェイ機能は、プライマリポイントツーマルチポイントLSPからバイパスポイントツーマルチポイントLSPへのトラフィックスイッチングには対応していません。ポイントツーマルチポイントLSPに switch-away-lsps ステートメントを設定すると、トラフィックはバイパスポイントツーマルチポイントLSPにスイッチされません。

  • 動的LSPのパスに沿うインターフェイスにスイッチアウェイ機能を設定すると、そのパス上で新しい動的LSPを確立することはできません。スイッチアウェイ機能は、RSVP信号LSPの事前対応動作を防止します。通常、事前対応の動作により、ルーターは、元のLSPを破棄する前に、まず動的LSPへの再シグナリングを試みます。

RSVP セットアップ保護の設定

施設バックアップの高速再ルート メカニズムを設定して、シグナリングされるプロセス中の LSP のセットアップ保護を提供できます。ポイントツーポイント LSP とポイントツーマルチポイント LSP の両方がサポートされています。この機能は、以下のシナリオに適用されます。

  1. LSP がシグナリングされる前に、LSP の厳密な明示的パスに障害が発生したリンクまたはノードが存在します。

  2. また、リンクまたはノードを保護するバイパスLSPもあります。

  3. RSVP は、バイパス LSP を介して LSP にシグナリングします。LSP は、最初にプライマリ パスに沿って設定されているように見え、リンクまたはノード障害が発生したため、バイパス LSP にフェイルオーバーしました。

  4. リンクまたはノードが回復すると、LSP をプライマリ パスに自動的に復帰できます。

LSP セットアップ保護を有効にしたい LSP パスに沿った各ルーターの[edit protocols rsvp]setup-protection ステートメントを設定する必要があります。また、LSP パス上のすべてのルーターで IGP トラフィック制御を設定する必要があります。show rsvp session コマンドを発行して、LSP が PLR(Point of Local Repair)またはマージ ポイントとして機能するルーターでセットアップ保護が有効になっているかどうかを確認できます。

RSVP セットアップ保護を有効にするには、 setup-protection ステートメントを含めます

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

RSVP LSP 間のロード バランシングの設定

デフォルトでは、同じegressルーターに複数のRSVP LSPを設定した場合、メトリックが最も低いLSPが選択され、すべてのトラフィックを伝送します。すべてのLSPのメトリックが同じ場合、LSPの1つがランダムに選択され、すべてのトラフィックがその上に転送されます。

または、パケットごとのロードバランシングを有効にすることで、すべてのLSP間でトラフィックのロードバランシングを行うこともできます。

イングレスLSPでパケットごとのロードバランシングを有効にするには、 policy-statement ステートメントを次のように設定します。

次に、このステートメントをエクスポートポリシーとして転送テーブルに適用する必要があります。

パケットごとのロードバランシングが適用されると、トラフィックはLSP間で均等に分散されます(デフォルト)。

PFEの高速再ルートを有効にする場合は、パケットごとのロードバランシングを設定する必要があります。PFE 高速再ルートを有効にするには、再ルートが発生する可能性のある各ルーターの設定に、このセクションに示されているパケットごとのロードバランシングに対する policy-statement ステートメントを含めます。 高速再ルートの設定も参照してください。

また、各LSPに設定された帯域幅の量に比例して、LSP間のトラフィックをロードバランシングすることもできます。LSPの設定された帯域幅は通常、そのLSPのトラフィック容量を反映するため、この機能により、外部リンク全体で非対称帯域幅機能を備えたネットワークでトラフィックをより適切に分散できます。

RSVP LSP ロードバランシングを設定するには、bandwidthオプションにload-balanceステートメントを含めます。

以下の階層レベルでこのステートメントを設定できます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

load-balanceステートメントを使用する場合は、以下の情報に注意してください。

  • load-balanceステートメントを設定すると、現在実行中のLSPの動作は変更されません。現在実行中のLSPに新しい動作を強制的に使用させるには、clear mpls lspコマンドを発行します。

  • load-balanceステートメントは、パケット単位のロードバランシングが有効になっているイングレスLSPにのみ適用されます。

  • 差別化サービスを意識したトラフィックエンジニアリングLSPの場合、LSPの帯域幅はすべてのクラスタイプの帯域幅を合計して計算されます。

RSVP 自動メッシュの設定

LSPのフルメッシュに追加された新しいPEルーターに対して、ポイントツーポイントのラベルスイッチパス(LSP)を自動的に確立するようにRSVPを設定することができます。この機能を有効にするには、フルメッシュのすべてのPEルーターで rsvp-te ステートメントを設定する必要があります。

注:

CCCと組み合わせてRSVP自動メッシュを設定することはできません。CCCは動的に生成されたLSPを使用できません。

RSVP自動メッシュを設定するには、 rsvp-te ステートメントを含めます。

これらのステートメントは、以下の階層レベルで設定することができます。

  • [edit routing-options dynamic-tunnels tunnel-name]

  • [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name]

また、RSVP自動メッシュを有効にするには、以下のステートメントを設定する必要があります。

  • destination-networks—宛先ネットワークのIPバージョン4(IPv4)プレフィックス範囲を指定します。指定したIPv4プレフィックス範囲内の動的トンネルを開始することができます。

  • label-switched-path-template (Multicast)default-template オプションを使用して明示的にデフォルトのテンプレートを設定することも、 template-name オプションを使用して独自のLSPテンプレートを設定することもできます。LSPテンプレートは、動的に生成されるLSPのモデル設定として機能します。

RSVP更新メッセージのタイマーの設定

RSVP では、関連する 2 つのタイミングパラメーターを使用します。

  • refresh-time—更新時間は、連続したRSVP状態更新メッセージの生成間の間隔を制御します。更新時間(R)のデフォルト値は、RFC 8370で推奨されているように、1200秒または20分です。 set protocols rsvp no-enhanced-frr-bypass ステートメントを設定すると、更新時間は30秒に設定されます。ネットワークで更新メッセージの同期を回避するために、状態の更新時間は、RFC 2205で指定されたように、0.5Rおよび1.5Rの範囲の値にランダムに設定されます。

    更新メッセージには、パスメッセージとResvメッセージが含まれます。隣接ノードの予約状態がタイムアウトしないように、更新メッセージが定期的に送信されます。各パスとResvメッセージには更新タイマー値が伝送され、受信側はメッセージからこの値を抽出します。

  • keep-multiplier—Keep Multiplier は、1 から 255 までのローカルに設定された小さな整数です。デフォルト値は3です。特定の状態が古いと宣言され削除されるまでに、失うことができるメッセージの数を示します。Keep Multiplierは、RSVP状態の存続期間に直接的な影響を与えます。

予約状態の存続期間を決定するには、以下の式を使用します。

最悪なケースの場合、予約状態が削除されるまでに(keep-multiplier – 1)個の連続した更新メッセージが失われる必要があります。

デフォルトでは、更新タイマー値は1200秒です。 no-enhanced-frr-bypass ステートメントを設定すると、更新タイマー値は30秒になります。この値を変更するには、 refresh-time ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

Keep Multiplier のデフォルト値は 3 です。この値を変更するには、 keep-multiplier ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

RSVPセッションのプリエンプト

すべてのRSVPセッションを処理するのに帯域幅が不十分な場合はいつでも、RSVPセッションのプリエンプションを制御できます。デフォルトでは、RSVPセッションは、新しい優先度の高いセッションでのみプリエンプトされます。

帯域幅が不十分な場合に常にセッションをプリエンプトするには、aggressiveオプションにpreemptionステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

RSVPセッションプリエンプションを無効にするには、disabledオプションにpreemptionステートメントを含めます。

デフォルトに戻す(つまり、新しい優先度の高いセッションに対してのみセッションをプリエンプトする)には、normalオプションにpreemptionステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

RSVP での MTU シグナリングの設定

RSVP で最大送信単位(MTU)シグナリングを設定するには、IP パケットが MPLS にカプセル化される前にフラグメント化できるように MPLS を設定する必要があります。また、RSVP で MTU シグナリングを設定する必要があります。トラブルシューティングのために、パケットのフラグメント化を有効にせずに、MTUシグナリングのみを設定することができます。

RSVP でMTUシグナリングを設定するには、 path-mtu ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

以下のセクションでは、RSVP でパケット フラグメント化と MTU シグナリングを有効にする方法について説明します。

RSVP における MTU シグナリングの有効化

RSVP で MTU シグナリングを有効にするには、 rsvp mtu-signaling ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

設定をコミットすると、RSVP の MTU シグナリング動作の変更は、次回パスが更新されたときに有効になります。

[edit protocols mpls path-mtu rsvp]階層レベルでmtu-signalingステートメントを単独で設定できます。これはトラブルシューティングに有効です。mtu-signalingステートメントだけを設定すると、show rsvp session detailコマンドを使用してLSP上の最小MTUが何かを判断することができます。show rsvp session detailコマンドは、Adspecオブジェクトで送受信したMTU値を表示します。

パケットフラグメント化の有効化

IP パケットを MPLS でカプセル化する前にフラグメント化できるようにするには、 allow-fragmentation ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls path-mtu]

  • [edit logical-systems logical-system-name protocols mpls path-mtu]

    注:

    allow-fragmentation ステートメントだけで設定しないでください。必ずmtu-signalingステートメントと合わせて設定してください。

RSVP信号化MPLS LSPに最終ホップポッピングを設定する

デフォルトでは、RSVPシグナル化されたLSPは、最後から2番目のホップポッピング(PHP)を使用します。 図3 は、ルーターPE1とルーターPE2の間の最後から2番目のホップポッピングLSPを示しています。ルーターCE1は、パケットをそのネクストホップ(ルーターPE1)に転送します。これは、LSP ingressでもあります。ルーターPE1は、パケットにラベル1をプッシュし、ラベル付きパケットをルーターP1に転送します。ルーターP1は、ラベル1とラベル2を入れ替える標準的なMPLSラベル入れ替え操作を完了し、パケットをルーターP2に転送します。ルーターP2は、LSPからルーターPE2への最後から2番目のホップルーターであるため、まずラベルをポップし、次にパケットをルーターPE2に転送します。ルーターPE2がそれを受信すると、パケットはサービスラベル、明示的nullラベル、または単に普通のIPまたはVPLSパケットにすることができます。ルーターPE2は、ラベルなしパケットをルーターCE2に転送します。

図3:LSPNetwork diagram of MPLS architecture with CE routers CE1 and CE2, PE routers PE1 and PE2, and P routers P1 and P2. Data packets labeled L1 and L2 show flow direction.の最後から2番目のホップポッピング

また、RSVP信号LSPにUHP(最終ホップポッピング)( 図4を参照)を設定することもできます。一部のネットワークアプリケーションでは、パケットが非nullの外部ラベルとともにegressルーター(ルーターPE2)に到達することを求めることがあります。最後のホップポッピングLSPに対して、最後から2番目のルーター( 図4のルーターP2)は、標準的なMPLSラベル入れ替え操作(この例では、ラベル2をラベル3に入れ替える)を実行してから、パケットをエグレスルーターPE2に転送します。ルーターPE2は、外側ラベルをポップし、パケットアドレスの2回目のルックアップを実行して、最終宛先を決定します。次に、適切な宛先(ルーターCE2またはルーターCE4)にパケットを転送します。

図4:LSPNetwork diagram showing data flow between CE, PE, and P routers in an MPLS network, with IP and MAC labels.の最終ホップポッピング

以下のネットワークアプリケーションでは、UHP LSPを設定する必要があります。

  • パフォーマンス監視とインバンドOAMのためのMPLS-TP

  • エッジ保護仮想回線

以下の機能はUHP動作をサポートしていません。

  • LDPシグナルのLSP

  • 静的LSP

  • ポイントツーマルチポイントLSP

  • CCC

  • traceroute コマンド

UHP動作の詳細については、インターネットドラフトdraft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt、 非PHP動作、RSVP TE LSPのアウトオブバンドマッピングを参照してください。

ポイントツーポイントRSVP信号化LSPの場合、UHP動作はLSP ingressからシグナリングされます。ingressルーターの設定に基づいて、RSVPは非PHPフラグセットでUHP LSPをシグナリングできます。RSVP PATHメッセージは、LSP-ATTRIBUTESオブジェクトで2つのフラグを伝送します。egressルーターがパスメッセージを受信すると、非nullラベルをLSPに割り当てます。また、RSVPはmpls.0ルーティングテーブルに2つのルートを作成し、インストールします。Sは、MPLSラベルのSビットを表し、ラベルスタックの最下部に到達したかどうかを示します。

  • ルートS=0—スタックにさらにラベルが存在することを示します。このルートのネクストホップはmpls.0ルーティングテーブルを指し示し、連鎖されたMPLSラベルルックアップをトリガーして、スタック内の残りのMPLSラベルを見つけ出します。

  • ルートS=1—ラベルがもう存在しないことを示します。プラットフォームが連鎖されたルックアップとマルチファミリのルックアップに対応している場合、ネクストホップはinet.0ルーティングテーブルを指します。または、ラベルルートが VT インターフェイスを指し示して、IP転送を開始することもできます。

UHP LSPを有効にすると、レイヤー3VPN、VPLS、レイヤー2VPN、レイヤー2回線などのMPLSアプリケーションはUHP LSPを使用することができます。以下に、UHP LSP がさまざまなタイプの MPLS アプリケーションにどのように影響するかについて説明します。

  • レイヤー2 VPNとレイヤー2回線—1つのパケットが2つのラベルとともにPEルーター(UHP LSPのegress)に到達します。外側ラベル(S=0)はUHPラベルで、内側ラベル(S=1)は VC ラベルです。トランスポートラベルに基づくルックアップは、mpls.0ルーティングテーブルのテーブルハンドルを獲得します。mpls.0 ルーティングテーブルには、内側ラベルに対応する追加ルートがあります。内側ラベルに基づくルックアップは、CEルーターのネクストホップを獲得します。

  • レイヤー3VPN—1つのパケットが2つのラベルとともにPEルーター(UHP LSPのegress)に到達します。外側ラベル(S=0)はUHPラベルで、内側ラベルはVPNラベル(S=1)です。トランスポートラベルに基づくルックアップは、mpls.0ルーティングテーブルのテーブルハンドルを獲得します。このシナリオには 2 つのケースがあります。デフォルトでは、レイヤー3VPNはネクストホップごとのラベルをアドバタイズします。内側ラベルに基づくルックアップは、CEルーターに向かうネクストホップを獲得します。ただし、レイヤー3VPNルーティングインスタンスに vrf-table-label ステートメントを設定している場合、内側 LSI ラベルはVRFルーティングテーブルを指します。VRFルーティングテーブルのIPルックアップも完了します。

    注:

    vrf-table-labelステートメントで設定されたレイヤー3 VPNのUHPは、MXシリーズ5Gユニバーサルルーティングプラットフォームでのみサポートされています。

  • VPLS—1つのパケットが2つのラベルとともにPEルーター(UHP LSPのegress)に到達します。外側ラベルはトランスポートラベル(S=0)で、内側ラベルはVPLSラベル(S=1)です。トランスポートラベルに基づくルックアップは、mpls.0ルーティングテーブルのテーブルハンドルを獲得します。mpls.0 ルーティングテーブルの内側ラベルに基づくルックアップは、トンネル-services が設定されていない(または VT インターフェイスが利用できない)場合、VPLS ルーティング インスタンスの LSI トンネル インターフェイスを獲得します。MX 3Dシリーズルーターは、連鎖されたルックアップとマルチファミリのルックアップに対応しています。

    注:

    no-tunnel-serviceステートメントで設定されたVPLSのUHPは、MX 3Dシリーズルーターのみでサポートされています。

  • IPv4 over MPLS—パケットは1つのラベル(S=1)とともにPEルーター(UHP LSPのegress)に到達します。このラベルに基づくルックアップは、VTトンネルインターフェイスを返します。もう1つのIPルックアップはVTインターフェイスで完了し、パケットの転送場所を決定します。ルーティングプラットフォームが、マルチファミリおよび連鎖されたルックアップ(例えば、MX 3DルーターやPTXシリーズパケットトランスポートルーター)をサポートする場合、ラベルルート(S=1)に基づくルックアップはinet.0ルーティングテーブルを指します。

  • IPv6 over MPLS—MPLS 上の IPv6 トンネリングでは、PE ルーターはラベル値 2 を使用して、IPv6 ルートを相互にアドバタイズします。これは、IPv6 の明示的な null ラベルです。その結果、リモートPEルーターから学習したIPv6ルートの転送ネクストホップは、通常2つのラベルをプッシュします。内側ラベルは2で(アドバタイズするPEルーターが他のベンダーのものである場合、異なることもあります)、ルーターラベルはLSPラベルです。パケットは、2つのラベルとともにPEルーター(UHP LSPのegress)に到達します。外側ラベルはトランスポートラベル(S=0)で、内側ラベルはIPv6明示的nullラベル(ラベル2)です。mpls.0 ルーティングテーブルの内側ラベルに基づくルックアップは、mpls.0 ルーティングテーブルにリダイレクトされます。MX 3Dシリーズルーターでは、内側ラベル(ラベル2)は取り除かれ、IPv6ルックアップはinet6.0ルーティングテーブルを使用して実行されます。

  • PHPとUHP LSPの両方の有効化—同じネットワークパス上でPHPとUHP LSPの両方を設定できます。 install-nexthop ステートメントとともに正規表現を使用する転送LSPネクストホップを選択することで、PHPとUHPトラフィックを分離できます。また、LSPに適切な名前を付けるだけで、トラフィックを分離することもできます。

以下のステートメントで、LSPの最終ホップポッピングを有効にします。特定のLSP上、またはルーターに設定されたすべてのingress LSPに対して、この機能を有効にできます。LSP ingressで、これらのステートメントをルーター上で設定します。

  1. 最終ホップ ポッピングを有効にするには、 ultimate-hop-popping ステートメントを含めます。

    このステートメントを[edit protocols mpls label-switched-path label-switched-path-name]階層レベルに含めて、特定のLSPで最終ホップポッピングを有効にします。このステートメントを[edit protocols mpls]階層レベルに含めて、ルーターに設定されたすべてのingress LSPで最終ホップポッピングを有効にします。また、同等の[edit logical-routers]階層レベルでultimate-hop-poppingステートメントを設定することもできます。

    注:

    最終ホップポッピングを有効にすると、RSVPは、事前対応方式で既存のLSPを最終ホップポッピングLSPとして再シグナルしようと試みます。egressルーターが最終ホップポッピングをサポートしていない場合、既存のLSPは破棄されます(RSVPはLSPのパスに沿って PathTearメッセージ を送信し、パス状態と依存予約状態を削除し、関連するネットワークリソースを解放します)。

    最終ホップポッピングを無効にすると、RSVPは既存のLSPを最後から2番目のホップポッピングLSPとして、再シグナルします。

  2. MX 3Dシリーズルーターのみに最終ホップポッピングと連鎖ネクストホップの両方を有効にする場合は、network-servicesステートメントのenhanced-ipオプションも設定する必要があります。

    このステートメントは、 [edit chassis] 階層レベルで設定します。 network-services ステートメントを設定したら、ルーターを再起動してUHP動作を有効にする必要があります。

最終ホップルーターでラベルをポップさせるRSVPの設定

LSPのエグレスegressルーターでアドバタイズされるラベル値を制御できます。デフォルトでアドバタイズされたラベルは、ラベル3(Implicit Nullラベル)です。ラベル3がアドバタイズされると、最後から2番目のホップルーターはラベルを削除し、パケットをegressルーターに送信します。最終ホップのポッピングが有効な場合、ラベル0(IPバージョン4 [IPv4]明示的なNullラベル)がアドバタイズされます。最終ホップのポッピングにより、MPLSネットワークを通過するすべてのパケットにラベルが含まれます。

注:

ジュニパーネットワークスのルーターは、着信ラベルに基づいてパケットをキューに入れます。他のベンダーのルーターは、パケットを個別にキューに入れる場合があります。複数のベンダーのルーターを搭載したネットワークで作業する場合は、この点に留意してください。

RSVPに最終ホップポッピングを設定するには、 explicit-null ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols mpls]

  • [edit logical-systems logical-system-name protocols mpls]

ポイントツーマルチポイント LSP での最終ホップ ポッピングの有効化

デフォルトでは、ポイントツーポイントおよびポイントツーマルチポイント LSP の両方で、MPLS トラフィックに最後から 2 番目のホップ ポッピングが使用されます。MPLSラベルは、LSPのegressルーターの直前に、ルーター上のパケットから削除されます。次に、プレーンIPパケットがegressルーターに転送されます。最終ホップ ポッピングでは、egressルーターがMPLSラベルの削除とプレインIPパケットの処理の両方を行います。

特にトラフィックが同じエグレス デバイスを通過する場合、ポイントツーマルチポイント LSP で最終ホップ ポッピングを有効にするのが有用な場合があります。最終ホップ ポッピングを有効にすると、トラフィックのコピーが 1 つ、受信リンクを介して送信され、帯域幅を大幅に節約できます。デフォルトでは、最終ホップ ポッピングは無効になっています。

tunnel-servicesステートメントを設定することで、ポイントツーマルチポイントLSPの最終ホップポッピングを有効にします。最終ホップ ポッピングを有効にすると、Junos OS は、利用可能な仮想ループバック トンネル(VT)インターフェイスの 1 つを選択して、IP 転送の PFE にパケットをループバックします。デフォルトでは、VT インターフェイスの選択プロセスは自動的に実行されます。帯域幅アドミッション制御は、1 つの VT インターフェイスで使用できる LSP の数を制限するために使用されます。1 つのインターフェイスですべての帯域幅が消費されると、Junos OS は、アドミッション制御に十分な帯域幅を持つ別の VT インターフェイスを選択します。

LSP が必要とする帯域幅がどの VT インターフェイスから利用可能な帯域幅よりも大きくなった場合、最終ホップ ポッピングを有効にすることはできず、代わりに最後から 2 番目のホップ ポッピングが有効になります。

ポイントツーマルチポイント LSP の最終ホップ ポッピングが正しく機能するためには、egressルーター に、トンネル サービス PIC やアダプティブ サービス PIC などのトンネルサービスを提供する PIC が必要です。最終的な MPLS ラベルのポッピングと IP アドレス ルックアップのためのパケットの返送には、トンネル サービスが必要です。

tunnel-services ステートメントの devices オプションを含めることで、どの VT インターフェイスが RSVP トラフィックを処理するかを明示的に設定できます。devicesオプションでは、RSVP によって使用される VT インターフェイスを指定できます。このオプションを設定しない場合、ルーターで使用可能なすべての VT インターフェイスを使用できます。

ルーター上のエグレス ポイントツーマルチポイント LSP の最終ホップ ポッピングを有効にするには、 tunnel-services ステートメントを設定します。

以下の階層レベルでこのステートメントを設定できます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

エグレス ポイントツーマルチポイント LSP の最終ホップ ポッピングを有効にするには、all オプションで interface ステートメントを設定する必要もあります。

このステートメントは、 [edit protocols rsvp] 階層レベルで設定する必要があります。

RSVPプロトコルトラフィックのトレーシング

RSVPプロトコルトラフィックをトレースするには、 traceoptions ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit protocols rsvp]

  • [edit logical-systems logical-system-name protocols rsvp]

RSVP traceoptions ステートメントで、以下のRSVP固有のフラグを指定できます。

file ステートメントを使用して、トレース操作の出力を受信するファイル名を指定します。すべてのファイルがディレクトリ/var/logに配置されます。RSVPトレーシングの出力は、ファイルrsvp-logに置くことをお勧めします。

  • all—すべてのトレーシング操作。

  • error—すべての検出されたエラー状態

  • event—RSVP関連のイベント(RSVPグレースフルリスタートに関連するイベントをトレースするのに役立ちます)

  • lmp—RSVPとリンク管理プロトコル(LMP)の相互作用

  • packets—すべてのRSVPパケット

  • path—すべてのパスメッセージ

  • pathtear—PathTearメッセージ

  • resv—Resvメッセージ

  • resvtear—ResvTearメッセージ

  • route—ルーティング情報

  • state—RSVP信号化されたLSPの立ち上がりと終了を含むセッション状態の遷移。

注:

allトレースフラグとdetailフラグ修飾子は、CPUが非常にビジー状態になる可能性があるため、注意して使用してください。

RSVPトレースオプションを有効にしたときに生成されるログファイルを表示するには、 show log file-name コマンドを発行します。ここで file-nametraceoptions ステートメントを使用して指定したファイルです。

トレーシングとグローバルトレーシングオプションに関する一般的な情報については、 ルーティングデバイス用Junos OSルーティングプロトコルライブラリを参照してください。

例:RSVPプロトコルトラフィックのトレース

RSVPパスメッセージを詳細にトレースします。

すべてのRSVPメッセージをトレースします。

すべてのRSVPエラー状態をトレースします。

RSVP 状態遷移をトレースします。

RSVPログファイル出力

以下は、stateフラグを設定してRSVPトレースオプションが有効になっているルーターでshow log file-nameコマンドを発行することで生成される出力例です。RSVP信号化されたLSP E-Dは、3月11日14:04:36.707092に破棄されていることが示されています。3月11日14:05:30.101492には、再び立ち上げられています。

RSVP グレースフル リスタート

RSVP グレースフル リスタートにより、再起動中のルーターがその状態を隣接するネイバーに通知できます。再起動するルーターは、ネイバーまたはピアに猶予期間を要求し、その後、再起動するルーターと協力することができます。再起動中のルーターは、再起動期間中もMPLSトラフィックを転送できます。ネットワークのコンバージェンスは中断されません。再起動はネットワークの他の部分に表示されず、再起動中のルーターはネットワーク トポロジーから削除されません。RSVP グレースフル リスタートは、トランジット ルーターとイングレス ルーターの両方で有効にできます。ポイントツーポイント LSP とポイントツーマルチポイント LSP の両方で使用できます。

RSVP グレースフル リスタートは、以下のセクションで説明されています。

RSVPグレースフルリスタート用語集

再起動時間(ミリ秒単位)

デフォルト値は60,000ミリ秒(1分)です。再起動時間はhelloメッセージ内にアドバタイズされます。この時間は、再起動しているルーターからhelloメッセージを受信してから、そのルーターを停止したと宣言して状態をパージするまでの、ネイバーが待機する時間を示します。

Junos OSは、アドバタイズされたリスタート時間がローカルリスタート時間の3分の1よりも大きい場合に、ネイバーのアドバタイズされたリスタート時間を上書きすることができます。例えば、デフォルトの再起動時間が60秒の場合、ルーターは再起動するネイバーからのHelloメッセージを受信するまで、最長で20秒間待機します。再起動時間がゼロの場合、再起動しているネイバーは、即時に停止と宣言することができます。

回復時間(ミリ秒単位)

リスタート時間前に制御チャネルが立ち上がっている(hello交換が完了している)場合にのみ適用されます。ノードの障害にのみ適用されます。

グレースフル リスタートが進行中の場合は、回復が完了するまでの時間がアドバタイズされます。その他の場合には、この値はゼロになります。アドバタイズされた回復時間は最大2分(120,000ミリ秒)です。

回復時間中、再起動するノードは、ネイバーのサポートを得ながら失われた状態を回復しようと試みます。再起動するノードのネイバーは、回復時間の半分の時間内に、回復ラベルを含むパスメッセージを再起動するノードに送信する必要があります。再起動するノードは、アドバタイズされた回復時間の終了後にグレースフルリスタートが完了したとみなします。

RSVPグレースフルリスタート動作

RSVP グレースフル リスタートが機能するには、グローバル ルーティング インスタンスでこの機能を有効にする必要があります。RSVPグレースフルリスタートは、プロトコルレベル(RSVPのみの場合)またはすべてのプロトコルのグローバルレベルで無効にできます。

RSVPグレースフルリスタートには、再起動するルーターとルーターのネイバーの次のものが必要です。

  • 再起動ルーターの場合、RSVPグレースフルリスタートは、RSVPによってインストールされたルートと割り当てられたラベルを維持しようとするため、トラフィックは中断することなく転送され続けます。RSVPグレースフルリスタートは、隣接ノードへの影響を軽減または排除するのに十分な速さで実行されます。

  • 隣接ルーターでは、RSVPグレースフルリスタートヘルパーモードが有効になっている必要があります。これにより、RSVPをリスタートしようとするルーターを支援できます。

RSVP helloメッセージで送信されるリスタートキャップと呼ばれるオブジェクトは、ノードの再起動機能をアドバタイズします。隣接ノードは、リカバリーラベルオブジェクトを再起動ノードに送信して、転送状態を回復します。このオブジェクトは基本的に、ノードがダウンする前に再起動ノードがアドバタイズした古いラベルです。

次に、RSVPグレースフルリスタート動作を示します。設定および有効になっている機能によって異なります。

  • ヘルパーモードを無効にすると、Junos OSはネイバーがRSVPを再起動するのを支援しようとしません。ネイバーからリスタートキャップオブジェクトとともに到着する情報はすべて無視されます。

  • ルーティングインスタンス設定でグレースフルリスタートを有効にすると、ルーターはネイバーの助けを借りてグレースフルリスタートできます。RSVPは、再起動時間と回復時間(どちらの値も0ではない)が指定されているhelloメッセージで再起動キャップオブジェクト(RSVP RESTART)をアドバタイズします。

  • [protocols rsvp]階層レベルでRSVPグレースフルリスタートを明示的に無効にすると、再起動キャップオブジェクトは再起動時間と回復時間を0として指定してアドバタイズされます。隣接ルーターの再起動はサポートされますが(ヘルパーモードが無効になっていない場合)、ルーター自体はRSVP転送状態を保持せず、制御状態を回復できません。

  • 再起動後、RSVPが転送状態が保持されていないことを認識した場合、再起動キャップオブジェクトは、再起動時間と回復時間を0として指定してアドバタイズされます。

  • グレースフル リスタートとヘルパー モードが無効になっている場合、RSVP グレースフル リスタートは完全に無効になります。ルーターは、RSVPグレースフルリスタートオブジェクトを認識もアドバタイズもしません。

再起動時間と回復時間の値を明示的に設定することはできません。

他のプロトコルとは異なり、RSVPは、固定タイムアウト以外に、再起動手順が完了したと判断する方法はありません。すべてのRSVPグレースフルリスタート手順はタイマーベースです。 show rsvp version コマンドは、すべてのRSVPセッションがバックアップされ、ルートが復元されている場合でも、再起動がまだ進行中であることを示している場合があります。

リスタート キャップ オブジェクトの処理

Restart Capオブジェクトに基づくネイバーについて、以下の仮定を行う(制御チャネル障害とノード再起動を明確に区別できると仮定する)。

  • helloメッセージでRestart Capオブジェクトをアドバタイズしないネイバーは、状態やラベルの回復でルーターを支援することができず、RSVPグレースフルリスタートを実行することもできません。

  • 再起動後、任意の値に等しい再起動時間と0に等しい回復時間を持つRestart Capオブジェクトを広告するネイバーは、その転送状態を保存していません。回復時間が0になると、再起動時間の値に関係なく、ネイバーは死んだとみなされ、このネイバーに関連するすべてのステートがパージされます。

  • 再起動後、0以外の値で回復時間をアドバタイズしているネイバーは、転送状態を維持できる、または維持していた。ローカルルーターが隣人の再起動または回復手順を支援している場合、この隣人にRecover Labelオブジェクトを送信します。

RSVP グレースフル リスタートの設定

以下の RSVP グレースフル リスタート設定が可能です。

  • グレースフル リスタートとヘルパー モードの両方が有効になっています(デフォルト)。

  • グレースフル リスタートは有効ですが、ヘルパー モードは無効です。この方法で設定されたルーターはグレースフルに再起動できますが、再起動と回復手順でネイバーを支援できません。

  • グレースフル リスタートは無効ですが、ヘルパー モードは有効です。このように設定されたルーターは正常に再起動できませんが、ネイバーの再起動には役立ちます。

  • グレースフル リスタートとヘルパー モードの両方が無効です。この設定は、RSVP グレースフル リスタート(再起動および回復手順とヘルパー モードを含む)を完全に無効にします。ルーターは、RSVP グレースフル リスタートをサポートしていないルーターのように動作します。

注:

RSVP グレースフル リスタートを有効にするには、グローバル グレースフル リスタート タイマーを少なくとも 180 秒に設定する必要があります。

以下のセクションでは、RSVP グレースフル リスタートの設定方法について説明します。

すべてのルーティング プロトコルでグレースフル リスタートを有効にする

RSVP のグレースフル リスタートを有効にするには、ルーターでグレースフル リスタートをサポートするすべてのプロトコルのグレースフル リスタートを有効にする必要があります。グレースフル リスタートの詳細については、 ルーティング デバイス用 Junos OS ルーティング プロトコル ライブラリを参照してください。

ルーターでグレースフル リスタートを有効にするには、 graceful-restart ステートメントを含めます。

以下の階層レベルでこのステートメントを含めることができます。

  • [edit routing-options]

  • [edit logical-systems logical-system-name routing-options]

RSVP のグレースフル リスタートの無効化

デフォルトでは、グレースフル リスタートを有効にすると、RSVP グレースフル リスタートと RSVP ヘルパー モードが有効になります。ただし、これらの機能の 1 つまたは両方を無効にできます。

RSVP グレースフル リスタートと回復を無効にするには、[edit protocols rsvp graceful-restart] 階層レベルで disable ステートメントを含めます。

RSVP ヘルパー モードの無効化

RSVP ヘルパー モードを無効にするには、[edit protocols rsvp graceful-restart] 階層レベルで helper-disable ステートメントを含めます。

最大ヘルパー回復時間の設定

グレースフル リスタート中に ルーター が RSVP ネイバーの状態を保持する時間を設定するには、[edit protocols rsvp graceful-restart]階層レベルに maximum-helper-recovery-time ステートメントを含めます。この値は隣接するすべてのルーターに適用されるため、最も遅い RSVP ネイバーの回復に必要な時間に基づく必要があります。

最大ヘルパー リスタート時間の設定

ルーターが隣接するルーターのダウンを発見してからネイバーのダウンを宣言するまでの遅延を設定するには、[edit protocols rsvp graceful-restart]階層レベルにmaximum-helper-restart-timeステートメントを含めます。この値は隣接するすべてのルーターに適用されるため、最も遅い RSVP ネイバーの再起動に必要な時間に基づく必要があります。

RSVP LSP トンネルの概要

RSVP(リソース予約プロトコル)LSP(ラベルスイッチ パス)トンネルは、RSVP LSP を他の RSVP LSP 内部に送信することができます。これにより、ネットワーク管理者は、ネットワークの端から端までトラフィック制御を行うことができます。この機能の便利な用途は、RSVP LSP を使用してカスタマー エッジ(CE)ルーターとプロバイダ エッジ(PE)ルーターを接続し、このエッジ LSP をネットワーク コアを経由する 2 つ目の RSVP LSP 内にトンネル化することです。

MPLSとラベルスイッチングの概念を概ね理解していることが求められます。MPLS の詳細については、 『Junos MPLS アプリケーション設定ガイド』を参照してください。

RSVP LSP トンネルでは、GMPLS(Generalized MPLS Switching)で使用されるものと同様に、転送隣接関係の概念が追加されています。(GMPLS の詳細については、 Junos GMPLS ユーザーガイドを参照してください。

転送隣接関係は、RSVP LSP ネットワーク内のピア デバイス間でデータを送信するためのトンネル パスを作成します。FA-LSP(転送隣接関係 LSP)が確立されると、CSPF(Constrained Shortest Path First)、LMP(Link Management Protocol)、OSPF(Open Shortest Path First)、RSVPなどを用いて、FA-LSPを介して他のLSPを送信することができます。

RSVP LSP トンネルを有効にするために、Junos OS は以下のメカニズムを使用します。

  • LMP - 本来は GMPLS 用に設計されたもので、RSVP LSP トンネル ピア間で転送隣接関係を確立し、トラフィック制御リンクのリソースを維持および割り当てます。

  • OSPF拡張 - OSPFは、 物理インターフェイスカード (PIC)に関連する物理インターフェイスおよび論理インターフェイスにパケットをルーティングするために設計されました。このプロトコルは、LMP 構成で定義された仮想ピア インターフェイスにパケットをルーティングするように拡張されています。

  • RSVP-TE拡張 - RSVP-TEは、パケットLSPの設定を物理インターフェイスに通知するために設計されました。このプロトコルは、LMP 設定で定義された仮想ピア インターフェイスに向かうパケット LSP のパス設定をリクエストするように拡張されています。

    注:

    Junos OSリリース15.1以降、マルチインスタンスのサポートはMPLS RSVP-TEに拡張されています。このサポートは、仮想ルーターのインスタンスタイプでのみ使用できます。ルーターは、複数の独立した TE トポロジー パーティションを作成して参加できるため、パーティションされた各 TE ドメインを独立してスケーリングできます。マルチインスタンスRSVP-TEでは、インスタンスを認識する必要のあるコントロールプレーンのエンティティを柔軟に選択することができます。例えば、ルーターは単一のBGPインスタンスを実行しながら複数のTEインスタンスに参加することができます。

    Junos OS MPLS リリース 16.1 では、 RSVP-TE のJunos OS実装が拡張され、LSP の操作性、可視性、設定、トラブルシューティングが強化されています。

    これらの機能強化により、RSVP-TEの設定が大規模に容易になります。

    • RSVP-TE LSP self-ping メカニズムを使用して、トラフィックが LSP を通過する前に、LSP resignaling 中に LSP データプレーンの準備ができるようにします。

      LSPは、データプレーンでプログラムされていることがわからない限り、トラフィックの伝送を開始してはいけません。LSP データ プレーンでのデータ交換(LSP ping リクエストなど)は、トラフィックを LSP またはその MBB インスタンスにスイッチする前に、ingressルーターで行われます。大規模なネットワークでは、エグレス LSP が LSP egressルーターに応答する必要があるため、このトラフィックが LSP エグレス ルーターを圧倒する可能性があります。LSP self-ping メカニズムにより、イングレス LER は LSP ping 応答メッセージを作成し、LSP データプレーン上で送信できます。これらのメッセージを受信したエグレス LERは、LSPデータ プレーンのライブ性を示すために、これらのメッセージをイングレスに転送します。これにより、データプレーンがプログラムされる前にLSPがトラフィックを伝送し始めることはありません。

    • 現在のハードリミットであるingressルーターの64K LSPを削除し、RSVP-TEシグナル付きLSPでLSPの総数をスケーリングします。エグレスごとに最大64K LSPを設定することができます。以前は、この制限はイングレス LER に設定可能な LSP の総数でした。

    • トランジット ルーターでの LSP のシグナリングの遅延による、ingressルーターによる LSP の突然の破棄を防止します。

    • LSP 特性データの可視化を促進するために、LSP データセットの柔軟な表示を可能にします。

    注:

    Junos OSリリース17.4以降、1800秒のself-pingデフォルトタイマーが導入されました。

LSP 階層には以下の制限があります。

  • 回線クロスコネクト(CCC)ベースのLSPはサポートされていません。

  • グレースフル リスタートはサポートされていません。

  • リンク保護は、FA-LSPや転送隣接関係のエグレスポイントでは利用できません。

  • ポイントツーマルチポイント LSP は、FA-LSP を介してサポートされていません。

例:RSVP LSP トンネル設定

図5:RSVP LSPトンネルトポロジー図 RSVP LSP Tunnel Topology Diagram

図5は、ルーター0を起点とし、ルーター5を終点とするe2e_lsp_r0r5と呼ばれるエンドツーエンドのRSVP LSPを示しています。トランジットでは、このLSPはFA-LSPfa_lsp_r1r4を通過します。リターンパスは、FA-LSPfa_lsp_r4r1上を移動するエンドツーエンドのRSVP LSPe2e_lsp_r5r0で表されます。

ルーター0では、ルーター5に移動するエンドツーエンドのRSVP LSPを設定します。ルーター1とルーター1からルーター4に移動するLMPトラフィック制御リンクを通過する厳密なパスを使用します。

ルーター0

ルーター1で、ルーター4に到達するようにFA-LSPを設定します。ルーター4とLMPトラフィックエンジニアリングリンクおよびLMPピア関係を確立します。トラフィック制御リンクでFA-LSPを参照し、ピアインターフェイスをOSPFとRSVPの両方に追加します。

リターンパスのエンドツーエンドLSPがルーター1に到達すると、ルーティングプラットフォームはルーティング検索を実行し、トラフィックをルーター0に転送できます。ルーター0とルーター1の間でOSPFが正しく設定されていることを確認してください。

ルーター1

ルーター2では、コアネットワークを介してFA-LSPを転送するすべてのインターフェイスで、OSPF、MPLS、およびRSVPを設定します。

ルーター2

ルーター3では、コアネットワークを介してFA-LSPを転送するすべてのインターフェイスで、OSPF、MPLS、およびRSVPを設定します。

ルーター3

ルーター4では、ルーター1に到達するようにリターンパスFA-LSPを設定します。ルーター1とLMPトラフィック制御リンクおよびLMPピア関係を確立します。トラフィック制御リンクでFA-LSPを参照し、ピアインターフェイスをOSPFとRSVPの両方に追加します。

最初のエンドツーエンドLSPがルーター4に到着すると、ルーティングプラットフォームはルーティング検索を実行し、トラフィックをルーター5に転送できます。ルーター4とルーター5の間でOSPFが正しく設定されていることを確認してください。

ルーター4

ルーター5では、ルーター0に移動するリターンパスエンドツーエンドRSVP LSPを設定します。ルーター4とルーター4からルーター1に移動するLMPトラフィック制御リンクを通過する厳密なパスを使用します。

ルーター5

作業の検証

RSVP LSP トンネルが正しく機能していることを確認するには、以下のコマンドを発行します。

  • show ted database (extensive)

  • show rsvp session name (extensive)

  • show link-management

  • show link-management te-link name (detail)

設定例で使用されるこれらのコマンドを確認するには、次のセクションを参照してください。

ルーター0

ルーター0では、FA-LSPがトラフィック制御データベースに有効なパスとして表示されていることを確認できます。この場合、172.16.30.1172.16.30.2のLMPトラフィック制御リンクアドレスを参照するルーター1(10.255.41.216)およびルーター4(10.255.41.217)からのパスを探します。また、show rsvp session extensiveコマンドを発行して、FA-LSPを介してルーター5に移動する際のエンドツーエンドLSPのパスを探すこともできます。

ルーター1

ルーター1では、 show link-management コマンドセットを発行して、LMPトラフィック制御リンク設定が機能していること、およびエンドツーエンドLSPがトラフィック制御リンクを通過していることを確認します。また、 show rsvp session extensive コマンドを発行して、FA-LSPが動作していることを確認することもできます。

OSPF および RSVP のピア インターフェイスの設定

LMP ピアを確立した後、OSPF と RSVP にピア インターフェイスを追加する必要があります。ピアインターフェイスは、2つのピア間の制御隣接をサポートするために使用される仮想インターフェイスです。

ピア インターフェイス名は、[edit protocols link-management]階層レベルで LMP に設定された peer peer-name ステートメントと一致する必要があります。実際のプロトコルパケットはピアインターフェイスで送受信されるため、OSPFおよびRSVP用に設定された他の物理インターフェイスと同様に、ピアインターフェイスはシグナリングおよびピアにアドバタイズできます。LMP ピアに OSPF ルーティングを設定するには、[edit protocols ospf area area-number] 階層レベルで peer-interface ステートメントを含めます。LMP ピアの RSVP シグナリングを設定するには、階層レベルで peer-interface ステートメントを含めます [edit protocols rsvp]

FA-LSPのラベルスイッチパスの定義

次に、[edit protocols mpls] 階層レベルでlabel-switched-pathステートメントを含めて、FA-LSPを定義します。[edit protocols mpls label-switched-path] 階層レベルのtoステートメントにピアのルーター IDを含めます。パケットLSPは単方向であるため、ピアに到達するために1つのFA-LSPを作成し、ピアから戻るために2番目のFA-LSPを作成する必要があります。

FA-LSPパス情報の確立

FA-LSPに明示的なLSPパスを設定する場合、トラフィック制御リンクリモートアドレスをネクストホップアドレスとして使用する必要があります。CSPFがサポートされている場合は、任意のパスオプションを使用できます。ただし、[edit protocols mpls label-switched-path lsp-name]階層レベルで no-cspf ステートメントを使用して CSPF を無効にする場合は、厳密なパスを使用する必要があります。

注:

エンドツーエンドLSPがFA-LSPと同じルーティングプラットフォームに由来する場合、CSPFを無効にし、厳密なパスを使用する必要があります。

オプション:RSVP LSPを正常に破棄する

RSVP LSP は、LSP が使用している RSVP セッションを支障なく取り消すという 2 段階のプロセスで破棄できます。支障のない破棄をサポートするすべてのネイバーに対して、ルーティング プラットフォームから LSP のデスティネーション エンドポイントとパス内のすべての RSVP ネイバーに破棄のリクエストが送信されます。このリクエストは、RSVP パケットの ADMIN_STATUS フィールド内に含まれます。ネイバーは要求を受信すると、RSVP セッションを取り消す準備をします。2 番目のメッセージがルーティング プラットフォームから送信され、RSVP セッションの破棄が完了します。ネイバーが支障のない破棄をサポートしていない場合、そのリクエストは支障のない破棄ではなく標準のセッション破棄として処理されます。

RSVP セッションの支障のない破棄を実行するには、clear rsvp session gracefully コマンドを発行します。オプションで、RSVP セッションの送信元アドレスと宛先アドレス、RSVP 送信者の LSP 識別子、RSVP セッションのトンネル識別子を指定できます。これらの修飾子を使用するには、clear rsvp session gracefullyコマンドを発行するときにconnection-sourceconnection-destinationlsp-id、およびtunnel-idオプションを含めます。

また、[edit protocols rsvp]階層レベルでgraceful-deletion-timeoutステートメントを含めることで、ルーティングプラットフォームが実際の破棄を開始する前にネイバーがグレースフル破棄リクエストを受信するのを待つ時間を設定することもできます。支障のない削除のタイムアウトのデフォルト値は 30 秒で、最小値は 1 秒、最大値は 300 秒です。支障のない削除のタイムアウトに設定されている現在の値を表示するには、show rsvp version運用モードコマンドを発行します。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
19.4R1
16.1
しかしながら、Junos OSリリース16.1以降では、RSVPのHelloメッセージがタイムアウトすると、RSVPセッションが停止します。