Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

 

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

RSVP 更新の削減を構成する

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

  • aggregateすべてreliable—の RSVP 更新削減機能を有効にします。RSVP メッセージバンドル, RSVP メッセージ ID, 信頼性の高いメッセージ配信, および要約の更新

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

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

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

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

この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を発行します。サンプル出力は以下のとおりです。

user@host> 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 セッションの総需要が、クラスタイプの実際の容量を超えることを許可されます。

クラスタイプの帯域幅サブスクリプションを構成する方法の詳細については、 Configuring the Bandwidth Subscription Percentage for LSPsを参照してください。

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

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

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

からの値を設定でき 0.00IGP 更新をトリガーする時期の 1% ~ 20% (デフォルトは10%) 予約帯域幅の変更がそのインターフェイス上の静的な帯域幅の設定したしきい値以上である場合は、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 As 200 mbps として表示されます。

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

たとえば、1 Gbps のリンクでは、 しきい値-パーセントが5% に設定されthreshold-valueている場合、が計算され、50 mbps として表示されます。同様に、 threshold-valueが50m に設定されている場合は、 しきい値-パーセントは計算され、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. 「 Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages参照してください。

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

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

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

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

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