このページで
RSVP の設定
最小RSVP設定
単一のインターフェイスでRSVPを有効にする場合は、rsvp
ステートメントを使用し、interface
ステートメントを使用してインターフェイスを指定します。これが最小RSVP設定です。その他の RSVP 構成ステートメントはオプションです。
rsvp { interface interface-name; }
以下の階層レベルでこれらのステートメントを使用することができます。
[edit protocols]
[edit logical-systems logical-system-name protocols]
すべてのインターフェイスでRSVPを有効にするには、all
をinterface-name
変数に代入します。
インターフェイスのグループでインターフェイスのプロパティを設定し、そのうちの1つのインターフェイスでRSVPを無効にする場合は、disable
ステートメントを使用します。
interface interface-name { disable; }
以下の階層レベルでこのステートメントを使用することができます。
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の先頭のルーターの設定例を次に示します。
[edit] protocols { mpls { label-switched-path sf-to-london { to 192.168.1.4; } } rsvp { interface so-0/0/0; } }
LSP を形成する他のすべてのルータに対する設定例を次に示します。
[edit] protocols { mpls { interface so-0/0/0; } rsvp { interface so-0/0/0; } }
RSVPインターフェイスを設定する
以下のセクションでは、RSVPインターフェイスの設定方法について説明します。
- RSVP更新の削減を設定する
- RSVP Hello間隔を設定する
- RSVP認証を設定する
- クラスタイプの帯域幅サブスクリプションを設定する
- インターフェイス上の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
ステートメントを含めます。
aggregate;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp interface interface-name]
[edit logical-systems logical-system-name protocols rsvp interface interface-name]
RSVPメッセージのバンドリングと概要の更新を無効にするには、no-aggregate
ステートメントを含めます。
no-aggregate;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp interface interface-name]
[edit logical-systems logical-system-name protocols rsvp interface interface-name]
インターフェイスでRSVPメッセージIDと信頼性の高いメッセージ配信を有効にするには、reliable
ステートメントを含めます。
reliable;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp interface interface-name]
[edit logical-systems logical-system-name protocols rsvp interface interface-name]
RSVPメッセージID、信頼性の高いメッセージ配信、および概要の更新を無効にするには、no-reliable
ステートメントを含めます。
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
コマンドを発行します。以下は出力のサンプル例です。
user@host> show rsvp neighbor detail RSVP neighbor: 6 learned Address: 192.168.224.178 via: fxp1.0 status: Up Last changed time: 10:06, Idle: 5 sec, Up cnt: 1, Down cnt: 0 Message received: 36 Hello: sent 69, received: 69, interval: 9 sec Remote instance: 0x60b8feba, Local instance: 0x74bc7a8d Refresh reduction: not operational Address: 192.168.224.186 via: fxp2.0 status: Down Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0 Message received: 6 Hello: sent 20, received: 0, interval: 9 sec Remote instance: 0x0, Local instance: 0x2ae1b339 Refresh reduction: incomplete Remote end: disabled, Ack-extension: enabled Address: 192.168.224.188 via: fxp2.0 status: Up Last changed time: 4:15, Idle: 0 sec, Up cnt: 1, Down cnt: 0 Message received: 55 Hello: sent 47, received: 31, interval: 9 sec Remote instance: 0x6436a35b, Local instance: 0x663849f0 Refresh reduction: operational Remote end: enabled, Ack-extension: enabled
より詳細な情報は、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
ステートメントを含めます。
hello-interval seconds;
リリース16.1以降、Junosは、利用可能な場合、RSVP HelloメッセージをバイパスLSP経由で送信します。IGPネクストホップ経由でhellosを送信するこれまでの動作に戻す方法については、no-node-hello-on-bypassをご覧ください。
このステートメントを含めることができる階層レベルの一覧は、ステートメント概要セクションを参照してください。
RSVP認証を設定する
すべてのRSVPプロトコル交換が認証されるようにして、信頼できるネイバーのみが予約設定に参加できるようにすることができます。デフォルトでは、RSVP認証は無効になっています。
RSVP認証は、ハッシュメッセージ認証コード(HMAC)-MD5メッセージベースのダイジェストを使用します。このスキームでは、シークレット認証鍵とメッセージのコンテンツに基づいて、メッセージダイジェストが生成されます。(メッセージコンテンツにはシーケンス番号も含まれます。)計算されたダイジェストは、RSVPメッセージとともに送信されます。認証を設定した後は、すべてのネイバーと受送信を交わしたすべてのRSVPメッセージがこのインタフェイス上で認証されます。
MD5認証は、偽造やメッセージの改ざんを防ぎます。また、リプレイ攻撃を防止することもできます。しかしながら、すべてのメッセージがクリアテキストで送信されるため、機密性はありません。
デフォルトでは認証は無効になっています。認証を有効にするには、authentication-key
ステートメントを含めて各インターフェイス上で鍵を設定します。
authentication-key key;
以下の階層レベルでこのステートメントを使用することができます。
クラスタイプの帯域幅サブスクリプションを設定する
デフォルトでは、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-percentとthreshold-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で示されるようにサンプル ネットワークを設定します。
トポロジー
ルーター間で 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にコマンドをコピー&ペーストしてください。
set interfaces ge-0/0/0 unit 0 family mpls set protocols rsvp interface ge-0/0/0.0 set protocols mpls label-switched-path r1-r7 to 10.0.9.7 set protocols mpls label-switched-path r1-r7 bandwidth 10m set protocols mpls interface all
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLI のナビゲーションについては、CLI User Guideの『Using the CLI Editor in Configuration Mode』を参照してください。
RSVP を設定するには。
MPLS ネットワークのすべてのトランジット インターフェイスで MPLS ファミリーを有効化します。
[edit] user@host# set interfaces ge-0/0/0 unit 0 family mpls
MPLS ネットワークの各トランジット インターフェイスで RSVP を有効化します。
[edit] user @host# set protocols rsvp interface ge-0/0/0
MPLS ネットワークのトランジット インターフェイスで MPLS プロセスを有効にします。
[edit] user@host# set protocols mpls interface ge-0/0/0
イングレス ルーターの LSP を定義します。
[edit protocols mpls] user@host# set label-switched-path r1-r7 to 10.0.9.7
LSP の帯域幅 10 Mbpsをします。
[edit protocols mpls] user @host# set label-switched-path r1-r7 bandwidth 10m
結果
設定モードから show
コマンドを入力し、設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の設定手順を繰り返して設定を修正します。
簡潔にするために、このshow
コマンド出力には、この例に関連する設定のみ含まれています。システム上のその他の設定はすべて省略記号(...)で置き換えられています。
user@host# show ... interfaces { ge-0/0/0 { family mpls; } } } ... protocols { rsvp { interface ge-0/0/0.0; } mpls { label-switched-path r1-r7 { to 10.0.9.7; bandwidth 10m; } interface all; } } ...
デバイスの設定が完了したら、設定モードから commit を入力します。
検証
設定が正常に機能していることを確認するには、次のタスクを実行します。
RSVPネイバーの検証
目的
各デバイスに適切な RSVP ネイバーが表示されていることを確認します。例えば、図 1のルーター R1 は、ルーター R3 とルーター R2 の両方を RSVP ネイバーとしてリストアップしています。
アクション
CLIからshow rsvp neighbor
コマンドを入力します。
user@r1> show rsvp neighbor RSVP neighbor: 2 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 10.0.6.2 0 3/2 13:01 3 366/349 10.0.3.3 0 1/0 22:49 3 448/448
出力には、隣接するルーターのIPアドレスが表示されます。隣接する 各 RSVP ルーター ループバック アドレスがリストされていることを検証します。
RSVP セッションの検証
目的
すべての RSVP ネイバー間で RSVP セッションが確立されていることを検証します。また帯域幅予約値がアクティブなことを検証します。
アクション
CLIからshow rsvp session detail
コマンドを入力します。
user@r1> show rsvp session detail Ingress RSVP: 1 sessions 10.0.9.7 From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 LSPname: r1–r7, LSPpath: Primary Bidirectional, Upstream label in: –, Upstream label out: - Suggested label received: -, Suggested label sent: – Recovery label received: -, Recovery label sent: 100000 Resv style: 1 FF, Label in: -, Label out: 100000 Time left: -, Since: Thu Jan 26 17:57:45 2002 Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 Port number: sender 3 receiver 17 protocol 0 PATH rcvfrom: localclient PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts RESV rcvfrom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts Record route: <self> 10.0.4.13 10.0.2.1 10.0.8.10
確立された各RSVP セッションの、セッション ID、帯域幅予約、ネクストホップ アドレスなどの詳細情報が出力されます。次の情報を確認します。
各 RSVP ネイバー アドレスには、ループバック アドレスごとに各ネイバーのエントリーがあります。
各 LSP セッションの状態はUpです。
Tspecに対しては、適切な帯域幅値、10Mbps、が表示されます。
RSVP シグナル化 LSP の存在を検証
目的
エントリー(イングレス)ルーターのルーティング テーブルに、もう一方のルーターのループバックアドレスへの LSP が設定されていることを検証します。例えば、図 1の R1 エントリー ルーターのinet.3ルーティング テーブルに、ルーター R7 のループバック アドレスへの LSP が設定されていることを確認します。
アクション
CLIからshow route table inet.3
コマンドを入力します。
user@r1> show route table inet.3 inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.0.9.7/32 *[RSVP/7] 00:05:29, metric 10 > to 10.0.4.17 via ge-0/0/0.0, label-switched-path r1–r7
出力には、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 のネットワーク アドレスが表示されます。
設定
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 ルーター
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
RSVP 自動メッシュの設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。その方法の詳細については、CLIユーザー ガイドの設定モードにおけるCLIエディターの使用を参照してください。
RSVP 自動メッシュを有効にするには。
[edit routing-options dynamic-tunnels]
階層レベルでrsvp-te
を設定します。[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template
[edit routing-options dynamic-tunnels]
階層レベルでdestination-networks
を設定します。[edit routing-options dynamic-tunnels] user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24
結果
[edit routing-options dynamic-tunnels]
の階層かshow
コマンドを発行し、設定結果を確認します。
[edit routing-options dynamic-tunnels] user@PE4#show dt-1 { rsvp-te rsvp-te-1 { label-switched-path-template { default-template; } destination-networks { 192.0.2.0/24; } } }
検証
ルーター PE4 での RSVP 自動メッシュ トンネルの存在を検証
目的
新しく設定した PE4 ルーターの動作を検証するために、運用モードからshow dynamic-tunnels database
コマンドを発行します。このコマンドは、動的なトンネールを作成できる宛先ネットワークを表示します。
アクション
user@PE4> show dynamic-tunnels database Table: inet.3 Destination-network: 192.0.2.0/24
ルーター PE4 での MPLS LSP の存在を検証します。
目的
PE4 ルータで MPLS LSP の存在を確認するには、運用モードからshow mpls lsp
コマンドを発行します。このコマンドは MPLS LSP の状態を表示します。
アクション
user@PE4> show mpls lsp
Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 3 sessions To From State Rt Style Labelin Labelout LSPname 192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.102 Up 0 1 FF 3 - PE2-PE4 192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 Total 3 displayed, Up 3, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
非セッション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 メッセージを確認し続けます。インターフェースベースのネイバーは、自動的にエージングされません。
hello-acknowledgements;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]
ネットワークノードからのLSPのスイッチング
ルーターを設定して、インターフェイスに対して有効にされたバイパスLSPで、アクティブなLSPをネットワークノードからスイッチすることができます。この機能は、ネットワークを通過するトラフィックを遮ることなく、デバイスを交換しなければならない場合、アクティブネットワークを維持するために使用されることがあります。LSP は、静的または動的ないずれの状態でも対応します。
ネットワークノードからアクティブなLSPをスイッチするのに関連する、以下の制限にご留意ください。
スイッチアウェイ機能は、MXシリーズルーターのみで対応されています。
スイッチアウェイ機能は、プラマリポイントツーマルチポイントLSPから、バイパスポイントツーマルチポイントLSPへのトラフィックスイッチングには対応していません。ポイントツーマルチポイントLSPに対する
switch-away-lsps
のステートメントを設定すると、トラフィックはバイパスポイントツーマルチポイントLSPにスイッチされません。動的LSPのパスに沿うインターフェイス上で、スイッチアウェイ機能を設定すると、新しい動的LSPをそのパス上で確立することはできません。スイッチアウェイ機能は、RSVP信号LSPの事前対応動作を防止します。通常、事前対応の動作により、ルーターは、元のLSPを破棄する前に、まず、動的LSPへ信号再信を試みます。
RSVP セットアップ保護の設定
施設バックアップ高速再ルート メカニズムが、シグナリングされるプロセス中の LSP のセットアップ保護を提供するように設定できます。ポイントツーポイント LSP とポイントツーマルチポイント LSP が両方サポートされています。この機能は、以下のシナリオで適用されます。
LSP がシグナリングされる前に、LSP の厳密な明示的パスに障害が発生したリンクまたはノードが存在します。
また、リンクまたはノードを保護するバイパス LSP もあります。
RSVP は、バイパス LSP を通じて LSP にシグナリングします。LSP は、最初にプライマリ パスに沿って設定されているように見え、リンクまたはノード障害が発生したため、バイパス LSP に障害が発生したように見えるようになります。
リンクまたはノードが回復すると、LSP をプライマリ パスに自動的に復帰できます。
LSP セットアップ保護を有効にしたい LSP パスに沿った各ルーターの [edit protocols rsvp]
で setup-protection
ステートメントを設定する必要があります。また、LSP パスのすべてのルーターで IGP トラフィック制御を設定することもできます。show rsvp session
コマンドを発行して、LSP が PLR(Point of Local Repair)またはマージ ポイントとして機能するルーターでセットアップ保護が有効になっているかどうかが確認できます。
RSVP セットアップ保護を有効にするには、setup-protection
ステートメントを含めます。
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
ステートメントを次のように設定します。
[edit policy-options] policy-statement policy-name { then { load-balance per-packet; } accept; }
次に、このステートメントをエクスポートポリシーとして転送テーブルに適用する必要があります。
パケットごとのロード バランシングが適用されると、トラフィックはLSP間で均等に分散されます(デフォルト)。
PFE高速再ルートを有効にする場合は、パケットごとのロード バランシングを設定する必要があります。PFE高速再ルートを有効にするには、再ルートが発生する可能性のある各ルーターの設定に、このセクションに示されているパケットごとのロード バランシングに関するpolicy-statement
ステートメントを使用します。高速再ルート設定も参照してください。
また、各LSPに設定されている帯域幅の量に比例して、LSP間のトラフィックをロードバランシングすることもできます。LSPの設定された帯域幅は通常、そのLSPのトラフィック容量を反映するため、この機能により、外部リンク全体で非対称帯域幅機能を備えたネットワークでトラフィックをより適切に分散できます。
RSVP LSPロード バランシングを設定するには、bandwidth
オプションにload-balance
ステートメントを使用します。
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-te
RSVP自動メッシュを設定するには、ステートメントを含めます。
rsvp-te { destination-networks network-prefix; label-switched-path-template (Multicast) { default-template; template-name; } }
これらのステートメントは、以下の階層レベルで設定することができます。
[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
—更新時間は、連続した更新メッセージを生成する間隔を制御します。更新時間のデフォルト値は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状態の存続期間に直接的な影響を与えます。
予約状態の存続期間は、以下の式を使用して決定します。
lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time)
最悪なケースの場合、予約状態が削除されるまでに(keep-multiplier
– 1)つの連続した更新メッセージが失われる必要があります。
短い RSVP hello タイターを設定することは推奨しません。障害のあるネイバーの迅速な発見が必要な場合は、Short IGP(OSF または IS-IS)hello タイマーを設定します。
デフォルトでは、更新タイマーの値は30秒です。この値を変更するには、refresh-time
ステートメントを使用します。
refresh-time seconds;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]
Keep Multiplierのデフォルト値は3です。この値を変更するには、keep-multiplier
ステートメントを含めます。
keep-multiplier number;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]
RSVPセッションのプリエンプト
すべてのRSVPセッションを処理するのに帯域幅が不十分な場合はいつでも、RSVPセッションのプリエンプションを制御できます。デフォルトでは、RSVPセッションは、新しい優先度の高いセッションでのみプリエンプトされます。
帯域幅が不十分な場合に常にセッションをプリエンプトするには、次のaggressive
オプションを含むpreemption
ステートメントを使用します。
preemption aggressive;
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]
RSVPセッションプリエンプションを無効にするには、disabled
オプションにpreemption
ステートメントを使用します。
preemption disabled;
デフォルトに戻す(つまり、新しい優先度の高いセッションに対してのみセッションをプリエンプトする)には、normal
オプションにpreemption
ステートメントを使用してください。
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
ステートメントを含めます。
path-mtu { allow-fragmentation; rsvp { mtu-signaling; } }
以下の階層レベルでこのステートメントを使用することができます。
[edit protocols mpls]
[edit logical-systems logical-system-name protocols mpls]
以下のセクションでは、RSVP でパケットのフラグメント化と MTU シグナリングを有効にする方法について説明します。
RSVP における MTU シグナリングの有効化
RSVP で MTU シグナリングを有効化するには、 rsvp mtu-signaling
ステートメントを含めます。
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
ステートメントを含めます。
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に転送します。
また、RSVPがシグナルしたLSPに、UHP(最後のホップポッピング)(図 4で表示)を設定することもできます。一部のネットワークアプリケーションは、パケットが非nullの外側ラベルとともにイグレスルーター(ルーターPE2)に到達することを求めることがあります。最後のホップポッピングLSPに対して、最後から2番目のルーター(図 4のルーターP2)は、標準的なMPLSラベル入れ替え操作(この例では、ラベル2をラベル3に入れ替え)をエグレスルーターPE2に転送する前に実行します。ルーターPE2は、外側ラベルをポップし、2回目のパケットアドレスのルックアップをして、最終宛先を決定します。そして、次に適切な宛先(ルーターCE2かルーターCE4)にパケットを転送します。
以下のネットワークアプリケーションには、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イングレスで、以下のステートメントをルーター上で設定します。
最終ホップルータでラベルをポップさせるRSVPの設定
LSPのエグレスルータでアドバタイズされるラベル値を制御できます。デフォルトでアドバタイズされたラベルは、ラベル3(Implicit Nullラベル)です。ラベル3がアドバタイズされると、最終ホップルーターはラベルを削除し、パケットをエグレスルーターに送信します。最終ホップのポッピングが有効な場合、ラベル0(IPバージョン4 [IPv4]明示的なNullラベル)がアドバタイズされます。最終ホップのポッピングにより、MPLSネットワークを通過するどのパケットにも確実にラベルが含まれます。
ジュニパーネットワークスのルーターは、着信ラベルに基づいてパケットをキューに入れます。他のベンダーのルーターは、個別にパケットをキューに入れます。複数のベンダーのルーターを搭載したネットワークで作業する場合、このことを覚えておいてください。
RSVPに最終ホップのポッピングを設定するには、explicit-null
ステートメントを使用します。
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
ステートメントを設定します。
tunnel-services { devices device-names; }
以下の階層レベルでこのステートメントを設定することができます。
[edit protocols rsvp]
[edit logical-systems logical-system-name protocols rsvp]
エグレス ポイントツーマルチポイント LSP の最終ホップ ポッピングを有効にするには、all
オプションで interface
ステートメントを設定する必要があります。
interface all;
[edit protocols rsvp]
階層レベルでこのステートメントを設定する必要があります。
RSVPプロトコルトラフィックのトレーシング
RSVPプロトコルトラフィックをトレースするには、traceoptions
ステートメントを含めます。
traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; }
以下の階層レベルでこのステートメントを使用することができます。
[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-name
はtraceoptions
ステートメントを使用して指定したファイルです。
トレーシングとグローバルトレーシングオプションに関する一般的な情報については、ルーティングデバイス用Junos OSルーティングプロトコルライブラリ を参照してください。
例:RSVPプロトコルトラフィックのトレーシング
RSVPパスメッセージを詳細にトレースします。
[edit] protocols { rsvp { traceoptions { file rsvp size 10m files 5; flag path; } } }
すべてのRSVPメッセージをトレースします。
[edit] protocols { rsvp { traceoptions { file rsvp size 10m files 5; flag packets; } } }
すべてのRSVPエラー状態をトレースします。
[edit] protocols { rsvp { traceoptions { file rsvp size 10m files 5; flag error; } } }
RSVP状態の遷移をトレースします。
[edit] protocols { rsvp { traceoptions { file rsvp-data; flag state; } } }
RSVPログファイル出力
RSVPトレースオプションが有効になっており、state
フラグが設定されているルーターで、show log file-name
コマンドを発行した場合の出力例を次に示します。RSVP信号化されたLSP E-Dは、3月11日14:04:36.707092に破棄されていることがわかります。3月11日14:05:30.101492には、再び立ち上げられています。
user@host> show log rsvp-data Mar 11 13:58:51 trace_on: Tracing to "/var/log/E/rsvp-data" started Mar 11 13:58:51.286413 rsvp_iflchange for vt ifl vt-1/2/0.69206016 Mar 11 13:58:51.286718 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 1, is_appl_vt 0, already known Mar 11 13:58:51.286818 RSVP Peer vt-1/2/0.69206016 TE-link __rpd:vt-1/2/0.69206016 Up Mar 11 13:58:51.286978 RSVP add interface vt-1/2/0.69206016, ifindex 101, ifaddr (null), family 3, is_appl_vt 0, already known Mar 11 13:58:51.287962 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr (null), family 2, is_appl_vt 0, already known Mar 11 13:58:51.288629 RSVP add interface lt-1/2/0.2, ifindex 113, ifaddr 10.0.0.2, family 1, is_appl_vt 0, already known Mar 11 13:58:51.288996 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 2, is_appl_vt 0, already known Mar 11 13:58:51.289593 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr (null), family 3, is_appl_vt 0, already known Mar 11 13:58:51.289949 RSVP add interface lt-1/2/0.17, ifindex 114, ifaddr 10.0.0.17, family 1, is_appl_vt 0, already known Mar 11 13:58:51.290049 RSVP Peer lt-1/2/0.17 TE-link __rpd:lt-1/2/0.17 Up Mar 11 13:59:05.042034 RSVP new bypass Bypass->10.0.0.18 on interface lt-1/2/0.17 to 10.0.0.18 avoid 0.0.0.0 Mar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted) Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 1) Mar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Mar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Mar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Mar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0, session ID 3 Mar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Mar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Mar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295 Mar 11 14:05:30.180353 LSP "E-D" is Up Session: 192.168.0.4(port/tunnel ID 10321 Ext-ID 192.168.0.5) Proto 0 Sender: 192.168.0.5(port/lsp ID 2)
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 のグレース フルリスタートの無効化
- RSVP ヘルパー モードの無効化
- 最大ヘルパー回復時間の設定
- 最大ヘルパー リスタート時間の設定
すべてのルーティング プロトコル向けグレースフル リスタートの有効化
RSVP のグレースフル リスタートを有効にするには、ルーターでグレースフル リスタートをサポートするすべてのプロトコルのグレースフル リスタートを有効にする必要があります。グレースフルリスタートの詳細については、ルーティングデバイス用 Junos OS ルーティングプロトコルライブラリをご覧ください。
ルーター上でグレースフル リスタートを有効にするには、graceful-restart
ステートメントを含めます。
graceful-restart;
以下の階層レベルでこのステートメントを含むことができます。
[edit routing-options]
[edit logical-systems logical-system-name routing-options]
RSVP のグレース フルリスタートの無効化
デフォルトでは、グレースフル リスタートを有効にすると RSVP グレースフルリスタートとRSVPヘルパー モードが有効になります。しかし、これらの機能を 1 つまたは両方無効にできます。
RSVP グレースフル リスタートと回復を無効にするには、[edit protocols rsvp graceful-restart]
階層レベルで disable
ステートメントを含めます。
disable;
RSVP ヘルパー モードの無効化
RSVP ヘルパー モードを無効にするには、[edit protocols rsvp graceful-restart]
階層レベルで helper-disable
ステートメントを含めます。
helper-disable;
最大ヘルパー回復時間の設定
グレースフル リスタート中にルーターが RSVP ネイバーの状態を保持する時間を設定するには、[edit protocols rsvp graceful-restart]
階層レベルに maximum-helper-recovery-time
ステートメントを含めます。この値は隣接するすべてのルーターに適用されるため、最も遅い RSVP ネイバーの回復に必要な時間に基づく必要があります。
maximum-helper-recovery-time seconds;
最大ヘルパー リスタート時間の設定
ルーターが隣接するルーターのダウンを発見する時間とネイバーのダウンを宣言する時間の間のディレイを設定するには、[edit protocols rsvp graceful-restart]
階層レベルに maximum-helper-restart-time
ステートメントを含めます。この値は隣接するすべてのルーターに適用されるため、最も遅い RSVP ネイバーの再起動に必要な時間に基づく必要があります。
maximum-helper-restart-time seconds;
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は、ルーター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
[edit] interfaces { so-0/0/3 { unit 0 { family inet { address 10.1.2.1/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.41.222/32; } family mpls; } } } routing-options { forwarding-table { export pplb; } } protocols { rsvp { interface all; interface fxp0.0 { disable; } } mpls { admin-groups { fa 1; backup 2; other 3; } label-switched-path e2e_lsp_r0r5 { # An end-to-end LSP traveling to Router 5. to 10.255.41.221; bandwidth 30k; primary path-fa; # Reference the requested path here. } path path-fa { # Configure the strict path here. 10.1.2.2 strict; 172.16.30.2 strict; # This traverses the TE link heading to Router 4. } interface all; interface fxp0.0 { disable; } interface so-3/2/1.0 { admin-group other; } interface so-0/0/3.0 { admin-group other; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; } } } policy-options { policy-statement pplb { then { load-balance per-packet; } } }
ルーター1では、ルーター4に到達するようにFA-LSPを設定します。ルーター4とLMPトラフィック制御リンクおよびLMPピア関係を確立します。トラフィック制御リンクでFA-LSPを参照し、OSPFとRSVPの両方にピアインターフェイスを追加します。
リターンパスのエンドツーエンドLSPがルーター1に到達すると、ルーティングプラットフォームはルーティング検索を実行し、トラフィックをルーター0に転送できます。ルーター0とルーター1の間でOSPFが正しく設定されていることを確認してください。
ルーター1
[edit] interfaces { so-0/0/1 { unit 0 { family inet { address 10.2.3.1/30; } family mpls; } } so-0/0/2 { unit 0 { family inet { address 10.2.4.1/30; } family mpls; } } so-0/0/3 { unit 0 { family inet { address 10.1.2.2/30; } family mpls; } } fe-0/1/2 { unit 0 { family inet { address 10.2.5.1/30; } family mpls; } } at-1/0/0 { atm-options { vpi 1; } unit 0 { vci 1.100; family inet { address 10.2.3.5/30; } family mpls; } } } routing-options { forwarding-table { export [ pplb choose_lsp ]; } } protocols { rsvp { interface all; interface fxp0.0 { disable; } peer-interface r4; # Apply the LMP peer interface here. } mpls { admin-groups { fa 1; backup 2; other 3; } label-switched-path fa_lsp_r1r4 { # Configure your FA-LSP to Router 4 here. to 10.255.41.217; bandwidth 400k; primary path_r1r4; # Apply the FA-LSP path here. } path path_r1r4 { # Configure the FA-LSP path here. 10.2.4.2; 10.4.5.2; 10.3.5.1; } interface so-0/0/3.0 { admin-group other; } interface so-0/0/1.0 { admin-group fa; } interface at-1/0/0.0 { admin-group backup; } interface fe-0/1/2.0 { admin-group backup; } interface so-0/0/2.0 { admin-group fa; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; peer-interface r4; # Apply the LMP peer interface here. } } link-management { # Configure LMP statements here. te-link link_r1r4 { # Assign a name to the TE link here. local-address 172.16.30.1; # Configure a local address for the TE link. remote-address 172.16.30.2; # Configure a remote address for the TE link. te-metric 1; # Manually set a metric here if you are not relying on CSPF. label-switched-path fa_lsp_r1r4; # Reference the FA-LSP here. } peer r4 { # Configure LMP peers here. address 10.255.41.217; # Configure the loopback address of your peer here. te-link link_r1r4; # Apply the LMP TE link here. } } } policy-options { policy-statement choose_lsp { term A { from community choose_e2e_lsp; then { install-nexthop strict lsp e2e_lsp_r1r4; accept; } } term B { from community choose_fa_lsp; then { install-nexthop strict lsp fa_lsp_r1r4; accept; } } } policy-statement pplb { then { load-balance per-packet; } } community choose_e2e_lsp members 1000:1000; community choose_fa_lsp members 2000:2000; community set_e2e_lsp members 1000:1000; community set_fa_lsp members 2000:2000; }
ルーター2では、コアネットワークを介してFA-LSPを転送するすべてのインターフェイスでOSPF、MPLS、およびRSVPを設定します。
ルーター2
[edit] interfaces { so-0/0/0 { unit 0 { family inet { address 10.4.5.1/30; } family mpls; } } so-0/0/1 { unit 0 { family inet { address 10.1.4.2/30; } family mpls; } } so-0/0/2 { unit 0 { family inet { address 10.2.4.2/30; } family mpls; } } fe-0/1/2 { unit 0 { family inet { address 10.3.4.2/30; } family mpls; } } } routing-options { forwarding-table { export pplb; } } protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs. rsvp { interface all; interface fxp0.0 { disable; } } mpls { admin-groups { fa 1; backup 2; other 3; } path path_r1 { 10.2.4.1; } path path_r3r4 { 10.4.5.2; 10.3.5.1; } interface all; interface fxp0.0 { disable; } interface so-0/0/1.0 { admin-group other; } interface fe-0/1/2.0 { admin-group backup; } interface so-0/0/2.0 { admin-group fa; } interface so-0/0/0.0 { admin-group fa; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; } } } policy-options { policy-statement pplb { then { load-balance per-packet; } } }
ルーター3では、コアネットワークを介してFA-LSPを転送するすべてのインターフェイスでOSPF、MPLS、およびRSVPを設定します。
ルーター3
[edit] interfaces { so-0/0/0 { unit 0 { family inet { address 10.4.5.2/30; } family mpls; } } so-0/0/1 { unit 0 { family inet { address 10.5.6.1/30; } family mpls; } } so-0/0/2 { unit 0 { family inet { address 10.3.5.2/30; } family mpls; } } fe-0/1/2 { unit 0 { family inet { address 10.2.5.2/30; } family mpls; } } } routing-options { forwarding-table { export pplb; } } protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs. rsvp { interface all; interface fxp0.0 { disable; } } mpls { admin-groups { fa 1; backup 2; other 3; } path path_r4 { 10.3.5.1; } path path_r2r1 { 10.4.5.1; 10.2.4.1; } interface all; interface fxp0.0 { disable; } interface so-0/0/2.0 { admin-group fa; } interface fe-0/1/2.0 { admin-group backup; } interface so-0/0/1.0 { admin-group other; } interface so-0/0/0.0 { admin-group fa; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; } } } policy-options { policy-statement pplb { then { load-balance per-packet; } } }
ルーター4では、ルーター1に到達するようにリターンパスFA-LSPを設定します。ルーター1とLMPトラフィック制御リンクおよびLMPピア関係を確立します。トラフィック制御リンクでFA-LSPを参照し、OSPFとRSVPの両方にピアインターフェイスを追加します。
最初のエンドツーエンドLSPがルーター4に到達すると、ルーティングプラットフォームはルーティング検索を実行し、トラフィックをルーター5に転送できます。ルーター4とルーター5の間でOSPFが正しく設定されていることを確認してください。
ルーター4
[edit] interfaces { so-0/0/0 { unit 0 { family inet { address 10.3.6.1/30; } family mpls; } } so-0/0/1 { unit 0 { family inet { address 10.2.3.2/30; } family mpls; } } so-0/0/2 { unit 0 { family inet { address 10.3.5.1/30; } family mpls; } } fe-0/1/2 { unit 0 { family inet { address 10.3.4.1/30; } family mpls; } } at-1/0/0 { atm-options { vpi 1; } unit 0 { vci 1.100; family inet { address 10.2.3.6/30; } family mpls; } } } routing-options { forwarding-table { export [ pplb choose_lsp ]; } } protocols { rsvp { interface all; interface fxp0.0 { disable; } peer-interface r1; # Apply the LMP peer interface here. } mpls { admin-groups { fa 1; backup 2; other 3; } label-switched-path fa_lsp_r4r1 { # Configure your FA-LSP here. to 10.255.41.216; bandwidth 400k; primary path_r4r1; # Apply the FA-LSP path here. } path path_r4r1 { # Configure the FA-LSP path here. 10.3.5.2; 10.4.5.1; 10.2.4.1; } interface all; interface fxp0.0 { disable; } interface at-1/0/0.0 { admin-group backup; } interface so-0/0/2.0 { admin-group fa; } interface fe-0/1/2.0 { admin-group backup; } interface so-0/0/0.0 { admin-group other; } interface so-0/0/1.0 { admin-group fa; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; peer-interface r1; # Apply the LMP peer interface here. } } link-management { # Configure LMP statements here. te-link link_r4r1 { # Assign a name to the TE link here. local-address 172.16.30.2; # Configure a local address for the TE link. remote-address 172.16.30.1; # Configure a remote address for the TE link. te-metric 1; # Manually set a metric here if you are not relying on CSPF. label-switched-path fa_lsp_r4r1; # Reference the FA-LSP here. } peer r1 { # Configure LMP peers here. address 10.255.41.216; # Configure the loopback address of your peer here. te-link link_r4r1; # Apply the LMP TE link here. } } } policy-options { policy-statement choose_lsp { term A { from community choose_e2e_lsp; then { install-nexthop strict lsp e2e_lsp_r4r1; accept; } } term B { from community choose_fa_lsp; then { install-nexthop strict lsp fa_lsp_r4r1; accept; } } } policy-statement pplb { then { load-balance per-packet; } } community choose_e2e_lsp members 1000:1000; community choose_fa_lsp members 2000:2000; community set_e2e_lsp members 1000:1000; community set_fa_lsp members 2000:2000; }
ルーター5では、ルーター0に移動するリターンパスエンドツーエンドRSVP LSPを設定します。ルーター4とルーター4からルーター1に移動するLMPトラフィック制御リンクを通過する厳密なパスを使用します。
ルーター5
[edit] interfaces { so-0/0/2 { unit 0 { family inet { address 10.3.6.2/30; } family mpls; } } lo0 { unit 0 { family inet { address 10.255.41.221/32; } } } } routing-options { forwarding-table { export pplb; } } protocols { rsvp { interface all; interface fxp0.0 { disable; } } mpls { admin-groups { fa 1; backup 2; other 3; } label-switched-path e2e_lsp_r5r0 { # An end-to-end LSP returning to Router 0. to 10.255.41.222; bandwidth 30k; primary path-fa; # Reference the requested path here. } path path-fa { # Configure the strict path here. 10.3.6.1 strict; 172.16.30.1 strict; # This traverses the TE link heading to Router 1. } interface all; interface fxp0.0 { disable; } interface so-0/0/2.0 { admin-group other; } interface so-0/0/1.0 { admin-group other; } } ospf { traffic-engineering; area 0.0.0.0 { interface fxp0.0 { disable; } interface all; } } } policy-options { policy-statement pplb { then { load-balance per-packet; } } }
機能の検証
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のパスを探すこともできます。
user@router0> show ted database TED database: 0 ISIS nodes 8 INET nodes ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.214 Rtr 486 4 4 OSPF(0.0.0.0) To: 10.255.41.222, Local: 10.1.4.2, Remote: 10.1.4.1 To: 10.255.41.216, Local: 10.2.4.2, Remote: 10.2.4.1 To: 10.255.41.215, Local: 10.4.5.1, Remote: 10.4.5.2 To: 10.3.4.1-1, Local: 10.3.4.2, Remote: 0.0.0.0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.215 Rtr 187 4 4 OSPF(0.0.0.0) To: 10.255.41.214, Local: 10.4.5.2, Remote: 10.4.5.1 To: 10.255.41.217, Local: 10.3.5.2, Remote: 10.3.5.1 To: 10.255.41.221, Local: 10.5.6.1, Remote: 10.5.6.2 To: 10.2.5.1-1, Local: 10.2.5.2, Remote: 0.0.0.0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.216 Rtr 396 6 6 OSPF(0.0.0.0) To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1 To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2 To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2 To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2 To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6 To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.217 Rtr 404 6 6 OSPF(0.0.0.0) To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1 To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1 To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5 To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2 To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2 To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0 ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.221 Rtr 481 2 2 OSPF(0.0.0.0) To: 10.255.41.215, Local: 10.5.6.2, Remote: 10.5.6.1 To: 10.255.41.217, Local: 10.3.6.2, Remote: 10.3.6.1 ID Type Age(s) LnkIn LnkOut Protocol 10.255.41.222 Rtr 2883 2 2 OSPF(0.0.0.0) To: 10.255.41.216, Local: 10.1.2.1, Remote: 10.1.2.2 To: 10.255.41.214, Local: 10.1.4.1, Remote: 10.1.4.2 user@router0> show ted database 10.255.41.216 extensive TED database: 0 ISIS nodes 8 INET nodes NodeID: 10.255.41.216 Type: Rtr, Age: 421 secs, LinkIn: 6, LinkOut: 6 Protocol: OSPF(0.0.0.0) To: 10.255.41.222, Local: 10.1.2.2, Remote: 10.1.2.1 Color: 0x8 other Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps [4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.4Mbps [1] 155.4Mbps [2] 155.4Mbps [3] 155.4Mbps [4] 155.4Mbps [5] 155.4Mbps [6] 155.4Mbps [7] 155.4Mbps To: 10.255.41.214, Local: 10.2.4.1, Remote: 10.2.4.2 Color: 0x2 fa Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps [4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps [4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps To: 10.255.41.217, Local: 10.2.3.1, Remote: 10.2.3.2 Color: 0x2 fa Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps To: 10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2 Metric: 1 Static BW: 400kbps Reservable BW: 400kbps Available BW [priority] bps: [0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps [4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps [4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps To: 10.255.41.217, Local: 10.2.3.5, Remote: 10.2.3.6 Color: 0x4 backup Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps To: 10.2.5.1-1, Local: 10.2.5.1, Remote: 0.0.0.0 Color: 0x4 backup Metric: 1 Static BW: 100Mbps Reservable BW: 100Mbps Available BW [priority] bps: [0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps [4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps [4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps user@router0> show ted database 10.255.41.217 extensive TED database: 0 ISIS nodes 8 INET nodes NodeID: 10.255.41.217 Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6 Protocol: OSPF(0.0.0.0) To: 10.255.41.216, Local: 10.2.3.2, Remote: 10.2.3.1 Color: 0x2 fa Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1 Metric: 1 Static BW: 400kbps Reservable BW: 400kbps Available BW [priority] bps: [0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps [4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps [4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps To: 10.255.41.216, Local: 10.2.3.6, Remote: 10.2.3.5 Color: 0x4 backup Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps To: 10.255.41.215, Local: 10.3.5.1, Remote: 10.3.5.2 Color: 0x2 fa Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps [4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.12Mbps [1] 155.12Mbps [2] 155.12Mbps [3] 155.12Mbps [4] 155.12Mbps [5] 155.12Mbps [6] 155.12Mbps [7] 155.12Mbps To: 10.255.41.221, Local: 10.3.6.1, Remote: 10.3.6.2 Color: 0x8 other Metric: 1 Static BW: 155.52Mbps Reservable BW: 155.52Mbps Available BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 155.52Mbps [1] 155.52Mbps [2] 155.52Mbps [3] 155.52Mbps [4] 155.52Mbps [5] 155.52Mbps [6] 155.52Mbps [7] 155.52Mbps To: 10.3.4.1-1, Local: 10.3.4.1, Remote: 0.0.0.0 Color: 0x4 backup Metric: 1 Static BW: 100Mbps Reservable BW: 100Mbps Available BW [priority] bps: [0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps [4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps [4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps user@router0> show rsvp session name e2e_lsp_r0r5 extensive Ingress RSVP: 1 sessions 10.255.41.221 From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2 LSPname: e2e_lsp_r0r5, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 101584 Resv style: 1 FF, Label in: -, Label out: 101584 Time left: -, Since: Wed Sep 7 19:02:56 2005 Tspec: rate 30kbps size 30kbps peak Infbps m 20 M 1500 Port number: sender 2 receiver 29458 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.1.2.2 (so-0/0/3.0) 15 pkts RESV rcvfrom: 10.1.2.2 (so-0/0/3.0) 16 pkts Explct route: 10.1.2.2 172.16.30.2 10.3.6.2 Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
ルーター1
ルーター1では、show link-management
セットのコマンドを発行して、LMPトラフィック制御リンク設定が機能していること、およびエンドツーエンドLSPがトラフィック制御リンクを通過していることを確認します。show rsvp session extensive
コマンドを発行して、FA-LSPが動作していることを確認することもできます。
user@router1> show link-management Peer name: r4 , System identifier: 10758 State: Up, Control address: 10.255.41.217 TE links: link_r1r4 TE link name: link_r1r4, State: Up Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2, Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps, Total bandwidth: 400kbps, Available bandwidth: 370kbps Name State Local ID Remote ID Bandwidth Used LSP-name fa_lsp_r1r4 Up 22642 0 400kbps Yes e2e_lsp_r0r5 user@router1> show link-management te-link name link_r1r4 detail TE link name: link_r1r4, State: Up Local identifier: 16299, Remote identifier: 0, Local address: 172.16.30.1, Remote address: 172.16.30.2, Encoding: Packet, Switching: Packet, Minimum bandwidth: 0bps, Maximum bandwidth: 400kbps, Total bandwidth: 400kbps, Available bandwidth: 370kbps Resource: fa_lsp_r1r4, Type: LSP, System identifier: 2147483683, State: Up, Local identifier: 22642, Remote identifier: 0 Total bandwidth: 400kbps, Unallocated bandwidth: 370kbps Traffic parameters: Encoding: Packet, Switching: Packet, Granularity: Unknown Number of allocations: 1, In use: Yes LSP name: e2e_lsp_r0r5, Allocated bandwidth: 30kbps user@router1> show rsvp session name fa_lsp_r1r4 extensive Ingress RSVP: 1 sessions 10.255.41.217 From: 10.255.41.216, LSPstate: Up, ActiveRoute: 0 LSPname: fa_lsp_r1r4, LSPpath: Primary Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 100816 Resv style: 1 FF, Label in: -, Label out: 100816 Time left: -, Since: Wed Sep 7 19:02:33 2005 Tspec: rate 400kbps size 400kbps peak Infbps m 20 M 1500 Port number: sender 2 receiver 5933 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.2.4.2 (so-0/0/2.0) 28 pkts RESV rcvfrom: 10.2.4.2 (so-0/0/2.0) 26 pkts Explct route: 10.2.4.2 10.4.5.2 10.3.5.1 Record route: <self> 10.2.4.2 10.4.5.2 10.3.5.1 Total 1 displayed, Up 1, Down 0 Egress RSVP: 1 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 2 sessions Total 0 displayed, Up 0, Down 0
リンク管理プロトコル ピアの設定
トラフィック制御リンクを設定した後、LMP ネットワーク ピアを[edit protocols link-management]
階層レベルでpeer peer-name
ステートメントで設定します。ピアは、ルーティング プラットフォームが通信をし、FA-LSPを確立するネットワーク デバイスです。ピア名を指定し、ピア ルーター ID をアドレス(多くはループバック アドレス)として設定し、このピアに関連するトラフィック制御を適用します。ピアリング関係の両サイドを設定して、双方向通信を有効にすることを忘れないでください。
GMPLS とは異なり、ピアに制御チャネルを設定する必要はありません。制御 チャネルを含めると、コミット操作は失敗します。
[edit] protocols { link-management { peer peer-name { # Configure the name of your network peer. address ip-address; # Include the router ID of the peer. te-link te-link-name; # Assign a TE link to this peer. } } }
リンク管理プロトコルのトラフィック制御リンクの設定
RSVP LSP トンネルの設定を開始するために、イングレスとエグレスの両方のルーティング プラットフォームで LMP トラフィック制御リンクを設定します。トラフィック制御リンクはピア デバイス間の一方通行の接続を定義するため、パケットの双方向伝送を可能にするには、ピア間の両方向にトラフィック制御リンクを設定する必要があります。
LMP でトラフィック制御リンクを設定するには,[edit protocols link-management
] 階層レベルでte-link te-link-name
のステートメントを含めます。以下に示すトラフィック制御リンクのオプションのうち、ピアに到達するために FA-LSP として特に使用するラベルスイッチ・パスを定義します。オプションで、TE リンク(トラフィック制御リンク)のトラフィック制御メトリックを指定することができます。デフォルトで、トラフィック制御メトリックは CSPF 計算から導き出されています。
[edit] protocols { link-management { te-link te-link-name { # Name of the TE link. label-switched-pathlsp-name
; # LSP used for the forwarding adjacency. local-address ip-address; # Local IP address associated with the TE link. remote-address ip-address; # Remote IP address mapped to the TE link. te-metricvalue
; # Traffic engineering metric used for the TE link. } } }
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
ステートメントを含めます。
[edit]
protocols {
rsvp {
peer-interface peer-name { # Configure the name of your LMP peer.
}
ospf {
area area-number
{
peer-interface peer-name { # Configure the name of your LMP peer.
}
}
}
}
}
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を作成する必要があります。
[edit] protocols { mpls { label-switched-path lsp-name { from ip-address; to ip-address; primary path-name; secondary path-name; no-cspf; # This statement to disable CSPF is optional. } } }
FA-LSPパス情報の確立
FA-LSPに明示的なLSPパスを設定する場合、トラフィック制御リンクリモートアドレスをネクストホップアドレスとして使用する必要があります。CSPFがサポートされている場合は、任意のパスオプションを使用できます。ただし[edit protocols mpls label-switched-path lsp-name]
階層レベルでno-cspf
ステートメントを使用してCSPFを無効にする場合は、厳密なパスを使用する必要があります。
[edit] protocols { mpls { path path-name { next-hop-address (strict | loose); } } }
エンドツーエンド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-source
connection-destination
lsp-id
およびtunnel-id
のオプションを付けます。
また、ルーティング プラットフォームが、実際の破棄を開始する前に、ネイバーが支障のない破棄のリクエストを受信するのを待つ時間を設定するには、[edit protocols rsvp]
の階層レベルでgraceful-deletion-timeout
のステートメントを含める必要があります。支障のない削除のタイムアウトのデフォルト値は 3 0秒で、最小値は 1 秒、最大値は 300 秒となっています。支障のない削除のタイムアウトに設定されている現在の値を表示するには、show rsvp version
運用モード コマンドを発行します。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。