LDP設定 |Junos OS |ジュニパーネットワークス

最小 LDP 設定

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

ファミリー MPLS で関連するすべてのインターフェイスを有効にします。ディレクテッドLDPの場合、ループバックインターフェイスをファミリーMPLSで有効にする必要があります。
(オプション) [edit protocol mpls] 階層レベルで関連するインターフェイスを設定します。
単一のインターフェイスでLDPを有効にし、 ldp ステートメントを含め、 interface ステートメントを使用してインターフェイスを指定します。

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

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

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

LDPの有効化および無効化

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

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

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

インターフェイスのグループでインターフェイスのプロパティを設定し、そのうちの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 タイマーの設定
ターゲット Hello メッセージ用の LDP タイマーの設定

リンク 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 保留時間を設定する
ターゲット Hello メッセージ用の LDP 保留時間を設定する

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

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

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

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

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

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

LDPの厳密なターゲットhelloメッセージの有効化

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

LDPトンネリングが設定されているRSVPトンネルの終点
レイヤー2回線ネイバー

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

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

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

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エリアまたはIS-ISレベルで集約または要約されたルートを学習できるようにするため、Junos OSでは、 RFC5283に基づいてLDPのロンゲストマッチを設定することができます。

LDPのロンゲストマッチを設定する前に、以下のことを行う必要があります。

デバイスインターフェイスを設定します。
MPLSプロトコルを設定します。
OSPFプロトコルを設定します。

LDPのロンゲストマッチを設定するには、次のようにする必要があります。

LDPプロトコルのロンゲストマッチを設定します。

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

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

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

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

要件
概要
設定
検証

要件

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

OSPFプロトコルを備えた6台のMXシリーズルーターと、接続されたインターフェイスで有効にされた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を設定することで、これを解決できます。

トポロジー

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

図1:LDP

Network diagram with five routers labeled R0 to R4, connected by interfaces with IPs. Divided into AREA 0.0.0.0, 0.0.0.1, and 0.0.0.2 for OSPF routing.

のロンゲストマッチ例

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

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

R0

R1

R2

R3

R4

R5

デバイスR0の設定

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

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

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

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

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

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

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

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

LDPプロトコルのロンゲストマッチを設定します。

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

結果

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

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

検証

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

ルートの検証
LDPの概要情報の検証
内部トポロジーテーブル内のLDPエントリーの検証
LDPルートのFEC情報のみの検証
LDPのFECおよびシャドウルートの検証

ルートの検証

目的
アクション
意味

目的

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

アクション

デバイス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グレースフルリスタートまたはヘルパーモードの無効化
再接続時間の設定
回復時間と最大回復時間の設定

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

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 ステートメントで行われます。表1 は、LDP受信ラベルフィルタリングに適用される from 演算子のみを示しています。

表1:LDP受信ラベルフィルタリングに適用される演算子
`from` オペレーター	説明
`interface`	指定されたインターフェイス上で隣接するネイバーから受信したバインディングにマッチする
`neighbor`	指定されたLDPルーターIDから受信したバインディングにマッチする
`next-hop`	指定したインターフェースアドレスをアドバタイズしているネイバーから受信したバインディングにマッチする
`route-filter`	指定されたプレフィックスを持つバインディングに一致します

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

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

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

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

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

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

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

ルーター ID 10.10.255.2からは 131.108/16 以上を受け入れ、他のすべてのネイバーからはすべてのプレフィックスを受け入れます。

アウトバウンド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-hop 演算子と interface 演算子は使用しないでください。

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

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

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

すべてのネイバーへの 10.10.255.6/32 のルートの送信をブロックします。

131.108/16 以上だけを ID 10.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 トランスポートアドレスの概要
トランスポートアドレスの優先度
トランスポートアドレス設定のトラブルシューティング

ターゲット 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 以降、ターゲット LDP セッションのトランスポートアドレスに使用されるデフォルト IP アドレスに加えて、 session、 session-group、 interface 設定ステートメントの下で他の IP アドレスをトランスポートアドレスとして設定できるようになりました。トランスポートアドレス設定は、レイヤー2回線、MPLS、VPLS隣接関係を含む設定されたネイバーにのみ適用されます。この設定は、検出された隣接関係(ターゲットかどうかは関係ない)には適用されません。

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

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

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

ターゲットネイバー(レイヤー 2 回線、MPLS、VPLS、LDP 設定で設定)のトランスポートアドレスの優先順位は次のとおりです。

[edit protocols ldp session]階層の下。
[edit protocols ldp session-group]階層の下。
[edit protocols ldp interfcae lo0]階層の下。
[edit protocols ldp]階層の下。
デフォルトのアドレス。

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

[edit protocols ldp interfcae]階層の下。
[edit protocols ldp]階層の下。
デフォルトのアドレス。

LDPがhelloパケットを受け入れるように設定されている自動ターゲットネイバーのトランスポートアドレスの優先順位は、以下のとおりです。

[edit protocols ldp interfcae lo0]階層の下。
[edit protocols ldp]階層の下。
デフォルトのアドレス。

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

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

show ldp session
show ldp neighbor

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

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

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

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

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

address familyを確認してください。sessionステートメントの下で設定されたトランスポートアドレスは、ネイバーまたはセッションと同じアドレスファミリーに属している必要があります。
neighborまたはsessionステートメントの下のトランスポートアドレスとして設定されたアドレスは、ターゲットのhelloメッセージが起動するルーターに対してローカルである必要があります。アドレスが設定されているかどうかを確認できます。どのインターフェイスの下でもアドレスが設定されていない場合、設定は拒否されます。

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

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

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

注:

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

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

注:

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

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

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

FEC Deaggregationの設定

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

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

FEC をデアグリゲーションすると、各プレフィックスが別々のラベルにバインドされ、別々の LSP になります。

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

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

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

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

FECを集計するには、 no-deaggregate ステートメントを含めます。

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

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

LDP FEC のポリシーの設定

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

LDP FEC のイングレストラフィックを追跡または規制する。
LDP FEC のトランジットトラフィックを追跡または規制する。
特定の転送クラスから発信された LDP FEC トラフィックを追跡または規制します。
特定の仮想ルーティングおよび転送(VRF)サイトから発信された LDP FEC トラフィックを追跡または規制します。
特定のLDP FECに対してバインドされた偽トラフィックを廃棄する。

LDP FEC のトラフィックを規制するには、まずフィルターを設定する必要があります。具体的には、 interface ステートメントまたは interface-set ステートメントのいずれかを [edit firewall family protocol-family filter filter-name term term-name from] 階層レベルで設定する必要があります。 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ステートメントも設定する必要があります。設定しなかった場合、コミット操作は失敗します。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ステートメントとともに、グローバル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]階層レベル)にperiodic-tracerouteステートメントを含める必要があります。それ以外の場合、コミット操作は失敗します。

注:

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 セッション障害が発生した場合の障害アクションを設定するには、failure-action ステートメントに remove-nexthop オプションまたは remove-route オプションを含めます。

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

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

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

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

LDPリンク保護の設定

ユニキャストおよびマルチキャストLDPラベルスイッチパス(LSP)に対して、ラベル配布プロトコル(LDP)リンク保護を設定し、リンクまたはノードの障害時に耐障害性を提供できます。

始める前に:

デバイスインターフェイスを設定します。
デバイスのルーターIDと自律システム番号を設定します。
以下のプロトコルを設定します。
1. 出欠確認
2. トラフィック制御機能を備えた MPLS。
3. トラフィック制御機能を備えた OSPF。
  注:
  ループフリーオルタナティブ(LFA)を使用したマルチキャストLDPリンク保護の場合は、リンク保護を有効にします。

LDPリンク保護を設定するには:

ポイントツーマルチポイントLDP LSPを有効にします。
ルーターR0のすべてのインターフェイス(管理インターフェイスを除く)でLDPを有効にし、動的RSVPバイパスLSPを使用してリンク保護を設定します。

設定を確認し、コミットします。

次に例を示します。

例:LDPリンク保護の設定

LDPリンク保護の概要
例:LDPリンク保護の設定

LDPリンク保護の概要

LDPの概要
Junos OS LDP プロトコルの実装
LDPへのマルチポイント拡張を理解する
ターゲット LDP セッションでの LDP へのマルチポイント拡張の使用
LDPリンク保護の現在の制限
RSVP LSPをソリューションとして使用
マルチキャストLDPリンク保護について
LDPリンク保護を提供するためのさまざまなモード
LDPリンク保護のためのラベル操作
マルチキャストLDPリンク保護設定の例
メークビフォアブレーク
注意事項と制限事項

LDPの概要

LDP(Label Distribution Protocol)は、トラフィックエンジニアリングを行っていないアプリケーションでラベルを配布するためのプロトコルです。LDP は、ネットワーク層の経路情報をデータリンク LSP に直接マッピングすることで、ルーターがネットワークを介した LSP(ラベルスイッチパス)を確立することを可能にします。

これらのLSPは、直接接続されたネイバー(IPホップバイホップ転送に相当)またはネットワークの出口ノードにエンドポイントがある場合があり、すべての中間ノードを介した切り替えを可能にします。LDP で確立した LSP は、RSVP で作成したトラフィックエンジニアリング LSP も通過できます。

LDP は、作成する各 LSP に FEC(Forwarding Equivalence Class)を関連付けます。LSP に関連する FEC は、どのパケットがその LSP にマッピングされるかを指定します。各ルーターは、ネクストホップが FEC 用にアドバタイズするラベルを選択し、他のすべてのルーターにアドバタイズするラベルにスプライスすることで、LSP はネットワークを介して拡張されます。このプロセスは、egressルーターに収束するLSPのツリーを形成します。

Junos OS LDP プロトコルの実装

LDPのJunos OS実装は、LDPバージョン1をサポートしています。Junos OSは、内部ゲートウェイプロトコル(IGP)のルーター間でトンネリングするためのシンプルなメカニズムをサポートしており、コア内での外部ルートの必要な配布を排除しています。Junos OSでは、ネットワーク内のすべてのエグレスルーターへのMPLSトンネルネクストホップが許可され、コアで実行されているIGPのみでエグレスルーターにルートを分配できます。エッジルーターはBGPを実行しますが、外部ルートをコアに配信しません。代わりに、エッジでの再帰的なルート検索では、egressルーターに切り替えられたLSPに解決されます。トランジット LDP ルーターには外部ルートは必要ありません。

LDPへのマルチポイント拡張を理解する

LDP は、ネットワーク内にポイントツーポイント、マルチポイントツーポイント、ポイントツーマルチポイント、およびマルチポイントツーマルチポイント LSP を設定するためのメカニズムを定義します。ポイントツーマルチポイントおよびマルチポイントツーマルチポイントLSPは、総称してマルチポイントLSPと呼ばれ、トラフィックはそれぞれ単一の送信元から複数の宛先へ、および複数の送信元から複数の宛先へトラフィックが流れます。宛先ルーターまたは出口ルーターはリーフノードと呼ばれ、送信元からのトラフィックはリーフノードに到達する前に1つ以上のトランジットノードを通過します。

注:

Junos OS は、マルチポイントツーマルチポイント LSP をサポートしていません。

マルチポイントLSPは、ネットワークのMPLSパケットレプリケーション機能を利用することで、ingressルーターでの不要なパケットレプリケーションを回避します。パケットレプリケーションは、異なるネットワークパスを必要とする2つ以上の異なる宛先にパケットが転送された場合にのみ行われます。

ターゲット LDP セッションでの LDP へのマルチポイント拡張の使用

LDPへのマルチポイント拡張の仕様では、LDPセッションの2つのエンドポイントがレイヤー2メディアで直接接続されているか、ネットワークのIGPによってネイバーと見なされていることが求められています。これは、LDPリンクセッションと呼ばれます。LDPセッションの2つのエンドポイントが直接接続されていない場合、そのセッションはターゲットLDPセッションと呼ばれます。

過去の Junos OS 実装では、リンクセッションに対してのみマルチキャスト LDP がサポートされています。LDPリンク保護機能の導入により、マルチキャストLDP機能がターゲットLDPセッションに拡張されます。図2 は、サンプルのトポロジーを示しています。

図2:ターゲットLDPセッション Network topology diagram with routers R1 to R9 showing MPLS protocols: LDP on R1, R4, R6, R9; RSVP-TE on R5; LDP/RSVP on R2, R3. R7 is LSR-U, R8 is LSR-D. R6 is Root, R9 is Leaf.

Network topology diagram with routers R1 to R9 showing MPLS protocols: LDP on R1, R4, R6, R9; RSVP-TE on R5; LDP/RSVP on R2, R3. R7 is LSR-U, R8 is LSR-D. R6 is Root, R9 is Leaf.

に対するマルチキャストLDPサポート

ルーターR7およびR8は、それぞれアップストリーム(LSR-U)およびダウンストリーム(LSR-D)のラベルスイッチルーター(LSR)であり、マルチキャストLDPを導入します。コアルーターであるルーターR5では、RSVP-TEが有効になっています。

LSR-DがルートおよびLSP ID属性でポイントツーマルチポイントLSPを設定する場合、アップストリームのLSR-Uをルートへの最適パスのネクストホップとして決定します(現在、このネクストホップはIGPネクストホップと見なされています)。

ターゲットLDPセッションでのマルチキャストLDPサポートにより、LSR-DとLSR-Uが直接接続されたネイバーではなく、ターゲットLDPピアであるLSR-Dのルートへのパス上にあるLSR-UへのLSPネクストホップがあるかどうかを判断できます。LSR-DとLSR-U間のターゲットLDPセッションでアドバタイズされるポイントツーマルチポイントラベルは、LSR-DとLSR-Uの間にLSPがない限り使用されません。そのため、LSR-UからLSR-Dへの逆方向に対応するLSPが必要です。

データは、パケットのユニキャストレプリケーションを使用してポイントツーマルチポイントLSPで送信され、LSR-UはポイントツーマルチポイントLSPの各ダウンストリームLSRに1つのコピーを送信します。

データ転送は、以下の方法で実装されます。

ターゲットLDPセッションのポイントツーマルチポイント機能がネゴシエートされます。
アップストリームLSRを選択するアルゴリズムが変更され、IGPネクストホップが利用できない場合、つまり、LSR-DとLSR-Uの間にLDPリンクセッションがない場合、RSVP LSPがLSR-Uに到達するネクストホップとして使用されます。
ターゲットLDPセッションで受信した受信ラベルは、LDPラベルを内側ラベル、RSVPラベルを外側ラベルとして、このポイントツーマルチポイントFECルートのブランチネクストホップとしてインストールされます。

LDPリンク保護の現在の制限

LDPネットワークの導入でリンクまたはノード障害が発生した場合、ミッションクリティカルなサービスで影響を受けたトラフィックフローを復旧するために、迅速なトラフィック復旧を提供する必要があります。マルチポイントLSPの場合、ポイントツーマルチポイントツリーのリンクの1つに障害が発生すると、IGPが再収束し、ダウンストリームルーターから新しいアップストリームルーターへの最適なパスを使用してマルチポイントLSPが確立されるまで、サブツリーが切り離される可能性があります。

LDPトラフィックのローカル修復を使用した高速再ルートでは、バックアップパス(修復パス)がパケット転送エンジンに事前インストールされています。プライマリパスに障害が発生すると、トラフィックはルーティングプロトコルが収束するのを待つことなく、バックアップパスに迅速に移動します。ループフリー代替(LFA)は、コアおよびサービスプロバイダネットワークにIP高速再ルート機能を提供するために使用される方法の1つです。

LFAを使用しない場合、リンクまたはルーターに障害が発生したり、サービスに復帰したりすると、分散ルーティングアルゴリズムがネットワークの変化に基づいて新しいルートを計算します。新しいルートが計算される時間をルーティング遷移と呼びます。ルーティング遷移が完了するまで、障害に隣接するルーターが、代替パスが特定されるまで障害コンポーネントを介してデータパケットを転送し続けるため、ネットワーク接続は中断されます。

ただし、LFAはIGPメトリックのため、すべてのネットワーク展開を完全にカバーできるわけではありません。その結果、これは現在のLDPリンク保護方式の制限となります。

図3 は、トラフィックが送信元ルーター(S)からルーターR1を経由して宛先ルーター(D)に流れる、不完全なLFAカバレッジを持つサンプルネットワークを示しています。ネットワーク内の各リンクのメトリックが同じであると仮定すると、ルーターSとルーターR1の間のリンクに障害が発生すると、ルーターR4はS-R1リンクを保護するLFAではないため、トラフィックの耐障害性が失われます。したがって、プレーンLFAを使用していては、完全なカバレッジを実現できません。一般的なネットワークでは、プレーン LFA とは常にある程度の割合の LFA カバレッジギャップが存在します。

図3:LFA

Network topology diagram showing six nodes in a hexagon: R1, R2, R3, R4, S, D. Nodes connected by lines indicating data flow.

による不完全なカバレッジ問題

RSVP LSPをソリューションとして使用

LDP LSP を通過するトラフィックを保護する鍵は、リンクまたはノードに障害が発生した場合にトラフィックを再ルーティングするための明示的なトンネルを用意することです。明示的パスは、次のダウンストリームルーターで終了し、RPF チェックに合格する必要がある明示的パスでトラフィックを受け入れる必要があります。

RSVP LSP は、以下の方法で LFA カバレッジを拡張することで、ポイントツーポイントおよびポイントツーマルチポイントの両方の LDP LSP におけるループフリー代替(LFA)の現在の制限を克服するのに役立ちます。

手動設定されたRSVP LSP
動的に設定されたRSVP LSP

手動設定されたRSVP LSP

図 3 で使用した例を考慮すると、S-R1 リンクに障害が発生し、ルーター R4 がその特定のリンクの LFA ではない場合、手動で作成した RSVP LSP がパッチとして使用され、LFA を完全にカバーします。RSVP LSP は、ルーター S のパケット転送エンジンに事前にシグナリングされ、事前にインストールされているため、ルーター S がリンクの障害を検出するとすぐに使用できます。

図4:手動設定のRSVP LSPカバレッジ Network topology diagram showing RSVP and LDP in MPLS: Routers R1, R2, R3, R4, S, D. Blue arrow for RSVP LSP. Dashed line for LDP session.

Network topology diagram showing RSVP and LDP in MPLS: Routers R1, R2, R3, R4, S, D. Blue arrow for RSVP LSP. Dashed line for LDP session.

この場合、図4に示すように、ルーターS、R4、R3の間でRSVP LSPが作成されます。ルーターSとルーターR3の間でターゲットLDPセッションが作成され、その結果、S-R1リンクに障害が発生すると、トラフィックはルーターR3に到達します。ルーターR3は、宛先であるルーターDに到達するまでの最短パスであるため、トラフィックをルーターR2に転送します。

動的に設定されたRSVP LSP

この方法では、RSVP LSP が自動的に作成され、システムに事前インストールされるため、リンク障害が発生した場合にすぐに使用できます。ここでは、egressは保護対象のリンクの反対側のノードであるため、LFAカバレッジが向上します。

Benefits of Enabling Dynamic RSVP LSPs

設定のしやすさ。
保護対象のリンクの遠端への代替パスがある限り、リンク障害に対して100%カバーします。
RSVP バイパス LSP の設定と破棄は自動的に行われます。
RSVP LSPはリンク保護にのみ使用され、保護対象のリンクが稼働している間はトラフィックの転送には使用されません。
システムに必要なRSVP LSPの総数を減らします。

図 3 で使用した例を考慮すると、S-R1 リンクの潜在的な障害からトラフィックを保護するために、ルーター R4 はその特定のリンクの LFA ではないため、図 5 に示すように、保護されたリンクの向こう側のノードであるルーター R1 に RSVP バイパス LSP が自動的に作成されます。ルーターR1から、トラフィックは元の宛先であるルーターDに転送されます。

RSVP LSP は、ルーター S のパケット転送エンジンに事前にシグナリングされ、事前にインストールされているため、ルーター S がリンクの障害を検出するとすぐに使用できます。

図5:動的に設定されたRSVP LSPカバレッジ Network topology diagram showing RSVP-TE LSP path from source router S to destination router D via routers R1, R2, R3, and R4.

Network topology diagram showing RSVP-TE LSP path from source router S to destination router D via routers R1, R2, R3, and R4.

別の動作モードは、LFA をまったく使用せず、すべてのリンク障害をカバーするために常に RSVP LSP を作成することです。

動的RSVP LSPを有効にするには、適切なインターフェイスでRSVPプロトコルを有効にすることに加えて、[edit protocols ldp interface interface-name link-protection]階層レベルにdynamic-rsvp-lspステートメントを含めます。

マルチキャストLDPリンク保護について

ポイントツーマルチポイントLDPラベルスイッチパス(LSP)は、ポイントツーマルチポイントであるLDP信号LSPであり、マルチキャストLDPと呼ばれます。

マルチキャストLDP LSPを使用して、単一のルートノードまたはイングレスノードから、1つ以上のトランジットノードを通過する多数のリーフノードまたはエグレスノードにトラフィックを送信できます。マルチキャストLDPリンク保護により、リンク障害が発生した場合に、ポイントツーマルチポイントLDP LSPを介して転送されたトラフィックの高速再ルートが可能になります。ポイントツーマルチポイントツリーのリンクの 1 つに障害が発生すると、IGP が再収束し、ダウンストリームルーターから新しいアップストリームルーターへの最適なパスを使用してマルチポイント LSP が確立されるまで、サブツリーが切り離される可能性があります。

マルチキャストLDP LSPを通過するトラフィックを保護するために、リンク障害が発生した場合にトラフィックを再ルーティングするように明示的なトンネルを設定することができます。明示的パスは、次のダウンストリームルーターで終了する必要があります。トラフィックのリバースパスフォワーディングが成功しているはずです。

マルチキャストLDPリンク保護には、以下の特徴と機能が導入されています。

バイパストンネルとしての動的RSVP LSPの使用

RSVP LSPの明示的なルートオブジェクト(ERO)は、回避するリンクとして制約付き最短パスファースト(CSPF)を使用して計算されます。LSP は、リンク保護が必要なたびに動的にシグナリングおよび破棄されます。
事前対応

事前対応機能により、マルチキャストLDP LSPの古いLSPパスを破棄する前に、新しいLSPパスをシグナリングしようとする際のパケット損失が最小限に抑えられます。
ターゲット LDP セッション

ダウンストリームのラベルスイッチングルーター(LSR)へのターゲット隣接関係は、次の 2 つの理由で作成されます。
- リンク障害後もセッションを稼働させ続けるため。
- セッションから受信したポイントツーマルチポイントラベルを使用して、RSVP LSPバイパストンネル上のダウンストリームLSRにトラフィックを送信するには。
  
  ダウンストリーム LSR がルートノードと LSP ID を持つマルチキャスト LDP LSP を設定する場合、ルートへの最適なパスにあるそのアップストリーム LSR を使用します。

注:

ダウンストリームLSRに複数のリンク隣接関係(パラレルリンク)がある場合、マルチキャストLDPリンク保護は必要ありません。

LDPリンク保護を提供するためのさまざまなモード

ユニキャストおよびマルチキャストLDPリンク保護で使用できる3つの動作モードを以下に示します。

Case A: LFA only

この動作モードでは、既存の有効なループフリーの代替(LFA)を使用して、マルチキャスト LDP リンク保護が提供されます。有効なLFAがない場合、マルチキャストLDP LSPに対してリンク保護は提供されません。
Case B: LFA and Dynamic RSVP LSP

この動作モードでは、既存の有効なLFAを使用してマルチキャストLDPリンク保護が提供されます。有効なLFAが存在しない場合、RSVPバイパスLSPが自動的に作成され、マルチキャストLDP LSPにリンク保護を提供します。
Case C: Dynamic RSVP LSP only

この動作モードでは、LFA はリンク保護には使用されません。マルチキャストLDPリンク保護は、自動的に作成されたRSVPバイパスLSPを使用して提供されます。

図6 は、マルチキャストLDPリンク保護のさまざまな動作モードを示すトポロジーの例です。ルーターR5は、ルーターR3およびR4の2つのリーフノードに接続するルートです。ルーターR0とルーターR1は、それぞれアップストリームとダウンストリームのLSR(ラベルスイッチルーター)です。マルチキャストLDP LSPは、ルートノードとリーフノード間を走ります。

図6:マルチキャストLDPリンク保護トポロジー Network topology diagram with routers R0 to R5, labeled links L20, L21, L22, L23, and L100. Dashed blue lines show Multicast LDP LSP paths, and a dashed orange line labeled L100 indicates a protection tunnel. Numbers denote bandwidth or metrics.

Network topology diagram with routers R0 to R5, labeled links L20, L21, L22, L23, and L100. Dashed blue lines show Multicast LDP LSP paths, and a dashed orange line labeled L100 indicates a protection tunnel. Numbers denote bandwidth or metrics.

例

R0-R1リンクに障害が発生した場合に、ルーターR0がマルチキャストLDP LSPを保護する必要があることを考慮して、リンク保護のさまざまなモードは次のように動作します。

Case A: LFA only

ルーターR0は、R0-R1リンクを回避してルーターR1に到達できる有効なLFAパスが存在するかどうかを確認します。メトリックに基づくと、ルーターR2はR0-R1リンクの有効なLFAパスであり、ユニキャストLDPトラフィックの転送に使用されます。複数のマルチキャストLDP LSPがR0-R1リンクを使用する場合、同じLFA(ルーターR2)がマルチキャストLDPリンク保護に使用されます。

R0-R1リンクに障害が発生すると、マルチキャストLDP LSPトラフィックはルーターR0によってLFAパスに移動され、ルーターR1(L100)に到達するユニキャストLDPラベルがマルチキャストLDPラベル(L21)の上にプッシュされます。
Case B: LFA and Dynamic RSVP LSP

ルーターR0は、R0-R1リンクを回避してルーターR1に到達できる有効なLFAパスが存在するかどうかを確認します。メトリックに基づくと、ルーターR2はR0-R1リンクの有効なLFAパスであり、ユニキャストLDPトラフィックの転送に使用されます。複数のマルチキャストLDP LSPがR0-R1リンクを使用する場合、同じLFA(ルーターR2)がマルチキャストLDPリンク保護に使用されます。R0-R1リンクに障害が発生すると、マルチキャストLDP LSPトラフィックはルーターR0によってLFAパスに移動します。

ただし、R2-R1リンクのメトリックが10ではなく50であった場合、ルーター2はR0-R1リンクに対して有効なLFAではありません。この場合、ルーターR0とR1の間を移動するマルチキャストLDPトラフィックを保護するためにRSVP LSPが自動的に作成されます。
Case C: Dynamic RSVP LSP only

RSVP LSP は、インターフェイス ge-1/1/0 を避けて、ルーター R0 からルーター R2 を経由してルーター R1 に自動的にシグナリングされます。複数のマルチキャスト LDP LSP が R0-R1 リンクを使用する場合、同じ RSVP LSP がマルチキャスト LDP リンク保護に使用されます。

R0-R1 リンクに障害が発生すると、マルチキャスト LDP LSP トラフィックはルーター R0 によって RSVP LSP に移動され、ルーター R1(L100)に到達するための RSVP ラベルがマルチキャスト LDP ラベル(L21)の上にプッシュされます。

LDPリンク保護のためのラベル操作

図 5 と同じネットワークトポロジーを使用して、図 7 は、ユニキャストおよびマルチキャスト LDP リンク保護のラベル操作を示しています。

図7:LDPラベル動作トポロジー Network diagram with routers R0 to R5 connected via interfaces. Dashed blue lines indicate Multicast LDP paths and dashed gray lines indicate Unicast LDP paths. A table lists loopback addresses: R1 192.168.0.1, R2 192.168.0.2, R3 192.168.0.3, R4 192.168.0.4, R5 192.168.0.5.

Network diagram with routers R0 to R5 connected via interfaces. Dashed blue lines indicate Multicast LDP paths and dashed gray lines indicate Unicast LDP paths. A table lists loopback addresses: R1 192.168.0.1, R2 192.168.0.2, R3 192.168.0.3, R4 192.168.0.4, R5 192.168.0.5.

例

ルーターR5は、ルーターR3およびR4の2つのリーフノードに接続するルートです。ルーターR0とルーターR1は、それぞれアップストリームとダウンストリームのLSR(ラベルスイッチルーター)です。マルチキャストLDP LSPは、ルートノードとリーフノード間を走ります。ユニキャスト LDP パスは、ルーター R1 からルーター R5 に接続します。

ラベル操作は、以下のLDPリンク保護モードでの実行が異なります。

ケースA:LFAのみ
ケースB:LFAと動的RSVP LSP
ケースC:動的RSVP LSPのみ

ケースA:LFAのみ

ルーターR0の show route detail コマンド出力を使用して、ユニキャストLDPトラフィックとマルチキャストLDPトラフィックを導き出すことができます。

ラベル299840は、ルーターR0に到着するトラフィックで、ルーターR1へのユニキャストLDPトラフィックに対応します。ラベル299856は、ルートノードR5からリーフエグレスノードR3およびR4へのマルチキャストLDPトラフィックに対応する、ルーター0に到着するトラフィックです。

ユニキャストおよびマルチキャストLDP LSPのメインパスは、インターフェイスge-0/0/1(ルーターR1へのリンク)を経由し、LFAパスはインターフェイスge-0/0/2(ルーターR2へのリンク)を経由します。ge-0/0/1インターフェイスがダウンしない限り、LFAパスは使用されません。

ケースAのラベル操作では、LFAのみの動作モードがユニキャストとマルチキャストLDPトラフィックで異なります。

ユニキャストラベル操作

ユニキャストLDPトラフィックの場合、FECおよび関連するラベルは、LDPが有効になっているネットワーク内のすべてのリンクにアドバタイズされます。つまり、ルーターR4にユニキャストLDPトラフィックに対するLFAアクションを提供するために、ルーターR0は、受信ラベルをルーターR1がFEC R4に対してアドバタイズしたラベル299824に交換する代わりに、ルーターR0は、受信ラベルをルーターR2がFEC R4に対してアドバタイズしたラベル299808と交換するだけです。これは、ユニキャストLDPトラフィックに対する標準的なJunos OS LFA操作です。

図8 は、R0-R1リンクに障害が発生した場合のユニキャストトラフィックのラベル操作を示しています。灰色のボックスは、通常条件下でのユニキャストLDPトラフィックのラベル操作を示し、点線のボックスは、R0-R1リンクに障害が発生した場合のユニキャストLDPトラフィックのラベル操作を示しています。

図8:ユニキャストLDPラベル動作
マルチキャストラベル操作

マルチポイントLSPラベルは、リーフノードからイングレスノードへの最適なパスに沿ってのみアドバタイズされるため、マルチキャストLDPトラフィックのラベル操作は、ユニキャストLDPラベル操作とは異なります。その結果、ルーターR2はマルチキャストLDPを認識しません。これを克服するために、マルチキャスト LDP LSP トラフィックは、ルーター R1 で終端するルーター R2 を経由するユニキャスト LDP LSP パス内に単純にトンネリングされます。

これを実現するために、ルーターR0はまず、受信マルチキャストLDP LSPラベル299856をルーターR1によってアドバタイズされたラベル299888にスワップします。次に、ラベル 299776 が最上位にプッシュされますが、これはルーター R2 が FEC R1 に対してアドバタイズした LDP ラベルです。パケットがルーターR2に到着すると、最後から2番目のホップポッピングによりトップラベルがポップアウトされます。これは、パケットが、ルーター R1 が最初にルーター R0 にアドバタイズしたマルチキャスト LDP ラベル299888を使用してルーター R1 に到着することを意味します。

図9 は、R0-R1リンクに障害が発生した場合のマルチキャストLDPトラフィックのラベル操作を示しています。青いボックスは、通常条件下のマルチキャストLDPトラフィックのラベル操作を示し、点線のボックスは、R0-R1リンクに障害が発生した場合のマルチキャストLDPトラフィックのラベル操作を示しています。

図9:マルチキャストLDPラベル動作

R2-R1リンクのメトリックが1ではなく1000に設定されている場合、ルーターR2はルーターR0に対して有効なLFAではありません。この場合、ルーターR2がIGPが収束する前にルーターR1、R3、またはR4宛のパケットを受信すると、パケットはルーターR0に送り返され、ループパケットになります。

ルーターR0には有効なLFAがないため、パケット転送エンジンにバックアップパスはインストールされません。R0-R1リンクに障害が発生すると、IGPとLDPが収束し、影響を受けるルーターに新しいエントリーがインストールされるまで、トラフィックフローが中断されます。

show route detailコマンドは、リンク保護に使用できるLFAがない場合の状態を表示します。

ケースB:LFAと動的RSVP LSP

この動作モードでは、有効なLFAネイバーが存在する場合、ラベル操作の動作はケースAのLFAのみモードと同様です。ただし、有効なLFAネイバーがない場合は、RSVPバイパストンネルが自動的に作成されます。

リンクR2-R1のメトリックが1ではなく1000に設定されている場合、ルーターR2はルーターR0のLFAではありません。R0-R1 リンク障害を保護する LFA パスがないことが判明すると、ルーター R1 をエグレスノードとする RSVP バイパストンネルが自動的に作成され、R0-R1 リンクを回避するパス(例:R0-R2-R1)をたどります。

R0-R1リンクに障害が発生した場合、ユニキャストLDPおよびマルチキャストLDPトラフィックはRSVPバイパストンネルを介してトンネリングされます。RSVP バイパストンネルは通常の転送には使用されず、R0-R1 リンク障害が発生した場合に LDP トラフィックにリンク保護を提供する目的にのみ使用されます。

show route detailコマンドを使用すると、ユニキャストとマルチキャストLDPトラフィックを導き出すことができます。

ユニキャストおよびマルチキャストLDP LSPのメインパスは、インターフェイスge-0/0/1(ルーターR1へのリンク)を経由し、LFAパスはインターフェイスge-0/0/2(ルーターR2へのリンク)を経由します。ge-0/0/1インターフェイスがダウンしない限り、LFAパスは使用されません。

ラベル299840は、ルーターR0に到着するトラフィックで、ルーターR4へのユニキャストLDPトラフィックに対応します。ラベル299856は、ルートノードR5からリーフエグレスノードR3およびR4へのマルチキャストLDPトラフィックに対応する、ルーター0に到着するトラフィックです。

show route detailコマンド出力に見られるように、保護パスのラベル操作は、ユニキャストLDPトラフィックとマルチキャストLDPトラフィックで同じです。ルーターR0で受信するLDPラベルは、ルーターR1からルーターR0にアドバタイズされたLDPラベルに交換されます。次に、バイパストンネル用に299872されたRSVPラベルがパケットにプッシュされます。バイパストンネルで最後から 2 番目のホップポッピングが使用され、ルーター R2 がそのラベルをポップします。したがって、パケットは、最初にルーターR0にアドバタイズされたLDPラベルとともに、ルーターR1に到着します。

図10 は、RSVPバイパストンネルで保護されたユニキャストLDPおよびマルチキャストLDPトラフィックのラベル操作を示しています。灰色と青色のボックスは、ユニキャスト LDP トラフィックとマルチキャスト LDP トラフィックにそれぞれ通常の条件下で使用されるラベル値を表しています。点線のボックスは、R0-R1 リンクに障害が発生した場合に使用されるラベル値を表しています。

図10:LDPリンク保護ラベル動作 Network topology diagram showing routers R0 to R5 with LSPs: blue dashed lines for multicast, gray for unicast, green for RSVP bypass to R2. Black dashed line indicates R0-R1 link failure.

Network topology diagram showing routers R0 to R5 with LSPs: blue dashed lines for multicast, gray for unicast, green for RSVP bypass to R2. Black dashed line indicates R0-R1 link failure.

ケースC:動的RSVP LSPのみ

この動作モードでは、LFAはまったく使用されません。リンク保護を提供するために、動的RSVPバイパスLSPが自動的に作成されます。 show route detail コマンドからの出力とラベル操作は、ケースB、LFAおよび動的RSVP LSPモードと似ています。

マルチキャストLDPリンク保護設定の例

マルチキャストLDPリンク保護を有効にするには、ルーターR0で以下の設定が必要です。

注:

このサンプルでは、ルーター R1 に接続するルーター R0 の ge-1/0/0 インターフェイスでマルチキャスト LDP リンク保護が有効になっていますが、通常はすべてのインターフェイスをリンク保護用に設定する必要があります。

ルーターR0

以下の設定ステートメントは、以下のように、マルチキャストLDP保護の異なるモードに適用されます。

link-protection でのステートメント [edit protocols ospf interface ge-0/0/1.0]

この設定は、マルチキャストLDPリンク保護のケースA(LFAのみ)およびケースB(LFAおよび動的RSVP LSP)モードにのみ適用されます。ケースCでは、IGPの下でのリンク保護の設定は必要ありません(動的RSVP LSPのみ)。
link-protection でのステートメント [edit protocols ldp interface ge-0/0/1.0]

この設定は、マルチキャストLDP保護のすべてのモードで必要です。ただし、LDP トラフィックがユニキャストのみ存在し、動的 RSVP バイパスが不要な場合は、[edit protocols ospf interface ge-0/0/1.0]階層レベルの link-protection ステートメントが LDP ユニキャストトラフィックに対して LFA アクションを実行するため、この設定は不要です。
dynamic-rsvp-lsp でのステートメント [edit protocols ldp interface ge-0/0/1.0 link-protection]

この設定は、LDPリンク保護のケースB(LFAおよび動的RSVP LSP)およびケースC(動的RSVP LSPのみ)モードにのみ適用されます。動的 RSVP LSP 設定は、ケース A には適用されません(LFA のみ)。

メークビフォアブレーク

Junos OSでは、事前対応機能がデフォルトで有効になっており、ポイントツーマルチポイントLSPにいくつかのメリットがあります。

ポイントツーマルチポイント LSP の場合、LSR(ラベルスイッチルーター)は、LSP のルートへのネクストホップである LSR をアップストリーム LSR として選択します。ルートに到達する最適なパスが変更されると、LSR は新しいアップストリーム LSR を選択します。この期間中、LSP が一時的に切断され、LSP が新しいアップストリーム LSR に再収束するまでパケット損失が発生する可能性があります。この場合のメークビフォアブレークの目的は、パケットロスを最小限に抑えることです。LSRからルートへの最適なパスが変更されたにもかかわらず、LSPが以前のネクストホップからルートへのトラフィックを転送し続ける場合、パケット損失の期間を最小限に抑えるために、古いLSPを取り消す前に新しいLSPを確立する必要があります。

例えば、リンク障害後も、ダウンストリームの LSR(例えば、LSR-D)は、ワンホップの RSVP LSP からのパケット受信を継続するため、他のダウンストリームの LSR にパケットを受信および/または転送します。ルーティングが収束すると、LSR-D はこのポイントツーマルチポイント LSP の FEC(FEC-A)用に新しいアップストリーム LSR(LSR-U)を選択します。新しい LSR は、すでに FEC-A 用のパケットを LSR-D 以外のダウンストリーム LSR に転送している可能性があります。LSR-Uは、LSR-DからFEC-Aのラベルを受信した後、LSR-A用LSPがルートから自身に確立されたことを学習すると、LSR-Dに通知します。LSR-Dはこのような通知を受信すると、LSPルートのネクストホップをLSR-Uに変更します。これは、LSR-Dでのルート削除と追加の操作です。この時点で、LSR-DはLSPスイッチオーバーを行い、RSVP LSPまたはLFAを介してトンネリングされたトラフィックはドロップされ、LSR-Uからのトラフィックは受け入れられます。LSR-Uの新しいトランジットルートが追加されました。RPF チェックが、LSR-U からのトラフィックを受け入れ、古いアップストリーム LSR からのトラフィックをドロップするように変更されるか、古いルートが削除されて新しいルートが追加されます。

LSR-Uは、FEC-AポイントツーマルチポイントLSPのアップストリームルーターからメークビフォアブレーク通知を受信し、LSPの転送状態をインストールしていることを前提としています。その時点で、FEC-A によって識別されるツリーの一部になったこと、および LSR-D が LSP への切り替えを開始することを、メークビフォアブレーク通知によって LSR-D に通知する必要があります。それ以外の場合、LSR-Uは、FEC-AのアップストリームLSRからメークビフォアブレーク通知を受信し、このLSPの転送状態をインストールするときに、LSR-Dに通知を送信する必要があることを覚えておく必要があります。LSR-Dは、新しいポイントツーマルチポイントLSPからLSR-Uに切り替えるまで、1ホップのRSVP LSPまたはLFAパスを使用して、古いネクストホップからルートノードへのトラフィックを受信し続けます。

マルチキャストLDPリンク保護によるメークビフォアブレーク機能には、以下の機能があります。

事前対応機能

LSRは、機能アドバタイズメントを使用して、事前対応LSPを処理できることをアドバタイズします。ピアが事前対応でない場合、事前対応パラメーターはこのピアに送信されません。LSRがダウンストリームのLSR(LSR-D)からメークビフォアブレークパラメータを受信したが、アップストリームのLSR(LSR-U)がメークビフォアブレークに対応していない場合、LSRは直ちにメークビフォアブレーク通知をLSR-Dに送信し、メークビフォアブレーク対応LSPは確立されません。代わりに、通常のLSPが確立されます。
事前対応ステータスコード

事前対応ステータスコードには、以下が含まれます。
- 1 - 事前対応要求
- 2 - 事前対応確認応答
ダウンストリームの LSR がポイントツーマルチポイント LSP のラベルマッピングメッセージを送信すると、1(リクエスト)として事前対応ステータスコードが含まれます。アップストリームの LSR がポイントツーマルチポイント LSP の転送状態を更新すると、ダウンストリームの LSR に、メークビフォアブレークのステータスコードを含む通知メッセージを 2(確認応答)として通知します。その時点で、ダウンストリームの LSR は LSP スイッチオーバーを行います。

注意事項と制限事項

LDPリンク保護機能のJunos OS実装には、以下の注意点と制限があります。

メークビフォアブレークは、エグレス LSR 上の以下のポイントツーマルチポイント LSP ではサポートされていません。
- 仮想ルーティングおよび転送(VRF)ラベルを使用した次世代マルチキャスト仮想プライベートネットワーク(MVPN)
- 静的LSP
以下の機能はサポートされていません。
- Junos OSリリース12.3、13.1、13.2におけるポイントツーマルチポイントLSPのノンストップアクティブルーティング
- グレースフルリスタートスイッチオーバーポイントツーマルチポイント LSP
- ルーティングインスタンスのリンク保護

例:LDPリンク保護の設定

この例では、ユニキャストおよびマルチキャストLDPラベルスイッチパス(LSP)の両方に対して、ラベル配布プロトコル(LDP)リンクプロテクションを設定する方法を示します。

要件
概要
設定
検証

要件

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

M Series、MXシリーズ、またはT Seriesルーターの組み合わせが可能な6台のルーターで、1つのルートノードと2つのリーフノードでポイントツーマルチポイントLDP LSPを実行します。
すべてのルーターで実行されている Junos OS リリース 12.3 以降。

始める前に:

デバイスインターフェイスを設定します。
以下のプロトコルを設定します。
1. 出欠確認
2. MPLS
3. OSPFまたはその他のIGP
4. LDP

概要

LDPリンク保護により、リンク障害が発生した場合にLDP LSPを介して伝送されるトラフィックの高速再ルートが可能になります。LDPポイントツーマルチポイントLSPを使用して、単一のルートまたはイングレスノードから、1つ以上のトランジットノードを通過する多数のリーフノードまたはエグレスノードにトラフィックを送信できます。ポイントツーマルチポイントツリーのリンクの 1 つに障害が発生すると、IGP が再収束し、マルチキャスト LDP がダウンストリームルーターから新しいアップストリームルーターへの最適なパスを使用してラベルマッピングを開始するまで、サブツリーが切り離される可能性があります。リンク障害が発生した場合にトラフィックを保護するために、明示的なトンネルを設定して、トンネルを使用してトラフィックを再ルーティングできるようにすることができます。Junos OSは、古いLSPパスを破棄する前に新しいLSPパスに信号を送ろうとする際のパケット損失を最小限に抑えるために、メークビフォアブレーク機能をサポートしています。この機能により、マルチキャストLDPリンク保護のターゲットLDPサポートも追加されます。

LDPリンク保護を設定する際は、以下の点に留意してください。

IGPでトラフィックエンジニアリングを設定し(デフォルトでサポートされていない場合)、MPLSとRSVP用に設定されたインターフェイスを含めて、制約付きベースのリンク保護動的RSVP LSPが、CSPF(制約付き最短パスファースト)を使用してRSVPによってシグナリングされるようにします。この条件が満たされない場合、RSVP LSP が立ち上がらない可能性があり、LDP はそれを保護されたネクストホップとして使用できません。
リンク障害が発生した場合に、2つのLSR(ラベルスイッチルーター)間のパスを設定し、ルーター間でIP接続を提供します。これにより、CSPF はリンク保護の代替パスを計算できます。ルーター間の接続が失われると、LDP ターゲット隣接関係が立ち上がらず、動的 RSVP LSP がシグナリングされないため、ピアがダウンストリーム LSR である LDP 転送等価クラス(FEC)の保護は失われます。
リンク保護が一方のLSRでのみアクティブである場合、もう一方のLSRに strict-targeted-hellos ステートメントを設定しないでください。これにより、リンク保護なしの LSR で、非対称リモートネイバーの検出を可能にし、リモートネイバーを開始した LSR に定期的にターゲット LSR を送信することができます。この条件が満たされない場合、LDPターゲット隣接関係は形成されません。
LDPトンネリング、LDPベースの仮想プライベートLANサービス(VPLS)、レイヤー2回線、またはLDPセッション保護に基づいてリモートネイバーを作成するには、LSRのループバックインターフェイスでLDPを有効にする必要があります。この条件が満たされない場合、LDPターゲット隣接関係は形成されません。
ユニキャスト LDP LSP の場合、IGP で LFA(loop-free alternate)を設定する必要があります。
マージポイントへのイングレスルートには、少なくとも1つのネクストホップがあり、マージポイントとユニキャストLDP LSPのローカル修復ポイントとの間のプライマリリンクを回避する必要があります。
ローカル修復ポイントには、バックアップネクストホップがマージポイントに到達するためのユニキャストLDPラベルが必要です。

トポロジー

図11:LDPリンク保護 Network topology diagram with five routers R0-R4 connected via interfaces and subnets. Table lists loopback IPs: R0-R4 have 10.255.1.0-10.255.1.4/32. Used for network design and troubleshooting.

Network topology diagram with five routers R0-R4 connected via interfaces and subnets. Table lists loopback IPs: R0-R4 have 10.255.1.0-10.255.1.4/32. Used for network design and troubleshooting.

この例では、ルーターR5は2つのリーフノード、ルーターR3とR4に接続するルートです。ルーターR0は、ローカル修復のポイントです。

設定

CLIクイックコンフィグレーション
手順

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

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

R5

R0

R1

R2

R3

R4

手順

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

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

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

ルーターR0を設定するには:

ルーターR0インターフェイスを設定します。

ルーターR0のルーターIDと自律システムを設定します。

(管理インターフェイスを除く)ルーターR0のすべてのインターフェイスでRSVPを有効にします。
トラフィック制御機能とともに、ルーターR0のすべてのインターフェイス(管理インターフェイスを除く)でMPLSを有効にします。
ルーターR0のすべてのインターフェイス(管理インターフェイスを除く)でOSPFを有効にし、リンクに等コストメトリックを割り当て、トラフィック制御機能を有効にします。
注:
ループフリーオルタナティブ(LFA)を使用したLDPリンク保護マルチキャストには、 [edit protocols] 階層レベルで以下の設定を有効にします。
ルーターR0のすべてのインターフェイス(管理インターフェイスを除く)でLDPを有効にし、動的RSVPバイパスLSPを使用してリンク保護を設定します。

結果

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

検証

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

バイパスRSVP LSPパスの検証
ラベル動作の検証

バイパスRSVP LSPパスの検証

目的
アクション
意味

目的

バイパスRSVP LSPパスがPLR(Point of Local Repair)で作成されていることを確認します。

アクション

動作モードから、 show route tale mpls.0 コマンドを実行します。

意味

R0-R1リンクがダウンすると、RSVPバイパスLSPを使用してトラフィックをルーティングします。

ラベル動作の検証

目的
アクション
意味

目的

PLRでのラベルスワップを確認します。

アクション

動作モードから、 show route table mpls.0 label label extensive コマンドを実行します。

意味

ラベルは、リーフノードであるルーターR4に到達するはずです。

マルチキャストのみの高速再ルートについて

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

注:

スイッチでは、MPLSラベルスイッチパスとマルチポイントLDPを備えたMoFRRはサポートされていません。

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

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

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

MoFRR の概要
PIM 機能
マルチポイント LDP 機能
パケット転送
制限と注意事項

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 Sample Topology

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

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

MoFRR は、ECMP(Equal Cost マルチパス)パスと非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 の前提条件となります( 『ポイントツーマルチポイント LSP のマルチポイント LDP インバンドシグナリングを理解する』を参照してください)。

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 リンクが追加されると、プライマリパス上のジョインメッセージが再配信され、ロードバランシングされます。バックアップパス上のジョインメッセージは、同じパスをたどる可能性があり、均等に再配配信されない可能性があります。

MoFRR を有効にするには、[edit routing-options multicast]階層の stream-protection 設定ステートメントを使用します。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 つの異なるアップストリームピアは、MPLS トラフィックの 2 つのストリームをエグレスルーティングデバイスに送信します。デバイスは、MPLSトラフィックを受け入れるプライマリパスとして、アップストリームのネイバーパスのうち1つだけを選択します。もう一方のパスはバックアップパスとなり、デバイスはそのトラフィックをドロップします。プライマリアップストリームパスに障害が発生すると、デバイスはバックアップパスからのトラフィックの受け入れを開始します。マルチポイントLDPデバイスは、内部ゲートウェイプロトコル(IGP)ルートデバイスのネクストホップに基づいて、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 Route Lookup in the Packet Forwarding Engine on Routers

図14:スイッチ

MoFRR IP Route Handling in the Packet Forwarding Engine on Switches

上のパケット転送エンジンにおけるMoFRR IPルート処理

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

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

図15:パケット転送エンジン MoFRR MPLS Route Lookup in the Packet Forwarding Engine

でのMoFRR MPLSルート検索

制限と注意事項

スイッチングおよびルーティングデバイスに関する MoFRR の制限と注意事項
MoFRR による PIM 付きスイッチングデバイスの制限
マルチポイント LDP を搭載したルーティングデバイスでの MoFRR の制限と注意事項

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

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

MoFRR の障害検出は、MoFRR が有効になっているルーティングデバイスの即時リンク保護に対応しており、マルチキャストトラフィックパスのすべてのリンク(エンドツーエンド)には対応していません。
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 デンスモードはサポートされていません。
バックアップトラフィックストリームのマルチキャスト統計は 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 packets や Output 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)を事前に確立するか、IP ループフリーの代替ルート(LFA)の高速再ルートバックアップパスを事前に計算します。

マルチキャストルーティングでは、トラフィック分散グラフは通常、受信者によって発信されます。これは、通常、送信元から受信者へのパスを確立するユニキャストルーティングとは異なります。マルチキャスト配信グラフを確立できるプロトコルは、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 を設定するには:

(MXシリーズおよびSRXシリーズルーターのみ)ルーターを拡張IPモードに設定します。

MoFRRを有効にします。

(オプション)MoFRR 設定に影響される制限されたマルチキャストストリームのセットをフィルターするルーティングポリシーを設定します。

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

次に例を示します。

(オプション)MoFRR 設定に影響されるマルチキャストグループのセットをフィルタリングするようにルーティングポリシーを設定した場合、MoFRR ストリーム保護にポリシーを適用します。
次に例を示します。
(オプション)MoFRR がある PIM ドメインで、MoFRR をエニーソースマルチキャスト(ASM)(*,G)に適用できます。
これは、マルチポイント LDP MoFRR ではサポートされていません。
(オプション)MoFRR がある PIM ドメインで、不連続な RPF(個別のプレーン上の RPF)のみをバックアップ RPF パスとして選択できます。
これは、マルチポイント LDP MoFRR ではサポートされていません。マルチポイント LDP MoFRR ドメインでは、同じアップストリームネイバーへのパラレルリンク間で同じラベルが共有されます。これは、各リンクがネイバーを形成するPIMドメインには当てはまりません。パスがプライマリ RPF パスと同じアップストリームネイバーに移動する場合、 mofrr-disjoint-upstream-only ステートメントはバックアップ RPF パスを選択できません。これにより、MoFRR が、複数の RPF アップストリームネイバーを持つトポロジーでのみトリガーされます。
(オプション)MoFRR がある PIM ドメインで、バックアップパスでの参加メッセージの送信を防止しますが、その他の MoFRR 機能をすべて維持します。
これは、マルチポイント LDP MoFRR ではサポートされていません。
(オプション)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で破棄されます。プライマリパスに障害が発生した場合、バックアップストリームが受け入れられます。

要件
概要
CLIクイックコンフィグレーション
設定
検証

要件

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

マルチポイント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 MoFRR in a Multipoint LDP Domain

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

「構成」セクションでは、デバイスR3の手順について説明します。

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

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

デバイスsrc1

デバイスsrc2

デバイスR1

デバイスR2

デバイスR3

デバイスR4

デバイスR5

デバイスR6

デバイスR7

デバイスR8

設定

手順

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

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

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

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

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

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

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

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

PIMを設定します。

LDPを設定します。

IGPまたはスタティックルートを設定します。

内部BGPを設定します。

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

MoFRRを有効にします。

結果

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

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

検証

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

LDPポイントツーマルチポイント転送等価クラスの確認
ラベル情報の検証
マルチキャストルートの確認
LDPポイントツーマルチポイントのトラフィック統計の確認

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

目的
アクション
意味

目的

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

アクション

意味

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

ラベル情報の検証

目的
アクション
意味

目的

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

アクション

意味

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

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

目的
アクション
意味

目的

IPマルチキャスト転送テーブルを調べて、プライマリインターフェイスとバックアップインターフェイスを含むアップストリームRPFインターフェイスリストがあることを確認します。

アクション

意味

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

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

目的
アクション
意味

目的

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

アクション

意味

出力には、ラベル付きのプライマリルートとバックアップルートの両方が表示されます。

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

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

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

要件
概要
設定
検証

要件

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

M Series ルーター
Junos OS 12.2

概要

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

設定

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

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

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

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

ダウンストリームオンデマンドポリシー(この例ではDOD-Request-Loopbacks )を設定します。

このポリシーにより、ルーターは、 DOD-Request-Loopbacks ポリシーに一致するFECにのみラベルリクエストメッセージを転送します。

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

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

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

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

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

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

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

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

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

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

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

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

ネイバー10.1.1.1、10.2.2.2、10.3.3.3にルートを転送しないようにdo-not-propagate-du-sessionsポリシーを設定します。

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

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

結果

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

検証

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

目的
アクション

目的

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

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

アクション

show ldp sessionおよびshow ldp session detailコマンドを発行します。

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

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

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

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

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

LDPネイティブIPv6サポートを設定するには、次の手順を実行する必要があります。

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

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

IPv4とIPv6の両方が有効になっている場合に、TCP接続の優先トランスポートを選択するように transport-preference ステートメントを設定します。デフォルトでは、IPv6 は LDP 接続を確立するための TCP トランスポートとして使用されます。
(オプション)デュアルトランスポートを設定して、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 リリース 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-id と inet6-lsr-id は、IPv4およびIPv6 TCPトランスポートでLDPセッションを確立するために設定する必要がある2つのLSR IDです。これらの 2 つの ID はゼロ以外である必要があり、異なる値で設定する必要があります。

トポロジー

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

図17:LDPネイティブIPv6サポート Simple network topology with routers R1 and R2 connected via point-to-point link. R1 has interface ge-1/0/0 with IPs 192.168.12.1/24 and 2001:db8:0:12::/64. R2 has interface ge-1/0/1 with IPs 192.168.12.2/24 and 2001:db8:0:12::/64. Both routers have loopback interfaces with unique IPv4 and IPv6 addresses. Label g043404 near the connection.

Simple network topology with routers R1 and R2 connected via point-to-point link. R1 has interface ge-1/0/0 with IPs 192.168.12.1/24 and 2001:db8:0:12::/64. R2 has interface ge-1/0/1 with IPs 192.168.12.2/24 and 2001:db8:0:12::/64. Both routers have loopback interfaces with unique IPv4 and IPv6 addresses. Label g043404 near the connection.

例

設定

CLIクイックコンフィグレーション
R1の設定
transport-preferenceを設定して優先トランスポートを選択します
IPv4ネイバーとのIPv4およびIPv6ネイバーとのIPv6の個別のセッションを確立するようにデュアルトランスポートを設定します。

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

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

R1

R2

R1の設定

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

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

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

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

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

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

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

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

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

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

結果

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

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

CLIクイックコンフィグレーション
ステップバイステップの手順
結果

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

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

IPv4とIPv6の両方が有効になっている場合に、TCP接続の優先トランスポートを選択するように transport-preference ステートメントを設定できます。デフォルトでは、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テーブル内のルートエントリーの検証
inet.3テーブル内のルートエントリーの検証
inet6.3テーブル内のルートエントリーの検証
LDP データベースの検証
LDP ネイバー情報の検証
LDP セッション情報の検証

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 neighbor および show ldp neighbor extensive コマンドを実行して、LDPネイバー情報を表示します。

意味

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

LDP セッション情報の検証

目的
アクション
意味

目的

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

アクション

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

意味

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

検証

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

LDP ネイバー情報の検証
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 セッション情報の検証

LDP ネイバー情報の検証

目的
アクション
意味

目的

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

アクション

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

意味

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

LDP セッション情報の検証

目的
アクション

目的

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

アクション

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

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

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

ポイントツーマルチポイント LSP のマルチポイント LDP インバンドシグナリングの理解

インバンドシグナリングによるポイントツーマルチポイントラベルスイッチパス(LSP)用のマルチポイントラベル配布プロトコル(M-LDP)は、IPTVなど、マルチキャストトラフィックを伝送する必要がある既存のIP/MPLSバックボーンで導入する場合に役立ちます。

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

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

そのために、サービスプロバイダは、既存の導入の拡張を活用して、マルチキャストトラフィックを通過させることに関心を持っています。IP/MPLS用の既存のマルチキャスト拡張は、RSVP-TE用のポイントツーマルチポイント拡張と、LDP用のポイントツーマルチポイントおよびマルチポイントツーマルチポイント拡張です。これらの導入シナリオについては、RFC 6826、ポイントツーマルチポイントおよびマルチポイントツーマルチポイントのラベルスイッチパス向けのマルチポイントLDPインバンドシグナリングで説明しています。この機能の概要は、LDP のポイントツーマルチポイント拡張に限定されています。

M-LDPの仕組み
用語
イングレス参加変換と疑似インターフェイス処理
イングレススプライシング
リバースパスフォワーディング
LSPルート検出
エグレスジョイン変換と疑似インターフェイス処理
Egressスプライシング
サポートされている機能
サポートされていない機能
LDP機能
Egress LER機能
トランジット LSR 機能
Ingress LER機能

M-LDPの仕組み

M-LDPシグナリングにおけるラベルバインディング
PIM フリー MPLS コアの M-LDP
PIM 対応 MPLS コアの M-LDP

M-LDPシグナリングにおけるラベルバインディング

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

図18:M-LDPシグナル伝達 Network diagram showing MPLS label flow: PE routers PE1, PE2, PE3 connect to MPLS backbone. P routers swap labels to route traffic. Red arrows indicate label mapping.

Network diagram showing MPLS label flow: PE routers PE1, PE2, PE3 connect to MPLS backbone. P routers swap labels to route traffic. Red arrows indicate label mapping.

におけるラベル結合

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コア Network diagram of a PIM-Free MPLS Domain with Sites A B and C. Dashed lines for IP multicast links and solid lines for MPLS multicast links. Core Site C is PIM-free.

Network diagram of a PIM-Free MPLS Domain with Sites A B and C. Dashed lines for IP multicast links and solid lines for MPLS multicast links. Core Site C is PIM-free.

におけるサンプル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 は、図19と同様のM-LDPトポロジーを示していますが、シナリオは異なります。コアはPIMで有効になっており、1つのソースですべてのIPTVチャンネルをストリーミングしています。TVチャンネルはASMストリームとして送信され、各チャンネルはグループアドレスで識別されます。以前は、これらのチャネルはコア上でIPストリームとしてストリーミングされ、PIMを使用してシグナリングされていました。

図20:PIM対応MPLSコア

Network diagram showing multicast setup across three sites: Site A with router A1, Site C with routers C1-C4 as PIM MPLS domain, and Site B with routers B2-B3. Site A and B connect to Site C via IP multicast links. Multicast sources and receivers: Sa, 1 and Ra, 1 at Site A; Sb, 1 and Rb, 2 at Site B. Uses mLDP and PIM for multicast routing, IS-IS/OSPF for protocols, and IBGP for MPLS domain routing.

におけるM-LDPトポロジーの例

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

設定

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

注:

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

次に例を示します。

注:

上記の設定の制限の一部を以下に示します。

selected-mldp-egressステートメントは、LER上でのみ設定する必要があります。非エグレスPIMルーターでselected-mldp-egressステートメントを設定すると、パス設定に失敗することがあります。
PIMアップストリームからM-LDPアップストリームへ、またはその逆にトラフィックを切り替えるポリシー変更が行われた場合、コントロールプレーンでブレークアンドメークメカニズムが実行されるため、パケットロスが予想される可能性があります。

用語

以下の用語は、マルチキャストトラフィックの M-LDP 帯域内シグナリングを理解するために重要です。

Point-to-point LSP	1 つのイングレスラベルスイッチルーター(LSR)と 1 つのエグレス LSR を持つ LSP。
Multipoint LSP	ポイントツーマルチポイントまたはマルチポイントツーマルチポイントLSPのいずれか。
Point-to-multipoint LSP	1 つのイングレス LSR と 1 つ以上のエグレス LSR を持つ LSP。
Multipoint-to-point LSP	1つ以上のイングレスLSRと1つの固有のエグレスLSRを持つLSP。
Multipoint-to-multipoint LSP	LSP 内の任意のノードから送信されたトラフィックが他のすべてのノードに配信されるように、一連のノードを接続する LSP。
Ingress LSR	特定の LSP のイングレス LSR は、LSP に沿ってデータパケットを送信できる LSR です。マルチポイントツーマルチポイント LSP は、複数のイングレス LSR を持つことができます。ポイントツーマルチポイント LSP は 1 つしかなく、そのノードはしばしばルートノードと呼ばれます。
Egress LSR	特定の LSP のエグレス LSR は、さらに処理するためにその LSP からデータパケットを削除できる LSR です。ポイントツーポイントおよびマルチポイントツーポイントLSPには、エグレスノードが1つしかありません。ポイントツーマルチポイントおよびマルチポイントツーマルチポイント LSP は、複数のエグレスノードを持つことができます。
Transit LSR	直接接続されたアップストリーム LSR と 1 つ以上の直接接続されたダウンストリーム LSR を介してマルチポイント LSP のルートに到達可能な LSR。
Bud LSR	エグレスでありながら、1つ以上の直接接続されたダウンストリームLSRを持つLSR。
Leaf node	ポイントツーマルチポイントLSPのコンテキストにおけるエグレスまたはバッド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シグナリングのパラメーターです。

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

既存の静的設定で送信元アドレスが指定されている場合、ルートは設定で指定されたとおりに取られます。
ルックアップは、ユニキャストルーティングテーブルで実行されます。送信元アドレスが見つかった場合、送信元に向かうプロトコルネクストホップが 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以降、ルートアドレスがMPLS LSP上でさらに再帰的に解決されるBGPルートの場合、M-LDPはASBR、トランジット、またはegressでポイントツーマルチポイントLSPをシグナリングできます。

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

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

Egressスプライシング

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

サポートされている機能

M-LDPインバンドシグナリングでは、Junos OSは以下の機能をサポートしています。

PIMネクストホップのLDPルートによるエグレススプライシング
PIMルートとLDPネクストホップのイングレススプライシング
PIMジョインメッセージのLDPポイントツーマルチポイントLSP設定パラメータへの変換
PIM ジョインメッセージを設定するための M-LDP インバンド LSP パラメーターの変換
静的に設定されたBGPプロトコルのネクストホップベースのLSPルート検出
PIMのソース固有マルチキャスト(SSM)およびすべてのソースマルチキャスト(ASM)の範囲に含まれるPIM(S、G)の状態
エッジルーターとして機能できるようにするためのイングレスおよびエグレスLERの設定ステートメント
LER上のIGMPジョインメッセージ
IPv6送信元アドレスとグループアドレスを不透明な情報としてIPv4ルートノードに送信
IPv6(S,G)をIPv4ルートアドレスにマッピングするための静的構成

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

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

PIM ASMの完全サポート
(S,G)オプション付き mpls lsp point-to-multipoint ping コマンド
ノンストップアクティブルーティング (NSR)
PIM の Make-Before-Break(MBB)
IPv6 LSP ルートアドレス(LDP は IPv6 LSP をサポートしていません)。
直接接続されていないPIMスピーカー間の近隣関係
グレースフルリスタート
PIM デンスモード
PIM双方向モード

LDP機能

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

Egress LER機能

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

ルートノード
(S、G)
ネクストホップ

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

LDP は、ルートノードに基づいてアップストリームノードを検索し、ラベルを割り当てて、ラベルマッピングをアップストリームノードに送信します。LDPは、インバンドM-LDPシグナリングに最後から2番目のホップポッピング(PHP)を使用しません。

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

トランジット LSR 機能

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

Ingress LER機能

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

(S、G)
フラッドネクストホップ

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

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

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

要件
概要
設定
検証

要件

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

Junos OSリリース13.2以降
MXシリーズ 5Gユニバーサルルーティングプラットフォーム、プロバイダエッジ(PE)ルーター用のM Seriesマルチサービスエッジルーター
トランジットラベルスイッチルーターとして機能するPTXシリーズパケットトランスポートルーター
コアルーター用のT Seriesコアルーター

注:

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

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

概要

CLIクイックコンフィグレーションは、図21に示すすべてのデバイスのコンフィギュレーションを示しています。セクション #d372e68__d372e836 では、デバイスEgressPEの手順を説明しています。

図21:ポイントツーマルチポイントLSP向けM-LDPインバンドシグナリングトポロジー Multicast network diagram with nodes: src1 10.1.1.7/32 to IngressPE 10.1.1.2/32, Transit p6 10.1.1.6/32, EgressPE 10.1.1.1/32 to Receiver 192.168.215.11/28 via interfaces. Nodes pr3, pr4, pr5 and cloud networks shown.

Multicast network diagram with nodes: src1 10.1.1.7/32 to IngressPE 10.1.1.2/32, Transit p6 10.1.1.6/32, EgressPE 10.1.1.1/32 to Receiver 192.168.215.11/28 via interfaces. Nodes pr3, pr4, pr5 and cloud networks shown.

例

設定

手順

CLIクイックコンフィグレーション
ステップバイステップの手順
結果

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

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

デバイスsrc1

デバイスIngressPE

デバイスエグレスPE

デバイスp6

デバイスpr3

デバイスpr4

デバイスpr5

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

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

Device EgressPEを設定するには:

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

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

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

テスト用に、この例では静的なグループアドレスと送信元アドレスを含めています。

コアに面するインターフェイスで MPLS を設定します。

BGPを設定します。

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

例えば、スタティックルートをBGPにエクスポートすることができます。
(オプション)異なる PIM ドメインを相互接続して冗長 RP を有効にするために、デバイス pr5 との MSDP ピア接続を設定します。

OSPFを設定します。

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

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

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

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

M-LDPの帯域内シグナリングを有効にし、関連するポリシーを設定します。

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

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

結果

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

デバイスエグレスPE

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

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

検証

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

PIM の参加状態の確認
PIM ソースのチェック
LDP データベースの確認
MPLSラベルのルート情報を検索する
LDP トラフィック統計の確認

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コマンドに、予期されるルートツー(S,G)バインディングが表示されていることを確認します。

アクション

MPLSラベルのルート情報を検索する

目的
アクション

目的

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

アクション

LDP トラフィック統計の確認

目的
アクション

目的

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

アクション

LDPへのセグメントルーティング相互運用性のためのクライアントとサーバーのマッピング

セグメントルーティングマッピングサーバーとクライアントのサポートにより、LDPおよびセグメントルーティング(SRまたはSPRING)を実行するネットワークアイランド間での相互運用性が可能になります。この相互運用性は、LDPからSRへの移行時に役立ちます。移行中に、LDPのみまたはセグメントルーティングのみをサポートするデバイスを持つ島(またはドメイン)が存在する可能性があります。これらのデバイスを相互運用するためには、LDP セグメントルーティングマッピングサーバー(SRMS)とセグメントルーティングマッピングクライアント(SRMC)機能が必要です。これらのサーバーおよびクライアント機能は、セグメントルーティングネットワーク内のデバイスで有効にします。

SRマッピングサーバーとクライアント機能は、OSPFまたはIS-ISのいずれかでサポートされています。

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

LDPへのセグメントルーティング相互運用性の概要

図 22 は、セグメントルーティングデバイスと LDP デバイスの相互運用性がどのように行われるかを説明するためのシンプルな LDP ネットワークトポロジーを示しています。OSPFとIS-ISの両方がサポートされているので、今のところ、IGPに関しては依存関係がないことに留意してください。サンプルトポロジーには、LDPからセグメントルーティングへの移行を行っているネットワークにR1からR6の6つのデバイスがあります。

このトポロジーでは、デバイスR1、R2、R3はセグメントルーティング用にのみ設定されています。デバイスR5およびR6はレガシーLDPドメインの一部であり、現在SRをサポートしていません。デバイスR4はLDPとセグメントルーティングの両方をサポートしています。すべてのデバイスのループバックアドレスが表示されます。これらのループバックは、LDPドメインではegress FECとして、またSRドメインではSRノードIDとしてアドバタイズされます。相互運用性は、LDP FECをSRノードIDに、またSRノードIDにLDP FEDをマッピングすることに基づいています。

図22:LDPへの相互運用性トポロジー Network topology with six routers R1 to R6. R1-R3: Segment Routing. R3-R5: LDP/Segment Routing. R5-R6: LDP.

へのセグメントルーティング例

R1がR6と相互作用するためには、LDPセグメントルーティングマッピングサーバー(SRMS)とセグメントルーティングマッピングクライアント(SRMC)の両方が必要です。トラフィックフローを一方向に見た方が、SRMSとSRMCの役割は理解しやすいでしょう。図22に基づくと、左から右にトラフィックフローはSRドメインで発生し、LDPドメインで終了することになります。同様に、右から左に流れるトラフィックは、LDPドメインで発生し、SRドメインで終了します。

SRMSは、トラフィックを左から右方向にステッチするのに必要な情報を提供します。SRMCは、右から左に流れるトラフィックのマッピングを提供します。

左から右へのトラフィックフロー:セグメントルーティングマッピングサーバー
SRMSは、SRドメインとLDPドメイン間のLSPステッチを容易にします。サーバーは、LDP FECをSRノードIDにマッピングします。LDP FECを [edit routing-options source-packet-routing] 階層レベルでマッピングするように設定します。通常、完全接続するには、すべてのLDPノードループバックアドレスをマッピングする必要があります。以下に示すように、単一のレンジステートメントで連続プレフィクスをマッピングできます。LDPノードループバックが連続しない場合は、複数のマッピングステートメントを定義する必要があります。

SRMSマッピング設定は、 [edit protocols ospf] または [edit protocols isis] 階層レベルで適用します。この選択は、どの IGP が使用されているかによって異なります。SRノードとLDPノードの両方が、共通のシングルエリア/レベル、IGPルーティングドメインを共有することに注意してください。

SRMSは、拡張プレフィックスリストLSA(あるいはIS-ISの場合はLSP)を生成します。このLSAの情報により、SRノードはLDPプレフィックス(FEC)をSRノードIDにマッピングできます。LDPプレフィックス用のマッピングされたルートは、SRノードの inet.3 および mpls.0 ルーティングテーブルにインストールされ、左から右方向のトラフィックのLSP ingressとステッチ操作を容易にします。

拡張LSA(またはLSP)は、(単一の)IGPエリア全体にフラッドされます。つまり、SRドメインのどのルーターにでも自由にSRMS設定を配置できます。SRMSノードは、LDPを実行する必要はありません。
右から左のトラフィックフロー:セグメントルーティングマッピングクライアント
右から左方向、つまり、LDPアイランドからSRアイランドへ相互運用するには、SRとLDPの両方と対話するノードでセグメントルーティングマッピングクライアント機能を有効にするだけです。この例では、R4です。SRMC機能を有効にするには、[edit protocols ldp]階層のmapping-clientステートメントを使用します。

SRMC設定は、自動的にLDP egressポリシーを有効にし、SRドメインのノードとプレフィックスSIDをLDP egress FECとしてアドバタイズします。これにより、LDP ノードから SR ドメインのノードへの LSP 到達可能性が提供されます。
SRMC機能は、SRドメインとLSPドメインの両方に接続するルーターで設定する必要があります。必要に応じて、同じノードをSRMSとして機能させることもできます。

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

図22を参照し、デバイスR2(セグメントルーティングネットワーク内)がSRMSであると仮定します。

SRMS機能を定義します。
この設定は、サンプルトポロジー内の両方のLDPデバイスループバックアドレスのマッピングブロックを作成します。R5のループバックにマッピングされた最初のセグメントID(SID)インデックスは 1000です。サイズ 2 を指定すると、SIDインデックス10001がR6のループバックアドレスにマッピングされます。
注:
start-prefixとして使用されるIPアドレスは、LDPネットワーク内のデバイスのループバックアドレスです(この例ではR5)。完全接続するには、LDPルーターのすべてのループバックアドレスをSRドメインにマッピングする必要があります。ループバックアドレスが連続している場合は、1つのprefix-segment-rangeステートメントでこれを行うことができます。連続していないループバックでは、複数のプレフィックスマッピングステートメントを定義する必要があります。

この例では連続したループバックを使用しているため、1つの prefix-segment-range を上記に示します。ここでは、連続していないループバックアドレスを持つ2つのLDPノードのケースをサポートするための複数マッピングの例を示します。
次に、マッピングされたプレフィックスをフラッディングするのに使用される拡張LSAのOSPFサポートを設定します。
デバイスR2でマッピングサーバー設定がコミットされると、拡張プレフィックス範囲TLVがOSPFエリア全体にフラッディングされます。セグメントルーティング(R1、R2、R3)が可能なデバイスは、セグメントID(SID)インデックスで指定されたループバックアドレス(この例ではR5とR6)のOSPFセグメントルーティングルートをインストールします。SIDインデックスは、セグメントルーティングデバイスによって mpls.0 ルーティングテーブルでも更新されます。
SRMC機能を有効にします。サンプルトポロジーでは、R4でSRMC機能を有効にする必要があります。
デバイスR4でマッピングクライアント設定がコミットされると、SRノードIDとラベルブロックはエグレスFECとしてルーターR5にアドバタイズされ、次にR6に再アドバタイズされます。

Junos OS 19.1R1で、OSPFによるセグメントルーティングとLDPネクストホップのステッチのサポートが開始されました。

Unsupported Features and Functionality for Segment Routing interoperability with LDP using OSPF

IPv6 プレフィックスはサポートされていません。
AS境界をまたぐOSPF拡張プレフィックス不透明LSAのフラッディング(AS間)はサポートされていません。
エリア間LDPマッピングサーバー機能はサポートされていません。
拡張プレフィックスOpaque LSAのABR機能はサポートされていません。
拡張プレフィックスOpaque LSAのASBR機能はサポートされていません。
セグメントルーティングマッピングサーバー優先度 TLV はサポートされていません。

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

図22を参照し、デバイスR2(セグメントルーティングネットワーク内)がSRMSであると仮定します。マッピング機能に以下の設定が追加されます。

SRMS機能を定義します。
この設定は、サンプルトポロジー内の両方のLDPデバイスループバックアドレスのマッピングブロックを作成します。R5のループバックにマッピングされた最初のセグメントID(SID)インデックスは 1000です。サイズ 2 を指定すると、SIDインデックス10001がR6のループバックアドレスにマッピングされます。
注:
start-prefixとして使用されるIPアドレスは、LDPネットワーク内のデバイスのループバックアドレスです(この例ではR5)。完全接続するには、LDPルーターのすべてのループバックアドレスをSRドメインにマッピングする必要があります。ループバックアドレスが連続している場合は、prefix-segment-rangeステートメントでこれを行うことができます。連続していないループバックでは、複数のマッピングステートメントを定義する必要があります。

この例では連続したループバックを使用しているため、1つの prefix-segment-range を上記に示します。ここでは、連続していないループバックアドレスを持つ2つのLDPルーターのケースを処理するためのプレフィックスマッピングの例を示します。
次に、マッピングされたプレフィックスをフラッディングするために使用される拡張LSPのIS-ISサポートを設定します。
デバイスR2でマッピングサーバー設定がコミットされると、拡張プレフィックス範囲TLVがOSPFエリア全体にフラッディングされます。セグメントルーティングが可能なデバイス(R1、R2、R3)は、セグメントID(SID)インデックスを使用して、指定されたループバックアドレス(この例ではR5とR6)のIS-ISセグメントルーティングルートをインストールします。SIDインデックスは、セグメントルーティングデバイスによって mpls.0 ルーティングテーブルでも更新されます。
SRMC機能を有効にします。サンプルトポロジーでは、R4でSRMC機能を有効にする必要があります。
デバイスR4でマッピングクライアント設定がコミットされると、SRノードIDとラベルブロックはエグレスFECとしてルーターR5にアドバタイズされ、そこからR6にアドバタイズされます。

Junos OS 17.4R1で、IS-ISでのセグメントルーティングとLDPネクストホップのステッチのサポートが開始されました。

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

ラベルバインディングTLVの最後から2番目のホップポッピング動作はサポートされていません。
ラベルバインディングTLVのプレフィックス範囲のアドバタイズはサポートされていません。
セグメントルーティングの競合解決はサポートされていません。
LDPトラフィック統計は機能しません。
NSR(ノンストップアクティブルーティング)とGRES(グレースフルルーティングエンジンスイッチオーバー)はサポートされていません。
IS-IS 階層間はサポートされていません。
RFC 7794、拡張IPv4のIS-ISプレフィックス属性はサポートされていません。
ステッチノードでのプレフィックスSIDとしてのLDPルートの再配布はサポートされていません。

その他のLDPプロパティ

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

IGPルートメトリックを使用するようにLDPを設定する
inet.0ルーティングテーブルへのイングレスルートの追加防止
複数インスタンスLDPおよびキャリアオブキャリアVPN
最終ホップルーターでラベルをポップするようにMPLSおよびLDPを設定します
RSVPが確立したLSP上でLDPの有効化
ヘテロジニアスネットワークでRSVPが確立したLSP上でLDPの有効化
LDPセッションのTCP MD5シグネチャの設定
LDPセッション保護の設定
LDPのSNMPトラップの無効化
LDPリンク上のIGPとのLDP同期の設定
ルーターの IGP との LDP 同期の設定
ラベル取消タイマーの設定
LDPサブネットチェックの無視

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

デフォルトのLDPルートメトリック(デフォルトのLDPルートメトリックは1)ではなく、interior gateway protocol(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ステートメントを有効にした場合でも、ingressルートが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がアドバタイズされると、最後から2番目のホップルーターはラベルを削除し、パケットをegressルーターに送信します。最終ホップのポッピングが有効になっている場合、ラベル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を設定する必要があります。

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

注:

LDPは、リンク保護が有効なRSVPセッションをトンネルできます。Junos OSリリース21.1R1以降、LDPトンネルルートに関する詳細を表示すると、プライマリおよびバイパスLSPネクストホップの両方が表示されます。以前の Junos OS リリースでは、バイパス LSP ネクストホップはプライマリ LSP のネクストホップを表示します。

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

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

ジュニパーネットワークスルーターがRSVPトンネルを介して別のベンダーのルーターにリンクされ、LDPトンネリングも有効になっている場合、RSVPパスに物理OSPFパスよりも1大きいメトリックがある場合、ジュニパーネットワークスルーターはデフォルトでRSVPトンネルを使用して他のベンダーのegressルーターの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セグメントの導入を防止することができます。TCP認証の詳細については、 TCPを参照してください。TCP MD5ではなくTCP認証オプション(TCP-AO)の使用方法については、 TCP認証オプション(TCP-AO)を参照してください。

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

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

LDPセッションのハッシュメッセージ認証コード(HMAC)およびMD5認証は、セッションごとの構成またはサブネットマッチ(つまり最長プレフィックスマッチ)構成として構成できます。サブネット一致認証のサポートにより、自動ターゲットLDP(TLDP)セッションの認証を柔軟に設定できます。これにより、リモートループフリー代替(LFA)およびFEC 129疑似ワイヤの導入が容易になります。

LDP TCP接続にMD5シグネチャを設定するには、セッショングループの一部として authentication-key ステートメントを含めます。

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

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

また、LDPルーティングプロトコルに認証キー更新メカニズムを設定することもできます。このメカニズムにより、OSPF(Open Shortest Path First)やRSVP(Resource Reservation Setup Protocol)などの関連するルーティングやシグナリングプロトコルを中断することなく、認証キーを更新できます。

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

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

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

LDPセッション保護の設定

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

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

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

LDPのSNMPトラップの無効化

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

LDP SNMPトラップおよび独自のLDP MIBについては、 SNMP MIBエクスプローラーを参照してください。

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のラベルはすべてのアップストリームルーターから取り消されます。

デフォルトでは、LDP はラベルを取り消す前に 60 秒待機してからラベルを取り消すため、IGP が再収束している間に何度も LSP を再シグナリングしないようにします。ラベル取消の遅延時間を秒単位で設定するには、 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 統計出力
最後から 2 番目のホップルーターでの LDP 統計の無効化
LDP 統計の制限

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プロトコルトラフィックのトレース
FEC 内で 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—アドレス、アドレス取り消し、初期化、ラベル要求、ラベルマップ、ラベル取り消し、ラベルリリース、通知、および周期メッセージの動作をトレースします。この修飾子は、 address、 initialization、 label、 notification、および 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 プロトコルのトラフィックをトレースしたり、トラブルシューティングしたりする場合に便利です。この目的には、 route、 path、 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 プロトコルトラフィックをトレースします。

このページの内容

LDP の設定

最小 LDP 設定

LDPの有効化および無効化

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

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

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

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

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

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

LDPの厳密なターゲットhelloメッセージの有効化

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

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

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

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

要件

概要

トポロジー

設定

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

デバイスR0の設定

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

結果

検証

ルートの検証

目的

アクション

意味

LDPの概要情報の検証

目的

アクション

意味

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

目的

アクション

意味

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

目的

アクション

意味

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

目的

アクション

意味

LDPルート設定の構成

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

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

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

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

再接続時間の設定

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

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

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

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

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

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

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

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

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

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

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

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

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

FEC Deaggregationの設定

LDP FEC のポリシーの設定

LDP IPv4 FECフィルタリングの設定

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

LDP LSP 向け ECMP-Aware BFD の設定

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

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

LDPリンク保護の設定

例:LDPリンク保護の設定

LDPリンク保護の概要

LDPの概要

Junos OS LDP プロトコルの実装

LDPへのマルチポイント拡張を理解する

ターゲット LDP セッションでの LDP へのマルチポイント拡張の使用

LDPリンク保護の現在の制限

RSVP LSPをソリューションとして使用

手動設定されたRSVP LSP

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

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

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

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

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