Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

LDP の設定

最小 LDP 設定

最小設定でLDPを有効にするには。

  1. ファミリー MPLS で関連するすべてのインターフェースを有効にします。ディレクテッドLDPの事例では、ループバック インターフェースをファミリー MPLS で有効にする必要があります。

  2. (オプション) [edit protocol mpls]階層レベル下に関連するインターフェースを設定します。

  3. 単一のインターフェイスで LDP を有効にするにはldpステートメントを使用し、interfaceステートメントを使用してインターフェイスを指定します。

これが、最小 LDP 設定です。他のすべての LDP 設定ステートメントはオプションです。

すべてのインターフェイスで LDP を有効にするには、interface-nameallを指定します。

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

LDPの有効化および無効化

LDPはルーティングインスタンスを意識しています。特定のインターフェイスでLDPを有効にするには、以下のステートメントを使用します。

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

すべてのインターフェイスでLDPを有効にするには、interface-nameallを指定します。

インターフェイスのグループでインターフェイスのプロパティを設定し、そのうちの1つのインターフェイスでLDPを無効にする場合は、disableオプションにinterfaceステートメントを使用します。

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

Hello メッセージ用の LDP タイマーの設定

LDP Hello メッセージは、LDP ノードがお互いを発見し、ネイバーの障害やネイバーへのリンクを検出するためのものです。Hello メッセージは、LDP が有効になっているすべてのインターフェイスで定期的に送信されます。

LDP Hello メッセージには 2 種類あります。

  • リンク Hello メッセージ - LDP インターフェィスを介して、LDP ディスカバリー ポートに宛てた UDP パケットとして送信される。インターフェイスで LDP リンク Hello メッセージを受信すると、LDP ピア ルーターとの隣接関係が識別されます。

  • ターゲット Hello メッセージ - 特定のアドレスの LDP ディスカバリー ポートに宛てた UDP パケットとして送信されます。ターゲット Hello メッセージは、直接接続されていないルーター間の LDP セッションをサポートするために使用されます。ターゲット ルーターは、ターゲット Hello メッセージに応答するか無視するかを決定します。応答を選択したターゲット ルーターは、ターゲット Hello メッセージを定期的に送信することにより応答します。

デフォルトでは、LDP は、リンク Hello メッセージは 5 秒ごとに、ターゲット Hello メッセージは 15 秒ごとに送信します。LDP タイマーを設定することで、両方のタイプの Hello メッセージを送信する頻度を変更することができます。ただし、LDP 保留時間よりも長く LDP タイマーの設定はできません。詳細については、『Configuring the Delay Before LDP Neighbors Are Considered Down』を参照してください。

リンク Hello メッセージ用の LDP タイマーの設定

LDP がリンク Hello メッセージを送信する頻度を変更するには、hello-intervalステートメントを使用して、LDP タイマー に新しいリンク Hello メッセージの間隔を指定します。

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

ターゲット Hello メッセージ向け LDP タイマーの設定

LDP がターゲット Hello メッセージを送信する頻度を変更するには、targeted-helloステートメントのオプションとして、hello-intervalステートメントを設定し、LDP のタイマーに新しいターゲット Hello メッセージの間隔を指定します。

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

LDP ネイバーがダウンしたと判断される前に遅延を設定する

保留時間は、ネイバーがダウンしたと示すまで、LDP ノードが Hello メッセージを待つ時間を割り出します。この値は、各 LDP ノードがネイバーに待ち時間を伝えるために、Hello メッセージの一部として送信されます。各ネイバーから送信される値は一致しなくても構いません。

保留時間は、通常、Hello 間隔の少なくとも 3 倍にする必要があります。デフォルトでは、リンク Hello メッセージは 15 秒、ターゲット Hello メッセージは 45 秒です。ただし、Hello 間隔の値に近い LDP 保留時間を設定することは可能です。

注:

LDP の保留時間を Hello 間隔に近い値(Hello 間隔の 3 倍以下)に設定することで、LDP ネイバーの障害をより早く検知できる可能性があります。しかし、この方法では、まだ正常に機能している LDP ネイバーを、ルーターがダウンと宣言してしまう可能性も高くなります。詳細については、Hello メッセージ用の LDP タイマーの設定を参照してください。

また、LDP の保留時間は、LDP ピア間で自動的にネゴシエートされます。2 つの LDP ピアが互いに異なる LDP 保留時間をアドバタイズする場合は、小さい方の値を使用します。LDP のピアルーターが、設定した値よりも短い保留時間をアドバタイズした場合、ピア ルーターのアドバタイズされた保留時間をが使用されます。このネゴシエーションは、LDP のキープアライブ間隔にも影響します。

LDP ピアネゴシエーション中に、ローカル LDP の保留時間が短縮されない場合、ユーザーが設定したキープアライブ間隔は変更されません。しかし、ピアネゴシエーション中に、ローカル保留時間が短縮されると、キープアライブ間隔が再計算されます。ピアネゴシエーション中に、LDP の保留時間が短縮された場合、キープアライブ間隔は新しい保留時間の値の 3 分の 1 に短縮されます。例えば、新しい保留時間の値が 45 秒の場合、キープアライブ間隔は 15 秒に設定されます。

このキープアライブ間隔の自動計算により、各ピアルーターで、異なるキープアライブ間隔を設定できます。これは、LDP ピアネゴシエーションにより、LDP の保留時間よりも頻繁に、キープアライブメッセージが送信されることが保証されるためで、ルーターはキープアライブメッセージの送信頻度を柔軟に変更することができます。

ホールドタイムの間隔を再設定しても、セッションがリセットされるまで、変更は反映されません。保留時間は、LDP ピアリングセッションの開始時にネゴシエートされ、セッションが稼働している間は再ネゴシエートできません(RFC 5036、LDP仕様で要求されています)。LDP セッションを手動で強制的にリセットするには、このclear ldp sessionコマンドを発行します。

リンク Hello メッセージ用の LDP 保留時間を設定する

ネイバーダウンを宣言する前に、LDP ノードがリンク Hello メッセージを待つ時間を変更するには、このhold-timeステートメントを使用して、新しい時間を秒単位で指定します。

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

ターゲット Hello メッセージ用の LDP 保留時間を設定する

ネイバーダウンを宣言する前に、LDP ノードがターゲット Hello メッセージを待つ時間を変更するには、このhold-timeステートメントをこのtargeted-helloのステートメントのオプションとして使用して、新しい時間を秒単位で指定します。

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

LDP の Strict Targeted Hello メッセージの有効化

厳密にターゲットされたHelloメッセージを使用して、特に設定されていないリモートネイバーとLDPセッションが確立されないようにします。strict-targeted-hellosこのステートメントを設定すると、LDPピアが、設定されたリモートネイバーではないソースから来るターゲットHelloメッセージに応答しなくなります。設定されたリモートネイバーは、以下を含むことができます。

  • LDPトンネリングが設定されているRSVPトンネルの終点

  • レイヤー2回線ネイバー

error未構成のネイバーが Hello メッセージを送信した場合、 LDP ピアはそのメッセージを無視し、送信元を示すエラー (trace フラグ付き) を記録します。たとえば、LDP ピアでインターネット アドレス 10.0.0.1 からターゲット ハローを受信し、このアドレスを持つネイバーが特に設定されていない場合、 LDP ログ ファイルに次のようなメッセージが出力されます。

strict-targeted-hellos厳密にターゲットを絞ったHelloメッセージを有効にするには、このステートメントを含めます。

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

LDP キープアライブ メッセージの間隔を設定

キープアライブ間隔は、キープアライブのタイムアウトを超えないように、セッション上でメッセージを送信する頻度を決定します。この時間内に他の LDP トラフィックがセッションを介して送信されない場合、キープアライブ メッセージが送信されます。デフォルトは 10 秒です。最小値は 1 秒です。

ピア ルーターの LDP ホールドタイムに設定された値がローカルに設定された値よりも低い場合、LDP セッションのネゴシエーション時にキープアライブ間隔に設定された値を変更することができます。詳細については、『Configuring the Delay Before LDP Neighbors Are Considered Down』を参照してください。

キープアライブ間隔を変更するには、keepalive-intervalステートメントを含みます。

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

LDPキープアライブタイムアウトの設定

LDP セッションの確立後は、セッションが正常に動作していることを確認するために、定期的にメッセージ交換を行う必要があります。キープアライブタイムアウトは、ネイバーLDPノードがセッションの失敗を判断するまでに待機する時間を定義します。この値は通常、キープアライブ間隔の少なくとも3倍に設定されます。デフォルトは30秒です。

キープアライブ間隔を変更するには、keepalive-timeoutステートメントを使用します。

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

keepalive-timeoutステートメントで設定した値は、show ldp session detailコマンドを発行したときの保留時間として表示されます。

LDPのロンゲストマッチ設定

LDPがOSPFエリア全体またはドメイン間のISISレベルで集約または要約されたルートを学習できるようにするため、Junos OSでは、RFC5283に基づいてLDPのロンゲストマッチを設定できます。

LDPのロンゲストマッチを設定する前に、以下のことをしてください。

  1. デバイスインターフィスを設定します。

  2. MPLSプロトコルを設定します。

  3. OSPFプロトコルを設定します。

LDPのロンゲストマッチの設定は、以下のとおりです。

  1. LDPプロトコルに対してロンゲストマッチを設定します。
  2. インターフェイスにLDPプロトコルを設定します。

    例えば、インターフェイスを設定する場合:

例:LDPのロンゲストマッチ設定

この例では、RFC5283に基づくLDPロンゲストマッチの設定方法を説明します。これにより、LDPが、OSPFエリア全体で集約されたルート、またはドメイン間のISISレベルを学習できます。ロンゲストマッチのポリシーは、プレフィックス単位の詳細を提供します。

要件

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

  • OSPFプロトコルを備えたMXシリーズルーター6台と、接続されたインターフェイスで有効にされたLDP。

  • すべてのデバイスで稼働するJunos OSリリース16.1以降。

開始する前に、以下を実行します。

  • デバイスインターフィスを設定します。

  • OSPFを設定する。

概要

LDPは、OSPFもしくはIS-ISなどのIGPを利用して、すべてのネットワークドメイン全体で、MPLSラベルスイッチパス(LSP)を確立するために頻繁に使用されます。そのようなネットワークにおいて、ドメインのすべてのリンクには、IGPの隣接関係、またLDPの隣接関係があります。LDPは、IP転送によって決定され、宛先までの最短パスでLSPを確立しますJunos OSにおいて、LDPの実装は、ラベルマッピングの目的で、RIBもしくはIGPルートのFECのIPアドレス上で完全一致検索を行います。この正確なマッピングには、すべてのLERで、MPLSエンドツーエンドのLDPエンドポイントIPアドレスの設定が必要となります。そうなると、IP階層設計や、アクセスデバイスのデフォルトルーティングの目的が果たせなくなります。longest-matchの設定は、完全一致の動作や、プレフィックス単位でのロンゲストマッチルートに基づくLSP設定を抑制することによって、これを解決に導きます。

トポロジー

トポロジーでは、デバイスR0にLDPのロンゲストマッチが設定されていることを図 1で表示しています。

図 1: LDPのロンゲストマッチ例LDPのロンゲストマッチ例

設定

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

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

R0

R1

R2

R3

R4

R5

デバイス R0 の設定

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

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

Device R0 を設定するには:

  1. インターフェイスを設定します。

  2. デバイスにループバックアドレスを割り当てます。

  3. ルーターIDを設定します。

  4. インターフェイスにMPLSプロトコルを設定します。

  5. インターフェイスにOSPFプロトコルを設定します。

  6. LDPプロトコルに対してロンゲストマッチを設定します。

  7. インターフェイスにLDPプロトコルを設定します。

結果

コンフィギュレーションモードから、show protocolsshow routing-options、およびshow interfacesの各コマンドを入力し、コンフィギュレーションを確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

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

検証

設定が正常に機能していることを確認します。

ルートの検証

目的

期待ルートが学習されていることを確認します。

対処

デバイスR0では、運用モードからshow route コマンドを実行し、ルーティングテーブル内のルートを表示します。

意味

出力で、デバイスR0のルーティングテーブル内のすべてのルートが表示されます。

LDPの概要情報の検証

目的

LDPの概要情報を表示します。

対処

デバイスR0では、運用モードから、show ldp overviewコマンドを実行し、LDPの概要を表示します。

意味

出力で、デバイスR0のLDPの概要情報が表示されます。

内部トポロジーテーブル内でのLDPエントリーを検証

目的

ラベル配布プロトコル(LDP)内部トポロジーテーブル内のルートエントリーを表示します。

対処

デバイスR0では、運用モードから、show ldp routeコマンドを実行してLDPの内部トポロジーテーブルを表示します。

意味

出力で、デバイスR0のラベル配布プロトコル(LDP)内部トポロジーテーブル内のルートエントリーが表示されます。

LDPルートのFEC情報のみの検証

目的

LDPルートのFEC情報のみを表示します。

対処

デバイスR0では、運用モードからshow ldp route fec-only コマンドを実行し、ルーティングテーブル内のルートを表示します。

意味

出力で、デバイスR0に使用できるLDPプロトコルのFECルートのみが表示されます。

LDPのFECおよびシャドウルートの検証

目的

ルーティングテーブル内のFECおよびシャドウルートを表示します。

対処

デバイスR0では、運用モードから、show ldp route fec-and-routeコマンドを実行し、ルーティングテーブル内のFECとシャドウルートを表示します。

意味

出力で、デバイスR0のFECとシャドウルートが表示されます。

LDPルート設定の構成

複数のプロトコルが同じ宛先へのルートを計算する場合、ルート設定を使用して、転送テーブルにインストールするルートを選択します。優先度の最も低いルートが選択されます。優先度は、0〜255の数値を指定することができます。デフォルトでは、LDPルートの優先度は9です。

ルート設定を変更するには、preferenceステートメントを使用します。

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

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

LDPグレースフルリスタートにより、隣接ルーターからその状態を復旧する間も、LDPコントロールプレーン再起動中のルーターが、トラフィックの転送を継続することを可能にします。また、ヘルパーモードが有効になっているルーターが、LDP再起動を試みている隣接ルーターを補助することを可能にします。

セッション初期中に、ルーターはその機能をアドバタイズして、LDPグレースフルリスタートを実行したり、グレースフルリスタートTLVを送信することによって、動作中のネイバーLDPグレースフルリスタートを利用することができます。このTLVには、LDPグレースフルリスタートに関連する2つのフィールドがあります。再接続時間と回復時間です。再接続および回復時間の値は、ルーターでサポートされているグレースフルリスタートの機能を表します。

ルーターが隣接ルーターの再起動を検知すると、接続を試みる前に、回復時間の終了まで待機します。回復時間は、ルーターがLDPが緩やかに再起動するための待機時間です。回復時間は、初期化メッセージが送信、または受信されると開始します。また、この時間帯は、通常、隣接ルーターがその再起動に関する情報を維持する時間で、これによりトラフィックの転送を継続させます。

LDPグレースフルリスタートは、LDPプロトコルに対するマスターインスタンスと、特定のルーティングスタンスの両方で設定できます。すべてのプロトコルのグローバルレベル、LDPのみのプロトコルレベル、特定のルーティングインスタンスで、グレースフルリスタートを無効にすることができます。グローバルレベルにおいて、グレースフルリスタートはデフォルトで無効になっているため、LDPグレースフルリスタートもデフォルトで無効になっています。ただし、ヘルパーモード(グレースフルリスタートを試みる隣接ルーターを補助する機能)はデフォルトで有効になっています。

以下は、LDPグレースフルリスタートに関連する動作の一部です。

  • 送信ラベルは再起動時に維持されません。新しい送信ラベルが割り当てられます。

  • ルーターが再起動されると、再起動中のルーターが安定するまでグレースフルリスタートをサポートする隣接ルーターに、ラベルマップメッセージは送信されません(ラベルマップメッセージは、グレースフルリスタートをサポートしない隣接ルーターには直ちに送信されます)。ただし、その他のメッセージ(キープアライブ、アドレスメッセージ、通知、リリース)は通常通りに送信されます。このようなその他のメッセージを配信することで、ルーターの不完全な情報配信を防ぐことができます。

  • ヘルパーモードとグレースフルリスタートは独立したものです。グレースフルリスタートを設定で無効にしても、ルーターがグレーススタートを試みようとする隣接するものに協力することは可能です。

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

[edit routing-options graceful-restart]または[edit protocols ldp graceful-restart]階層レベルでグレースフルリスタート設定を変更すると、実行中のLDPセッションが自動的に再起動され、グレースフルリスタート設定が適用されます。この動作は、グレースフルリスタート設定を変更したときのBGPの動作を反映しています。

デフォルトでは、グレースフルリスタートヘルパーモードは有効ですが、グレースフルリスタートは無効です。したがって、ルーターのデフォルトの動作は、隣接ルーターがグレースフルリスタートを試行するのを支援することですが、グレースフルリスタート自体を試行することはありません。

LDPグレースフルリスタートを設定するには、次のセクションを参照してください。

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

LDPグレースフルリスタートを有効にするには、ルーターでもグレースフルリスタートを有効にする必要があります。グレースフルリスタートを有効にするには、graceful-restartステートメントを使用します。

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

  • [edit routing-options]

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

注:

ACX シリーズのルーターは、[edit logical-systems logical-system-name routing-options]階層レベルをサポートしていません。

graceful-restartステートメントは、ルーターでこの機能をサポートするすべてのプロトコルのグレースフルリスタートを有効にします。グレースフルリスタートの詳細については、ルーティングデバイス用 Junos OS ルーティングプロトコルライブラリをご覧ください。

デフォルトでは、LDPプロトコルレベルとすべてのルーティングインスタンスの両方でグレースフルリスタートを有効にすると、LDPグレースフルリスタートが有効になります。ただし、LDPグレースフルリスタートとLDPグレースフルリスタートヘルパーモードの両方を無効にすることができます。

LDPグレースフルリスタートまたはヘルパーモードの無効化

LDPグレースフルリスタートと回復を無効にするには、disableステートメントを使用します。

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

LDPプロトコルレベルでのみヘルパーモードを無効にできます。特定のルーティングインスタンスではヘルパーモードを無効にすることはできません。LDPヘルパーモードを無効にするには、helper-disableステートメントを使用します。

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

LDPグレースフルリスタートの設定は、次のものが可能です。

  • LDPグレースフルリスタートおよびヘルパーモード両方が有効。

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

  • LDPグレースフルリスタートとヘルパーモードの両方を無効にする。ルーターは、LDPグレースフルリスタート、または初期化メッセージで送信されたグレースフルリスタートのタイプ、長さ、および値(TLV)を使用しません。ルーターは、LDPグレースフルリスタートをサポートできないルーターとして動作します。

グレースフルリスタートを有効にし、ヘルパーモードを無効にしようとすると、設定エラーが発行されます。

再接続時間の設定

ネイバー間のLDP接続に障害が発生した後、ネイバーは、正常に再起動しているルーターがLDPメッセージの送信を再開するまで一定時間待機します。待機時間が経過すると、LDPセッションを再確立できます。待機時間は秒単位で設定できます。この値は、LDPグレースフルリスタートが有効になっている場合にLDP初期化メッセージで送信される耐障害性セッションTLVに含まれます。

ルーターAとルーターBがLDPネイバーであると仮定します。ルーターAは、再起動ルーターです。再接続時間は、ルーターBがルーターAの再起動を検出した後、ルーターAがルーターBに待機するように指示する時間です。

再接続時間を設定するには、reconnect-timeステートメントを使用します。

再接続時間は30〜300秒の範囲で設定できます。デフォルトでは、60秒です。

これらのステートメントを設定できる階層レベルの一覧については、これらのステートメントの概要を参照してください。

回復時間と最大回復時間の設定

回復時間は、LDPが正常に再起動するためにルーターが待機する時間です。回復時間は、初期化メッセージが送信または受信されると開始します。また、この期間は、通常、隣接ルーターがその再起動に関する情報を維持する時間で、これによりトラフィックの転送を継続させます。

再起動しているルーターから回復時間の誤った値を受け取った場合に隣接ルーターが悪影響を受けるのを防ぐために、隣接ルーターで最大回復時間を設定できます。隣接ルーターは、2つの時間のうち短い方の時間でその状態を維持します。たとえば、ルーターAはLDPグレースフルリスタートを実行しています。隣接するルーターBに900秒の回復時間を送信しました。ただし、ルーターBの最大回復時間は400秒に設定されています。ルーターBは、ルーターAからLDP情報を削除する前に400秒だけ待機します。

回復時間を設定するには、recovery-timeステートメントとmaximum-neighbor-recovery-timeステートメントを使用します。

これらのステートメントを設定できる階層レベルの一覧については、これらのステートメントの概要を参照してください。

インバウンドLDPラベルバインディングのフィルタリング

受信したLDPラベルバインディングをフィルタリングし、近隣のルーターからアドバタイズされたバインディングを受け入れるか拒否するかのポリシーを適用することが可能です。import受信ラベルのフィルタリングを設定するには、このステートメントを含めます。

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

[edit policy-options]指定されたポリシー(階層レベルで設定)は、すべてのLDPネイバーから受信したすべてのラベルバインディングに適用されます。from表 1fromLDP受信ラベルフィルタリングに適用される演算子のみを列挙します。

表 1: LDP受信ラベルフィルタリングに適用される演算子から

from オペレーター

説明

interface

指定したインターフェースで隣接する隣人から受信したバインディングにマッチする

neighbor

指定されたLDPルーターIDから受信したバインディングにマッチする

next-hop

指定したインターフェースアドレスを広告している近隣から受信したバインディングにマッチする

route-filter

指定した接頭辞を持つバインディングにマッチします。

バインディングがフィルタリングされた場合、LDP データベースには表示されますが、ラベル スイッチド パス (LSP)の一部としてインストールされることは考慮されません。

一般に、LDP のポリシー適用は、LSP の確立を阻止するためにのみ使用でき、そのルーティングを制御するために使用できるわけではありません。これは、LSP がたどる経路は、LDP ではなくユニキャストルーティングで決定されるためです。しかし、異なるネイバーを経由したデスティネーションへのイコールコスト パスが複数存在する場合、LDP フィルタリングを使用して、可能性のあるネクスト ホップの一部を考慮から除外することができます。(そうでない場合は、LDPはネクストホップの候補の中からランダムに1つを選択します)。

LDPセッションは、インターフェイスやインターフェイスアドレスにバインドされていません。LDP は、 ルータ単位 (インタフェース単位ではない) のラベルのみを広告するため、 2 つのルータ間に複数のパラレル リンクが存在する場合、 LDP セッションは 1 つしか確立されず、 また 1 つのインタフェースに拘束されません。ルーターが同じネイバーに複数の隣接関係を持つ場合、フィルターが期待通りの働きをするように注意してください。next-hopinterface(一般的に、この場合andの使用は適切ではありません)。

ラベルがフィルタリングされた場合(ポリシーによって拒否され,LSPの構築に使用されないことを意味する),データベース内でフィルタリング済みとマークされる。

LDPのポリシーを設定する方法についての詳細は、ルーティングポリシー、ファイアウォールフィルター、トラフィックポリサーのユーザーガイドをご覧ください。

例:インバウンドLDPラベルバインディングのフィルタリング

すべてのネイバーから/32プレフィックスのみを受け入れる。

131.108/1610.10.255.2ルータ ID からは accept or longer、他のすべてのネイバーからは all prefix を accept します。

アウトバウンドLDPラベルバインディングのフィルタリング

エクスポートポリシーを設定することで、LDPアウトバウンドラベルのフィルター処理ができます。ルーティングポリシーを適用することで、アウトバウンドラベルバインディングをフィルター処理し、バインディングが隣接ルーターにアドバタイズされることを阻止できます。アウトバウンドラベルフィルタリングを設定するには、exportステートメントを入れます。

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

指名されたエクスポートポリシー([edit policy-options]の階層レベルで設定)は、すべてのLDPネイバーに送信された全ラベルバインディングに適用されます。LDPアウトバウンドラベルフィルタリングに適用された唯一のfrom演算子はroute-filterで、特定のプレフィックスのバインディングに一致します。アウトバウンドラベルフィルタリングに適用された唯一のto演算子は、表 2にある演算子です。

表 2: LDPアウトバンドラベルフィルタリングのto演算子

to演算子

説明

interface

指定されたインターフェイス上に隣接するネイバーに送信されたバインディングに一致

neighbor

指定されたLDPルーターIDに送信されたバインディングに一致

next-hop

指定されたインターフェイスアドレスをアドバタイズするネイバーに送信されたバインディングに一致

バインディングがフィルター処理されると、そのバインディングは隣接ルーターにはアドバタイズされませんが、ローカルルーターのLSPの一部としてインストールすることは可能です。LDPにポリシーを適用して、LSPの確立を止めることができますが、そのルーティングを操作することはできません。LSPがたどるパスは、LDPではなく、ユニキャストルーティングが決定します。

LDPセッションは、インターフェイスやインターフェイスアドレスにバインドされません。LDPは、ルーター単位(インターフェイス単位ではなく)のラベルのみをアドバタイズします。複数のパラレルリンクが2つのルーター間で存在する場合、1つのLDPセッションのみが確立され、単一のインターフェイスにはバインドされません。

ルーターが同じネイバーに複数の隣接関係がある場合、next-hopinterfaceの演算子は使用しないでください。

フィルターされたラベルは、データベースで記録されています。

LDPのポリシーを設定する方法についての詳細は、ルーティングポリシー、ファイアウォールフィルター、トラフィックポリサーのユーザーガイドをご覧ください。

例:アウトバウンドLDPラベルバインディングのフィルタリング

すべてのネイバーへの10.10.255.6/32に対するルートのトランスミッションを阻止します。

131.108/16もしくはそれより長いものだけをルーターID10.10.255.2に送信し、他全てのルーターにすべてのプレフィックスを送信します。

LDPで使用するトランスポートアドレスの指定

ルーターは、まずLDPセッションを確立する前に、互いにTCPセッションを確立する必要があります。TCPセッションでは、ルーターがLDPセッションに必要なラベルアドバタイズを交換できます。TCPセッションを確立するには、各ルーターがもう一方のルーターのトランスポートアドレスを学習する必要があります。トランスポートアドレスは、LDPセッションが実行するTCPセッションを特定するのに使用されるIPアドレスです。

LDPトランスポートアドレスを設定するには、transport-addressステートメントを含めます。

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

router-idオプションを指定した場合、ルーター識別子のアドレスはトランスポートアドレスとして使用されます(特に設定されていない限り、ルーター識別子は通常ループバックアドレスと同じです)。interfaceオプションを指定した場合、インターフェイスアドレスは、そのインターフェイス上で到達できるネイバーへのLDPセッションのトランスポートアドレスとして使用されます。ルーター識別子は、デフォルトでトランスポートアドレスとして使用されます。

注:

正しく動作するためには、LDPトランスポートアドレスに到達できる必要があります。ルーターIDは識別子であり、ルーティング可能なIPアドレスではありません。このため、ループバックアドレスと一致するようにルーターIDを設定して、ループバックアドレスをIGPでアドバタイズすることを推奨します。

LDP仕様では、同じネイバーへのすべてのインターフェイスで同じトランスポートアドレスをアドバタイズする必要があるため、同じLDPネイバーに複数のパラレルリンクがある場合、interfaceオプションを指定することができません。LDPが同じネイバーへの複数のパラレルリンクを検出した場合、インターフェイス上のネイバーを切断するか、 router-idオプションを指定することにより条件がクリアされるまで、そのネイバーへのインターフェイスを1つずつ無効にします。

ターゲット LDP セッションに使用されるトランスポートアドレスを制御する

2 つのデバイス間に TCP セッションを確立するには、各デバイスがもう片方のデバイスのトランスポートアドレスを学習する必要があります。トランスポートアドレスは、LDP セッションが稼働する TCP セッションを特定するのに使用される IP アドレスです。これまでは、このトランスポートアドレスはルーター ID またはインターフェイスアドレスに限定されていました。LDP トランスポートアドレス機能を使うと、レイヤー 2 回線、MPLS、VPLS 隣接関係のターゲット LDP ネイバーのトランスポートアドレスとして IP アドレスを明示的に設定できます。これにより、トランスポートアドレス設定を使用してターゲット LDP セッションをコントロールできるようになります。

ターゲット LDP セッションに使用されるトランスポートアドレスをコントロールすることの利点

ターゲット LDP セッションを確立するためにトランスポートアドレスを設定することには、次のような利点があります。

  • Flexible interface configurationsターゲット LDP ネイバー間の LDP セッション作成を中断させることなく、1 つのループバックインターフェイスに複数の IP アドレスを設定する柔軟性を提供します。

  • Ease of operation— インターフェイスレベルで設定されているトランスポートアドレスでは、LDP 向けの IGP バックボーンで複数のプロトコルを使用できます。これにより、スムーズで簡単な操作が可能になります。

ターゲット LDP トランスポートアドレスの概要

Junos OS リリース 19.1R1 以前は、LDP はすべての LDP インターフェイスのトランスポートアドレスとしてのルーター ID またはインターフェイスアドレスへのみサポートを提供していました。そのインターフェイスで形成された隣接関係は、インターフェイスまたはルーター ID に割り当てられた IP アドレスの 1 つを使用しました。ターゲットの隣接関係がある場合、インターフェイスはループバックインターフェイスです。デバイスに複数のループバックアドレスが設定されていた場合、トランスポートアドレスはインターフェイスから派生できず、その結果 LDP セッションを確立できません。

Junos OS リリース 19.1R1 以降は、sessionsession-groupinterface設定ステートメントの下で、ターゲット LDP セッションのトランスポートアドレスに使用されるデフォルト IP アドレスに加えて、他の IP アドレスをトランスポートアドレスとして設定することができます。トランスポートアドレス設定は、レイヤー 2 回線、MPLS、VPLS 隣接関係を含む設定されたネイバーのみに適用されます。この設定は、検知された隣接関係(ターゲットかどうかは関係ない)には適用されません。

トランスポートアドレスの優先度

セッション、セッショングループ、およびインターフェイスレベルで、ターゲット LDP セッションのトランスポートアドレスを設定できます。

トランスポートアドレスが設定された後、LDP のトランスポートアドレス設定に基づいてターゲット LDP セッションが確立されます。

ターゲットネイバー(レイヤー 2 回線、MPLS、VPLS、LDP 設定で設定)のトランスポートアドレスの優先度は、次のような順で設定されています。

  1. [edit protocols ldp session]階層の下。

  2. [edit protocols ldp session-group]階層の下。

  3. [edit protocols ldp interfcae lo0]階層の下。

  4. [edit protocols ldp]階層の下。

  5. デフォルトのアドレス。

検出されたネイバーのトランスポートアドレスの優先度は、次のような順序になっています。

  1. [edit protocols ldp interfcae]階層の下。

  2. [edit protocols ldp]階層の下。

  3. デフォルトのアドレス。

自動ターゲットネイバーのトランスポートアドレスの優先順位(LDP が hello パケットを承認するよう設定されている)は次のとおりです:

  1. [edit protocols ldp interfcae lo0]階層の下。

  2. [edit protocols ldp]階層の下。

  3. デフォルトのアドレス。

トランスポートアドレス設定のトラブルシューティング

次の表示コマンド出力を使用して、ターゲット LDP セッションのトラブルシューティングを行うことができます。

  • show ldp session

  • show ldp neighbor

    コマshow ldp neighborンドの出力のdetailレベルには、hello メッセージでターゲットネイバーに送信されたトランスポートアドレスが表示されます。このアドレスがネイバーから到達できない場合、LDP セッションは表示されません。

  • show configuration protocols ldp

また、LDP 形跡オプションを有効にしてさらにトラブルシューティングを行うこともできます。

  • 無効なトランスポートアドレス(到達不可能)の使用から、有効なトランスポートアドレス使用に設定が変更された場合、次の形跡が観察されます:

  • 有効なトランスポートアドレスの使用から、無効なトランスポートアドレス(到達不可能)使用に設定が変更された場合、次の形跡が観察されます:

設定がうまくいかない場合は、次のトラブルシューティングタスクを実行してください。

  • をチェックしますaddress familysessionステートメントの下で設定されたトランスポートアドレスは、ネイバーまたはセッションとして同じアドレスファミリーに属している必要があります。

  • neighborまたは sessionステートメントの下のトランスポートアドレスとして設定されたアドレスは、ターゲットの hello メッセージが起動するルーターに対してローカルなものである必要があります。アドレスが設定済みかどうかチェックできます。どのインターフェイスの下でもアドレスが設定されていない場合、設定は拒否されます。

ルーティングテーブルから LDP にアドバタイズするプレフィックスの設定

LDP にアドバタイズする一連のプレフィックスを制御し、ルーターをそれらのプレフィックスのエグレス ルーターとして、設定することができます。デフォルトでは、ループバックアドレスのみが LDP にアドバタイズされます。LDP にアドバタイズするルーティングテーブルのプレフィックスのセットを設定するには、 egress-policy ステートメントを使用します。

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

注:

ループバックアドレスを含まない LDP 用のエグレスポリシーを設定した場合、LDP でアドバタイズすることはありません。ループバックアドレスのアドバタイズを継続するには、LDP のエグレスポリシーの一部として明示的に設定する必要があります。

指定されたポリシー( [edit policy-options] または [edit logical-systems logical-system-name policy-options] 階層レベルで設定)は、ルーティングテーブルのすべてのルートに適用されます。ポリシーに一致するルートは、LDP にアドバタイズされます。export ステートメントを使用して、これらのプレフィックスがアドバタイズされるネイバーのセットを制御することができます。考慮されるのは from のオペレーターのみで、有効な from のオペレーターを使用することができます。詳細については、 ルーティングデバイス用 Junos OS ルーティングプロトコルライブラリをご覧ください。

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

例:LDP にアドバタイズされるプレフィックスの設定

すべての接続されたルートを LDP にアドバタイズします。

FEC Deaggregationの設定

LDP の出口ルータが複数のプレフィックスを広告する場合、 プレフィックスは 1 つのラベルに束ねられ、 1 つの FEC (forwarding equivalence class) に集約されます。デフォルトでは、 LDP はアドバタイズがネットワークを通過する際にこのアグレゲーショ ンを維持します。

通常、LSPは複数のネクストホップに分割されず、プレフィックスが単一のLSPに束ねられるため、等コストパス間の負荷分散は発生しない。ただし、ロードバランシングポリシーを設定し、FECを縮退させれば、等コストパス間でロードバランシングを行うことができます。

FEC を Deaggregate すると、各プレフィックスが別々のラベルにバインドされ、別々の LSP となります。

デアグリゲーション FECを設定するには、deaggregateステートメントを含めます。

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

すべての LDP セッションに対して、グローバルにのみデアグリゲーション FEC を設定できます。

FECを縮退することで、結果として複数のLSPを複数のイコールコストパスに分散させ、イグレスセグメント上の複数のネクストホップにLSPを分散させますが、LSPごとにネクストホップを1つだけ設置することができます。

no-deaggregateFECを集計する場合は、その旨を記載する。

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

すべての LDP セッションについて、グローバルにのみ集約 FEC を設定できます。

LDP FEC のポリシーの設定

Junos OS を設定して LDP FEC のトラフィックを追跡して規制できます。LDP FEC ポリシーは、以下のいずれかの方法で実行することができます。

  • LDP FEC のイングレストラフィックを追跡または規制する。

  • LDP FEC のトランジットトラフィックを追跡または規制する。

  • 特定の転送クラスから発信された LDP FEC のトラフィックを追跡または規制する。

  • 特定の仮想ルーティングおよび転送(VRF)サイトから発信された LDP FECトラフィックを追跡または規制する。

  • 特定の LDP FEC に対してバインドされた偽トラフィックを廃棄する。

LDP FEC のトラフィックを規制するには、まずフィルターを設定する必要があります。具体的には、 [edit firewall family protocol-family filter filter-name term term-name from]階層レベルでinterface ステートメントまたはinterface-set ステートメントのいずれかを設定する必要があります。interfaceステートメントでは、フィルターを単一のインターフェイスに一致させることができます。interface-setステートメントでは、フィルターを複数のインターフェイスに一致させることができます。

LDP FEC のinterfaceステートメント、interface-setステートメント、ポリシーの設定方法については、ルーティング ポリシー、ファイアウォール フィルター、トラフィック ポリシーユーザー ガイドを参照してください。

フィルターを設定した後、LDP のpolicingステートメント設定に含める必要があります。LDP FEC のポリシーを設定するには、policingステートメントを含めます。

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

policing ステートメントには、以下のオプションが含まれます。

  • fec—規制する LDP FEC の FEC アドレスを指定します。

  • ingress-filter—イングレストラフィックフィルターの名前を指定します。

  • transit-traffic—トランジットトラフィックフィルターの名前を指定します。

LDP IPv4 FECフィルターの設定

デフォルトでは、ターゲットLDPセッションが確立されると、Junos OSは常にIPv4転送等価クラス(FEC)とレイヤー2回線FECの両方をターゲットLDPセッション上で交換します。間接的に接続されたネイバーへのLDPセッションの場合、セッションがレイヤー2回線またはVPLSをサポートするように特別に設定されている場合にのみ、レイヤー2回線FECをネイバーにエクスポートすることができます。

すべての非BGPプレフィックスがLDPにアドバタイズされる混合ベンダーネットワークでは、LDPデータベースが大きくなる可能性があります。このタイプの環境では、レイヤー2回線またはLDP VPLS設定が原因で形成されたLDPセッションを介したIPv4 FECをアドバタイズしないようにすることが有効な場合があります。同様に、このような環境で受信したIPv4 FECをフィルタリングすることも有用です。

LDPセッションに関連するすべてのLDPネイバーがレイヤー2のみである場合、l2-smart-policyステートメントを設定することにより、レイヤー2回線FECのみをアドバタイズするようにJunos OSを設定できます。また、この機能は、このセッションで受信したIPv4 FECを自動的にフィルタリングします。l2-smart-policyに対して有効化される明示的なエクスポートまたはインポートポリシーを設定すると、対応する方向でこの機能が無効になります。

検出された隣接関係が原因でLDPセッションのネイバーの1つが形成された場合、または1つ以上のRSVP LSPのLDPトンネリング設定が原因で隣接関係が形成された場合、IPv4 FECはデフォルトの動作を使用してアドバタイズおよび受信されます。

LDPがレイヤー2ネイバーとのLDPセッションでのみIPv4 FECをエクスポートしないようにし、そのようなセッションで受信したIPv4 FECを除外するには、l2-smart-policyステートメントを使用します。

このステートメントを設定できる階層レベルの一覧については、このステートメントの概要を参照してください。

LDP LSPに対してBFDを設定する

LDP LSPに対して、Bidirectional Forwarding Detection(BFD)を設定できます。BFDプロトコルは、ネットワーク内の障害を検出するための単純なhelloメカニズムです。Helloパケットは指定された、定期的な間隔で送信されます。ルーターが一定時間経過した後に応答を受信しなくなった場合に、ネイバーの障害が検出されます。BFDは、さまざまなネットワーク環境とトポロジーで動作します。BFDの障害検出タイマーでは、静的ルートの障害検出メカニズムよりも制限時間が短くなっており、より高速に検出できます。

パスのBFDセッションが失敗するたびにエラーがログに記録されます。以下は、LDP LSPに対するBFDのログメッセージの一例を示しています。

また、RSVP信号付きLSPに対してBFDを設定するに記載されているように、RSVP LSPに対してBFDを設定することもできます。

BFDの障害検出タイマーは適応型であり、より厳格に、またはよりゆるめに調整することができます。例えば、隣接関係に障害が発生した場合にタイマーをより高い値に適応したり、ネイバーが設定されている値よりも高い値のタイマーをネゴシエートしたりすることができます。BFDセッションのフラップが15秒間に3回以上発生すると、タイマーはより高い値に適応します。バックオフアルゴリズムは、ローカルBFDインスタンスがセッションフラップの原因である場合に、受信(Rx)の間隔を2つ増加させます。リモートBFDインスタンスがセッションフラップの原因である場合は、送信(Tx)の間隔が2つ増加します。clear bfd adaptationコマンドを使用すれば、BFD間隔タイマーを設定した値に戻すことができます。clear bfd adaptationコマンドはヒットレスであり、コマンドがルーティングデバイスのトラフィックフローに影響を及ぼすことはありません。

LDP LSPに対してBFDを有効にするには、oamおよびbfd-liveness-detectionステートメントを含めます。

特定の転送等価クラス(FEC)に関連づけられたLDP LSPに対してBFDを有効にするには、[edit protocols ldp]階層レベルでfecオプションを使用してFECアドレスを設定します。または、Operation Administration and Management(OAM)イングレスポリシーを設定して、FECアドレスの範囲でBFDを有効にすることもできます。詳細については、LDPに対してOAMイングレスポリシーを設定するを参照してください。

BFD LDP LSPは、同等のFECアドレスが明示的に設定されているか、OAMイングレスポリシーを使用してFECでOAMが有効になっていなければ、有効にすることはできません。FECアドレスに対してBFDが有効になって場合、BFDセッションは立ち上がりません。

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

  • [edit protocols ldp]

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

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

oam ステートメントには、以下のオプションが含まれます。

  • fec—FECアドレスを指定します。BFDセッションを立ち上げるためには、FECアドレスを指定するかOAMイングレスポリシーを設定する必要があります。

  • lsp-ping-interval—LSPのping間隔を秒単位で指定します。LDPシグナル化されたLSPでpingを発行するには、ping mpls ldpコマンドを使用します。詳細については、CLIエクスプローラーを参照してください。

bfd-liveness-detection ステートメントには、以下のオプションが含まれます。

  • ecmp—指定されたFECに対して設定されたすべてのECMPパスに対して、LDPがBFDセッションを確立するようにします。ecmpオプションを設定する場合、指定したFECに対してもperiodic-tracerouteステートメントを設定する必要があります。設定しなかった場合、Commitの動作が失敗します。periodic-tracerouteステートメントをグローバル階層レベル([edit protocols ldp oam])で設定しながら、特定のFEC([edit protocols ldp oam fec address bfd-liveness-detection])に対してのみecmpオプションを設定することができます。

  • ホールドダウン間隔—ルートまたはネクストホップを追加する前に、BFDセッションの立ち上げた状態を維持しておく長さを指定します。0 秒を指定すると、BFD セッションが復旧するとすぐに、ルートやネクスト ホップが追加されます。

  • minimum-interval—最小の受送信間隔を指定します。minimum-intervalオプションを設定する場合、minimum-receive-intervalオプションまたはminimum-transmit-intervalオプションを設定する必要はありません。

  • minimum-receive-interval—最小の受信間隔を指定します。1~255,000ミリ秒の範囲になります。

  • minimum-transmit-interval—最小の送信間隔を指定します。1~255,000ミリ秒の範囲になります。

  • multiplier—検出時間の倍率を指定します。1~255の範囲になります。

  • バージョン—BFDバージョンを指定します。オプションは、BFDバージョン0またはBFDバージョン1となります。デフォルトでは、Junos OSソフトウェアが自動的にBFDバージョンを判断しようと試みます。

LDP LSP 向け ECMP-Aware BFD 設定

FEC に BFD を設定すると、ルーターのアクティブ ローカル ネクストホップ 1 つのみに対し、BFD セッションが確立されます。ただし、複数の BFD セッションを設定することができ、特定の ECMP(イコールコストマルチパス)パスに関連する FEC ごとに 1 つずつ設定することができます。これが正常に機能するために、 LDP LSP の定期的なトレースルートも設定する必要があります。(LDP LSP トレースルートの設定を参照してください)。LDP LSP トレースルートは、ECMP パスを発見するために使用されます検出された各 ECMP パスに BFD セッションが開始されます。ECMP パスの 1 つに対する BFD セッションが失敗するたびに、エラーが記録されます。

LDP LSP トレースルートを定期的に実行し、ECMP パスの整合性を確認します。問題が発見された場合、以下のようなことが発生する可能性があります。

  • ある FEC の最新の LDP LSP トレースルートが前回のトレースルートとは異なる場合、その FEC に関連する BFD セッション(前回の実行から変更されたアドレス範囲)の BFD セッションはダウンし、変更された宛先アドレスに対して新しい BFD セッションが開始されます。範囲。

  • LDP LSP トレースルートがエラー(例、タイムアウト)を返す場合、その FEC に関連するすべての BFD セッションは破棄されます。

指定された FEC に設定されたすべての ECMP パスに対して、BFD セッションを確立するよう LDP を設定するには、ecmpステートメントを含めます。

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

ecmpステートメントとともに、periodic-tracerouteステートメントもグローバル LDP OAM 設定([edit protocols ldp oam]または[edit logical-systems logical-system-name protocols ldp oam]階層レベル)または指定された FEC の設定([edit protocols ldp oam fec address]または[edit logical-systems logical-system-name protocols ldp oam fec address]階層レベル)に含める必要があります。それ以外の場合、コミット操作は失敗します。

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

LDP LSP での BFD セッションの障害アクションの設定

LDP LSP で BFD セッション障害イベントが発生した場合、ルートおよびネクストホップ プロパティを設定できます。障害イベントは、ダウンした既存の BFD セッションまたは起動しない BFD セッションです。LDP は、関連する BFD セッションが復帰すると、ルートまたはネクスト ホップを追加します。

LDP LSP で BFD セッション障害が発生した場合の failure-action ステートメントの障害アクション オプションの 1 つを設定できます。

  • remove-nexthop—BFD セッション障害イベントが検出された場合、イングレス ノードの LSP ルートのネクスト ホップに対応するルートを削除します。

  • remove-route—BFD セッション障害イベントが検出された場合、適切なルーティング テーブルから LSP に対応するルールを削除します。LSP が ECMP で設定されており、いずれかのパスに対応する BFD セッションがダウンした場合、ルートが削除されます。

LDP LSP で BFD セッション障害が発生した場合の障害イベントを設定するには、remove-nexthop ステートメントにオプションまたは failure-action ステートメントに remove-route オプションを含めます。

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

BFD セッションのホールドダウン間隔を設定する

BFD セッションがルートやネクスト ホップを追加するまでの時間を指定するには、holddown-interval ステートメントを [edit protocols ldp oam bfd-livenesss-detection] 階層レベルまたは [edit protocols ldp oam fec address bfd-livenesss-detection] 階層レベルのいずれかで設定する必要があります。0 秒を指定すると、BFD セッションが復旧するとすぐに、ルートやネクスト ホップが追加されます。

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

マルチキャストのみの高速再ルートの理解

MoFRR(マルチキャストのみの高速再ルート)は、リンク障害が発生した際に、マルチキャスト配信ツリー内のトラフィックのパケットロスを最小限に抑える機能で、PIM(プロトコル独立マルチキャスト)やLDP(マルチポイント ラベル配信プロトコル)などのマルチキャスト ルーティング プロトコルをサポートしています。

注:

スイッチでは MPLS ラベルスイッチ パスとマルチポイント LDP がある MoFRR はサポートされていません。

MX シリーズ ルーター、MoFRR は、MPC ライン カードがある MX シリーズ ルーターでのみサポートされています。前提として、ルーターをnetwork-services enhanced-ipモードに設定し、ルーターのすべてのラインカードが MPC である必要があります。

MoFRR を有効化すると、デバイスはマルチキャスト ソースに向けて、プライマリおよびバックアップのアップストリーム パスでジョイン メッセージを送信します。デバイスは、プライマリ パスとバックアップ パスの両方からデータ パケットを受信し、プライオリティ(プライマリ パスとバックアップ パスに割り当てられた重み)に基づいて冗長なパケットを廃棄します。プライマリ パスに障害が発生すると、デバイスは直ちにセカンダリ インターフェィス(バックアップ パス)からのパケットの受け入れを開始します。高速スイッチオーバーにより、プライマリ パスのリンク障害時のコンバージェンス時間が大幅に短縮されます。

MoFRR のアプリケーションの 1 つにIPTV のストリーミングがあります。IPTV のストリームは UDP ストリームとしてマルチキャストされているため、パケットが失われても再送されず、満足のいくユーザー エクスペリエンスが得られませんでした。MoFRR は、状況を改善できます。

MoFRR の概要

ユニキャスト ストリームの高速再ルートでは、アップストリームのルーティング デバイスが MPLS LSP(ラベルスイッチ パス)を事前に確立したり、LFA(IP ループフリーの代替ルート)の高速再ルートバックアップパスを事前に計算したりして、ダウンストリーム パスのセグメントの障害に対処します。

マルチキャスト ルーティングでは、通常、受信側がトラフィックの配信グラフを作成します。これは、一般的に、送信元から受信者へのパスを確立するユニキャスト ルーティングとは異なります。マルチキャストの配信グラフを構築できるプロトコルとして、PIM(IP用)、マルチポイント LDP(MPLS用)、RSVP-TE(MPLS用)があります。これらのうち、PIM とマルチポイント LDP の受信機がディストリビューション グラフの設定を開始するため、MoFRR はこれら 2 つのマルチキャスト プロトコルがサポートされている場所で動作します。

マルチキャストツリーでは、デバイスがネットワーク コンポーネントの障害を検出した場合、リアクティブ修復を実行するのに時間がかかり、代替パスを設定する間に大きなトラフィック ロスが発生します。MoFRR は、ネットワーク コンポーネントに障害が発生した場合に、マルチキャスト 配信 ツリーでのトラフィック ロスを低減します。MoFRR では、ダウンストリームのルーティング デバイスの 1 つが、同じマルチキャスト トラフィックのバックアップ ライブ ストリームを受信するために、ソースに向かう代替パスを設定します。プライマリ ストリームで障害が発生した場合、MoFRRルーティング デバイスはバックアップ ストリームに素早くスイッチすることができます。

MoFRR を有効にすると、各(S,G)エントリーに対して、デバイスは利用可能なアップストリーム インターフェィスのうち 2 つを使用して、ジョイン メッセージを送信し、マルチキャスト トラフィックを受信します。このプロトコルは、2 つのパスが利用可能な場合、2 つのディスジョイント パスを選択しようとします。ディスジョイント パスが利用できない場合、プロトコルは 2 つの非ディスジョイント パスを選択します。2 つの非ディスジョイント パスを利用できない場合、バックアップがないプライマリ パスのみが選択されます。MoFRR は、利用可能なパスのロード バランシングのために、不連続なバックアップを優先します。

MoFRR は、IPv4 および IPv6 両方のプロトコル ファミリーでサポートされています。

図 12は、マルチキャスト レシーバー ルーティング デバイス(エグレス PE(プロバイダ エッジ)デバイスとも呼ばれています)からマルチキャスト ソース ルーティング デバイス(イングレス PE デバイスとも呼ばれています)への 2 つのパスを示しています。

図 12: MoFRR サンプル トポロジーMoFRR サンプル トポロジー

MoFRR が有効な場合、エグレス(レシーバー側)のルーティング デバイスは、各 (S,G) のマルチキャスト ソースに向けて、プライマリ パスとバックアップ パスの 2 つのマルチキャスト ツリーを設定します。つまり、エグレス ルーティング デバイスは、同じ(S,G)ジョイン メッセージを 2 つの異なるアップストリーム ネイバーに向けて伝搬することで、2 つのマルチキャスト ツリーを作成します。

図 12に示すように、マルチキャスト ツリーの一方はプレーン 1 を経由し、もう一方はプレーン 2 を経由します。各(S,G)において、エグレス ルーティング デバイスは、プライマリ パスで受信したトラフィックを転送し、バックアップ パスで受信したトラフィックをドロップします。

MoFRR は、ECMP(Equal Cost Multipath)パスと非ECMP パスの両方でサポートされます。非ECMP パスでの MoFRR をサポートするためには、デバイスはユニキャストの LFA(ループフリーの代替ルート)を有効化する必要があります。LFA ルートを有効にするには、IGP(Interior Gateway Protocol)設定のlink-protection ステートメントを使用します。OSPF または IS-IS インターフェイスでリンク プロテクションを有効化すると、デバイスはプロテクションされたインターフェイスを通過するすべての宛先ルートのプライマリ ネクスト ホップへのバックアップ LFA パスを作成します。

Junos OSは、IP MoFRR の場合は IP ネットワークに、マルチポイント LDP MoFRR の場合は MPLS LER(ラベル エッジ ルーティング デバイス)にMoFRR を実装します。

マルチポイント LDP MoFRRは、パケットが IP ネットワークに転送される場である、MPLS ネットワークのエグレス デバイスで使用されます。マルチポイント LDP MoFRR では、デバイスは、LERで MPLS パケットの 2 つのストリームを受信するために、アップストリームの PEルーティングデバイスに向けて 2 つのパスを確立します。デバイスは一方のストリーム(プライマリ)を受け入れ、もう一方のストリーム(バックアップ)は LER でドロップされます。プライマリ パスが故障した場合、デバイスは代わりにバックアップ ストリームを受け入れます。インバンド シグナリング サポートは、マルチポイント LDP がある MoFRR の前提条件となります(『Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs』を参照してください)。

PIM 機能

Junos OSは、PIM の SSM(ソース スペシフィック マルチキャスト)と ASM(エニー ソース マルチキャスト)の SPT(最短パス ツリー)の結合に MoFRR をサポートしています。MoFRRは、SSMとASMの両方の範囲でサポートされています。(*,G)ジョインに対して MoFRR を有効にするには、[edit routing-options multicast stream-protection]階層に、mofrr-asm-starg設定ステートメントを含めます。各グループ G について、MoFRR は (S,G) または (*,G) のいずれかで動作しますが、両方ではありません。(S,G) は常に (*,G) よりも優先されます。

MoFRR を有効にすると、PIM ルーティング デバイスは、2 つのアップストリームの RPF(リバースパスフォワーディング)インターフェィスにジョイン メッセージを伝搬し、同じジョイン リクエストに対するマルチキャスト トラフィックを両方のリンクで受信します。MoFRRは、同一のすぐにアップストリームのルーティング デバイスに収束しない 2 つのパスを優先します。PIMは、アップストリームの RPF ネクスト ホップを持つ適切なマルチキャスト ルートを 2 つのインターフェイス(プライマリ パスとバックアップ パス)にインストールします。

プライマリ パスに障害が発生すると、バックアップ パスがプライマリ ステータスにアップグレードされ、デバイスはそれに応じてトラフィックを転送します。利用可能な代替パスがある場合、MoFRR は新しいバックアップ パスを計算し、適切なマルチキャスト ルートを更新またはインストールします。

PIM のジョイン ロード バランシングで MoFRR を有効化することができます(join-load-balance automaticのステートメントを参照してください)。しかし、その場合、リンク間のジョイン メッセージの配信が均等でない可能性があります。新しい ECMP リンクが追加されると、プライマリ パス上のジョイン メッセージが再配信され、ロード バランシングされます。バックアップ パス上のジョイン メッセージは、同じパスをたどる可能性があり、均等に再配配信されない可能性があります。

[edit routing-options multicast]階層のstream-protection設定ステートメントで MoFRR を有効化します。MoFRR は、一連のフィルター ポリシーによって管理されます。

エグレス PIM ルーティング デバイスは、ジョイン メッセージまたは IGMP レポートを受信すると、MoFRR 設定を確認し、以下のように処理を行います。

  • MoFRR の設定がない場合、PIM は 1 つのアップストリームのネイバー(例えば、図 12のプレーン 2)に向けてジョイン メッセージをアップストリームに送信します。

  • MoFRR の設定がある場合、デバイスはポリシーの設定を確認します。

  • ポリシーが存在しない場合、デバイスはプライマリ パスとバックアップ パス(アップストリームのインターフェイス)を確認し、以下のように処理を行います。

    • プライマリ パスとバックアップ パスが利用できない場合、PIM は 1 つのアップストリーム ネイバー(例えば、図 12のプレーン 2)に向けてジョイン メッセージをアップストリームで送信します。

    • プライマリ パスとバックアップ パスが利用可能な場合、PIM は利用可能なアップストリームの 2 つのネイバーに向けてジョイン メッセージをアップストリームに送信します。Junos OSは、マルチキャスト トラフィック(例えば、図 12のプレーン 1)を受信するために、プライマリおよびセカンダリのマルチキャスト パスを設定します。

  • ポリシーが存在する場合、デバイスはポリシーがこの (S,G) に対して MoFRR を許可しているかどうかを確認し、以下のように処理を進めます。

    • このポリシーチェックが失敗した場合、PIM は 1 つのアップストリーム ネイバー(例えば、図 12のプレーン 2)に向けてジョイン メッセージをアップストリームで送信します。

    • このポリシーチェックが通過した場合-デバイスはプライマリ パスとバックアップ パス(アップストリームのインターフェイス)をチェックします。

      • プライマリ パスとバックアップ パスが利用できない場合、PIMは 1 つのアップストリーム ネイバー(例えば、図 12のプレーン 2)に向けてジョイン メッセージをアップストリームで送信します。

      • プライマリ パスとバックアップ パスが利用可能な場合、PIM は利用可能なアップストリームの 2 つの利用可能なネイバーに向けてジョイン メッセージをアップストリームに送信します。デバイスは、マルチキャスト トラフィック(例えば、図 12のプレーン 1)を受信するために、プライマリおよびセカンダリのマルチキャスト パスを設定します。

マルチポイント LDP 機能

MPLS のトラフィックの重複を避けるため、マルチポイント LDP は通常、1 つのアップストリーム パスのみを選択します。(セクション 2.4.1.1を参照してください。RFC 6388における『アップストリームのLSR』の決定、『Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths』)。

MoFRR を使用したマルチポイント LDPでは、マルチポイント LDP デバイスが 2 つの別々のアップストリーム ピアを選択し、それぞれのアップストリーム ピアに 1 つずつ、2 つの別々のラベルを送信します。デバイスは、RFC 6388に記載されているのと同じアルゴリズムを使用して、プライマリ アップストリーム パスを選択します。デバイスは同じアルゴリズムを使用してバックアップ アップストリーム パスを選択しますが、プライマリ アップストリーム LSRは候補から除外されます。2 つの異なるアップストリーム ピアは、2 つの MPLS トラフィックのストリームをエグレス ルーティング デバイスに送信します。デバイスは、MPLS トラフィックを受け入れるプライマリ パスとして、アップストリーム側のネイバーパスのうち 1 つだけを選択します。もう一方のパスはバックアップ パスとなり、デバイスはそのトラフィックをドロップします。プライマリ アップストリーム パスに障害が発生すると、デバイスはバックアップ パスからのトラフィックの受け入れを開始します。マルチポイント LDP デバイスは、IGP(Interior Gateway Protocol)ルートデバイスのネクスト ホップに基づいて、2 つのアップストリーム パスを選択します。

FEC(Forwarding Equivalentency Class)とは、同じ方法、同じ経路、同じ転送処理で転送される IP パケットのグループのことです。通常、あるパケットに貼られるラベルは、そのパケットが割り当てられている FEC を表しています。MoFRR では、各 FEC の mpls.0 テーブルに、プライマリ ラベル用のルートとバックアップ ラベル用のルートの 2 つのルートが配置されます。

同じすぐアップストリームのデバイスに向かうパラレル リンクがある場合、デバイスは両方のパラレル リンクをプライマリとみなします。どの時点でも、アップストリームのデバイスは複数のパラレル リンクのうち 1 つだけにトラフィックを送ります。

bud nodeとは、エグレス LSR でありながら、1 つ以上の直接接続されたダウンストリーム LSR を持つ LSRのことです。バッド ノードの場合、プライマリ アップストリーム パスからのトラフィックは、ダウンストリーム LSR に転送されます。プライマリ アップストリーム パスが失敗した場合、バックアップ アップストリームパスからの MPLS トラフィックはダウンストリーム LSR に転送されます。これは、ダウンストリームの LSR のネクスト ホップが、両方の MPLS ルートに、エグレスのネクスト ホップとともに追加されることを意味します。

PIM と同様に、[edit routing-options multicast] 階層のstream-protection設定ステートメントを使用して、マルチポイント LDP で MoFRR を有効にし、一連のフィルタ ポリシーで管理します。

MoFRR のマルチポイント LDP ポイントツーパルチポイント FEC を有効にしている場合、デバイスは以下の点を考慮してアップストリーム パスを選択します。

  • ターゲットとなる LDP セッションは、非ターゲットとなる LDP セッションがある場合はスキップされます。ターゲットとなる LDP セッションが 1 つの場合、ターゲットとなる LDP セッションが選択されますが、ターゲットとなる LDP セッションに関連するインターフェィスがないため、対応するポイントツーマルチポイント FEC はMoFRR 機能を失います。

  • 同一のアップストリーム LSR に属するすべてのインターフェイスがプライマリ パスと見なされます。

  • ルートノードのルート更新では、IGP からの最新のネクスト ホップに基づいてアップストリーム パスが変更されます。より良いパスが利用可能な場合、マルチポイント LDP はより良いパスへの切り替えを試みます。

パケット転送

PIM またはマルチポイント LDP の場合、デバイスはマルチキャスト ソース ストリームの選択をイングレス インターフェィスで行います。これにより、ファブリック帯域幅を保持し、フォワーディングのパフォーマンスを最大化することができます。

  • ファブリック上での重複したストリームの送信を回避

  • マルチプル ルート ルック アップ(パケットロスの原因)を防ぎます。

PIM の場合、各 IP マルチキャスト ストリームには同じ宛先アドレスが含まれています。パケットがどのインターフェイスに到着しても、パケットは同じルートを通ることになります。デバイスは、各パケットが到着したインターフェイスを確認し、プライマリ・インターフェイスからのものだけを転送します。インターフェイスがバックアップ ストリームのインターフェイスと一致した場合、デバイスはそのパケットをドロップします。そのインターフェィスが、プライマリまたはバックアップのストリーム インターフェィスと一致しない場合、デバイスはそのパケットをコントロール プレーン内の例外として処理します。

図 13は、PIM を搭載したルーターのプライマリおよびバックアップ インターフェィスのサンプルを使って、このプロセスを示しています。 図 14では、PIM を搭載したスイッチでの同様の処理が示されています。

図 13: ルーターのパケット転送エンジンにおけるMoFRR IP ルート ルックアップルーターのパケット転送エンジンにおけるMoFRR IP ルート ルックアップ
図 14: スイッチのパケット転送エンジンにおけるMoFRR IP ルートの取り扱いについてスイッチのパケット転送エンジンにおけるMoFRR IP ルートの取り扱いについて

ルーター上のマルチポイント LDP を使用した MoFRR では、デバイスは複数の MPLS ラベルを使用して MoFRR のストリーム選択を制御します。各ラベルは別々のルートを表していますが、それぞれが同じインターフェィス リスト チェックを参照しています。デバイスは、プライマリ ラベルのみを転送し、その他のラベルはすべてドロップします。複数のインターフェィスが同じラベルを使ってパケットを受信できる。

図 15はマルチポイント LDP を搭載したルーターでのこのプロセスを示しています。

図 15: パケット転送エンジンにおける MoFRR MPLS ルート ルックアップパケット転送エンジンにおける MoFRR MPLS ルート ルックアップ

制限と注意事項

スイッチングおよびルーティング デバイスに関する MoFRR の制限と注意事項

MoFRR では、ルーティング デバイスやスイッチング デバイスについて、以下のような制限および注意点があります。

  • MoFRR の障害検出は、MoFRR が有効になっているルーティングデバイスの即時リンク プロテクションに対応しており、マルチキャスト トラフィック パスのすべてのリンク (end-to-end) には対応していません。

  • MoFRRは、ソースに向かって選択された 2 つのディスジョイント パスの高速再ルートをサポートします。選択された 2 つのアップストリーム ネイバーを、同じインターフェイス上に配置することはできません(つまり、LANセグメント上の2つのアップストリーム ネイバー)。アップストリームのインターフェイスがたまたまマルチキャスト トンネルのインターフェイスだった場合も同様です。

  • 最大エンド ツー エンドのディスジョイント アップストリーム パスの検出はサポートされていません。レシーバー(エグレス)のルーティング デバイスは、ディスジョイントのアップストリーム デバイス(直前のホップ)があるかどうかのみを確認します。PIM とマルチポイント LDP は、ERO(explicit route object)に相当するものをサポートしていません。そのため、ディスジョイント アップストリーム パスの検出は、直前のホップのデバイスに対する制御に限定されます。この制限のため、プライマリとバックアップに選択された前のホップのアップストリーム デバイスへのパスが共有される場合があります。

  • 以下のシナリオでは、トラフィックの損失が発生する可能性があります。

    • エグレス デバイスでより良いアップストリーム パスが利用可能になります。

    • MoFRRは、アクティブなトラフィック ストリームの流れの間、エグレス デバイスで有効化または無効化になります。

  • バックアップ パスのジョイン メッセージに対する PIM ジョイン ロード バランシングはサポートされていません。

  • マルチキャストグループGでは、(S,G) と (*,G) の両方のジョイン メッセージに対して MoFRR は許可されません。(S,G) ジョイン メッセージは、(*,G) に優先します。

  • MoFRR は、2 つの異なるマルチキャスト グループを使用するマルチキャスト トラフィック ストリームには対応していません。各 (S,G) の組み合わせは、ユニークなマルチキャスト・トラフィック・ストリームとして扱われます。

  • MoFRRでは、双方向の PIM 範囲には対応していません。

  • MoFRR では PIM dense-modeはサポートされていません。

  • バックアップ トラフィック ストリームのマルチキャスト統計は PIM では維持されないため、showコマンドの運用出力では利用できません。

  • レート監視はサポートされていません。

MoFRR による PIM 付きスイッチング デバイスの制限

PIMを用いた MoFRR では、スイッチング デバイスに以下のような制限があります。

  • アップストリームインターフェースがIRB(Integrated Routing and Bridging)インターフェィスの場合、MoFRRはサポートされません。この場合、IGMPv3(Internet Group Management Protocol version 3)スヌーピングなどの他のマルチキャスト機能に影響を与えます。

  • マルチキャスト トラフィックを転送する際のパケット レプリケーションやマルチキャストルックアップにより、パケットが PFE を何度も再循環することがあります。そのため、show pfe statistics traffic コマンドで表示されるマルチキャスト パケット数の値は、Input packetsOutput packets などの出力フィールドに予想以上の数値が表示される場合があります。MoFRR シナリオでは、プライマリとバックアップのストリームが重複すると、一般的にトラフィックフローが増加するため、このような動作が頻繁に発生することがあります。

マルチポイント LDP を搭載したルーティング デバイスでの MoFRR の制限と注意事項

MoFRRは、マルチポイント LDP と併用する場合、ルーターに以下のような制限や注意点があります。

  • RSVP トンネルはどのインターフェィスにも関連付けられていないため、RSVP トンネル上で受信したマルチポイント LDP トラフィックには MoFRR は適用されません。

  • Mixed upstream MoFRR はサポートされていません。これは PIM マルチポイント LDP の帯域内シグナリングのことで、アップストリーム側の 1 つ目のパスはマルチポイント LDP を経由し、2 つ目のアップストリーム側のパスは PIM を経由しています。

  • インナー ラベルとしてのマルチポイント LDP ラベルはサポートされていません。

  • ソースが複数のイングレス(ソース側)のPE(プロバイダ エッジ)ルーティング デバイスを介して到達可能な場合、マルチポイント LDP MoFRR はサポートされません。

  • ターゲットとなる LDP アップストリームセッションが、MoFRR のアップストリーム デバイスとして選択されません。

  • MoFRR インナー ラベルがサポートされていないため、バックアップ パスでのマルチポイント LDP リンク プロテクションはサポートされていません。

マルチキャストのみ高速再ルートの設定

マルチキャスト高速再ルート(MoFRR)を設定して、リンク障害が発生した場合のネットワークにおけるパケット ロスを最小限に抑えることができます。

ユニキャスト ストリームに高速再ルートを適用する場合、アップストリーム ルーターは、MPLS LSP(ラベル スイッチ パス)を事前に確立するか、LFA(IP ループフリーの代替ルート)の高速再ルート バックアップ パスを事前に計算し、ダウンストリーム パスのセグメントの障害に対処します。

マルチキャスト ルーティングでは、トラフィック分散グラフは通常、受信者によって発信されます。これは、通常、送信元から受信者へのパスを確立するユニキャスト ルーティングとは異なります。マルチキャスト配信グラフを確立できるプロトコルは、PIM(IP の場合)、マルチポイント LDP(MPLS の場合)、RSVP-TE(MPLS の場合)です。これらのうち、PIM とマルチポイント LDP 受信者が分散グラフ設定を開始するため、以下のようになります。

  • QFX シリーズでは、MoFRR が PIM ドメインでサポートされています。

  • MX シリーズおよび SRX シリーズでは、MoFRR が PIM およびマルチポイント LDP ドメインでサポートされています。

設定手順は、別途指示がない限り、この機能をサポートするすべてのデバイスで PIM の MoFRR を有効にする場合も同じです。マルチポイント LDP MoFRR に適用されていない設定手順も示しています。

(MX シリーズ ルーターのみ)MoFRR は、MPC ライン カードがある MX シリーズ ルーターでサポートされています。前提として、ルーター内のすべてのライン カードが MPC でなければなりません。

ルーターまたはスイッチで MoFRR を設定する方法:

  1. (MX シリーズおよび SRX シリーズ ルーターのみ)ルーターを拡張 IP モードに設定できます。
  2. MoFRRを有効にします。
  3. (オプション)MoFRR 設定に影響される制限されたマルチキャスト ストリームのセットをフィルターするルーティング ポリシーを設定します。

    送信元またはグループ アドレスに基づいてフィルタを適用できます。

    たとえば、以下のように表示されます。

  4. (オプション)MoFRR 設定に影響されるマルチキャスト グループのセットをフィルーするようにルーティング ポリシーを設定した場合、MoFRR ストリーム保護にポリシーを適用します。

    たとえば、以下のように表示されます。

  5. (オプション)MoFRR がある PIM ドメインで、MoFRR がASM(エニー ソース マルチキャスト)(*G)に適用できます。

    これは、マルチポイント LDP MoFRR ではサポートされていません。

  6. (オプション)MoFRR がある PIM ドメインで、不連続な RPF(個別のプレーン上の RPF)をバックアップ RPF パスとして選択できます。

    これは、マルチポイント LDP MoFRR ではサポートされていません。マルチポイント LDP MoFRR ドメインでは、同じアップストリーム ネイバーへのパラレル リンク間で共有されます。これは、各リンクがネイバーを形する PIM ドメインには当てはまりません。パスがプライマリ RPF パスと同じアップストリーム ネイバーに移動する場合、mofrr-disjoint-upstream-only ステートメントはバックアップ RPF パスが選択できません。これにより、MoFRR が、複数の RPF アップストリーム ネイバーを有するトポロジーでのみトリガーされます。

  7. (オプション)MoFRR がある PIM ドメインで、バックアップ パスでの参加メッセージの送信を防止しますが、その他の MoFRR 機能をすべて維持します。

    これは、マルチポイント LDP MoFRR ではサポートされていません。

  8. (オプション)MoFRR がある PIM ドメインでは、新しいプライマリ パス選択はソースへのユニキャスト ルートのためのユニキャスト ゲートウェイ選択に基づき、プライマリとしてバックアップ パスをプロモートするのではなく、ユニキャスト選択が変更されるタイミングを変更できます。これにより、プライマー RPF ホップが常に最適なパスにある状態を確保できます。

    mofrr-primary-selection-by-routing ステートメントを含める場合、バックアップ パスは、プライマリ パスがダウンした場合に新しいプライマリ パスとしてプロモートされる保証はありません。

    これは、マルチポイント LDP MoFRR ではサポートされていません。

例:マルチポイントLDPドメインにおけるマルチキャスト専用高速再ルートの設定

この例では、マルチキャスト専用高速再ルート(MoFRR)を設定し、リンク障害が発生した場合にネットワークのパケットロスを最小限に抑える方法を説明します。

マルチポイントLDP MoFRRは、パケットがIPネットワークに転送される場である、MPLSネットワークのエグレスノードで使用されます。マルチポイントLDP MoFRRの場合、アップストリームのPE(プロバイダエッジ)ルーターに向かう2つのパスが確立され、LER(ラベルエッジルーター)でMPLSパケットの2つのストリームを受信します。そのうちの1つのストリーム(プライマリ)が受け入れられ、もう1つ(バックアップ)はLERで破棄されます。プライマリパスに障害が生じた場合は、バックアップストリームが受け入れられます。

要件

この例を設定する前に、デバイス初期化以外の特別な設定を行う必要はありません。

マルチポイントLDPドメインで、MoFRRを機能させるには、MoFRRを有効にするエグレスPEルーターだけが必要です。他のルーターがMoFRRをサポートする必要はありません。

MoFRRは、MPCラインカードでMXシリーズプラットフォームでサポートされています。あらかじめ必要な条件として、ルーターはnetwork-services enhanced-ipモードに設定され、プラットフォームのすべてのラインカードはMPCである必要があります。

この例では、エグレスPEルーターにはJunos OSリリース14.1以降が必要です。

概要

この例では、デバイスR3がエグレスエッジ ルーターとなっています。MoFRRは、このデバイスのみで有効になっています。

接続にはOSPFが使用されていますが、IGP(内部ゲートウェイプロトコル)もしくは静的ルートも使用できます

テスト用に、送信元と受信先をシュミレーションするためにルーターが使われています。デバイスR4とデバイスR8は、set protocols igmp interface interface-name static group groupコマンドを使用して、必要なグループに静的に合流するように設定されています。実際のマルチキャスト受信ホストが利用できない場合、この例のように、この静的IGMP設定が使えます。受信側において、マルチキャストグループアドレスを受信するために、この例ではset protocols sap listen groupを使用しています。

MoFRR設定には、この例には表示されていないポリシーオプションがありますが、これは別途説明されています。オプションは以下のように設定されています。

トポロジー

図 16は、サンプルのネットワークを示しています。

図 16: マルチポイントLDPドメインのMoFRRマルチポイントLDPドメインのMoFRR

CLIクイックコンフィギュレーションは、図 16でのすべてのデバイスの設定を示しています。

セクション設定は、デバイス R3 の手順を説明します。

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

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

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

デバイスsrc1

デバイスsrc2

デバイス R1

デバイス R2

デバイス R3

デバイス R4

デバイス R5

デバイス R6

デバイス R7

デバイス R8

設定

手順

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

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

デバイス R3 を設定するには:

  1. 拡張IPモードを有効にします。

  2. デバイスインターフィスを設定します。

  3. 自律システム(AS)番号を設定します。

  4. ルーティングポリシーを設定します。

  5. PIMを設定します。

  6. LDP を設定します。

  7. IGPまたは静的ルートを設定します。

  8. 内部BGPを設定します。

  9. MPLSと、オプションでRSVPを設定します。

  10. MoFRRを有効にします。

結果

show policy-optionsコンフィギュレーション・モードから、 show chassisshow interfacesshow protocolsおよびとコマshow routing-optionsンドを入力して、コンフィギュレーションを確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。

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

検証

設定が正常に機能していることを確認します。

LDPポイントツーマルチポイント転送等価クラスの確認

目的

MoFRRが有効になっていることを確認し、どのラベルが使用されているかを判断します。

対処
意味

出力では、MoFRRが有効なことを示し、ラベル301568と301600が2つのマルチポイントLDPに使用されていることを表示しています。

ラベル情報の検証

目的

エグレスデバイスに、マルチキャストグループが参加できる2つのアップストリームインターフェイスが存在していることを確認します。

対処
意味

出力では、プライマリのアップストリームパスとバックアップのアップストリームパスを表示しています。また、RPFネクストホップも表示しています。

マルチキャストルートの確認

目的

IPマルチキャスト転送テーブルを検証し、プライマリおよびバックアップインターフェイスを含むアップストリームRPFインターフェイスリストが存在することを確認します。

対処
意味

出力では、プライマリおよびバックアップセッションとRPFネクストホップを表示しています。

LDPポイントツーマルチポイントのトラフィック統計の確認

目的

プライマリとバックアップ両方の統計が表示されていることを確認します。

対処
意味

出力では、ラベル付きのプライマリおよびバックアップルートを表示しています。

例:LDP ダウンストリームのオンデマンドでの設定

この例では、LDP ダウンストリームをオンデマンドで設定する方法を示しています。LDP は、一般的にダウンストリームの未承諾アドバタイズモードで設定されています。これは、すべてのルートのラベルアドバタイズは、すべての LDP ピアから受信されることを意味します。サービスプロバイダーが、アクセスネットワークとアグリゲーションネットワークを単一の MPLS ドメインに統合する際には、アクセスネットワークとアグリゲーションネットワーク間のバインディングを分散し、コントロールプレーンの処理要件を軽減するために、オンデマンドでの LDP ダウンストリームが必要となります。

ダウンストリームノードは、アップストリームのアグリゲーションノードから数万のラベルバインディングを受け取る可能性があります。ダウンストリームのアグリゲーションノードは、MPLS ネットワーク内のすべてのループバックアドレスに対するすべてのラベルバインディングを学習して保存する代わりに、オンデマンドでの LDP ダウンストリームを使用して、サービスが設定されているイグレスノードのループバックアドレスに対応する FEC のラベルバインディングのみを要求するように設定できます。

要件

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

  • M シリーズルーター

  • Junos OS 12.2

概要

[edit protocols ldp session] 階層レベルで、 オンデマンドでのダウンストリーム のステートメントを含めることで、LDP セッションの、オンデマンドでの LDP ダウンストリームのラベルアドバタイズメントを有効にできます。オンデマンドでダウンストリームを設定した場合、ジュニパーネットワークスルーターは、オンデマンドでのダウンストリームリクエストをピアルーターにアドバタイズします。2 つのルーター間で、オンデマンドでのダウンストリームセッションを確立するには、LDP セッション確立中に、双方がオンデマンドモードでのダウンストリームをアドバタイズする必要があります。一方のルーターが、ダウンストリームの未承諾モードをアドバタイズし、他方のルーターが、オンデマンドでのダウンストリームをアドバタイズすると場合、ダウンストリームの未承諾モードが使用されます。

設定

LDP ダウンストリームのオンデマンドでの設定

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

オンデマンドでの LDP ダウンストリームのポリシーを設定し、そのポリシーを設定して LDP セッションでオンデマンドでの LDP ダウンストリームを有効にするには。

  1. オンデマンドでのダウンストリーム ポリシー(この例では DOD リクエストループバック)を設定します。

    このポリシーでは、ルーターが、DOD リクエストループバックのポリシーに一致する FEC にのみ、ラベルリクエストメッセージを転送します。

  2. [edit protocols ldp] 階層レベルの dod-request-policy ステートメントを使用して DOD リクエストループバックのポリシーを指定します。

    dod-request-policy ステーポリシーで指定されたポリシーは、ラベル リクエストメッセージを送信するプレフィックスを特定するために使用されます。このポリシーは、エグレスポリシーやインポートポリシーと類似しています。inet.0 ルーティングテーブルからルートを処理する場合、(この例では)Junos OS ソフトウェアは、 DOD-Request-Loopbacks ポリシーに一致するルートを確認します。ルートがポリシーに一致しており、LDP セッションが DOD アドバタイズモードでネゴシエートされた場合、ラベル リクエストメッセージは、対応するダウンストリームの LDP セッションに送信されます。

  3. オンデマンド配信モードのダウンストリームを有効にするために、LDP セッションの設定にステートdownstream-on-demandメントを含めます。

ラベル付き BGP へオンデマンドルートでの LDP ダウンストリートを配信

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

オンデマンドルートでの LDP ダウンストリームをラベル付き BGP に配信するには、BGP エクスポートポリシーを使用します。

  1. redistribute_ldp この例では)LDP ルートポリシーを設定します。

  2. (この例では BGP グループ設定 ebgp-to-abr の一部として)LDP ルートポリシー redistribute_ldp を BGP 設定に含めます。

    BGP は、 redistribute_ldp のポリシーに基づく LDP ルートをリモート PE ルーターに転送します。

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

(オンデマンドでのダウンストリームではなく) ダウンストリームの未承諾モードで設定された他のルーターへのラベル伝送を制限するには、以下のポリシーを設定します。

  1. LDP からルートを受信するように dod-routesポリシー を設定します。

  2. ネイバー 1.1.1.12.2.2.2、 および 3.3.3.3にルートを転送しないように、 do-not-propagate-du-sessions ポリシーを設定します。

  3. filter-dod-on-du-sessions ポリシーを設定し、 dod-routes ポリシーで検査されたルートが do-not-propagate-du-sessions ポリシーで定義された隣接ルーターに転送されないようにします。

  4. BGP broup ebgp-to-abr のエクスポートポリシーとして filter-dod-routes-on-du-sesssion のポリシーを指定します。

結果

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

検証

ラベルアドバタイズモードの検証

目的

設定が正常に機能していることを確認します。

LDP セッションのラベルアドバタイズモードのステータスを検証するには、 show ldp session コマンドを使用します。

対処

show ldp sessionshow ldp session detail コマンドを発行します。

  • 以下の show ldp session コマンドのコマンド出力は、 Adv. Mode (ラベルアドバタイズモード) が DOD (オンデマンドセッションの LDP ダウンストリームが動作していることを意味する) であることを示しています。

  • 以下の show ldp session detail コマンドの出力では、 Local Label Advertisement mode がデフォルト値の Downstream unsolicited になっています(ローカルセッションでオンデマンドのダウンストリームが設定されていないことを意味します)。逆に、 Remote Label Advertisement modeNegotiated Label Advertisement mode は両方とも、 Downstream on demand がリモートセッションで設定されていることを示しています。

LDP ネイティブ IPv6 サポートの設定

LDP は、IPv6 のみのネットワーク、および RFC7552 で説明されている IPv6 または IPv4 デュアルスタックネットワークでサポートされます。アドレスファミリーを IPv4 の inet、IPv6 の inet6、またはその両方に設定し、トランスポートプリファレンスを IPv4 または IPv6 のいずれかに設定します。dual-transport ステートメントにより、Junos OS LDPは、IPv4とIPv4ネイバー、およびIPv6とIPv6ネイバーを介してシングルスタックLSRとしてTCP接続を確立できます。inet-lsr-id および inet6-lsr-id ID とは、IPv4 および IPv6 TCP トランスポートで LDP セッションを確立するために設定する必要がある 2 つの LSR ID です。これらの 2 つの ID はゼロ以外である必要があり、異なる値で設定してください。

IPv6をデュアルスタックとして設定する前に、ルーティングプロトコルとシグナリングプロトコルを設定してください。

LDPネイティブIPv6サポートを設定するには、次の手順に従います。

  1. 異なるアドレスファミリーに異なるラベルを使用するために、転送等価クラス (FEC) のディスアグリゲーションを有効にします。
  2. LDP アドレスファミリーを設定します。
  3. IPv4とIPv6の両方が有効になっている場合に、 transport-preference ステートメントを設定してTCP接続の優先トランスポートを選択します。デフォルトでは、IPv6 は LDP 接続を確立するための TCP トランスポートとして使用されます。
  4. (オプション) デュアルトランスポートを設定して、LDPがIPv4ネイバーとの個別のIPv4セッション、およびIPv6ネイバーとのIPv6セッションを確立できます。IPv4 の LSR ID に inet-lsr-id を、IPv6 の LSR ID に inet6-lsr-id を設定します。

    例えば、inet-lsr-idを10.255.0.1、inet6-lsr-idを 10.1.1.1と設定します。

例:LDP ネイティブ IPv6 サポートの設定

この例は、Junos OSラベル配布プロトコル(LDP)がIPv4とIPv4ネイバー、およびIPv6とIPv6ネイバーを介してシングルスタックLSRとしてTCP接続を確立できるようにする方法を示しています。これにより、IPv4信号化されたMPLSラベルスイッチパス(LSP)を使用してIPv4 MPLSコア上でIPv6のトンネリングを回避できます。

要件

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

  • 2つのMXシリーズルーター

  • すべてのデバイスでJunos OS Release 16.1以降が作動していること

IPv6をデュアルスタックとして設定する前に、ルーティングプロトコルとシグナリングプロトコルを設定してください。

概要

LDPは、IPv6のみのネットワーク、およびRFC 7552で説明されているIPv6またはIPv4デュアルスタックネットワークでサポートされます。IPv4の場合はinet、IPv6の場合はinet6とアドレスファミリーを設定します。デフォルトでは、IPv4とIPv6の両方が有効になっている場合、IPv6はピアとのLDPセッションのTCPトランスポートとして使用されます。デュアルトランスポートステートメントにより、Junos LDPは、IPv4とIPv4ネイバー、およびIPv6とIPv6ネイバーを介してシングルスタックLSRとしてTCP接続を確立できます。inet-lsr-idinet6-lsr-idは、IPv4およびIPv6 TCPトランスポートでLDPセッションを確立するために設定する必要がある2つのLSR IDです。これらの2つのIDはゼロ以外である必要があり、異なる値で設定してください。

トポロジー

図 17は、デバイスR1とデバイスR2でデュアルスタックとして設定したLDP IPv6を示しています。

図 17: LDP ネイティブ IPv6 サポートの例 LDP ネイティブ IPv6 サポートの例

設定

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

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

R1

R2

R1の設定

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

次の例では、設定階層内のさまざまなレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの「 Using the CLI Editor in Configuration Mode 」を参照してください。

Device R1 を設定するには:

  1. インターフェイスを設定します。

  2. デバイスにループバックアドレスを割り当てます。

  3. IS-IS インターフェイスを設定します。

  4. デバイスでLDPインターフェイスを使用するようMPLSを設定します。

  5. 異なるアドレスファミリーに異なるラベルを使用するために、転送等価クラス(FEC)のディスアグリゲーションを有効にします。

  6. LDP アドレスファミリーを設定します。

結果

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

transport-preferenceを設定して優先トランスポートを選択します。

CLIクイックコンフィギュレーション
ステップ・バイ・ステップの手順

IPv4とIPv6の両方が有効になっている場合に、transport-preferenceステートメントを設定してTCP接続の優先トランスポートを選択できます。デフォルトでは、IPv6はLDP接続を確立するためのTCPトランスポートとして使用されます。

  • (オプション)LDP接続のトランスポート優先度を設定します。

ステップ・バイ・ステップの手順
結果

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

IPv4ネイバーとのIPv4およびIPv6ネイバーとのIPv6の個別のセッションを確立するようにデュアルトランスポートを設定します。

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

dual-transportステートメントを設定して、LDPがIPv4ネイバーとの個別のIPv4セッション、およびIPv6ネイバーとのIPv6セッションを確立できるようにすることができます。これには、IPv4のLSR IDとしてinet-lsr-idを設定し、IPv6のLSR IDとしてinet6-lsr-id を設定する必要があります。

  • (オプション)デュアルトランスポートを設定して、LDPがIPv4とIPv4ネイバー、およびIPv6とIPv6ネイバーを介してシングルスタックLSRとしてTCP接続を確立できます。

結果

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

検証

設定が正常に機能していることを確認します。

mpls.0テーブル内のルートエントリーの検証
目的

mpls.0 ルートテーブル情報を表示します。

対処

デバイスR1で、運用モードからshow route table mpls.0コマンドを実行して、mpls.0ルートテーブル情報を表示します。

意味

出力は、mpls.0 ルートテーブル情報を示しています。

inet.3テーブル内のルートエントリーの検証
目的

inet.3 ルートテーブル情報を表示します。

対処

デバイスR1で、運用モードからshow route table inet.3コマンドを実行して、inet.3ルートテーブル情報を表示します。

意味

出力は、inet.3 ルートテーブル情報を示しています。

inet6.3テーブル内のルートエントリーの検証
目的

inet6.3 ルートテーブル情報を表示します。

対処

デバイスR1で、運用モードからshow route table inet6.3コマンドを実行して、inet6.3ルートテーブル情報を表示します。

意味

出力は、inet6.3 ルートテーブル情報を示しています。

LDP データベースの検証
目的

LDP データベース情報を表示します。

対処

デバイスR1で、運用モードからshow ldp databaseコマンドを実行して、LDPデータベース情報を表示します。

意味

出力は、LDP データベース内のエントリーを示しています。

LDP ネイバー情報の検証
目的

LDP ネイバー情報を表示します。

対処

デバイスR1で、運用モードからshow ldp neighborshow ldp neighbor extensiveコマンドを実行して、LDPネイバー情報を表示します。

意味

出力は、IPv4 と IPv6 アドレスのLDPネイバー情報を示しています。

LDP セッション情報の検証
目的

LDP セッション情報を表示します。

対処

デバイスR1で、運用モードからshow ldp sessionshow ldp session extensiveコマンドを実行して、LDPセッション情報を表示します。

意味

出力には、TCPトランスポートとしてIPv6を使用するLDPセッションの情報が表示されます。

検証

設定が正常に機能していることを確認します。

LDP ネイバー情報の検証
目的

LDP ネイバー情報を表示します。

対処

デバイスR1で、運用モードからshow ldp neighbor extensiveコマンドを実行して、LDPネイバー情報を表示します。

意味

出力は、IPv4 と IPv6 アドレスのLDPネイバー情報を示しています。

LDP セッション情報の検証
目的

LDP セッション情報を表示します。

対処

デバイスR1で、運用モードからshow ldp session extensiveコマンドを実行して、LDPセッション情報を表示します。

意味

出力には、TCPトランスポートとしてIPv6を使用するLDPセッションの情報が表示されます。

検証

設定が正常に機能していることを確認します。

LDP ネイバー情報の検証
目的

LDP ネイバー情報を表示します。

対処

デバイスR1で、運用モードからshow ldp neighbor extensiveコマンドを実行して、LDPネイバー情報を表示します。

意味

出力は、IPv4 と IPv6 アドレスのLDPネイバー情報を示しています。

LDP セッション情報の検証
目的

LDP セッション情報を表示します。

対処

デバイスR1で、運用モードからshow ldp session extensiveコマンドを実行して、LDPネイバー情報を表示します。

例:ポイントツーマルチポイント LSP 向けのマルチポイント LDP インバンド シグナリングの設定

ポイントツーマルチポイント LSP のマルチポイント LDP インバンド シグナリングについて

インバンド シグナリングを備えたポイントツーマルチポイント ラベルスイッチ パス(LSP)の M-LDP(Multipoint Label Distribution Protocol)は、IPTV などのマルチキャスト トラフィックを伝送する必要がある既存の IP/MPLS バックボーンを使用する導入で役立ちます。

何年もの間、マルチキャスト トラフィックの転送に最も広く使用されているソリューションは、マルチポイント IP トンネリングを使用してサービス プロバイダ コアでネイティブ IP マルチキャストを使用して、顧客のトラフィックを分離することでした。マルチキャスト ルーティング プロトコル(通常は PIM(プロトコル独立マルチキャスト)は、転送パスを設定するために導入されます。IP マルチキャスト ルーティングは、コアの PIM シグナリングを使用して転送に使用されます。このモデルを機能させるために、コア ネットワークはマルチキャストを有効にする必要があります。これにより、自律システム(AS)間のシナリオでも、効果的で安定した導入が可能になります。

ただし、既存の IP/MPLS ネットワークでは、PIM を導入することが第一の選択肢ではないかもしれません。一部のサービス プロバイダは、IP トンネリングを MPLS ラベル カプセル化に置き換えることに関心があります。MPLS ラベル スイッチングに移行する動機は、MPLS トラフィック エンジニアリングと保護機能を活用し、プロバイダ コアの制御トラフィックオーバーヘッドの量を減らすことです。

これを実現するために、サービス プロバイダは既存の導入の拡張を活用してマルチキャスト トラフィックの通過を許可することに関心を持っています。IP/MPLS の既存のマルチキャスト拡張機能は、RSVP-TE 用のポイントツーマルチポイント拡張、LDP のポイントツーマルチポイントおよびマルチポイント間の拡張です。これらの導入シナリオについては、RFC 6826、 Multipoint LDP In-Band Signaling for Point-to-Multipoint および Multipoint-to-Multipoint Label Switched Path で説明しています。この機能の概要は、LDP のポイントツーマルチポイント拡張に限定されています。

M-LDP の仕組み

M-LDP シグナリングのラベル バインディング

LDP へのマルチポイント拡張では、機能アドバタイズメント、ラベル マッピング、シグナリング手順とともに、ポイントツーマルチポイントおよびマルチポイントツーマルチポイント転送同等クラス(FEC)要素(RFC 5036、 LDP Specification で定義)を使用します。FEC 要素には、IP アドレスである LSP ルートの考え方と、同じ不透明な値を共有するリーフ ノードをグループ化するセレクターである「不透明」値が含まれます。不透明な値は中間ノードに対して透過的ですが、LSP ルートには意味があります。すべての LDP ノードは、FEC 内のルート IP アドレスへの最短パスで、アップストリーム LDP ノードへのローカル受信ラベル バインディングをアドバタイズします。ラベル バインディングを受け取るアップストリーム ノードは、独自のローカル ラベルと発信インターフェイスを作成します。このラベル割り当てプロセスでは、複数の発信ブランチがある場合、パケットレプリケーションが発生する可能性があります。に 図 18示すように、LDP ノードは、同じアップストリーム ノードを共有するダウンストリーム ノードが見つかると、同じ不透明な値のラベル バインディングをマージします。これにより、ポイントツーマルチポイント LSP の効果的な構築とラベルの保存が可能になります。

図 18: M-LDP シグナリングのラベル バインディングM-LDP シグナリングのラベル バインディング
PIM フリー MPLS コアの M-LDP

図 19 は、スケールダウンされた導入シナリオを示しています。2 つの独立した PIM ドメインが PIM フリー コア サイトによって相互接続されます。このコア サイトの境界ルーターは、境界インターフェイスで PIM をサポートしています。さらに、これらの境界ルーターは、隣接するサイトからコア ネットワークにルーティング情報を収集して配信します。サイト C のエッジ ルーターは、ルート ノード検出のために BGP を実行します。ほとんどの場合、IGP によって提供される転送ネクスト ホップはイングレス デバイスに関する情報を送信元に提供しないため、IGP(内部ゲートウェイ プロトコル)ルートをイングレス検出に使用できません。M-LDP インバンド シグナリングには、ポイントツーマルチポイント LSP と(S、G)フローの間に 1 対 1 のマッピングがあります。帯域内シグナリングでは、PIM メッセージは M-LDP FEC バインディングに直接変換されます。対照的に、アウトオブバンド シグナリングは手動設定に基づいています。M-LDP インバンド シグナリングの 1 つのアプリケーションは、MPLS バックボーンで IPTV マルチキャスト トラフィックを伝送することです。

図 19: PIM フリー MPLS コアの M-LDP トポロジーの例PIM フリー MPLS コアの M-LDP トポロジーの例
設定

ラベル エッジ ルーター(LER)の 設定ステートメント mldp-inband-signalling により、LER が PIM アップストリーム ネイバーを検出しない場合、PIM はアップストリーム ネイバーに M-LDP インバンド シグナリングを使用できます。ポリシーを使用して、MPLS LSP ルートの静的設定が PIM 設定に含まれます。これは、IBGP がコア サイトで使用できない場合、または IBGP ベースの LSP ルート検出をオーバーライドする場合に必要です。

例えば、

PIM 対応 MPLS コアの M-LDP

Junos OS リリース 14.1 以降では、既存の IPTV サービスをネイティブ IP マルチキャストから MPLS マルチキャストに移行するには、最小限の停止で PIM から M-LDP のポイントツーマルチポイント LSP にスムーズに移行する必要があります。 図 20 は 、と同様の M-LDP トポロジ 図 19を示していますが、シナリオは異なります。コアは PIM で有効になっており、1 つのソースですべての IPTV チャネルをストリーミングします。TV チャネルは ASM ストリームとして送信され、各チャネルはグループ アドレスによって識別されます。以前は、これらのチャネルはコア上で IP ストリームとしてストリーミングされ、PIM を使用してシグナリングされていました。

図 20: PIM 対応 MPLS コアの M-LDP トポロジーの例PIM 対応 MPLS コアの M-LDP トポロジーの例

このシナリオで設定 mldp-inband-signaling すると、M-LDP シグナリングは、送信元に PIM ネイバーがない場合にのみ開始されます。ただし、エグレス PE のアップストリーム インターフェイスで PIM が非アクティブ化されていない限り、ソースに向かう PIM ネイバーが常に存在するため、PIM は M-LDP よりも優先され、M-LDP は有効ではありません。

設定

チャネルごとに徐々にチャネルを M-LDP MPLS コアに段階的に移行し、既存の PIM アップストリームを使用する M-LDP アップストリームやその他のストリームを使用したストリームが少ない場合は、設定ステートメントと、M-LDP インバンド シグナリングのポリシー フィルタにグループ ベースのフィルタを含めます selected-mldp-egress

注:

M-LDP インバンド シグナリング ポリシー フィルターには、ステートメントまたはステートメント、 source-address-filter または route-filter 両方の組み合わせを含めることができます。

例えば、

注:

上記の設定の制限事項は次のとおりです。

  • ステートメントは selected-mldp-egress LER でのみ設定する必要があります。selected-mldp-egress非エグレス PIM ルーターでステートメントを設定すると、パス設定エラーが発生する可能性があります。

  • PIM アップストリームから M-LDP アップストリームにトラフィックを切り替えるポリシー変更が行われると、コントロール プレーンでブレークアンドメーキング メカニズムが実行されると、パケット ロスが発生する可能性があります。

用語

マルチキャスト トラフィックの M-LDP インバンド シグナリングを理解するうえで、次の用語が重要です。

ポイントツーポイント LSP

1 つのイングレス ラベルスイッチ ルーター(LSR)と 1 つのエグレス LSR を持つ LSP。

マルチポイント LSP

ポイントツーマルチポイントまたはマルチポイントツーマルチポイント LSP のいずれか。

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

1 つのイングレス LSR と 1 つ以上のエグレス LSR を持つ LSP。

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

1 つ以上のイングレス LSR と 1 つの固有のエグレス LSR を持つ LSP。

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

LSP 内の任意のノードによって送信されたトラフィックが他のすべてのノードに配信されるなど、ノードのセットを接続する LSP。

イングレス LSR

特定の LSP のイングレス LSR は、LSP に沿ってデータ パケットを送信できる LSR です。マルチポイントツーマルチポイント LSP には、複数のイングレス LSR を使用できます。ポイントツーマルチポイント LSP は 1 つだけで、そのノードはルート ノードと呼ばれることがよくあります。

エグレス LSR

特定の LSP のエグレス LSR は、その LSP からデータ パケットを削除してさらに処理できる LSR です。ポイントツーポイント LSP とマルチポイントツーポイント LSP のエグレス ノードは 1 つだけです。ポイントツーマルチポイント LSP とマルチポイントツーマルチポイント LSP には、複数のエグレス ノードを使用できます。

トランジット LSR

直接接続されたアップストリーム LSR と、1 つ以上の直接接続されたダウンストリーム LSR を介して、マルチポイント LSP のルートに到達可能な LSR。

Bud LSR

エグレスでありながら、1 つ以上の直接接続されたダウンストリーム LSR を持つ LSR。

リーフ ノード

ポイントツーマルチポイント LSP のコンテキストでのエグレス LSR または bud LSR のいずれか。マルチポイントツーマルチポイント LSP の場合、LSR は同じマルチポイントツーマルチポイント LSP のイングレスとエグレスの両方であり、また、つぼみ LSR にもなります。

イングレス結合変換および擬似インターフェイス処理

イングレス LER では、LDP はインバンド シグナリングを介して受信した(S、G)メッセージについて PIM に通知します。PIM は、各メッセージ(S、G)を擬似インターフェイスに関連付けます。その後、ソースに対して最短パス ツリー(SPT)結合メッセージが開始されます。PIM はこれを新しいタイプのローカル レシーバとして扱います。LSP がダウンすると、PIM は LDP からの通知に基づいてこのローカル レシーバを削除します。

イングレス スプライシング

LDP は、各(S、G)エントリーに関連付けられるネクスト ホップを PIM に提供します。PIM は、LDP のネクスト ホップおよびその他の PIM レシーバーを使用して PIM(S、G)マルチキャスト ルートをインストールします。ネクスト ホップは、ローカル レシーバの複合ネクスト ホップ + PIM ダウンストリーム ネイバーのリスト + LDP トンネルのサブレベルのネクスト ホップです。

リバース パス転送

PIM の RPF(リバース パスフォワーディング)計算はエグレス ノードで実行されます。

PIM は、以下のすべての条件に該当する場合、M-LDP インバンド シグナリングを実行します。

  • ソースに向かうPIMネイバーはありません。

  • M-LDP 帯域内シグナリング ステートメントが設定されています。

  • ネクスト ホップは BGP を介して学習されるか、静的マッピングに存在します(M-LDP 帯域内シグナリング ポリシーで指定)。

それ以外の場合、LSP ルート検出に失敗した場合、PIM は未解決の RPF 状態で(S、G)エントリーを保持します。

PIM RPF は、ユニキャスト ルーティング情報が変更されるたびに、この送信元アドレスを登録します。したがって、ソースへのルートが変更された場合、RPF 再計算が繰り返されます。送信元への BGP プロトコルのネクスト ホップも、LSP ルートの変更を監視します。このような変更により、短期間でトラフィックが中断される可能性があります。

LSP ルート検出

RPF 動作がアップストリームの M-LDP インバンド シグナリングの必要性を検出すると、LSP ルート(イングレス)が検出されます。このルートは、LDP LSP シグナリングのパラメータです。

ルート ノードは次のように検出されます。

  1. 既存の静的設定で送信元アドレスが指定されている場合、ルートは設定で指定されたとおりに取得されます。

  2. ユニキャスト ルーティング テーブルでルックアップが実行されます。送信元アドレスが見つかった場合、送信元へのプロトコルのネクスト ホップが LSP ルートとして使用されます。

    Junos OS リリース 16.1 より前の場合、M-LDP ポイントツーマルチポイント LSP は、イングレス LSR のルート アドレスを使用してエグレスからイングレスへの信号を受信します。このルート アドレスは IGP のみを介して到達可能であるため、M-LDP ポイントツーマルチポイント LSP は単一の自律システムに限定されます。ルート アドレスが IGP を介して到達できないが、BGP を介して到達可能であり、その BGP ルートが MPLS LSP を介して再帰的に解決される場合、ポイントツーマルチポイント LSP は、そのポイントからイングレス LSR ルート アドレスに向かってさらに信号を発しません。

    以下のアプリケーションで使用できる、セグメント化されていないポイントツーマルチポイント LSP を複数の自律システム間でシグナリングする必要があります。

    • セグメント化されていないポイントツーマルチポイントLSPを備えたAS間MVPN。

    • MPLSコアネットワークで接続されたクライアントネットワーク間のAS間M-LDPインバンドシグナリング。

    • セグメント化されていないポイントツーマルチポイント LSP(シームレスな MPLS マルチキャスト)によるエリア間 MVPN または M-LDP インバンド シグナリング。

    Junos OSリリース16.1以降、M-LDPは、ルートアドレスがMPLS LSPを介してさらに再帰的に解決されるBGPルートである場合、ASBRまたはトランジットまたはエグレスでポイントツーマルチポイントLSPに信号を送ることができます。

エグレスジョイン変換と擬似インターフェイス処理

エグレス LER で、PIM は LSP ルートとともに信号が送信される(S、G)メッセージを LDP に通知します。PIM は、この(S、G)メッセージのアップストリーム インターフェイスとして擬似インターフェイスを作成します。(S,G) プルーニング メッセージを受信すると、この関連付けが削除されます。

エグレス スプライシング

ダウンストリーム サイトからの(S、G)ジョイン メッセージが受信されるコア ネットワークのエグレス ノードでは、この結合メッセージは M-LDP 帯域シグナリング パラメータに変換され、LDP に通知されます。さらに、LSP のティアダウンは、(S、G)エントリーが失われた場合、LSP ルートが変更されたとき、または(S,G)エントリーが PIM ネイバーを介して到達可能な場合に発生します。

サポートされる機能

M-LDP 帯域内シグナリングの場合、Junos OS は次の機能をサポートします。

  • LDP ルートを使用した PIM ネクスト ホップのエグレス スプライシング

  • LDP ネクスト ホップを使用した PIM ルートのイングレス スプライシング

  • PIM ジョイン メッセージを LDP ポイントツーマルチポイント LSP セットアップ パラメータに変換

  • PIM ジョイン メッセージを設定するための M-LDP インバンド LSP パラメータの変換

  • 静的に設定され、BGP プロトコルのネクスト ホップベース LSP ルート検出

  • PIM ソース固有のマルチキャスト(SSM)および ASM(anysource multicsast)範囲における PIM(S、G)の状態

  • イングレス LER とエグレス LER の設定ステートメントを使用して、エッジ ルーターとして機能できるようにします。

  • LER の IGMP ジョイン メッセージ

  • IPv6 の送信元およびグループ アドレスを、IPv4 ルート ノードに不透明な情報として伝送する

  • IPv6(S、G)を IPv4 ルート アドレスにマッピングする静的構成

サポートされていない機能

M-LDP インバンド シグナリングの場合、Junos OS は次の機能をサポート していません

  • PIM ASMのフルサポート

  • mpls lsp point-to-multipoint ping(S,G) オプションを使用したコマンド

  • ノンストップ アクティブ ルーティング (NSR)

  • PIM の MBB(Make-before-Break)

  • IPv6 LSP ルート アドレス(LDP は IPv6 LSP をサポートしていません)。

  • 直接接続されていない PIM スピーカー間のネイバー関係

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

  • PIM デンス モード

  • PIM 双方向モード

LDP 機能

PIM(S、G)情報は、M-LDP 不透明型長値(TLV)エンコーディングとして送信されます。ポイントツーマルチポイント FEC 要素は、ルート ノード アドレスで構成されます。次世代マルチキャスト VPN(NGEN MVPN)の場合、ポイントツーマルチポイント LSP はルート ノード アドレスと LSP ID によって識別されます。

エグレス LER 機能

エグレス LER では、PIM は次の情報を使用して LDP をトリガーして、ポイントツーマルチポイント LSP を作成します。

  • ルート ノード

  • (S、G)

  • ネクスト ホップ

PIM は、マルチキャスト ツリーのソースに基づいてルート ノードを検索します。この(S、G)エントリーにルート アドレスが設定されている場合、設定されたアドレスはポイントツーマルチポイント LSP ルートとして使用されます。それ以外の場合、ルーティング テーブルを使用してソースへのルートを検索します。マルチキャスト ツリーのソースへのルートが BGP 学習ルートの場合、PIM は BGP ネクスト ホップ アドレスを取得し、それをポイントツーマルチポイント LSP のルート ノードとして使用します。

LDP は、ルート ノードに基づいてアップストリーム ノードを検索し、ラベルを割り当て、アップストリーム ノードにラベル マッピングを送信します。LDP は、帯域内 M-LDP シグナリングに究極のホップ ポッピング(PHP)を使用しません。

マルチキャスト ツリーのソースのルート アドレスが変更された場合、PIM はポイントツーマルチポイント LSP を削除し、LDP をトリガーして新しいポイントツーマルチポイント LSP を作成します。これが発生すると、発信インターフェイス リストが NULL になり、PIM は LDP をトリガーしてポイントツーマルチポイント LSP を削除し、LDP はアップストリーム ノードにラベルの撤回メッセージを送信します。

トランジット LSR 機能

トランジット LSR は、ポイントツーマルチポイント FEC の送信元に向けてアップストリーム LSR にラベルをアドバタイズし、パケットを転送するために必要な転送状態をインストールします。トランジット LSR は、任意の M-LDP 対応ルーターにできます。

イングレス LER 機能

イングレス LER では、ラベル マッピングを受信すると、LDP は PIM に次の情報を提供します。

  • (S、G)

  • フラッドネクストホップ

次に、PIM は転送状態をインストールします。新しい支社/拠点を追加または削除すると、フラッドのネクスト ホップがそれに応じて更新されます。ラベルが取り消されたためにすべての支社/拠点が削除された場合、LDP は更新された情報を PIM に送信します。アップストリームネイバーとダウンストリームネイバーの間に複数のリンクがある場合、ポイントツーマルチポイント LSP は負荷分散されません。

例:ポイントツーマルチポイント LSP のマルチポイント LDP インバンド シグナリングの設定

この例では、マルチキャスト トラフィックに対してマルチポイント LDP(M-LDP)インバンド シグナリングを設定する方法、PIM(プロトコル独立マルチキャスト)プロトコルの拡張として、または PIM の代わりとして設定する方法を示しています。

要件

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

  • Junos OS リリース 13.2 以降

  • MX シリーズ 5G ユニバーサル ルーティング プラットフォームまたは M シリーズ PE(プロバイダ エッジ)ルーター用マルチサービス エッジ ルーター

  • トランジット ラベルスイッチ ルーターとして機能する PTX シリーズ パケット トランスポート ルーター

  • コア ルーター用 T シリーズ コア ルーター

注:

PE ルーターは T シリーズ コア ルーターでも可能ですが、これは一般的ではありません。拡張要件によっては、コア ルーターが MX シリーズ 5G ユニバーサル ルーティング プラットフォームまたは M シリーズ マルチサービス エッジ ルーターである場合もあります。カスタマーエッジ(CE)デバイスは、ジュニパーネットワークスまたはその他のベンダーのルーターまたはスイッチです。

この例を設定する前に、デバイス初期化以外の特別な設定は必要ありません。

概要

CLI クイック設定 でのすべてのデバイス 図 21の設定を示しています。このセクション #d158e60__d158e616 では、デバイスエグレスPEの手順について説明します。

図 21: ポイントツーマルチポイント LSP の M-LDP インバンド シグナリングトポロジの例ポイントツーマルチポイント LSP の M-LDP インバンド シグナリングトポロジの例

設定

手順
CLI クイック設定

この例を迅速に設定するには、次のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致するために必要な詳細情報を変更してから、コマンドを階層レベルで [edit] CLI にコピーアンドペーストします。

デバイス src1

デバイスイングレスPE

デバイスエグレスPE

デバイス p6

デバイス pr3

デバイス pr4

デバイス pr5

手順

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

デバイスエグレスPEを設定するには、次の手順に従います。

  1. インターフェイスを設定します。

    コア側のインターフェイスで MPLS を有効にします。エグレスのネクスト ホップでは、MPLS を有効にする必要はありません。

  2. エグレス インターフェイスで IGMP を設定します。

    テストの目的で、この例には静的グループとソース アドレスが含まれています。

  3. コア側インターフェイスで MPLS を設定します。

  4. BGP を設定します。

    BGPはポリシー駆動型プロトコルであるため、必要なルーティングポリシーを設定して適用します。

    たとえば、スタティック ルートを BGP にエクスポートできます。

  5. (オプション)デバイス pr5 との MSDP ピア接続を設定して、異なる PIM ドメインを相互接続し、冗長な RP を有効にします。

  6. OSPF を設定します。

  7. コア側インターフェイスとループバック インターフェイスで LDP を設定します。

  8. ポイントツーマルチポイント MPLS LSP を有効にします。

  9. ダウンストリーム インターフェイスで PIM を設定します。

  10. このデバイスは PIM ランデブー ポイント(RP)として機能するため、RP 設定を行います。

  11. M-LDP インバンド シグナリングを有効にし、関連するポリシーを設定します。

  12. ポイントツーマルチポイント LSP と関連する送信元アドレスのルート アドレスを指定するルーティング ポリシーを設定します。

  13. 自律システム(AS)IDを設定します。

結果

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

デバイスエグレスPE

同様に、他のエグレス デバイスも設定します。

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

検証

設定が正しく機能していることを確認します。

PIM 結合状態の確認
目的

PIM 結合状態に関する情報を表示して、M-LDP のインバンド アップストリームとダウンストリームの詳細を検証します。イングレス デバイスでは、コマンドが show pim join extensive ダウンストリーム インターフェイスに表示されます Pseudo-MLDP 。エグレスでは、 show pim join extensive アップストリーム インターフェイスの Pseudo-MLDP コマンドが表示されます。

対処

動作モードから、コマンドを show pim join extensive 入力します。

PIM ソースの確認
目的

PIM ソースに、想定される M-LDP のアップストリームとダウンストリームの詳細があることを確認します。

対処

動作モードから、コマンドを show pim source 入力します。

LDP データベースの確認
目的

コマンドに show ldp database 、予想される root-to-(S,G)バインディングが表示されていることを確認します。

対処
MPLS ラベルのルート情報を調べること
目的

ポイントツーマルチポイント FEC 情報を表示します。

対処
LDP トラフィック統計情報の確認
目的

ポイントツーマルチポイント LSP のデータ トラフィック統計情報を監視します。

対処

セグメント ルーティングの相互運用性のための LDP マッピング サーバーの概要

セグメント ルーティングを徐々に導入する LDP ネットワークでは、LDP のみまたはセグメント ルーティングのみをサポートするデバイスの島がある可能性があります。デバイスを相互運用するためには、セグメント ルーティング ネットワーク内の任意のデバイスにLDPマッピング サーバー機能を設定する必要があります。

OSPF または ISIS を使用して、LDP マッピング サーバー機能が実装されます。

OSPF を使用した LDP とのセグメント ルーティングの相互運用性

OSPF を用いた LDP によるセグメント ルーティングの相互運用を実装するために、LDP のすべてのプレフィックスに対して Range TLV (type, length, and value) を持つ拡張プレフィックス LSA(リンク状態アドバタイズ)を生成し、 inet.3 および mpls.0 ルーティング テーブルに、プレフィックスに対応するマッピング ルートをインストールします。

図 22 は、OSPFを使用した LDP デバイスとセグメント ルーティング デバイスの相互運用性を示すために使用されるシンプルな LDP ネットワーク トポロジーです。トポロジーには、LDP ツーセグメント ルーティング移行がある 6 つのデバイス(デバイス R1、R2、R3、R4、R5、および R6)があります。

図 22: OSPF を使用した LDP とのセグメント ルーティングの相互運用性によるサンプル LDP トポロジーOSPF を使用した LDP とのセグメント ルーティングの相互運用性によるサンプル LDP トポロジー

上記のトポロジーでは、デバイス R1、R2、および R3 はセグメント ルーティングにのみ対応しており、デバイス R5 および R6 は LDPにのみ対応しており、デバイス R4 は LDP とセグメント ルーティングの両方に対応しています。ここでは、デバイス R1 は、相互運用性の問題により、デバイス R6 と相互運用できません。

LDP 対応デバイスとセグメント ルーティング デバイスの相互運用を可能にするため、セグメント ルーティングのネットワーク セグメント内のデバイスのいずれか 1 つのインターフェースが LDP マッピング サーバーとして構成されます。現在、マッピング サーバーは、[edit routing-options source-packet-routing] 階層レベルでプレフィックスを設定します。この機能を使用すると、LDP マッピング サーバーの構成は [edit protocols ospf]階層レベルで適用され、すべての LDP プレフィックスに対して範囲が TLV の新しい拡張プレフィックス LSA が OSPF によってアドバタイズされます。セグメント ルーティングが可能なデバイスは、拡張プレフィックス範囲 TLV を解析し、プレフィックスに対応するマッピング ルートを inet.3 および mpls.0 ルーティング テーブルにインストールします。

例えば、図 22 では、デバイス R2(セグメント ルーティング ネットワーク内)が LDP マッピング サーバーである場合、以下の構成が含まれています。

注:

start-prefix として使用される IP アドレスは、LDP ネットワーク内のデバイスのループバック アドレスです(この例では、デバイス R5)。

デバイス R2 で LDP マッピング サーバー設定がコミットされた場合、拡張プレフィックス範囲 TLV が OSPF エリア全体でフラッドされます。セグメント ルーティングが可能なデバイス(デバイス R1、R2、および R3)は、セグメント ID(SID)の指定されたループバック アドレスの OSPF セグメント ルーティングをインストールします。SID インデックスは、セグセグメント ルーティング デバイスによって mpls. ルーティング テーブルで更新されます。

Junos OS リリース 19.1R1 以降、セグメント ルーティング-LDP ボーディング ルーターは、セグメント ルーティング トラフィックとLDP ネクスト ホップ間のステッチが可能です。

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF

  • プレフィックス競合は、ソース構成でのみ検出されます。プレフィックス範囲の競合がある場合、下位ルーター ID からのプレフィックス SID が優先されます。この場合、システム ログ エラー メッセージ—RPD_OSPF_PFX_SID_RANGE_CONFLICT—が生成されます。

  • IPv6 プレフィックスはサポートされていません。

  • 自律システム(AS)のセグメントルーティングマッピングサーバーによって生成されたOSPF拡張プレフィックスOpaque LSAのフラッディングは、サポートされていません。

  • エリア間 LDP マッピング サーバー機能はサポートされていません。

  • 拡張 プレフィックス Opaque LSA の ABR 機能はサポートされていません。

  • 拡張プレフィックス Opaque LSA の ASBR 機能はサポートされていません。

  • セグメント ルーティング マッピング サーバー優先度 TLV はサポートされていません。

ISIS を使用して LDP とのセグメント ルーティングの相互運用性

ISIS を使って LDP とセグメント ルーティングの相互運用性を実装するには、それぞれ、プロトコル ISIS と LDP でサーバー クライアント構成が必要であり、セグメント ルーティング LSP と LDP LSP 間のステッチングに inet.3 または inet.0 ルーティング テーブルからのルートを使用します。

図 23 は、LDP マッピング サーバークライアント機能を使用した LDP デバイスとセグメント ルーティング デバイスの相互運用性を示すために使用されるシンプルな LDP ネットワーク トポロジーです。このトポロジーには、4 つのプロバイダー エッジ(PE)デバイス(デバイス PE1、PE2、PE3、および PE4)と、4 つのプロバイダー(P)デバイス(デバイス P5、P6、P7、および P8)があります。

図 23: ISIS を使用した LDP とのセグメント ルーティングの相互運用性によるサンプル LDP トポロジーISIS を使用した LDP とのセグメント ルーティングの相互運用性によるサンプル LDP トポロジー

デバイス PE3、PE4、P6、P7、 および P8 は LDP 対応デバイスです。デバイス PE1、PE2、P5、および P6は、セグメント ルーティング グローバル ブロック(SRGB)値が100と200、ノードセグメント ID(SID)の値がそれぞれ 101、102、105、106 のセグメント ルーティングを実行できます。

連続した MPLS トンネルを使用してデバイス PE3 とデバイス PE1 の間でサービス フローをトンネリングするには、セグメント ルーティングと LDP をサポートするデバイスの島が相互運用されている必要があります。

LDP Mapping Client Functionality (LDP to Segment Routing)

LDP クライアント機能は、図 23 の右から左へのトラフィック フローである LDP からセグメントへのルーティング マッピングです。デバイス P6 では、左側のセグメント ルーティング ネットワークからすべてのノード SID とプレフィックス SID をアドバタイズするように LDP エグレス ポリシーが設定されています。その結果 LDP は、デバイス P6 では、デバイス PE1、PE2、および P5 をデバイス P7 へのエグレス FEC ラベル バインディングとしてアドバタイズします。

デバイス PE3 は、プロトコル ネクスト ホップとしてデバイス PE1 とのサービス ルートを学習しました。デバイス PE3 には、PE1 FEC 向けの P8 ネクスト ホップからの LDP ラベル バインディングがあります。その結果、デバイス PE3 は、従来の LDP の動作に従って、そのサービス パケットをデバイス P8 に送信します。デバイス P8 には、PE1 FEC 向けの P7 ネクストホップからの LDP ラベル バインディングがあるため、デバイス P8 は従来の LDP の動作に従ってデバイス P7 に転送します。

デバイス P7 には、PE1 FEC の P6 ネクスト ホップから LDP ラベル バインディングがあり、その結果、デバイス P7 は従来の LDP の動作に従ってデバイス P6 に転送します。

PE1 FEC の LDP イグレスとして動作するデバイス P6 は、PE1 FEC の受信エグレス LDP ラベルを、同等のセグメント ルーティング ノード SID(この例では 101)とスワップして、デバイス P5 へトラフィックを転送します。

デバイス P5 は、デバイス PE1 が最後から 2 番目のポップ フラグが設定されたノード セグメント 101 をアドバタイズしたと仮定して 101 SIDをポップし、デバイス PE1 へトラフィックを転送します。デバイス PE1 は、トンネリングされたパケットを受信し、サービス ラベルを処理します。

その結果、エンドツーエンド MPLS トンネルは、デバイス PE3 からデバイス P6 までの LDP LSP と、デバイス P6 からデバイス PE1 までの関連ノード セグメントから構築されます。

LDP Mapping Server Functionality (Segment Routing to LDP)

LDP サーバーの機能は、図 23 における左から右へのトラフィック フローである LDP へのセグメント ルーティングのマッピングです。デバイス P6 では、マッピング サーバー プレフィックス構成が、[edit routing-options source-packet-routing] 階層レベルに含まれています。特定の IGP の下で設定を適用すると、LDP ネットワークからのすべての LDP FEC ラベル バインディングのタイプ、長さ、値 (TLV) が inet.3 LDP ルートとしてアドバタイズされます。

ここで、デバイス P6 は SRMS(セグメント ルーティング マッピング サーバ)として動作し、以下のマッピングをアドバタイズします - (P7, 107)、(P8, 108)、(PE3, 103)、(PE4, 104)、(P7, 107)。デバイス PE3 でセグメント ルーティングがサポートされている場合、ノード SID 103 がデバイス PE3 に設定されている。デバイス PE3 はセグメント ルーティングをサポートしていないため、ポリシーはデバイス P6 の SRMS で設定され、デバイス P6 はマッピングのアドバタイズを行います。

これらのマッピング サーバー アドバタイズを理解するのは、セグメント ルーティング デバイスのみです。セグメント ルーティング デバイスは、ノード自体がノード セグメントをアドバタイズしたのと全く同じ方法で、MPLS データ プレーンに関連するノード SID をインストールします。例えば、デバイス PE1 は、デバイス PE3 が SID 103 をアドバタイズしたかのように、P5 ネクスト ホップでノード SID 103 をインストールします。

デバイス PE1 には、そのプロトコル ネクスト ホップとして PE3 があるサービス ルートがあります。デバイス PE1 には、IGP ルート用のノード セグメントがあります。それは、P5 ネクスト ホップのある 103 です。その結果、デバイス PE1 は、サービス ラベルである下のラベルと、SID 103 である上のラベルの 2 つのラベルを持つサービス パケットをデバイス P5 へ送信します。デバイス P5 は、103 を 103 にスワップし、デバイス P6 に転送します。デバイス P6 のネクスト ホップは、セグメント ルーティングを実行できない IGP ルート PE3 です。(デバイス P7 はセグメント ルーティング機能っをアドバタイズしません)。ただし、デバイス P6 には、同じ FEC(LDP ラベル 1037 など)に対してそのネクスト ホップからの LDP ラベル バインディングがあります。その結果、で愛す P6 えは、IGP は 103 を 1037 にスワップし、デバイス P7 に転送します。

デバイス P7 は、このラベルをデバイス P8 から受信した LDP ラベルとスワップし、その後、デバイス P8 に転送します。LDP ラベルは、デバイス P8 によってポップされ、デバイス PE3 に転送されます。

デバイス PE3 は、トンネリングされたパケットを受信し、サービス ラベルを処理します。エンドツーエンド MPLS トンネルは、デバイス PE1 ~ P6 からセグメント ルーティング ノード、およびデバイス P6 ~ PE3 からの LDP LSP から構築されます。

Segment Routing to LDP Stitching

IGP セグメント ルーティング LSP の IP ネクスト ホップがセグメント ルーティングをサポートしていない場合、IGP は inet.3 ルーティング テーブルを参照し、同じプレフィックスへの LDP LSP があるかどうかを確認します。LDP LSP が存在する場合、IGP は、セグメント ルーティング ラベルと LDP ラベルをスワップする MPLS トランジット ルートをプログラミングして、セグメント ルーティング LSP を LDP LSP にステッチし、セグメント ルーティング ドメインから LDP ドメインへトラフィックを切り替えます。

図 24 は、相互運用性を実現するためのセグメント ルーティングと LDP LSP のステッチを示しています。

図 24: ルーティングと LDP LSP のステッチルーティングと LDP LSP のステッチ

トポロジーでは、デバイス PE3 は LDP 対応であり、セグメント ルーティングをサポートしています。セグメント ルーティング ドメイン内のマッピング サーバーは、デバイス P7、P8、および PE4 に対してラベル バインディング TLV をアドバタイズできます。このシナリオでは、デバイス PE1 は、プレフィックス SID とリモート ラベル バインディング TLV と SID の両方を持ち、デバイス PE4 に到達できます。しかし、デバイス PE1 は、デバイス PE4 へのイングレス セグメント ルーティング ルートをプログラムする際に、リモート ラベル バインディング TLV よりもプレフィックス SID を優先します。その結果、デバイス PE1 はデバイス PE4 にトラフィックを送信するためにセグメント ルーティング LSP をエンドツーエンドで使用し、デバイス PE3 にトラフィックを送信する際にセグメント ルーティングから LDP へのステッチを使用します。

Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS

  • ラベル バインディング TLV に対する最終ホップ ポッピング動作はサポートされていません。

  • ラベル バインディング TLV の範囲のアドバタイズはサポートされていません。

  • セグメント ルーティングの競合解決はサポートされていません。

  • LDP トラフィック統計は機能しません。

  • NSR(ノンストップ アクティブ ルーティング)と GRES(グレースフル ルーティング エンジン スイッチオーバー)はサポートされていません。

  • ISIS 階層間はサポートされていません。

  • RFC 7794、拡張 IPv4 向けの IS-IS プレフィックス属性はサポートされていません。

  • ステッチ ノードでのプレフィックス SID としての LDP ルートの再配布はサポートされていません。

各種LDPプロパティの設定

以下のセクションでは、各種LDPプロパティの設定方法について説明します。

IGPルートメトリックを使用するLDPの設定

デフォルトのLDPルートメトリック(デフォルトのLDPルートメトリックは1)ではなく、IGP(内部ゲートウェイプロトコル)ルートメトリックをLDPルートに使用したい場合、track-igp-metricのステートメントを使用します。

IGPルートメトリックを使用するには、以下のステートメントtrack-igp-metricをインクルードします。

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

inet.0ルーティング テーブルへのイングレスルートの追加防止

no-forwardingのステートメントを設定することで、[edit protocols mpls]または[edit logical-systems logical-system-name protocols mpls]階層レベルでtraffic-engineering bgp-igpのステートメントを有効にした場合でも、inet.3ルーティング テーブルの代わりに、inet.0ルーティング テーブルにイングレスルートを追加しないように設定できます。デフォルトでは、no-forwardingのステートメントは無効になっています。

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

inet.0ルーティング テーブルからイングレスルートを除外するには、以下のステートメントno-forwardingをインクルードします。

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

複数インスタンスLDPおよびキャリアオブキャリアVPN

複数のLDPルーティングインスタンスを設定することで、LDPを使用して、サービス プロバイダエエッジ(PE)ルーターからカスタマーキャリアのカスタマー エッジ(CE)ルーターまで、キャリアオブキャリアVPNのラベルをアドバタイズできます。これは、キャリアカスタマーが、基本的なインターネットサービス プロバイダ(ISP)になり、インターネットのフルルートをPEルーターに制限したい場合、特に役立ちます。BGPではなくLDPを使用することで、キャリアカスタマーはインターネットから他の内部ルーターを保護します。また、キャリアカスタマーが、レイヤー2またはレイヤー3VPNサービスを顧客に提供したい場合、複数インスタンスLDPが便利です。

キャリアオブキャリアVPNに複数のLDPルーティングインスタンスを設定する方法の例については、ラベル配布プロトコルユーザーガイドの複数インスタンスを参照してください。

最終ホップルーターでラベルをポップするMPLSおよびLDPの設定

デフォルトでアドバタイズされたラベルは、ラベル3(Implicit Nullラベル)です。ラベル3がアドバタイズされると、最終ホップルーターはラベルを削除し、パケットをエグレス ルーターに送信します。最終ホップのポッピングが有効になっていると、ラベル0(IPv4 Explicit Nullラベル)がアドバタイズされます。最終ホップのポッピングにより、MPLSネットワークを通過するどのパケットにも確実にラベルが含まれます。

最終ホップのポッピングを設定するには、以下のステートメントexplicit-nullをインクルードします。

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

注:

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

ラベルの詳細については、MPLSラベルの概要MPLSラベルの割り当てを参照してください。

RSVPが確立したLSP上でLDPの有効化

RSVPが確立したLSP上でLDPを実行し、RSVPが確立したLSPからLDPが確立したLSPを効果的にトンネリングできます。そのためには、lo0.0インターフェイスでLDPを有効にします(LDPの有効化および無効化を参照してください)。また、この[edit protocols mpls label-switched-path lsp-name]階層レベルでldp-tunnelingのステートメントをインクルードして、LDPを動作させるLSPを設定する必要があります。

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

ヘテロジニアスネットワークでRSVPが確立したLSP上でLDPの有効化

一部のベンダーは、ループバックアドレスにOSPFメトリック1を使用しています。ジュニパーネットワークスルータでは、ループバックアドレスにOSPFメトリック0を使用します。このため、ヘテロジニアスネットワークのRSVP LSP上でLDPのトンネリングを導入する場合、RSVPメトリックを手動で設定する必要があるかもしれません。

ジュニパーネットワークスルーターがRSVPトンネルで別のベンダーのルーターにリンクし、LDPトンネリングも有効になっている場合、ジュニパーネットワークスルーターは、デフォルトでRSVPトンネルを使用せず、RSVPパスにOSPF物理パスよりも1大きいメトリックがあるなら、他のベンダーのエグレス ルーターのLDP宛先ダウンストリームにトラフィックをルーティングするかもしれません。

ヘテロジニアスネットワークでLDPトンネリングが正しく機能することを確認するには、ignore-lsp-metricsのステートメントをインクルードすることで、RSVP LSPメトリックを無視するようOSPFを設定することができます。

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

  • [edit protocols ospf traffic-engineering shortcuts]

  • [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts]

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

RSVP LSP上のLDPを有効にするには、引き続きセクションRSVPが確立したLSP上でLDPの有効化の手順を完了する必要があります。

LDPセッションのTCP MD5シグネチャの設定

LDP TCP接続にMD5シグネチャを設定し、LDPセッション接続ストリームに偽装されたTCPセグメントの導入を防止することができます。

MD5シグネチャのオプションを使用したルーターは、認証が必要な各ピアのパスワードで設定されます。パスワードは暗号化して保存されます。

ピアリングインターフェースに様々なセキュリティシグネチャが設定されている場合でも、LDP Hello隣接関係を作成できます。ただし、TCPセッションの認証はできないので、確立されることはありません。

Junos OSのリリース16.1R1以降、LDPセッションのハッシュメッセージ認証コード(HMAC)およびMD5認証のサポートは、セッションごとの設定からサブネットマッチ(つまり、最長プレフィックスマッチ)設定に拡張されています。

サブネットマッチ認証のサポートにより、自動ターゲットLDP(TLDP)セッションの認証を柔軟に設定することができ、リモート ループフリーの代替ルート(LFA)およびFEC 129の疑似配線の導入が容易になります。

LDP TCP接続にMD5シグネチャを設定するには、session-groupおよびauthentication-keyのステートメントをインクルードします。

このsession-groupのステートメントを使用して、LDPセッションのリモートエンドにアドレスを設定します。

このmd5-authentication-key(パスワード)は最大69文字まで使用できます。文字には任意のASCII文字列を含めることができます。スペースを含む場合、すべての文字を引用符で囲んでください。

また、LDPルーティングプロトコルに認証キー更新メカニズムを設定することもできます。このメカニズムでは、OSPF(オープン最短パス ファースト)やRSVP(リソース予約セットアッププロトコル)などの、関連するルーティングやシグナリングプロトコルを中断することなく、認証キーを更新することができます。

認証キー更新メカニズムを設定するには、[edit security authentication-key-chains]階層レベルでkey-chainのステートメントをインクルードし、複数の認証キーで構成されるキーチェーンを作成するkeyオプションを指定します。

LDPルーティングプロトコルに認証キー更新メカニズムを設定するには、[edit protocols ldp]階層レベルでauthentication-key-chainのステートメントをインクルードし、プロトコルを[edit security authentication-key-chains]認証キーに関連付けます。また、[edit protocols ldp]階層レベルでauthentication-algorithm algorithmのステートメントをインクルードして、認証アルゴリズムを設定する必要があります。

認証キー更新機能に関する詳細については、「BGPおよびLDPルーティングプロトコルへの認証キー更新メカニズムの設定」を参照してください。

LDPセッション保護の設定

通常、1つ以上のリンクで接続されている2つのルーター間でLDPセッションが作成されます。このルーターは、各リンクに1つのHello隣接関係を形成し、これによってルーターが接続され、すべての隣接関係が対応するLDPセッションに関連付けられます。LDPセッションの最後のHello隣接関係がなくなると、LDPセッションは終了します。LDPセッションが不必要に終了し再確立されないよう、この動作を変更することができます。

2つのルーターを接続するリンクにHello隣接関係がない場合でも、Junos OSを設定して、session-protectionのステートメントを設定することで、2つのルーター間でLDPセッションを稼動させたままの状態にすることができます。timeoutオプションを使用して、オプションで時間を秒単位で指定できます。ルーターがIPネットワークの接続性を維持する限り、指定期間中、このセッションは稼働を続けます。

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

LDPのSNMPトラップの無効化

LDP LSPが上から下、または下から上に移動する場合、ルーターはSNMPトラップを送信します。ただし、ルーター、論理システム、またはルーティングインスタンスでLDP SNMPトラップを無効にすることは可能です。

LDP SNMPトラップおよび独自のLDP MIBの情報については、SNMP MIB Explorerをご覧ください。

LDPのSNMPトラップを無効にするには、log-updownのステートメントのtrap disableオプションを指定します。

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

LDPリンクでIGPとのLDP同期の設定

LDPは、トラフィックエンジニアリングを行っていないアプリケーションでラベルを配信するプロトコルです。IGPで決定する最適パスに沿ってラベルが配布されます。LDPとIGP間の同期が維持されていない場合、LSPは停止します。指定リンクでLDPがフル稼働していない(セッションが確立されておらず、ラベルが交換されていない)場合、IGPは最大コストメトリックでリンクをアドバタイズします。これは優先リンクではありませんが、ネットワークトポロジーに残っています。

LDP同期は、IGP下のポイントツーポイントとして設定されたアクティブポイントツーポイントインターフェイスおよびLANインターフェイスでのみサポートされています。LDP同期はグレースフルリスタート時にはサポートされていません。

LDPが稼働して同期するまで、最大コストメトリックをアドバタイズするには、以下のステートメントldp-synchronizationをインクルードします。

同期を無効にするには、disableのステートメントをインクルードします。フル稼働していないリンクの最大コストメトリックをアドバタイズする期間を設定するには、hold-timeのステートメントをインクルードします。

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

ルーターのIGPとのLDP同期の設定

インターフェイスのLDPネイバーおよびセッションが稼働していることをIGPに通知する前に、LDPの待機時間を設定することができます。数多くのFECを搭載した大規模ネットワークの場合、LDPラベルデータベースを交換する時間を十分確保できるよう長めの値を設定する必要があるかもしれません。

LDPネイバーおよびセッションが稼働していることをIGPに通知する前にLDPの待機時間を設定するには、igp-synchronizationのステートメントをインクルードし、holddown-intervalオプションの時間を秒単位で指定します。

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

ラベル取消タイマーの設定

ラベル取消タイマーは、FECのラベル取消メッセージをネイバーに送信するタイミングを遅らせます。ネイバーがFECのネクストホップの場合、ネイバーへのIGPリンクにエラーが生じると、すべてのアップストリームルーターからFECに関連するラベルを取り消す必要があります。IGPが収束し、新しいネクストホップからラベルを受信した後、すべてのアップストリームルーターにラベルを再度アドバタイズします。これが通常のネットワーク動作です。わずかな時間でもラベル取消のタイミングを遅らせることで(例えば、IGPが収束し、ルーターがダウンストリームのネクストホップからFECの新しいラベルを受信するまで)、ラベルの取消や、ラベルマッピングの早急な送信を避けることができます。label-withdrawal-delayのステートメントでは、この遅延時間を設定することができます。デフォルトの遅延時間は60秒です。

タイマーが時間切れになる前にルーターが新しいラベルを受信すると、ラベル取消タイマーはキャンセルされます。ただし、タイマーが時間切れになると、FECのラベルはすべてのアップストリームルーターから取り消されます。

デフォルトでは、IGPが再収束している間に何度もLSPを再シグナリングしないように、ラベルを取り消す前にLDPは60秒待機します。ラベル取消の遅延時間を秒単位で設定するには、以下のステートメントlabel-withdrawal-delayをインクルードします。

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

LDPサブネットチェックの無視

Junos OSリリース8.4以降のリリースでは、ネイバー確立の手続き中にLDP送信元アドレスサブネットチェックが行われます。LDPリンクのHelloパケットの送信元アドレスをインターフェイスアドレスと照合します。これにより、一部のベンダーの機器との相互運用性の問題が生じます。

サブネットチェックを無効にするには、以下のステートメントallow-subnet-mismatchをインクルードします。

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

  • [edit protocols ldp interface interface-name]

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

注:

ACX シリーズのルーターは、[edit logical-systems]階層レベルをサポートしていません。

LDP LSP トレースルートの設定

LDP シグナル LSP が続くルートをトレースできます。LDP LSP トレースルートは、RFC 4379 マルチプロトコルラベルスイッチ (MPLS) データプレーン障害を検知するに基づいています。この機能により、FEC 内のすべてのパスを定期的にトレースできます。FEC トポロジー情報は、CLI からアクセスできるデータベースに保存されます。

トポロジーを変更しても、LDP LSP のトレースが自動的にトリガーされることはありません。ただし、トレースルートは手動で開始できます。トレースルートリクエストが現在データベースにある FEC 向けの場合、データベースのコンテンツが結果とともに更新されます。

定期トレースルート機能は、 [edit protocols ldp]階層レベルで設定されたoamステートメントにより指定されたすべての FEC に適用されます。定期 LDP LSP トレースルートを設定するには、periodic-tracerouteステートメントを含めます。

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

periodic-tracerouteステートメントをそれ自体で、または以下のオプションのいずれかを使って設定できます。

  • exp—プローブを送信する際に使用するサービスのクラスを指定します。

  • fanout—ノードごとに検索するネクストホップの最大数を指定します。

  • frequency—トレースルート試行の間隔を指定します。

  • paths—検索するパスの最大数を指定します。

  • retries—あきらめる前に特定のノードにプローブを送信する試行回数を指定します。

  • source—プローブを送信する際に使用する IPv4 ソースアドレスを指定します。

  • ttl—TTL(Time-to-live)の最大値を指定します。この値がトレースされなくなるノード。

  • wait—プローブパケットを再送する前に、待機間隔を指定します。

LDP 統計の収集

LDP トラフィック統計は、ルーターで特定の FEC を通過したトラフィックの量を示しています。

[edit protocols ldp] 階層レベルでtraffic-statisticsステートメントを設定する場合、LDP トラフィック統計は定期的に収集され、ファイルに書き込まれています。intervalオプションを使用することで、統計を収集する頻度(秒単位)を設定することができます。デフォルトの収集間隔は 5 分です。LDP 統計ファイルを設定する必要があります。それ以外の場合、LDP トラフィック統計は収集されません。LSP がダウンした場合、LDP 統計はリセットされます。

LDPトラフィック統計を収集するには、traffic-statisticsステートメントを含みます。

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

このセクションには、以下のトピックが含まれています。

LDP 統計出力

以下のサンプル出力出力は LDP 統計ファイルからのものです。

LDP 統計ファイルには、以下のデータの列が含まれています。

  • FEC - LDP トラフィック統計を収集する FEC。

  • Type - ルーターから発信されたトラフィックのタイプ、Ingress(このルーターから発信)またはTransit(このルーターを経由して転送された)のいずれか。

  • Packets - LSP の出現以来、FEC がパスしたパケット数。

  • Bytes - LSPの出現以来、FEC がパスしたデータのバイト数。

  • Shared - Yes の値は、複数のプレフィックスが同じラベルにバインドされていることを示します(例えば、複数のプレフィックスがエグレスポリシーでアドバタイズされている場合など)。この事例での LDP トラフィック統計はすべてのプレフィックスに適用され、そのように処理する必要があります。

  • read -(日付と時刻の次に表示される)この数は、表示される実際の数とは異なる場合があります。表示される前に一部統計は概要説明されています。

最後から 2 番目のホップ ルーターでの LDP 統計の無効化

LDP トラフィック統計を最後から 2 番目のホップ ルーターで収集する場合、特にネクストホップ ルートにおいてリソースを過剰に消費する可能性があります。traffic-statisticsステートメントに、deaggregateステートメントを追加設定していると、この問題は悪化します。ネクストホップ ルート使用の限界に達するルーターには、traffic-statisticsステートメントのno-penultimate-hopオプションの設定を推奨します。

traffic-statisticsステートメントを設定できる階層レベルの一覧は、このステートメントの概要のセクションを参照してください。

注:

no-penultimate-hopオプションを設定する場合、このルーターの最後から 2 番目のホップである FEC は統計を利用できません。

このオプションを設定に含めたり削除するたびに、LDP セッションはダウンし再起動されます。

以下は、no-penultimate-hopオプションが設定されているルーターを示す LDP 統計ファイルの出力例です。

LDP 統計の限界

以下は、traffic-statisticsステートメントを設定することによる、LDP 統計の収集に関連する問題です。

  • LDP 統計のクリアはできません。

  • 指定された間隔を短縮する場合、統計タイマーが新しい間隔よりも遅い場合にのみ 新しいLDP 統計リクエストは発行されます。

  • 新しい LDP 統計収集の動作は以前のもものが完了するまで開始できません間隔が短い場合、または、LDP 統計の数が大きい場合は、2 つの統計収集のタイム ギャップが間隔よりも長くなることがあります。

LSP がダウンすると、LDP 統計はリセットされます。

LDP プロトコル トラフィックのトレース

次のセクションでは LDP プロトコル トラトラフィックを検証するためにトレース オプションを設定する方法について説明します

プロトコルとルーティング インスタンス レベルで LDP プロトコル トラフィックをトレース

LDP プロトコルのトラフィックをトレースするには、[edit routing-options]のグローバルtraceoptionsステートメントでオプションを指定し、traceoptionsステートメントを含めることで LDP 固有のオプションを指定することができます。

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

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

以下のトレース フラグは、様々な LDP メッセージの送受信に関連する動作を表示します。それぞれ、以下のような 1 つ以上の修飾子が伝送可能です。

  • address-アドレスおよびアドレス撤回メッセージの動作をトレースします。

  • binding―ラベルバインディング動作をトレースします。

  • error-エラー状態のトレースをします。

  • event―プロトコル イベントのトレースをします。

  • initialization―初期化メッセージの動作をトレースします。

  • label―ラベル リクエスト、ラベル マップ、ラベル取り消し、ラベル リリース メッセージの動作をトレースします。

  • notification―通知メッセージの動作をトレースします。

  • packets―アドレス、アドレス取り消し、初期化、ラベル リクエスト、ラベル マップ、ラベル取り消し、ラベル リリース、通知、および周期メッセージの動作をトレースします。この修飾子は、addressinitializationlabelnotification、およびperiodicの各修飾子を設定することと同じです。

    また、filterフラグ修飾子にpackets フラグのmatch-on addressサブオプションを設定することもできます。これにより、パケットの送信元アドレスと送信先アドレスをもとにしたトレースが可能になります。

  • path―ラベルスイッチ パス動作をトレースします。

  • path―ラベルスイッチ パス動作をトレースします。

  • periodic―helloとキープアライブ メッセージの動作をトレースします。

  • route―ルート メッセージの動作をトレースします。

  • state―プロトコル ステート遷移をトレースします。

FEC 内で LDP プロトコル トラフィックをトレース

LDP は、作成する各 LSP に FEC (Forwarding Equivalence Class) を関連付けます。LSP に関連する FEC は、どのパケットがその LSP にマッピングされるかを指定します。各ルーターは、ネクスト ホップが FEC 用にアドバタイズしたラベルを選択し、他のすべてのルーターにアドバタイズするラベルにスプライスすることで、LSP はネットワークを介して拡張されます。

特定の FEC 内の LDPプロトコルのトラフィックをトレースしたり、FEC に基づいて LDP トレース ステートメントをフィルタリングすることができます。この機能は、FEC に関連する LDPプロトコルのトラフィックをトレースしたり、トラブルシューティングしたりする場合に便利です。この目的には以下のトレース フラグが利用できます。routepath、およびbinding

次の例は、FEC に基づいて LDP トレース ステートメントをフィルタリングするために、LDP traceoptionsステートメントを設定する方法を示しています。

この機能には以下の制限が設けられています。

  • このフィルタリング機能は、IPv4(IPバージョン4)のプレフィックスで構成された FEC に対してのみ有効です。

  • レイヤー 2 回線 FEC はフィルタリングすることはできません。

  • ルート トレースとフィルタリングの両方を設定した場合、MPLS のルートは表示されません(フィルタでブロックされます)。

  • フィルタリングは、ポリシーとmatch-onオプションの設定値によって決定されます。ポリシーを設定する際、デフォルト動作は常にrejectであることを確認してください。

  • 唯一のmatch-onオプションはfecです。そのため、含めるべきポリシーの種類は、ルートフィルター ポリシーのみとなります。

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

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

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

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

すべての LDP 受信メッセージとすべてのラベルバインディング動作をトレースします。

LSP に関連する FEC の LDP プロトコルのトラフィックをトレースします。

リリース履歴テーブル
リリース
説明
19.1
Junos OS リリース 19.1R1 以降、セグメント ルーティング-LDP ボーディング ルーターは、セグメント ルーティング トラフィックとLDP ネクスト ホップ間のステッチが可能です。
16.1R1
Junos OSのリリース16.1R1以降、LDPセッションのハッシュメッセージ認証コード(HMAC)およびMD5認証のサポートは、セッションごとの設定からサブネットマッチ(つまり、最長プレフィックスマッチ)設定に拡張されています。
16.1
Junos OSリリース16.1以降、M-LDPは、ルートアドレスがMPLS LSPを介してさらに再帰的に解決されるBGPルートである場合、ASBRまたはトランジットまたはエグレスでポイントツーマルチポイントLSPに信号を送ることができます。
14.1
Junos OS リリース 14.1 以降では、既存の IPTV サービスをネイティブ IP マルチキャストから MPLS マルチキャストに移行するには、最小限の停止で PIM から M-LDP のポイントツーマルチポイント LSP にスムーズに移行する必要があります。