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を有効にするには、allinterface-name変数に代入します。

インターフェイスのグループでインターフェイスのプロパティを設定し、そのうちの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を結合するための追加設定は必要ありません。

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

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

ラベルスイッチング信号情報を渡すために、RSVPは4つの追加オブジェクトLabel Requestオブジェクト、Labelオブジェクト、Explicit Routeオブジェクト、Record Routeオブジェクトをサポートしています。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更新の削減を設定することができます。

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

    更新の削減と信頼性の高い配信を設定するには、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ネイバーがこのルーターにSummary Refresh(概要の更新)オブジェクトを送信した場合、エラーは生成されませんが、Summary Refreshオブジェクトは処理されません。その結果、ネイバーがRSVP状態を更新するにあたりSummary Refreshにのみ依存している場合、このルーターで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セッションは維持されます。ルーターでIGP Helloパケットの受信が停止するか、RSVPパスとResvメッセージがタイムアウトするまで、RSVPセッションは維持されます。しかしながら、Junos OS Release 16.1以降では、RSVPのHello Messageがタイムアウトすると、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 interface interface-name]

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

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

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

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

インターフェイス上のRSVP 更新しきい値を設定する

内部ゲートウェイプロトコル(IGP)はトラフィック制御データベースを維持しますが,トラフィック制御データベースリンク上の現在利用可能な帯域幅はRSVPからのものです。リンクの帯域幅が変更されると、RSVPから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と表示されます。

注:

2つのオプション、threshold-percentthreshold-valueは互いに排他的です。ある時点で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 hellos は、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典型的な RSVP シグナル化 LSP

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

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

設定

手順

CLIクイック構成

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

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

次の例では、設定階層のいくつかのレベルに移動する必要があります。CLI のナビゲーションについては、CLI User Guideの『Using the CLI Editor in Configuration Mode』を参照してください。

RSVP を設定するには。

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

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

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

  4. イングレス ルーターの LSP を定義します。

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

結果

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

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

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

検証

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

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 ルートが示されます。MPLS ネットワークで、 RSVP シグナル化 LSP が、出口(エグレス)ルーター R7 のループバック アドレスに関連付けられていることを検証します。

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

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

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

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

要件

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

  • Junos OS Release 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 ルーターを用いたサービス プロバイダ ネットワークPE ルーターを用いたサービス プロバイダ ネットワーク

設定

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 メッセージは破棄される。hello-acknowledgements[edit protocols rsvp]階層レベルでステートメントを設定した場合、非セッションネイバーからの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間のロード バランシングの設定

デフォルトでは、同じエグレスルーターに複数の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を設定することができます。rsvp-teこの機能を有効にするには、フルメッシュのすべてのPEルーターでステートメントを構成する必要があります。

注:

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

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

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

  • [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-templatetemplate-name-オプションを使って明示的にデフォルトのテンプレートを設定することも、オプションを使って独自のLSPテンプレートを設定することも可能です。LSPテンプレートは、動的に生成されるLSPのモデル構成として機能する。

RSVP更新メッセージに対するタイマーの設定

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

  • refresh-time—更新時間は、連続した更新メッセージを生成する間隔を制御します。更新時間のデフォルト値は45秒です。この数値は、refresh-timeステートメントのデフォルト値である30に、固定値の1.5を掛けたものです。この計算はRFC 2205とは異なります。RFC 2205には更新時間は0.5~1.5の範囲のランダムな値で掛け算する必要があると記述されています。

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

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

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

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

短い RSVP hello タイターを設定することは推奨しません。障害のあるネイバーの迅速な発見が必要な場合は、Short IGP(OSF または IS-IS)hello タイマーを設定します。

デフォルトでは、更新タイマーの値は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) シグナリングを設定するには、MPLS でカプセル化される前に IP パケットをフラグメント化できるように 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 ステートメントと合わせて設定してください。

LSPに最終ホップポッピングを設定

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

図 3: LSPに最後から2番目のホップポッピングLSPに最後から2番目のホップポッピング

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

図 4: LSPに最終ホップポッピングLSPに最終ホップポッピング

以下のネットワークアプリケーションには、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イングレスからシグナルされます。イングレスルーター設定に基づいて、RSVPは、非PHPフラグセットでUHPのLSPをシグナルできます。RSVPパスメッセージは、LSP属性オブジェクトで2つのフラグを伝送します。エグレスルーターがパスメッセージを受信すると、非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のエグレス)に到達します。外側ラベル(S=0)はUHPラベルで、内側ラベル(S=1)はVCラベルです。トランスポートラベルに基づくルックアップは、mpls.0ルーティングテーブルのテーブルハンドルを獲得します。内側ラベルに該当するmpls.0ルーティングテーブルには、追加ルートがあります。内側ラベルに基づくルックアップは、CEルーターネクストホップを獲得します。

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

    注:

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

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

    注:

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

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

  • MPLS上のIPv6—MPLS上IPv6トンネリングに対して、PEルーターはラベル値2を使用して、IPv6ルートを相互にアドバタイズします。これは、IPv6の明示的nullラベルです。結果として、リモートPEルーターから学習するIPv6の転送ネクストホップは、通常2つのラベルをプッシュします。内側ラベルは2で(アドバタイズするPEルーターが他のベンダーのものである場合、異なることもあります)、ルーターラベルはLSPラベルです。パケットは、2つのラベルとともにPEルーター(UHP LSPのエグレス)に到達します。外側ラベルはトランスポートラベル(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上、もしくはルーターで設定されたすべてのイングレスLSPに、この機能を有効にすることができます。LSPイングレスで、以下のステートメントをルーター上で設定します。

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

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

    注:

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

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

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

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

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

LSPのエグレスルータでアドバタイズされるラベル値を制御できます。デフォルトでアドバタイズされたラベルは、ラベル3(Implicit Nullラベル)です。ラベル3がアドバタイズされると、最終ホップルーターはラベルを削除し、パケットをエグレスルーターに送信します。最終ホップのポッピングが有効な場合、ラベル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 のエグレス ルーターの前にルーターのパケットから削除されます。次にプレイン IP パケットがエグレス ルーターに転送されます。最終ホップ ポッピングでは、エグレス ルーターが 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 の最終ホップ ポッピングがより正しく機能するために、エグレス ルーターはトンネル サービス 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ログファイル出力

RSVPトレースオプションが有効になっており、stateフラグが設定されているルーターで、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(Resource Reservation Protocol)LSP(ラベルスイッチ パス)トンネルは、RSVP LSP を他の RSVP LSP 内部に送ることができます。これにより、ネットワーク管理者は、ネットワークの端から端まで、トラフィック制御を行うことができます。この機能は、CE(カスタマー エッジ)ルーターと PE(プロバイダ エッジ)ルーターを RSVP LSP で接続し、このエッジ LSP を、ネットワーク コアを経由する2つ目の RSVP LSP の中にトンネリングする場合に有効です。

MPLS とラベル スイッチングの概念を概ね理解していることが求められます。MPLS の詳細については、『Junos MPLS Applications Configuration Guide』を参照してください。

RSVP LSP トンネルでは、GMPLS(Generalized Multiprotocol Label Switching)と同様に、転送隣接関係という概念が追加されています。(GMPLS の詳細については、『Junos GMPLS User Guide』を参照してください)。

転送隣接関係が、RSVP LSP ネットワーク内のピア デバイス間でデータを送信するためのトンネル パスを作成します。FA-LSP(転送隣接関係 LSP)が確立されると、CSPF(制限付き最短パス ファースト)、LMP(リンク管理プロトコル)、OSPF(オープン最短パス ファースト)、RSVPなどを用いて、FA-LSPを介して他のLSPを送信することができます。

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

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

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

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

    注:

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

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

    これらの機能強化により、RSVP-TE の設定がスケールに応じて容易になります。

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

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

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

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

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

    注:

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

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

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

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

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

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

例:RSVP LSPトンネル設定

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

図 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.1および172.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 シグナリングを設定するには、 [edit protocols rsvp] 階層レベルでpeer-interfaceステートメントを含めます。

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のステートメントを含める必要があります。支障のない削除のタイムアウトのデフォルト値は 3 0秒で、最小値は 1 秒、最大値は 300 秒となっています。支障のない削除のタイムアウトに設定されている現在の値を表示するには、show rsvp version運用モード コマンドを発行します。

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

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