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

インターフェイスのグループに対してインターフェイスのプロパティを設定していて、いずれかのインターフェイスで 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 をバインドするために追加の設定は必要ありません。

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

RSVP セッションが正常に作成されると、その RSVP セッションによって作成されたパスに基づいて LSP が設定されます。RSVP セッションが正常に行われなかった場合、RSVP はその状態の MPLS に通知します。バックアップパスを開始するか、最初のパスを再試行するのは MPLS です。

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

MPLS を構成して RSVP のクライアントにするには、次の手順に従います。

  • ラベルスイッチに参加するすべてのルーターで MPLS を有効にします (これは、ラベル交換パスの一部となる可能性があるすべてのルーターで実行されます)。

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

  • LSP の最初にルーターを構成します。

例:RSVP と MPLS の設定

LSP の開始時におけるルーターの構成例を以下に示します。

LSP を形成する他のすべてのルーターの構成例を以下に示します。

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

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

RSVP 更新の削減を構成する

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

  • aggregate および reliable : すべての RSVP 更新リダクション機能を有効にする: RSVP メッセージバンドル, RSVP メッセージ ID, 信頼性の高いメッセージ配信, および要約の更新

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

  • no-aggregate:RSVP メッセージ バンドルとサマリ更新を無効にします。

  • no-reliable:RSVP メッセージ ID、信頼性の高いメッセージ配信、サマリ更新を無効にします。

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

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

ただし、異なる更新削減機能を備えた2つの隣接ノードでは、すべての組み合わせが正しく機能しているわけではありません。たとえば、ルーター aggregateはステートメントとno-reliableステートメント、またはreliable and no-aggregateステートメントで構成されています。RSVP 近隣ノードがこのルーターに要約更新オブジェクトを送信しても、エラーは生成されませんが、Summary 更新オブジェクトを処理することはできません。そのため、このようなルーターでは 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 パケットが受信されなくなるため)、その近隣ノードも停止します。ただし、IGP のプロトコルと RSVP は、近隣ノードを導入する際には独立して機能します。

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

RSVP hello 間隔は、別のベンダーの機器が RSVP セッションを終了するときにも影響を受けることができます。たとえば、RSVP hello パケットを監視するように構成されている、ジュニパーネットワークスの隣接していないルーターである場合があります。

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

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

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 予約に使用できます。Multiclass LSP に対してクラスタイプをオーバーサブスクライブすると、すべての RSVP セッションの総需要が、クラスタイプの実際の容量を超えることを許可されます。

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

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

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

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

ネットワーク 更新をトリガーする時間の値を 0.001~20 パーセント(デフォルトは 10 パーセント)IGPできます。予約帯域幅の変更がそのインターフェイス上の静的な帯域幅の設定したしきい値以上である場合は、IGP 更新が発生します。たとえば、 update-threshold明細書が 15% に設定されていて、ルーターでリンクの予約帯域幅がリンク帯域幅の 10% によって変化したことが検出された場合、RSVP は IGP 更新をトリガーしません。しかし、リンク上で予約された帯域幅がリンク帯域幅の 20% によって変化する場合、RSVP は IGP 更新をトリガーします。

また、文のthreshold-valueupdate-threshold下のオプションを使用して、しきい値を絶対値として設定することもできます。

しきい値が、そのリンクの帯域幅の20% 以上に設定されている場合、しきい値は帯域幅の20% 以上になります。

たとえば、インターフェイスの帯域幅が1Gbps で、そのthreshold-value設定が 200 mbps threshold-valueを超える場合、は 200 mbps になります。しきい 値パーセントは 20.000%、 threshold-value および 200 Mbps と表示されます。

注:

しきい値パーセントと 、 という 2 つのオプションthreshold-value は、相互に限定されます。特定の時点で1つのオプションのみを設定して、帯域幅の低い予約用に IGP 更新を生成することができます。その結果、1つのオプションが設定されると、もう一方のオプションが計算されて CLI に表示されるようになります。

たとえば、1 Gbps のリンクでしきい値パーセントが 5% に設定されている場合、そのしきい値は threshold-value 計算され、50 Mbps として表示されます。同様に、 を 50m に設定した場合は、しきい値 - パーセントが計算され threshold-value 、5% と表示されます。

予約された帯域幅の変更によって IGP 更新がトリガーされるしきい値を調整するには、 update thresholdステートメントを含めます。この更新にしきい値があるため、リンク上の古くなったトラフィックエンジニアリングデータベース帯域情報を使用してパスを計算するために、最短パスの最初 (CSPF) に制限されている場合があります。RSVP がそのパス経由で LSP を確立しようとすると、そのリンクに十分な帯域幅がないことがわかる場合があります。これが発生すると、RSVP は IGP トラフィックエンジニアリングデータベースの更新をトリガーし、ネットワーク上の更新された帯域幅情報をフラッディング状態にします。CSPF は、更新された帯域情報を使用してパスを再計算し、輻輳リンクを回避して別のパスを見つけられるようにします。この機能はデフォルトであり、追加の構成を必要としないことに注意してください。

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

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

Junos OS では、番号なしインターフェイスで RSVP トラフィックエンジニアリングをサポートしています。番号付けされていないリンクに関するトラフィック エンジニアリング情報は、RFC 4203、GMPLS(Generalized Multi-Protocol Label Switching)をサポートする OSPF 拡張、GMPLS(Generalized Multi-Protocol Label Switching)をサポートする OSPF 拡張、および一般化マルチプロトコル ラベル スイッチ(GMPLS)をサポートする RFC 4205、中間システム - 中間システム(IS-IS)拡張で説明されている、OSPF IGP トラフィック制御 IS-IS 拡張で実行されます。番号なしリンクは、 RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering(RSVP-TE)で説明されているとおり、MPLS トラフィック エンジニアリングシグナリングで指定できます。この機能により、RSVP 信号ネットワークに参加する各インターフェイスに IP アドレスを設定しなくても済むようになります。

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

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

RSVP ノード ID/Los の構成

ノード ID ベースの RSVP/los を構成して、ジュニパーネットワークスルーターが他のベンダーの機器と相互運用できるようにすることができます。デフォルトでは、Junos OS はインターフェイスベースの RSVP/los を使用します。ノード ID ベースの RSVP hello は、RFC 4558、Node-ID Based Resource Reservation Protocol(RSVP) Hello: 明確化ステートメント 。Rsvp ノード ID は、RSVP インターフェイスを使用して問題を検知するように BFD を設定している場合に便利です。これらのインターフェイスのインターフェイスは無効になります。また、ノード ID/los を使用して、再起動の手続きをスムーズに実行することもできます。

ノード ID/los は、すべての RSVP 近隣ルーターに対してグローバルに有効にすることができます。デフォルトでは、ノード ID hello サポートは無効になっています。ルーターで RSVP ノード Id が有効になっていない場合、Junos OS はノード ID hello パケットを受け付けません。

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

  • [edit protocols rsvp]

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

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

ルーターで RSVP インターフェイス・ los をグローバルに無効にするには、 interface-hello文を以下の階層レベルに追加します。

  • [edit protocols rsvp]

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

例:RSVP シグナル Lsp を構成する

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

要件

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

概要とトポロジー

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

Topology

図 1: 典型的な RSVP シグナル LSP典型的な RSVP シグナル LSP

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

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

構成

手順

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細情報を変更してから、コマンド[edit]を階層レベルで CLI にコピー & ペーストします。

順を追った手順

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

RSVP を構成するには

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

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

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

  4. 受信ルーター上で LSP を定義します。

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

結果

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

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

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

検証

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

RSVP 近隣ノードの検証

目的

各デバイスが適切なRSVPネイバー(たとえば、ルーターR3とルーターR2の両方をRSVPネイバーとしてリストしているなど)を示すように 図 1 検証します。

アクション

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

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

RSVP セッションの確認

目的

すべての RSVP 近隣ノード間で RSVP セッションが確立されていることを確認します。また、帯域幅予約値がアクティブになっていることを確認します。

アクション

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

この出力には、セッション Id、帯域幅予約、次ホップアドレスなどの詳細情報が、確立された各 RSVP セッションごとに表示されるようになっています。以下の情報を確認します。

  • 各 RSVP 近隣ノードアドレスには、各近隣ノードのエントリが、ループバックアドレスごとに記載されています。

  • 各 LSP セッションの状態 Up は .

  • Tspec で、適切な帯域幅値として 10Mbps 、 を表示します。

RSVP シグナル Lsp の存在の確認

目的

Entry (受信) ルーターのルーティングテーブルに、他のルーターのループバックアドレスへの LSP が設定されていることを確認します。たとえば、内の R1 エントリー ルーターのルーティング テーブル LSP がルーター R7 のループバック アドレスに設定されていることを inet.3図 1 検証します。

アクション

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

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

例:RSVP 自動メッシュの構成

サービスプロバイダは多くの場合、BGP と MPLS Vpn を使用してネットワークを効率的に拡張しながら、収益を生み出すサービスを提供しています。このような環境では、サービスプロバイダのネットワーク全体で VPN ルーティング情報を配信するために BGP を使用し、MPLS を使用して vpn トラフィックを1つの VPN から別のサイトに転送します。

BGP と MPLS Vpn に参加する新しい PE ルーターを追加する際には、BGP と MPLS の両方について、既存のすべての PE ルーターを新しい PE ルーターとピアに設定する必要があります。新しい PE ルーターがサービスプロバイダのネットワークに追加されると、すぐに設定の負担が多すぎて、それ以上の処理ができなくなっています。

BGP ピアリングの構成要件は、ルートリフレクタを使用して減らすことができます。Rsvp シグナル MPLS ネットワークでは、RSVP 自動メッシュを使用して、ネットワークの MPLS 部分の設定負担を最小限に抑えることができます。すべてrsvp-teの pe ルーターを構成すると、新しい 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 自動メッシュがすでに設定されていることを前提としています。

Topology

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

図 2: PE ルーターを使用したネットワークのサービスプロバイダPE ルーターを使用したネットワークのサービスプロバイダ

構成

RSVP 自動メッシュを構成するには、以下のタスクを実行する必要があります。

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

  • 必須destination-networksの要素を設定しています。

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

  • 必須label-switched-path-templateの要素を設定しています。

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

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細情報を変更してから、コマンド[edit]を階層レベルで CLI にコピー & ペーストします。

PE4 ルーター

RSVP 自動メッシュの構成

順を追った手順

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

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

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

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

結果

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

検証

ルーター PE4 上での RSVP 自動メッシュトンネルの存在の確認

目的

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

アクション

MPLS Lsp がルーター PE4 に存在することを確認しています

目的

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

アクション

非セッション RSVP 近隣ノードの Hello 肯定応答を構成しています

このhello-acknowledgementsステートメントは、同じセッションに含まれているかどうかに関係なく、RSVP 隣接ノード間の hello 肯定応答動作を制御します。

共通の RSVP セッションの一部ではない RSVP 近隣ノードから受信した Hello メッセージは、破棄されます。hello-acknowledgements階層レベルで[edit protocols rsvp]ステートメントを設定した場合は、非セッション近隣からの hello メッセージに hello 受信確認メッセージが応答されます。このように、セッション以外の近隣から使用すると、RSVP 近隣関係が作成され、不定期の hello メッセージを非セッション近隣ノードから受信できるようになります。デフォルトhello-acknowledgementsでは、このステートメントは無効になっています。このステートメントを設定すると、hello パケットを使用して RSVP 対応ルーターを発見し、インターフェイスが RSVP パケットを受信してから MPLS LSP セットアップメッセージを送信できることを確認できます。

非セッション 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 をバイパスするために、プライマリポイントツー multipoint Lsp からのトラフィックをスイッチングすることはサポートされていません。ポイントツー multipoint LSP switch-away-lspsに対してステートメントを設定した場合、トラフィックはバイパスポイントツーマルチポイント lsp に切り替えられません。

  • 動的 LSP のパスに沿ったインターフェイスに対して、スイッチの場所を変更した場合、そのパス上で新しい動的な Lsp を確立することはできません。この機能により、RSVP シグナル Lsp の実行前ブレーク動作ができなくなります。通常、このような中断動作により、ルーターは元の状態になる前に動的な LSP を再通知しようとします。

RSVP セットアップ保護を構成する

設備のバックアップの高速再ルーティングメカニズムを設定して、通知を受けている Lsp のセットアップ保護を提供することができます。ポイントツーポイント Lsp とポイントツー multipoint Lsp の両方がサポートされています。この機能は、以下のシナリオで適用できます。

  1. LSP が通知される前に、LSP の厳密な明示的パスにある失敗したリンクまたはノードが存在します。

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

  3. RSVP は、バイパス LSP を通じて LSP に通知します。LSP は、最初にプライマリパスに設定されているかのように表示され、リンクまたはノードの障害が原因で、バイパス LSP にフェイルオーバーしたことになります。

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

Lsp の設定保護setup-protectionを有効に[edit protocols rsvp]するには、lsp のパスにある各ルーターのでステートメントを設定する必要があります。また、LSP パス上のすべてのルーターで IGP トラフィックエンジニアリングを設定する必要があります。コマンドをshow rsvp session発行して、LSP がローカル修復 (plr) またはマージポイントとして機能するルーターで、設定保護が有効になっているかどうかを確認できます。

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 負荷分散を構成するにはload-balance 、以下のbandwidthオプションを含むステートメントを含めます。

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

  • [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 自動メッシュを構成するには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 LSP テンプレートを設定 template-name できます。LSP テンプレートは、動的に生成された Lsp のモデル構成として機能します。

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

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

  • refresh-time—更新時間により、連続する更新メッセージの生成間隔が制御されます。更新時間のデフォルト値は45秒です。この数字は、ステートメントのデフォルト値 30 から取得され、固定値 refresh-time の 1.5 で乗じされます。この計算は RFC 2205 とは異なります。これは、更新時間に 0.5 から 1.5 までの範囲のランダム値を乗じて行う必要があるという点です。

    更新メッセージには、path および Resv メッセージが含まれます。更新メッセージは定期的に送信されるため、近隣ノードの予約状態がタイムアウトすることはありません。各 path および Resv メッセージには更新タイマーの値が格納され、受信側ノードはメッセージからこの値を抽出します。

  • keep-multiplier—乗数を維持するには、ローカルで設定された 1~255 の小さな整数が使用されます。デフォルト値は3です。これは、特定の状態が古くなっており、削除しなければならないメッセージの数を示します。Keep マルチプライヤーは RSVP 状態の有効期間に直接影響します。

予約状態の有効期間を確認するには、以下の式を使用します。

最悪の場合、 ( – 1)連続する更新メッセージは、予約状態を削除する前 keep-multiplier に失う必要があります。

短い RSVP hello タイマーを設定することは推奨されていません。失敗した隣接ノードのクイック検出が必要な場合は、短い IGP (OSPF または IS-IS) hello タイマーを構成します。

デフォルトでは、更新タイマー値は 30 秒です。この値を変更するにはrefresh-time 、以下のステートメントを含めます。

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

  • [edit protocols rsvp]

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

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

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

  • [edit protocols rsvp]

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

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

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

帯域幅が不十分な場合にセッションを常にプリエンプトするpreemptionには、 aggressive以下のオプションを記載した文を使用します。

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

  • [edit protocols rsvp]

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

RSVP セッションプリエンプションを無効にするにpreemptionは、以下disabledのオプションを使用して明細書を追加します。

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

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

  • [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 シグナリング動作の変更は、パスが次回更新されたときに有効になります。

このステートメントはmtu-signaling[edit protocols mpls path-mtu rsvp]階層レベルで設定することができます。これはトラブルシューティングに役立ちます。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 は penultimate のポップアップ (PHP) を使用しています。図 3は、ルーター PE1 とルーター PE2 の間の penultimate のポップアップ LSP を示しています。ルーター CE1 は、次ホップ (ルーター PE1) にパケットを転送します。これは LSP の入口でもあります。ルーター PE1 は、このパケットにラベル1をプッシュし、ラベル付きパケットをルーター P1 に転送します。ルーター P1 は、標準 MPLS ラベルのスワップ操作を完了し、ラベル2のラベル1を交換して、パケットをルーター P2 に転送します。ルーター P2 は LSP の penultimate ホップルーターであるため、まずラベルをポップし、次にルーター PE2 にパケットを転送します。ルーター PE2 がそれを受信するとき、パケットには、サービスラベル、明示的な null ラベル、または単なる IP または VPLS パケットのみが含まれています。ルーター PE2 は、ラベルのないパケットをルーター CE2 に転送します。

図 3: LSP の Penultimate のホップのポップアップLSP の Penultimate のホップのポップアップ

また、に示すように図 4、RSVP シグナル lsp の最終ホップ (uhp) を構成することもできます。一部のネットワークアプリケーションでは、パケットが null 以外の外部ラベルを使用して送信ルーター (ルーター PE2) に到着することが要求される場合があります。最終ホップ LSP の場合、penultimate ルーター (ルーター P2 in 図 4) は標準 MPLS ラベルのスワップ操作 (この例ではラベル3のラベル 2) を実行してから、送信ルーター PE2 にパケットを転送します。ルーター PE2 は、外側のラベルをポップし、2番目のパケットアドレスのルックアップを実行して、エンド宛先を特定します。次に、パケットを適切な宛先に転送します (ルーター CE2 またはルーター CE4)。

図 4: LSP の最終ホップポップアップLSP の最終ホップポップアップ

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

  • パフォーマンス監視用 MPLS TP とインバンドOam

  • エッジ保護仮想回線

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

  • LDP シグナル Lsp

  • 静的 Lsp

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

  • CCC

  • tracerouteコマンド

UHP の動作の詳細については、 Internet draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.テキスト 、 RSVP-TE LSPの Non PHP 動作およびアウトオブバンド マッピング を参照してください。

ポイントツーポイントの RSVP シグナル Lsp の場合、UHP の動作は LSP からのシグナルで通知されます。受信ルーターの構成に基づき、RSVP は、非 PHP フラグセットを使用して UHP LSP に通知します。RSVP PATH メッセージには、LSP 属性オブジェクト内の2つのフラグが含まれています。送信ルーターは PATH メッセージを受信すると、null 以外のラベルを LSP に割り当てます。また、RSVP は mpls に2つのルートを作成してインストールします。0ルーティングテーブル。S は、MPLS ラベルの S ビットを参照しています。これは、ラベルスタックの最下部に到達しているかどうかを示します。

  • ルート S=0 — スタック内にラベルが多いかどうかを示します。このルートのネクストホップは mpls を指しています。0ルーティングテーブル、チェーン MPLS ラベルルックアップをトリガーして、スタック内の残り MPLS ラベルを検出します。

  • ルート S=1 — ラベルがこれ以上いかどうかを示します。チェーンと複数ファミリのルックアップをサポートしているプラットフォームでは、ネクストホップは inet. 0 ルーティングテーブルを指しています。または、ラベルルートで、 VTインターフェイスをポイントして IP 転送を開始することもできます。

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

  • レイヤー 2 VPN とレイヤー 2 回線—パケットが 2 つのラベルを使用して PE ルーター(UHP LSP のエグレス)に到着します。外側のラベル (S = 0) は UHP ラベルであり、内部ラベル (S = 1) はVCラベルです。トランスポートラベルを基にしたルックアップでは、mpls のテーブルハンドルが得られます。0ルーティングテーブル。Mpls に追加のルートがあります。0ルーティングテーブルが内部ラベルに対応しています。内側のラベルに基づくルックアップでは、CE ルーターの次ホップになります。

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

    注:

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

  • VPLS —パケットが 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 シリーズルーターでのみサポートされています。

  • IPv4 over MPLS— パケットが PE ルーターに到着します(UHP LSP のエグレス)、1 つのラベル(S=1)。このラベルを基にしたルックアップは、VT トンネルインターフェイスを返します。VT インターフェイスで別の IP ルックアップが完了し、パケットを転送する場所が決定されます。ルーティングプラットフォームが、複数ファミリと連鎖ルックアップ (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 から送信) に到着します。外側のラベルはトランスポートラベル (S = 0) で、内側のラベルは IPv6 明示的-null ラベル (ラベル 2) です。Mpls の内部ラベルに基づいてルックアップを行います。0ルーティングテーブルが mpls に戻ります。0ルーティングテーブル。MX 3D シリーズルーターでは、内部ラベル (ラベル 2) は取り除かれており、inet 6.0 ルーティングテーブルを使用して IPv6 ルックアップが行われます。

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

以下の文は、LSP の最終ホップを可能にします。この機能は、特定の LSP またはルーター上で構成されたすべての受信 Lsp で有効にすることができます。LSP 受信で、ルーター上でこれらのステートメントを設定します。

  1. 究極のホップを有効にするにはultimate-hop-popping 、以下のステートメントを含めます。

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

    注:

    Resignal では、最終ホップポップを有効にすると、既存の Lsp を最終ホップとして作成しようとしています。これは、その前に中断されます。エグレス ルーター が究極のホップ ポップをサポートしていない場合、既存の LSP は取り除かされます(RSVP は LSP のパスに沿って PathTear メッセージを送信し、パスの状態と依存する予約状態を削除し、関連するネットワーク リソースを解放します)。

    究極のホップを無効にすると、RSVP は既存の Lsp を penultimate ホップとして設定し、中断されたタイミングで再通知します。

  2. MX 3D シリーズルーターだけで、最終的なホップとチェーン化されenhanced-ipnetwork-servicesた次のホップの両方を有効にするには、以下のステートメントのオプションも設定する必要があります。

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

最終ホップルーターでラベルをポップするために RSVP を構成しています

LSP の送信ルーターでアドバタイズされたラベル値を制御できます。デフォルトのアドバタイズラベルはラベル 3 (暗黙的な Null ラベル) です。ラベル3がアドバタイズされている場合、penultimate ホップルーターはそのラベルを削除して、パケットを発信ルーターに送信します。ultimate-hop popping が有効になっている場合、ラベル 0(IP バージョン 4 [IPv4] Explicit Null ラベル)がアドバタイズされます。究極のホップ・ポップアップにより、MPLS ネットワークを通過するパケットにラベルが含まれるようになります。

注:

ジュニパーネットワークスルーターは、着信ラベルに基づいてパケットをキューに入れます。他のベンダーのルーターは、パケットを別のキューに置いてしまうことがあります。複数のベンダーのルーターを含むネットワークを使用する際には、このことを念頭に置いてください。

RSVP の最終ホップポップアップを構成するには、 explicit-null以下のステートメントを含めます。

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

  • [edit protocols mpls]

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

ポイントツー Multipoint Lsp での究極のホップを有効にする

デフォルトでは、ポイントツーポイントの Lsp とポイントツー multipoint の両方について、penultimate のトラフィックに対して MPLS ホップポップアップが使用されます。MPLS ラベルは、LSP の送信ルーターの直前にルーター上のパケットから削除されます。その後、プレーン IP パケットが送信ルーターに転送されます。究極のホップを実現するために、送信ルーターは MPLS ラベルを削除し、プレーン IP パケットを処理する必要があります。

特に転送トラフィックが同じ送信デバイスを通過している場合は、ポイントツー multipoint Lsp で究極のホップを有効にすると効果的です。究極のホップを有効にすると、トラフィックの単一コピーが受信リンクを介して送信されるため、大幅な帯域幅を節約できます。デフォルトでは、究極のホップ・ポップアップは無効になっています。

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

LSP に、VT インターフェイスで提供されるよりも多くの帯域幅が必要な場合は、最終的なホップ・ポップアップを有効にすることができず、代わりに penultimate ・ホップ・ポップが有効になります。

Point-to-point Lsp を正常に機能させるための究極のポップアップについては、送信ルーターには、トンネルサービスを提供する PIC、または、アダプティブサービス PIC などが必要です。トンネルサービスは、最終的な MPLS ラベルをポップし、IP アドレス検索用のパケットを返すために必要です。

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

ルーターで送信ポイントツーマルチポイント Lsp の最終ホップポップアップを有効にするには、以下のtunnel-servicesステートメントを構成します。

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

  • [edit protocols rsvp]

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

送信ポイントツーマルチポイント Lsp の最終ホップポップアップを有効にするには、以下のinterfaceallオプションを使用してステートメントを設定する必要もあります。

このステートメントは、 [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-Link Management Protocol(LMP)通信

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

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

  • pathtear—PathTear メッセージ

  • resv—Resv メッセージ

  • resvtear—ResvTear メッセージ

  • route—ルーティング情報

  • state:セッションの状態が変化します。RSVP信号を受け取ったLSPがダウンした場合などです。

注:

allトレースフラグとdetailフラグ修飾子を使用すると、CPU が非常にビジーになる可能性があるため、注意が必要です。

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

トレースおよびグローバル トレース オプションの全般的な情報については、「 ルーティング デバイス用ルーティング Junos OSプロトコル ライブラリ 」を参照してください

\N RSVP プロトコルトラフィックをトレースしています

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

すべての RSVP メッセージをトレース:

すべての RSVP エラー条件をトレースします。

RSVP 状態遷移のトレース:

RSVP ログファイル出力

以下は、RSVP traceoptions が設定さshow log file-nameれたstateフラグで有効になっているルーター上でコマンドを発行した場合に生成されるサンプル出力です。RSVP シグナル LSP E-D は、3月11日 (04: 36.707092) に破棄されることが示されています。3月11日:05: 30.101492 では、今後のバックアップについて説明しています。

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

RSVP の正常な再起動により、再起動中のルーターが、その条件の隣接する近隣ノードに通知されます。再起動するルーターは、近隣またはピアから猶予期間を要求しています。これは再起動ルーターと協調して実行されます。ルーターを再起動すると、再起動中でも MPLS トラフィックを転送できます。ネットワークのコンバージェンスが中断されることはありません。ネットワークの他の部分では再起動が見えず、再起動するルーターはネットワークトポロジから削除されていません。中継ルーターと受信ルーターの両方で、RSVP 正常な再起動を有効にすることができます。この機能は、ポイントツーポイント Lsp とポイントツー multipoint Lsp の両方で使用できます。

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

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

再起動時間(ミリ秒)

デフォルト値は 60,000 ミリ秒(1 分)です。再起動時間は hello メッセージで通知されます。この時間は、近隣がルーターの停止と消去の状態を宣言する前に、再起動ルーターから hello メッセージを受信するまでの期間を示します。

ネットワーク Junos OSのアドバタイズされた再起動時間がローカルの再起動時間の 3 分の 1 を超える場合、ネイバーの通知された再起動時間を上書きできます。たとえば、デフォルトの再起動時間が 60 秒の場合、ルーターが再起動するネイバーから hello メッセージを受信するまでに 20 秒未満待機します。再起動時間がゼロの場合、再起動した近隣ノードは即座に dead として宣言できます。

復旧時間(ミリ秒)

再起動の前に、制御チャネルが稼働している場合 (hello exchange が完了している場合) にのみ適用されます。Nodal の障害にのみ適用されます。

正常な再起動が進行している場合は、回復を完了するまでの残り時間が通知されます。その他の場合、この値はゼロになります。アドバタイズされた最大の復旧時間は、2分 (12万ミリ秒) です。

復旧時には、ノードの再起動によって、失われた状態を回復し、その近隣からの支援を試みます。再起動ノードの隣接ノードは、回復ラベル付きの path メッセージを、復旧時間の半分の期間内に再起動して送信する必要があります。再起動ノードは、公表されている復旧時間が過ぎると、正常なリスタートが完了したと見なします。

RSVP グレースフルリスタートオペレーション

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

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

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

  • 近接ルーターは、RSVP グレースフル再起動ヘルパーモードが有効になっている必要があります。これにより、RSVP の再起動を試みるルーターのサポートが可能になります。

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

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

  • ヘルパーモードを無効にすると、Junos OS は近傍再起動 RSVP のサポートを試みません。近隣からのリスタートキャップオブジェクトによって受信した情報は無視されます。

  • ルーティングインスタンス構成で正常な再起動を有効にすると、その近隣ノードのサポートを利用してルーターを適切に再起動できます。RSVP は、再起動および復旧時間が指定された hello メッセージで、再起動キャップオブジェクト (RSVP 再起動) を通知します (値は0ではありません)。

  • [protocols rsvp]階層レベルで RSVP グレースフル再起動を明示的に無効にした場合、再起動キャップオブジェクトは、0として指定された再起動と復旧時刻を使用して通知されます。近隣ルーターの再起動はサポートされています (ヘルパーモードが無効になっていない場合)。ただし、ルーター自体は RSVP 転送状態を維持せず、コントロールの状態を回復することはできません。

  • 再起動時に RSVP が転送状態が維持されていないことを認識した場合、再起動キャップオブジェクトは、0として指定された再起動と復旧時刻を使用して通知されます。

  • 正常な再起動とヘルパーモードが無効になっている場合、RSVP の正常な再起動は完全に無効になります。ルーターは、RSVP の正常なリスタートオブジェクトを認識したりアドバタイズしたりすることはありません。

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

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

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

次の前提は、リスタートキャップオブジェクトに基づく近傍に関するものです (制御チャネルの障害は、ノードの再起動とは明確に区別できることが前提です)。

  • Hello メッセージに再起動キャップオブジェクトを通知しない近隣ノードは、ルーターの状態またはラベルの回復を支援したり、RSVP グレースフル再起動を実行したりすることはできません。

  • 再起動後、再起動時間が任意の値に等しく、復旧にかかる時間が0であるリスタートキャップオブジェクトを通知する近傍は、転送状態を維持しませんでした。復旧時間が0の場合、その近隣ノードは dead と見なされ、再起動時間の値に関係なく、その近隣ノードに関連するすべての状態が削除されます。

  • 再起動後は、その復旧時刻が0以外の値になっている近傍通知によって、転送状態が維持または維持されます。ローカルルーターが再起動または復旧手順による近隣ノードを支援している場合、Recover ラベルオブジェクトをこの隣接ノードに送信します。

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 ヘルパーモードが有効になります。ただし、これらの機能の一方または両方を無効にすることができます。

RSVP の正常な再起動と回復を無効disableにするに[edit protocols rsvp graceful-restart]は、以下のように階層レベルのステートメントを追加します。

RSVP ヘルパーモードを無効にする

RSVP ヘルパーモードを無効にするにhelper-disableは、次[edit protocols rsvp graceful-restart]のように階層レベルのステートメントを追加します。

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

正常な再起動を実行している間、ルーターが RSVP 近隣ノードの状態を保持する時間を設定maximum-helper-recovery-timeするには[edit protocols rsvp graceful-restart] 、階層レベルのステートメントを含めます。この値はすべての近隣ルーターに適用されるため、最も遅い RSVP 近隣ノードが復旧するのに必要な時間に基づいている必要があります。

最大ヘルパー再起動時間の設定

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

RSVP LSP トンネルの概要

リソース予約プロトコル (RSVP) ラベルスイッチパス (LSP) トンネルを使用すると、他の RSVP Lsp 内に RSVP Lsp を送信できます。これにより、ネットワーク管理者は、ネットワークの一方の端から他方へとトラフィックエンジニアリングを提供できます。この機能の便利な用途は、RSVP LSP を使用して顧客エッジ (CE) ルーターをプロバイダエッジ (PE) ルーターと接続し、ネットワークコアを介して移動した2つ目の RSVP LSP 内でこのエッジ LSP をトンネリングすることです。

MPLS とラベルのスイッチングの概念を全般的に理解している必要があります。データ センターの詳細については、「 MPLS アプリケーション構成 ガイド Junos MPLS 」を参照してください

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

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

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

  • LMP— 最初に GMPLS 向けとして設計された LMP は、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 インスタンスに参加できるようにします。

    MPLS RSVP TE の Junos OS 実装は、Junos OS リリース16.1 における Lsp のユーザビリティ、可視化、構成、トラブルシューティングを強化するために拡張されています。

    これらの機能強化により、RSVP TE の構成がさらに簡単に拡張できます。

    • Lsp のデータプレーンの準備状況を確実に確認します。これは、トラフィックが発生する前に、TE LSP 自己 ping メカニズムを使用して LSP を走査します。

      LSP は、データプレーンでプログラムされていることがわかっている場合を除き、トラフィックの伝送を開始すべきではありません。Lsp による ping 要求などの1つのデータプレーンで行われる、受信ルーターでは、lsp またはその MBB インスタンスへのトラフィックを切り替える前に受信します。大規模なネットワークでは、このトラフィックによって LSP 送信ルーターが過負荷になることがあります。これは、出力 LSP が LSP ping 要求に応答する必要があるためです。LSP の自己 ping メカニズムによって、受信管理者は LSP ping 応答メッセージを作成し、LSP データプレーン上で送信することができます。これらのメッセージを受信すると、送信されたのは、LSP データプレーンの liveliness を示す入口に転送されます。これにより、LSP は、データプレーンがプログラムされる前にトラフィックの送信を開始しなくなります。

    • 受信ルーター上で 64K Lsp の現在のハードリミットを削除し、RSVP TE シグナル Lsp を使用して Lsp の総数を拡張します。送信ベースでは、最大64K の Lsp を設定できます。前述のように、受信した・コントローラーで設定可能な Lsp の総数は、この制限を超えていました。

    • 送信ルーターで LSP の通知に遅延が生じるため、受信ルーターによって Lsp が突然切断されるのを防止します。

    • Lsp のデータセットの柔軟なビューを可能にすることによって、データの可視化を促進します。

    注:

    Junos OS リリース17.4 から開始して、自動 ping 用のデフォルトタイマーの1800秒を導入しました。

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

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

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

  • FA-Lsp または転送隣接関係の送信ポイントでは、リンク保護を使用できません。

  • ポイントツーマルチポイント Lsp は、FA-Lsp 全体でサポートされていません。

例:RSVP LSP トンネル構成

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

図 5 は、ルーター 0 で発生し、ルーター 5 で終了する、エンドツーエンドの RSVP LSP e2e_lsp_r0r5 を示しています。トランジット中に、この LSP は FA-LSP を通過します fa_lsp_r1r4 。戻りパスは、FA を通過するエンドツーエンドの RSVP LSP e2e_lsp_r5r0によって表されfa_lsp_r4r1ます。

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

ルーター0

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

リターン パスのエンドツーエンド 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 を設定します。LMP リンク リンクトラフィック制御、LMP ピア関係をルーター 1 と確立します。リンク内の FA-LSP を参照しトラフィック制御ピア インターフェイスをインターフェイスと RSVP の両方OSPF追加します。

最初のエンドツーエンド 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 がネットワーク データベースの有効なパスとして表示トラフィック制御できます。この場合、 および の リンク アドレスを参照するルーター 1( )とルーター 4 ( )からのパストラフィック制御 10.255.41.21610.255.41.217 を探します 172.16.30.1172.16.30.2 。また、 コマンドを発行して、FA-LSP を通ってルーター5に移動するエンドツーエンドのLSPのパスを検索 show rsvp session extensive できます。

ルーター1

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

OSPF および RSVP でのピアインターフェイスの構成

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

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

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

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

FA-LSP パス情報の確立

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

注:

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

ボタンRSVP Lsp を適切にティアリング

LSP が使用する RSVP セッションを適切に withdraws する2段階のプロセスで RSVP LSP を破棄することができます。正常な片付けをサポートしているすべての近隣において、破棄の要求は、ルーティングプラットフォームによって LSP の宛先エンドポイントと、パス内のすべての RSVP 近隣ノードに送信されます。RSVP パケットのADMIN_STATUSフィールド内に要求が含まれています。近隣がリクエストを受信すると、RSVP セッションをウィズドロウする準備ができます。2つ目のメッセージは、RSVP セッションの破棄を完了するためにルーティングプラットフォームによって送信されます。近隣がグレースフル片付けをサポートしていない場合、この要求は正常な切断ではなく標準のセッションの破棄として処理されます。

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

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

リリース履歴テーブル
リリース
説明
19.4R1
16.1
しかし、Junos OS リリース16.1 から開始している場合は、RSVP hello メッセージがタイムアウトすると、RSVP セッションがダウンします。