Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

LDP の設定

最小 LDP 設定

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

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

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

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

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

すべてのインターフェイスで LDP を有効にするには、interface-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 タイマーの設定

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

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

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

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

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

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

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

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要件

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

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

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

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

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

  • OSPFを設定します。

概要

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

トポロジー

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

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

設定

CLIクイック構成

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

R0

R1

R2

R3

R4

R5

デバイス R0 の設定

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

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

Device R0を設定するには：

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

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

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

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

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

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

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

結果

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

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

検証

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

ルートの検証

目的

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

アクション

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

意味

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

LDPの概要情報の検証

目的

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

アクション

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

意味

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

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

目的

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

アクション

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

意味

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

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

目的

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

アクション

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

意味

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

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

目的

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

アクション

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

意味

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

LDPルート設定の構成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [edit routing-options]

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

再接続時間の設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

from オペレーター

説明

interface

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

neighbor

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

next-hop

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

route-filter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

to演算子

説明

interface

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

neighbor

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

next-hop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • show ldp session

  • show ldp neighbor

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

  • show configuration protocols ldp

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

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

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

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

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

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

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

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

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

注:

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

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

注:

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

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

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

FEC Deaggregationの設定

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

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

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

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

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

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

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

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

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

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

LDP FEC のポリシーの設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LDP IPv4 FECフィルターの設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [edit protocols ldp]

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

LDP LSP 向け ECMP-Aware BFD 設定

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

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

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

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

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

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

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

注:

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

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

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

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

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

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

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

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

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

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

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

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

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

注:

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

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

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

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

MoFRR の概要

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

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

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

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

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

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

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

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

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

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

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

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

PIM 機能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マルチポイント LDP 機能

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

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

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

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

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

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

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

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

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

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

パケット転送

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

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

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

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

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

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

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

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

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

制限と注意事項

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • マルチキャスト トラフィックを転送する際のパケット レプリケーションやマルチキャストルックアップにより、パケットが PFE を何度も再循環することがあります。そのため、show pfe statistics traffic コマンドで表示されるマルチキャスト パケット数の値は、Input 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（ラベル スイッチ パス）を事前に確立するか、LFA（IP ループフリーの代替ルート）の高速再ルート バックアップ パスを事前に計算し、ダウンストリーム パスのセグメントの障害に対処します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要件

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

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

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

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

概要

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

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

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

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

トポロジー

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

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

CLIクイック構成は、図 16でのすべてのデバイスの設定を示しています。

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

CLIクイック構成

CLIクイック構成

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

デバイスsrc1

デバイスsrc2

デバイスR1

デバイスR2

デバイスR3

デバイス R4

デバイス R5

デバイス R6

デバイス R7

デバイス R8

設定

手順

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

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

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

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

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

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

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

  5. PIMを設定します。

  6. LDP を設定します。

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

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

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

  10. MoFRRを有効にします。

結果

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

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

検証

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

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

目的

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

アクション
意味

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

ラベル情報の検証

目的

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

アクション
意味

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

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

目的

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

アクション
意味

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

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

目的

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

アクション
意味

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

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

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

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

要件

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

  • M シリーズルーター

  • Junos OS 12.2

概要

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

設定

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結果

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

検証

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

目的

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

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

アクション

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

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

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

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

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

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

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

要件

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

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

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

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

概要

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

トポロジー

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

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

設定

CLIクイック構成

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

R1

R2

R1の設定

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

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

Device R1を設定するには：

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

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

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

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

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

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

結果

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

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

CLIクイック構成
ステップバイステップでの手順

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

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

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

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

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

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

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

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

結果

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

検証

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

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

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

アクション

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

意味

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

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

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

アクション

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

意味

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

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

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

アクション

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

意味

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

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

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

アクション

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

意味

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

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

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

アクション

デバイスR1で、運用モードからshow ldp 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 ネイバー情報を表示します。

アクション

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

意味

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

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

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

アクション

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

意味

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

検証

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

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

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

アクション

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

意味

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

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

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

アクション

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

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

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

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

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

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

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

M-LDPの仕組み

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

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

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

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

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

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

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

PIM 対応 MPLS コアの M-LDP

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

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

このシナリオで mldp-inband-signaling を設定することにより、送信元に PIM ネイバーがない場合にのみ M-LDP シグナリングが開始されます。しかし、エグレス 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 シグナリングのパラメータです。

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

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

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

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

    このようなセグメント化されていないポイントツーマルチポイント LSP は、複数の自律システムにまたがってシグナリングする必要があり、これは以下の用途に使用できます。

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

    • MPLSコアネットワークによって接続されたクライアントネットワーク間のAS間MLDPインバンドシグナリングです。

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

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

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

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

エグレススプライシング

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

サポートされている機能

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

  • LDP ルートによる PIM ネクスト ホップのエグレス スプライシング

  • LDP ネクスト ホップとの PIM ルートのイングレス スプライシング

  • PIM ジョイン メッセージの LDP ポイントツーマルチポイント LSP 設定パラメータへの変換

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

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

  • PIMのソース固有マルチキャスト（SSM）およびすべてのソースマルチキャスト（ASM）の範囲に含まれるPIM（S、G）の状態

  • イングレス LER とエグレス 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 の事前対応(MBB)

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

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

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

  • PIM デンス モード

  • PIM 双方向モード

LDP 機能

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

エグレス LER 機能

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

  • ルート ノード

  • (S,G)

  • ネクスト ホップ

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

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

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

トランジットLSR機能

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

イングレス LER 機能

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

  • (S,G)

  • フラッディング ネクスト ホップ

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

関連項目

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

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

要件

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

  • Junos OS リリース 13.2 以降

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

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

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

注:

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

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

概要

CLIクイック構成は、図 21でのすべてのデバイスの設定を示しています。セクション #d358e63__d358e831 では、デバイス EgressPE の手順について説明します。

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

設定

手順
CLIクイック構成

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

デバイスsrc1

デバイスイングレスPE

デバイスEgressPE

デバイスp6

デバイスpr3

デバイスpr4

デバイスpr5

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

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

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

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

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

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

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

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

  4. BGP を設定します。

    BGPはポリシー主導のプロトコルであるため、必要なルーティングポリシーの設定と適用も行います。

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

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

  6. OSPFを設定します。

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

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

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

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

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

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

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

結果

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

デバイスEgressPE

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

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

検証

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

PIM の参加状態の確認
目的

PIM の参加状態に関する情報を表示して、M-LDP のインバンド アップストリームおよびダウンストリームの詳細を確認します。イングレス デバイスでは、 show pim join extensive コマンドはダウンストリーム インターフェイスの Pseudo-MLDP を表示します。エグレスでは、 show pim join extensive コマンドはアップストリーム インターフェイスの Pseudo-MLDP を表示します。

アクション

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

PIM ソースの確認
目的

PIM ソースに、予想される M-LDP インバンド アップストリームおよびダウンストリームの詳細が含まれていることを確認します。

アクション

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

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

show ldp database コマンドで、予期されるルートから (S,G) へのバインドが表示されていることを確認します。

アクション
MPLS ラベルのルート情報の検索
目的

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

アクション
LDP トラフィック統計の確認
目的

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

アクション

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

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

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

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

図 22は、シンプルなLDPネットワークトポロジーを示しており、セグメントルーティングデバイスのLDPデバイスとの相互運用性がどのように行われるのかを説明しています。OSPFとISISの両方がサポートされているので、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へのセグメントルーティング相互運用性トポロジーのサンプル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ノードループバックが連続しない場合は、複数のマッピングステートメントを定義する必要があります。

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

    SRMSは、拡張プレフィックスリストLSA（あるいはISISのケースでは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です。[edit protocols ldp]階層のmapping-clientステートメントでSRMC機能を有効にします。

    SRMC設定は、自動的にLDP egressポリシーを有効にし、SRドメインのノードとプレフィックスSIDをLDP egress FECとしてアドバタイズします。これにより、LSP到達可能性のあるLDPノードがSRドメインのノードに提供されます。

  • SRMC機能は、SRおよびLSPドメインの両方にアタッチされたルーターで設定する必要があります。必要に応じて、同じノードをSRMSとして機能させることもできます。

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

図 22を参照してください。（セグメントルーティングネットワーク内の）デバイスR2がSRMSにあるとします。

  1. 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ノードのケースをサポートするための複数マッピングの例を示します。

  2. 次に、マッピングされたプレフィックスをフラッディングするのに使用される拡張LSA向けのOSPFサポートを設定します。

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

  3. SRMC機能を有効にします。サンプルトポロジー用に、R4でSRMC機能を有効にする必要があります。

    デバイスR4でクライアント設定マッピングがコミットされると、SRノードIDとラベルブロックはegress FECとしてルーターR5にアドバタイズされます。そして、それらはR6に再アドバタイズされます。

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

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

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

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

  • AS境界をまたぐ（inter-AS）OSPF拡張プレフィックス不透明LSAのフラッドはサポートされていません。

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

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

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

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

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

図 22を参照してください。（セグメントルーティングネットワーク内の）デバイスR2がSRMSにあるとします。マッピング機能に次の設定が追加されます。

  1. 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ルーターのケースを処理するためのプレフィックスマッピングの例を示します。

  2. 次に、マッピングされたプレフィックスをフラッディングするのに使用される拡張LSAのためのISISサポートを設定します。

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

  3. SRMC機能を有効にします。サンプルトポロジー用に、R4でSRMC機能を有効にする必要があります。

    デバイスR4でクライアント設定マッピングがコミットされると、SRノードIDとラベルブロックはegress FECとしてルーターR5に、そして、そこからR6にアドバタイズされます。

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

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

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

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

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

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

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

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

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

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

その他の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のステートメントを有効にした場合でも、inet.3ルーティング テーブルの代わりに、inet.0ルーティング テーブルにイングレスルートを追加しないように設定できます。デフォルトでは、no-forwardingのステートメントは無効になっています。

注:

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

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

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

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

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

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

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

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

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

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

注:

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

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

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

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

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

注:

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

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

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

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

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

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

  • [edit protocols ospf traffic-engineering shortcuts]

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

注:

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

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

LDPセッション向けTCP MD5署名の構成

LDP TCP接続にMD5シグネチャを設定し、LDPセッション接続ストリームに偽装されたTCPセグメントの導入を防止することができます。TCP認証の詳細については、TCPを参照してください。TCP MD5ではなくTCP認証オプション（TCP-AO）の使用方法については、を参照してくださいNo link title。

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

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

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

LDP TCPコネクションでMD5署名を構成するには、セッショングループの一部としてステート authentication-key メントを含みます：

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

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

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

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

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

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

LDPセッション保護の設定

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

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

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

LDPのSNMPトラップの無効化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デフォルトでは、IGPが再収束している間に何度もLSPを再シグナリングしないように、ラベルを取り消す前にLDPは60秒待機します。ラベル取消の遅延時間を秒単位で設定するには、以下のステートメントlabel-withdrawal-delayをインクルードします。

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

LDPサブネットチェックの無視

Junos OSリリース8.4以降のリリースでは、ネイバー確立の手続き中にLDP送信元アドレスサブネットチェックが行われます。LDPリンクのHelloパケットの送信元アドレスをインターフェイスアドレスと照合します。これにより、一部のベンダーの機器との相互運用性の問題が生じます。

サブネットチェックを無効にするには、以下のステートメントallow-subnet-mismatchをインクルードします。

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

  • [edit protocols ldp interface interface-name]

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

注:

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

関連項目

LDP LSP トレースルートの設定

LDP シグナル LSP が続くルートをトレースできます。LDP LSP トレースルートは、RFC 4379 マルチプロトコルラベルスイッチ (MPLS) データプレーン障害を検知するに基づいています。この機能により、FEC 内のすべてのパスを定期的にトレースできます。FEC トポロジー情報は、CLI からアクセスできるデータベースに保存されます。

トポロジーを変更しても、LDP LSP のトレースが自動的にトリガーされることはありません。ただし、トレースルートは手動で開始できます。トレースルートリクエストが現在データベースにある FEC 向けの場合、データベースのコンテンツが結果とともに更新されます。

定期トレースルート機能は、 [edit protocols ldp]階層レベルで設定されたoamステートメントにより指定されたすべての FEC に適用されます。定期 LDP LSP トレースルートを設定するには、periodic-tracerouteステートメントを含めます。

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

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

periodic-tracerouteステートメントをそれ自体で、または以下のオプションのいずれかを使って設定できます。

  • exp—プローブを送信する際に使用するサービスのクラスを指定します。

  • fanout—ノードごとに検索するネクストホップの最大数を指定します。

  • frequency—トレースルート試行の間隔を指定します。

  • paths—検索するパスの最大数を指定します。

  • retries—あきらめる前に特定のノードにプローブを送信する試行回数を指定します。

  • source—プローブを送信する際に使用する IPv4 ソースアドレスを指定します。

  • ttl—TTL（Time-to-live）の最大値を指定します。この値がトレースされなくなるノード。

  • wait—プローブパケットを再送する前に、待機間隔を指定します。

LDP 統計の収集

LDP トラフィック統計は、ルーターで特定の FEC を通過したトラフィックの量を示しています。

[edit protocols ldp] 階層レベルでtraffic-statisticsステートメントを設定する場合、LDP トラフィック統計は定期的に収集され、ファイルに書き込まれています。intervalオプションを使用することで、統計を収集する頻度（秒単位）を設定することができます。デフォルトの収集間隔は 5 分です。LDP 統計ファイルを設定する必要があります。それ以外の場合、LDP トラフィック統計は収集されません。LSP がダウンした場合、LDP 統計はリセットされます。

LDPトラフィック統計を収集するには、traffic-statisticsステートメントを含みます。

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

このセクションには、以下のトピックが含まれています。

LDP 統計出力

以下のサンプル出力出力は LDP 統計ファイルからのものです。

LDP 統計ファイルには、以下のデータの列が含まれています。

  • FEC - LDP トラフィック統計を収集する FEC。

  • Type - ルーターから発信されたトラフィックのタイプ、Ingress（このルーターから発信）またはTransit（このルーターを経由して転送された）のいずれか。

  • Packets - LSP の出現以来、FEC がパスしたパケット数。

  • Bytes - LSPの出現以来、FEC がパスしたデータのバイト数。

  • Shared - Yes の値は、複数のプレフィックスが同じラベルにバインドされていることを示します（例えば、複数のプレフィックスがエグレスポリシーでアドバタイズされている場合など）。この事例での LDP トラフィック統計はすべてのプレフィックスに適用され、そのように処理する必要があります。

  • read -（日付と時刻の次に表示される）この数は、表示される実際の数とは異なる場合があります。表示される前に一部統計は概要説明されています。

最後から ２ 番目のホップ ルーターでの LDP 統計の無効化

LDP トラフィック統計を最後から ２ 番目のホップ ルーターで収集する場合、特にネクストホップ ルートにおいてリソースを過剰に消費する可能性があります。traffic-statisticsステートメントに、deaggregateステートメントを追加設定していると、この問題は悪化します。ネクストホップ ルート使用の限界に達するルーターには、traffic-statisticsステートメントのno-penultimate-hopオプションの設定を推奨します。

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

注:

no-penultimate-hopオプションを設定する場合、このルーターの最後から ２ 番目のホップである FEC は統計を利用できません。

このオプションを設定に含めたり削除するたびに、LDP セッションはダウンし再起動されます。

以下は、no-penultimate-hopオプションが設定されているルーターを示す LDP 統計ファイルの出力例です。

LDP 統計の限界

以下は、traffic-statisticsステートメントを設定することによる、LDP 統計の収集に関連する問題です。

  • LDP 統計のクリアはできません。

  • 指定された間隔を短縮する場合、統計タイマーが新しい間隔よりも遅い場合にのみ 新しいLDP 統計リクエストは発行されます。

  • 新しい LDP 統計収集の動作は以前のもものが完了するまで開始できません間隔が短い場合、または、LDP 統計の数が大きい場合は、2 つの統計収集のタイム ギャップが間隔よりも長くなることがあります。

LSP がダウンすると、LDP 統計はリセットされます。

LDP プロトコル トラフィックのトレース

次のセクションでは LDP プロトコル トラトラフィックを検証するためにトレース オプションを設定する方法について説明します

プロトコルとルーティング インスタンス レベルで LDP プロトコル トラフィックをトレース

LDP プロトコルのトラフィックをトレースするには、[edit routing-options]のグローバルtraceoptionsステートメントでオプションを指定し、traceoptionsステートメントを含めることで LDP 固有のオプションを指定することができます。

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

fileステートメントを使用してトレース動作の出力を受信するファイル名を指定しますすべてのファイルが /var/log のディレクトリに置かれます。LDPトレーシングの出力は、ファイルldp-logに置くことをお勧めします。

以下のトレース フラグは、様々な LDP メッセージの送受信に関連する動作を表示します。それぞれ、以下のような 1 つ以上の修飾子が伝送可能です。

  • address－アドレスおよびアドレス撤回メッセージの動作をトレースします。

  • binding―ラベルバインディング動作をトレースします。

  • error－エラー状態のトレースをします。

  • event―プロトコル イベントのトレースをします。

  • initialization―初期化メッセージの動作をトレースします。

  • label―ラベル リクエスト、ラベル マップ、ラベル取り消し、ラベル リリース メッセージの動作をトレースします。

  • notification―通知メッセージの動作をトレースします。

  • packets―アドレス、アドレス取り消し、初期化、ラベル リクエスト、ラベル マップ、ラベル取り消し、ラベル リリース、通知、および周期メッセージの動作をトレースします。この修飾子は、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 プロトコルのトラフィックをトレースします。

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

リリース
説明
22.4R1
Junos OS Evolved Release 22.4R1以降、IPサブネットでTCP-AOまたはTCP MD5認証を構成して、そのサブネットの下にアドレス全体を含めることができます。
22.4R1
Junos OS Evolved Release 22.4R1以降、TCP認証はVRF認識です。
19.1
Junos OSリリース19.1R1以降、セグメントルーティング-LDPボーディングルーターは、セグメントルーティングトラフィックとLDPネクストホップ間のステッチが可能です。
16.1
Junos OSリリース16.1以降、M-LDPは、ルートアドレスがMPLS LSP上でさらに再帰的に解決されるBGPルートである場合、ASBRまたはトランジットまたはエグレスでポイントツーマルチポイントLSPをシグナリングできます。
14.1
Junos OS リリース 14.1 以降、既存の IPTV サービスをネイティブ IP マルチキャストから MPLS マルチキャストに移行するには、PIM から M-LDP ポイントツーマルチポイント LSP へ、最小限の停止でスムーズに移行する必要があります。