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 の場合、loopback インターフェイスを有効にするには、family MPLS を使用する必要があります。

  2. ナ階層レベルの[edit protocol mpls]下で関連するインターフェイスを構成します。

  3. 1つのインターフェイスで LDP を有効にldpし、文を含め、 interfaceステートメントを使用してインターフェイスを指定します。

これは LDP の最小構成です。その他すべての LDP 構成ステートメントはオプションです。

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

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

LDP を有効または無効にする

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

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

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

インターフェイスのグループに対してインターフェイスのプロパティを設定し、インターフェイスの1つで LDP を無効にする場合interfaceは、次disableのようなオプションを含むステートメントを追加します。

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

Hello メッセージ用に LDP タイマーを設定する

Ldp hello メッセージを使用すると、LDP ノードは相互に障害を検知し、近傍またはその近傍へのリンクを見つけることができます。Hello メッセージは、LDP が有効になっているすべてのインターフェイスで定期的に送信されます。

LDP hello メッセージには、次の2種類があります。

  • hello メッセージのリンク — LDP インターフェイスを通して、LDP 検出ポートにアドレス指定された UDP パケットとして送信されます。インターフェイス上での LDP link hello メッセージの受信は、LDP ピアルーターで隣接関係を識別します。

  • ターゲットを絞った hello メッセージ — 特定のアドレスで LDP 検出ポートにアドレス指定された UDP パケットとして送信されます。対象となる hello メッセージは、直接接続されていないルーター間の LDP セッションをサポートするために使用されます。ターゲットルーターは、ターゲットの hello メッセージを応答するか無視するかを決定します。対象となるルーターは、対象とする hello メッセージを定期的に開始ルーターに送信します。

デフォルトでは、LDP はリンク hello メッセージ用に 5 秒ごとに hello メッセージを送信し、15 秒ごとに hello メッセージを対象として送信します。LDP タイマーを設定して、両方のタイプの hello メッセージを送信する頻度を変更することができます。しかし、ldp の一時停止時間を超える時間を設定することはできません。詳細については、 LDP の近隣ノードがダウンする前に遅延を設定するを参照してください。

リンク Hello メッセージ用に LDP タイマーを設定する

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

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

対象となる Hello メッセージ用に LDP タイマーを設定する

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

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

LDP の近隣ノードが停止する前に遅延を設定する

保留時間によって、LDP ノードが hello メッセージを待機してから、近隣がダウンしていることを宣言するまでの期間を決定します。この値は、hello メッセージの一部として送信されるため、各 LDP ノードはその近くにあることを、どれだけ待機するかを示しています。各近傍によって送信される値は一致している必要はありません。

保留時間は通常、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 保持時間が短縮されないと、ユーザーが設定したキープアライブ間隔は変更されません。ただし、ピアネゴシエーション中にローカルの一時停止時間が短縮された場合は、keepalive interval が再計算されます。ピアネゴシエーション中に LDP 保持時間が短縮された場合、キープアライブ間隔は新しい保持時刻値の3分の1に減少します。たとえば、新しい保持時間の値が45秒の場合、keepalive interval は15秒に設定されます。

このように自動化された keepalive interval の計算により、各ピアルーターでキープアライブインターバルが設定される可能性があります。これにより、各ルーターが keepalive メッセージを送信する頻度を柔軟にすることができます。これにより、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 の対象となる Hello メッセージを厳密にすることを可能にする

厳格にターゲットにした hello メッセージを使用して、明示的に設定されていないリモートの隣接者との間で LDP セッションが確立されないようにします。strict-targeted-hellosステートメントを設定した場合、LDP ピアは、その構成されたリモート近隣の1つではないソースから送信された、対象の hello メッセージに応答しません。次のようなリモート・隣接環境を構成できます。

  • LDP トンネリングが設定されている RSVP トンネルのエンドポイント

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

構成されていない近隣ノードが hello メッセージを送信した場合、LDP ピアはそのメッセージerrorを無視して、送信元を示すエラー (トレースフラグ付き) を記録します。たとえば、LDP ピアがインターネットアドレス10.0.0.1 から対象の hello を受け取り、このアドレスの近隣ノードが特に設定されていない場合、以下のメッセージが LDP ログファイルに出力されます。

対象とする hello メッセージを有効にするstrict-targeted-hellosには、以下のステートメントを含めます。

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

LDP Keepalive メッセージの間隔を設定する

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

Keepalive interval 用に設定された値は、ピアルーターで LDP 保持時間に設定された値が、ローカルに設定された値よりも低い場合に、LDP セッションのネゴシエーション中に変更できます。詳細については、 LDP の近隣ノードがダウンする前に遅延を設定するを参照してください。

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

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

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

LDP セッションが確立された後、メッセージを定期的に交換し、セッションが機能していることを確認する必要があります。キープアライブタイムアウトは、そのセッションが失敗したことを判断する前に、近隣の LDP ノードが待つ時間を定義します。この値は通常、keepalive 間隔の3倍以上に設定されています。デフォルトは30秒です。

キープアライブ間隔を変更するにkeepalive-timeoutは、以下のステートメントを含めます。

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

コマンドを発行するとkeepalive-timeout 、明細書に対して設定された値が保留時間として表示されます。 show ldp session detail

LDP に最も一致するものを設定する

ドメイン間で OSPF エリアまたは ISIS レベルにわたって集約または集約されたルートを学習するために、Junos OS では RFC5283に基づいて LDP に対して最長一致を設定できます。

LDP に最も一致するものを設定する前に、以下のことを行う必要があります。

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

  2. MPLS プロトコルを構成します。

  3. OSPF プロトコルを構成します。

LDP に最も一致するものを設定するには、以下のことを行う必要があります。

  1. LDP プロトコルに最も一致するように設定します。
  2. インターフェイスに LDP プロトコルを構成します。

    たとえば、インターフェイスを構成するには、以下のようにします。

例:LDP に最も一致するものを設定する

この例では 、RFC5283に基づいて LDP に Longest match を設定する方法を示しています。これにより、LDP は、ドメイン間で OSPF 領域または ISIS レベル全体で集約または集約されたルートを学習できます。. 最長一致ポリシーは、プレフィックスの粒度によって提供されます。

要件

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

  • OSPF プロトコルを備えた6個の MX シリーズルーターと、接続されたインターフェイス上で LDP が有効になります。

  • Junos OS リリース16.1 以降がすべてのデバイスで実行されています。

開始する前に:

  • デバイスインターフェイスを構成します。

  • OSPF を構成します。

概要

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

Topology

トポロジでは、LDP の最 図 1 も長い一致がデバイス R0 で設定されていることを示しています。

図 1: LDP での最長一致LDP での最長一致

構成

CLI クイック構成

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

R0

R1

R2

R3

R4

R5

デバイス R0 の構成

順を追った手順

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

デバイス R0 を構成するには、次のようにします。

  1. インターフェイスを構成します。

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

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

  4. インターフェイス上で MPLS プロトコルを構成します。

  5. インターフェイス上で OSPF プロトコルを構成します。

  6. LDP プロトコルに最も一致するように設定します。

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

結果

設定モードから、、、およびshow interfacesshow protocolsshow 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 とシャドールートを表示します。

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

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 は再起動ルーターです。再接続時間とは、ルーター a がルーター A が再起動されたことを検知したときに、ルーター B による待ち時間を示します。

再接続時間を設定するにはreconnect-time 、以下のステートメントを含めます。

再接続時間は 30 ~ 300 秒の範囲内の値に設定できます。デフォルトでは、60秒に設定されています。

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

復旧時間と最大回復時間を設定する

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

再起動するルーターからの回復時刻に対して false 値が返された場合、近隣ルーターが悪影響を受けないようにするには、近隣ルーターの最大回復時間を構成できます。近接ルーターは、2つの時間の短い間、その状態を維持します。たとえば、ルーター A は LDP のグレースフルリスタートを実行しています。900秒のリカバリー時間が、隣接するルーターBに送信されました。ただし、ルーター 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 Operators

from オペレーター

説明

interface

指定されたインターフェイス上で隣接している近隣から受信した結合の一致

neighbor

指定された LDP ルーター ID から受信した結合の一致

next-hop

指定されたインターフェイスアドレスをアドバタイズした近傍から受信した結合の一致

route-filter

指定したプレフィックスを使用したバインディングでの一致

バインドがフィルタリングされている場合でも、LDP データベースには表示されますが、ラベル交換パス (LSP) の一部としてインストールすることは検討されません。

一般に、LDP でのポリシー適用は、そのルーティングを制御するのではなく、Lsp の確立をブロックするためだけに使用できます。これは LSP のパスが LDP ではなくユニキャストルーティングによって決まるからです。ただし、異なる場所に同じコストのパスが複数存在する場合は、LDP フィルタリングを使用して、考えられる次ホップの一部を除外することができます。(そうでない場合、LDP は可能な次ホップの1つをランダムに選択します)。

LDP セッションは、インターフェイスやインターフェイスアドレスにバインドされていません。LDP はルーター単位 (インターフェイス単位ではありません) のラベルをアドバタイズしています。したがって、2つのルーター間に複数の並行リンクが存在する場合、1つの LDP セッションだけが確立され、単一のインターフェイスにバインドされるわけではありません。ルーターに同じ近隣ノードへの複数の隣接関係がある場合は、フィルターが期待どおりに動作することを考慮してください。通常、and next-hopinterface使用することは適切ではありません。

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

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

\N 受信 LDP ラベルバインドのフィルタリング

すべての隣接ノードからの接頭辞/32 を適用:

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

送信 LDP ラベルバインドのフィルタリング

LDP 送信ラベルをフィルタリングするようにエクスポートポリシーを設定できます。ルーティングポリシーを適用することで、送信ラベルのバインドをフィルタリングして、バインドをブロックすることで、近隣ルーターにアドバタイズされないようにすることができます。送信ラベルフィルタリングを設定するにはexport 、以下の文を含めます。

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

[edit policy-options]階層レベルで設定された名前付きエクスポートポリシーは、すべての LDP 近隣ノードに送信されるすべてのラベルバインドに適用します。LDP 送信fromラベルフィルタリングに適用される唯一の演算子route-filterは、指定されたプレフィックスを使用してバインディングを照合することです。送信ラベルtoフィルタリングに適用される演算子は、の表 2演算子だけです。

表 2: LDP の送信ラベルフィルタリングのための事業者へ

to Operator

説明

interface

指定されたインターフェイス上で隣接している近傍に送信された結合での照合

neighbor

指定された LDP ルーター ID に送信されたバインドの一致

next-hop

指定されたインターフェイスアドレスをアドバタイズする近傍に送信する結合での一致

バインドがフィルター処理されている場合、バインドは隣接するルーターにアドバタイズされませんが、ローカルルーターに LSP の一部としてインストールできます。LDP でポリシーを適用して、Lsp の確立をブロックすることはできますが、そのルーティングの制御は行いません。LSP が従うパスは、LDP ではなく、ユニキャストルーティングによって決定されます。

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

ルーターが同じ近隣next-hopノードinterfaceに対して複数の隣接関係を持っている場合は、and 演算子を使用しないでください。

抽出したラベルは、データベースにマークされます。

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

\N 送信 LDP ラベルバインドのフィルタリング

近隣へのルートの送信 10.10.255.6/32 をブロックします。

ルーター ID 131.108/16 にのみ送信し、すべてのプレフィックスを他のすべてのルーター 10.10.255.2 に送信します。

LDP によって使用されるトランスポートアドレスの指定

ルーターは相互に TCP セッションを確立してからでなければ、LDP セッションを確立できません。TCP セッションでは、LDP セッションに必要なラベルの広告をルーターで交換できます。TCP セッションを確立するには、各ルーターが他のルーターのトランスポート アドレスを学習する必要があります。トランスポートアドレスは、LDP セッションが実行される TCP セッションを識別するために使用される IP アドレスです。

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

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

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

LDP の仕様でinterfaceは、同一の近隣ノードへのすべてのインターフェイスで同じトランスポートアドレスをアドバタイズする必要があるため、同じ LDP 近傍に対して複数の並行リンクが存在する場合、このオプションを指定することはできません。LDP が同一の近隣への複数の並列リンクを検出すると、インターフェイスの近隣ノードを切断するか、またはrouter-idオプションを指定することによって、その近隣ノードとのインターフェイスを1つずつ無効にします。

対象となる LDP セッションで使用されるトランスポートアドレスの制御

2 つのデバイス間に TCP セッションを確立するには、各デバイスが他のデバイスのトランスポート アドレスを学習する必要があります。トランスポートアドレスは、LDP セッションが動作する TCP セッションを識別するために使用される IP アドレスです。その前に、このトランスポートアドレスは、ルーター ID またはインターフェイスアドレスのみにすることができました。LDP トランスポートアドレス機能を使用すると、任意の IP アドレスを明示的にレイヤー2回線、MPLS、および VPLS の隣接関係にある LDP 近隣ノードのトランスポートアドレスとして設定できます。これにより、トランスポートアドレス構成を使用して、攻撃対象の LDP セッションを制御できます。

対象とする LDP セッションで使用されるトランスポートアドレスの制御のメリット

ターゲットの LDP セッションを確立するためのトランスポートアドレスの設定には、以下のメリットがあります。

  • Flexible interface configurations—対象となる LDP ネイバー間の LDP セッションの作成を中断することなく、1 つのループバック インターフェイスで複数の IP アドレスを柔軟に設定できます。

  • Ease of operation:インターフェイス レベルで設定されたトランスポート アドレスにより、LDP のプロトコル バックボーンでIGPプロトコルを使用できます。これにより、スムーズで容易な運用が可能になります。

対象の LDP トランスポートアドレスの概要

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

Junos OS リリース 19.1 r1 から開始して、ターゲットとしての LDP セッションの転送アドレスに使用されるデフォルト ip アドレスに加えて、その他の ip アドレスを、 sessionsession-groupinterface設定の下のトランスポートアドレスとして設定できます。はまる. トランスポートアドレスの設定は、レイヤー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

    detailコマンドの出力show ldp neighborレベルによって、hello メッセージで宛先となる近隣に送信されたトランスポートアドレスが表示されます。このアドレスに隣接ノードから到達できない場合、LDP セッションは開始されません。

  • show configuration protocols ldp

また、さらにトラブルシューティングを行うために LDP traceoptions を有効にすることもできます。

  • 構成が無効になっているトランスポートアドレス (到達不可能) からトランスポートアドレスへと変更されている場合は、以下のトレースを監視できます。

  • 無効 (到達不可能) のトランスポートアドレスに対して有効なトランスポートアドレスを使用して構成を変更した場合は、以下のトレースを監視できます。

構成に問題がある場合は、以下のトラブルシューティングタスクを実行します。

  • を確認address familyしてください。ステートメントのsession下で構成されるトランスポートアドレスは、近隣またはセッションと同じアドレスファミリに属している必要があります。

  • neighbor Or 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つの転送同値クラス (FEC) に集約します。デフォルトでは、LDP は広告がネットワークをトラバースする際に、このアグリゲーションを維持します。

通常、LSP は複数のネクストホップに分割されず、接頭辞は1つの LSP にバインドされていないため、コストの等しいパスでの負荷分散は発生しません。ただし、負荷分散ポリシーを構成し、FECs を統合すると、コストの異なるパス間でロードバランスを取ることができます。

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

Deaggregated ゲートを構成するには、 deaggregate以下のステートメントを含めます。

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

すべての LDP セッションで、deaggregated ゲートされた FECs のみをグローバルに設定できます。

FEC を集約することによって、複数の同じコストのパス間で1つの lsp を分散させ、送信セグメントに複数の次ホップに Lsp を配信できます。また、LSP ごとには、次ホップをインストールする必要があります。

FECs を集約するにはno-deaggregate 、以下のステートメントを含めます。

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

すべての LDP セッションで、集約された FECs のみをグローバルに構成できます。

LDP FECs のためのポリサーの構成

LDP FECs のトラフィックを追跡および管理するように 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 のステートメント、ステートメント、ポリサーを設定する方法の詳細については、「 ルーティング ポリシー、ファイアウォール フィルター、トラフィック ポリサー ユーザー ガイド 」を interfaceinterface-set参照してください

フィルターを設定したら、LDP のpolicingステートメント構成に含める必要があります。LDP FECs のためのポリサーを構成するpolicingには、以下のステートメントを含めます。

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

このpolicing文には、以下のオプションが含まれています。

  • fec—関連付けする LDP FEC の FEC アドレスを指定します。

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

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

LDP IPv4 FEC フィルタリングの構成

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

すべての非 BGP プレフィックスが LDP に記載されている混合ベンダーネットワークでは、LDP データベースが大規模になる可能性があります。このタイプの環境では、レイヤー 2 回線または LDP VPLS 設定によって形成される LDP セッションを使用した IPv4 FEC のアドバタイズメントを回避すると役立ちます。同様に、このような環境で受信された任意の IPv4 の FECs をフィルタリングすることも可能です。

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

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

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

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

の LDP Lsp 用の BFD の設定

LDP Lsp に双方向フォワーディング検知 (BFD) を設定できます。BFD プロトコルは、ネットワーク内の障害を検知するシンプルな hello メカニズムです。Hello パケットは、指定された定期的な間隔で送信されます。近傍障害は、ルーターが指定された間隔の経過後に応答の受信を停止したときに検出されます。BFD は、多種多様なネットワーク環境やトポロジーと連携して動作します。BFD の障害検出タイマーは、静的ルートの障害検出メカニズムよりも短時間で実行されるため、より迅速な検知が可能です。

パスの BFD セッションが失敗した場合、エラーが記録されます。次の図は、LDP LSP ログメッセージの BFD がどのように表示されるかを示しています。

また、bfd を rsvp Lsp用に構成するの説明に従って、BFD の rsvp を設定することもできます。

BFD 障害検出タイマーは適応性が高く、積極的に緩和するように調整できます。たとえば、隣接関係に障害が発生した場合にタイマーはより高い値に適応します。または、近隣は、設定された値よりもタイマーに対して高い値をネゴシエートできます。BFD セッションフラップが15秒間隔で3回以上発生した場合、タイマーはより高い値に適応します。バックオフアルゴリズムは、ローカルの BFD インスタンスがセッションフラップの理由であれば、受信 (Rx) インターバルを2つ増やします。伝送 (Tx) 間隔は、リモート BFD インスタンスがセッションフラップの理由である場合、2つ増加します。このclear bfd adaptationコマンドを使用して、設定した値に bfd インターバルタイマーを返すことができます。clear bfd adaptationこのコマンドは、ルーティングデバイス上のトラフィックフローに影響を与えないことを意味しています。

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

特定の転送同値クラス (FEC) に関連付けられた LDP Lsp のために BFD を有効にするにfecは、階層[edit protocols ldp]レベルのオプションを使用して FEC アドレスを設定します。または、運用管理と管理 (OAM) 受信ポリシーを設定して、FEC アドレス範囲の BFD を有効にすることもできます。詳細については、『 OAM 入口ポリシーの設定」を参照してください。

OAM 受信ポリシーを使用して、同等の FEC アドレスが明示的に設定されているか、FECs で OAM が有効になっている場合を除き、BFD の LDP Lsp を有効にすることはできません。BFD が FEC アドレスに対して有効になっていない場合、BFD セッションは起動しません。

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

  • [edit protocols ldp]

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

注:

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

このoam文には、以下のオプションが含まれています。

  • fec—FEC アドレスを指定します。FEC アドレスを指定するか、OAM 入口ポリシーを設定して BFD セッションが起動していることを確認しなければなりません。

  • lsp-ping-interval—LSP ping 間隔の長さ(秒)を指定します。LDP シグナル LSP に対して ping を発行するには、 ping mpls ldpこのコマンドを使用します。詳細については、 CLI Explorer を参照してください

このbfd-liveness-detection文には、以下のオプションが含まれています。

  • ecmp—LDP によって、指定された FEC に対して設定された ECMP パスすべてについて BFD セッションを確立します。ecmpオプションを設定する場合は、指定されたperiodic-traceroute FEC のステートメントも設定する必要があります。これを行わないと、コミット処理が失敗します。特定の FEC ( periodic-tracerouteecmp[edit protocols ldp oam fec address bfd-liveness-detection]) のオプションのみを設定する[edit protocols ldp oam]だけで、グローバルな階層レベル () で明細書を設定できます。

  • holddown-interval— ルートまたはネクスト ホップを追加する前に、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 対応 BFD を設定します。

FEC の BFD を設定する場合、BFD セッションはルーターに対して1つのアクティブなローカル next-hop のみに設定されます。ただし、特定の同等コストのマルチパス (ECMP) パスに関連付けられている FEC ごとに1つずつ、複数の BFD セッションを構成できます。これを適切に機能させるには、LDP LSP を定期的に traceroute に設定する必要もあります。( LDP LSP の Traceroute の設定を参照してください)。LDP LSP traceroute は、ECMP パスを検出するために使用されています。検出された各 ECMP パスに対して BFD セッションが開始します。ECMP パスのいずれかに対する BFD セッションが失敗すると、エラーがログに記録されます。

LDP LSP traceroute は定期的に実行され、ECMP パスの完全性を確認します。問題が検出されると、以下の現象が発生する可能性があります。

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

  • LDP LSP traceroute がエラー (タイムアウトなど) を返した場合、その FEC に関連付けられている BFD セッションすべてが切断されます。

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

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

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 セッション失敗イベントが発生した場合に、ルートと next-hop プロパティを設定できます。障害イベントは、停止した BFD セッションの場合もあれば、BFD セッションになったこともあります。LDP は、関連する BFD セッションが復旧したときにルートまたは次ホップをバックアップします。

LDP LSP で BFD セッションに障害が発生したfailure-action場合、以下のいずれかの失敗アクションオプションを設定できます。

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

  • remove-route:BFD セッション障害イベントが検出されると、LSP に対応するルートを適切なルーティング テーブルから削除します。LSP が ECMP で設定されていて、任意のパスに対応する BFD セッションが停止している場合、ルートは削除されます。

LDP LSP で BFD セッション障害が発生した場合に失敗アクションを設定するには、以下remove-nexthopのいずれかremove-routeのオプションまたfailure-actionはオプションを含めます。

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

BFD セッションの Holddown 間隔の設定

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(ラベルスイッチ パス)を事前に確立するか、IP ループフリーの代替ルート(LFA)高速再ルート バックアップ パスを事前に計算して、ダウンストリーム パス内のセグメントの障害を処理します。

マルチキャストルーティングでは、通常、受信側がトラフィック分散グラフを発信します。これは、一般的に送信元から受信側へのパスを確立するユニキャスト ルーティングとは異なり、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つはプレーン1で、もう一方はプレーン2を通過します。それぞれの(S、G)について、エグレス ルーティング デバイスはプライマリ パスで受信したトラフィックを転送し、バックアップ パスで受信したトラフィックをドロップします。

MoFRR は、同一コストのマルチパス (ECMP) パスと ECMP 以外のパスの両方でサポートされています。非 ECMP パスで MoFRR をサポートするには、デバイスでユニキャスト ループフリーの LFA(代替ルート)を有効にする必要があります。内部ゲートウェイ プロトコル(IGP)設定で ステートメントを使用して LFA link-protection ルートを有効にします。OSPF または IS-IS インターフェイスでリンク保護を有効にした場合、デバイスは保護されたインターフェイスを通過する宛先ルートすべてについて、プライマリのネクスト ホップへのバックアップ LFA パスを作成します。

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

マルチポイント LDP MoFRR は、パケットが IP ネットワークに転送されるMPLSのエグレス デバイスで使用されます。マルチポイント LDP MoFRR を使用して、デバイスはアップストリーム PE ルーティング デバイスに向かって 2 つのパスを確立し、LER で MPLS パケットの 2 つのストリームを受信します。デバイスは、1 つのストリーム(プライマリ)を受け入れ、もう 1 つのストリーム(バックアップ)を LER にドロップします。プライマリ パスに障害が発生した場合、デバイスは代わりにバックアップ ストリームを受け入れる必要があります。マルチポイント LDP を使用する MoFRR では、帯域内シグナリングのサポートが前提条件となります(「 マルチポイント LDP インバンド シグナリングについて 」を参照してください。ポイント to-マルチポイント LSPについては、 を参照してください)。

PIM 機能

Junos OS は、PIM のソース固有のマルチキャスト (SSM) および任意のソースマルチキャスト (ASM) で最短パスツリー (SPT) の結合に MoFRR をサポートしています。MoFRR は、SSM と ASM のどちらの範囲でもサポートされています。(*,G)参加に MoFRR を有効にするには、階層に mofrr-asm-starg 設定ステートメントを含 [edit routing-options multicast stream-protection] める必要があります。グループ G ごとに、MoFRR は (S,G) または (*,G) のいずれかで動作しますが、両方に対して動作しません。(S, g) は、常に (*, G) より優先されます。

MoFRR が有効になっている場合、PIM ルーティング デバイスは、2 つのアップストリームのリバース パス フォワーディング(RPF)インターフェイス上で join メッセージを伝達し、同じ参加リクエストのために両方のリンクでマルチキャスト トラフィックを受信します。MoFRR は、同じ即座のアップストリーム ルーティング デバイスにコンバージェンスしない 2 つのパスを優先します。PIM は、2 つのインターフェイス(プライマリ パスとバックアップ パス用)を使用して、アップストリーム RPF ネクスト ホップを使用して適切なマルチキャスト ルートをインストールします。

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

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

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

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

  • MoFRR 構成が存在しない場合、1つの上流側近隣ノード (たとえば、プレーン2インチ図 12) の方に向かって、PIM が join メッセージをアップストリームで送信します。

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

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

    • プライマリおよびバックアップ パスを使用できない場合、PIM は、1 つのアップストリーム ネイバー(プレーン 2 in など)にジョイン メッセージをアップストリームに送信します 図 12

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

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

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

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

      • プライマリとバックアップのパスが使用できない場合、PIM は1つの上位の隣接ノード (たとえば、プレーン2インチ図 12) の方に向けて、join メッセージをアップストリームで送信します。

      • プライマリおよびバックアップパスが使用可能な場合、各 PIM は、利用可能な上流の近隣ルーターの2つに向かって、join メッセージを上位に送信します。デバイスは、マルチキャスト トラフィックを受信するためにプライマリおよびセカンダリ マルチキャスト パス(プレーン 1 in など)を設定します 図 12

マルチポイント LDP 機能

トラフィックの重複をMPLS回避するために、マルチポイント LDP は通常、1 つのアップストリーム パスのみを選択します。(セクション2.4.1.1 を参照してください。RFC 6388 における One の「アップストリーム LSR』、Point-to-Multipoint および Multipoint-to-Multipoint Label Switched Paths(マルチポイントからマルチポイントへのラベル交換パス用のラベル配布プロトコル拡張)を確認します。

MoFRR を使用するマルチポイント LDP の場合、マルチポイント LDP デバイスは 2 つの独立したアップストリーム ピアを選択し、2 つの個別のラベル(1 つは各アップストリーム ピア)を送信します。このデバイスは、RFC 6388 に記載されているのと同じアルゴリズムを使用して、プライマリ アップストリーム パスを選択します。デバイスは、同じアルゴリズムを使用してバックアップ アップストリーム パスを選択しますが、プライマリ アップストリーム LSRを除外します。2 つの異なるアップストリーム ピアは、トラフィックの 2 つのストリームMPLSエグレス ルーティング デバイスに送信します。デバイスは、すべてのトラフィックを受け入れるプライマリ パスとして、アップストリームのネイバー パスの 1 MPLSします。もう 1 つのパスはバックアップ パスになり、デバイスはトラフィックをドロップします。プライマリ アップストリーム パスに障害が発生すると、デバイスはバックアップ パスからのトラフィックの受け入れを開始します。マルチポイント LDP デバイスは、内部ゲートウェイ プロトコル(IGP)ルート デバイスのネクスト ホップに基づいて、2 つのアップストリーム パスを選択します。

FEC(転送同等クラス)とは、同じパスを使用して同じ方法で転送され、同じ転送処理を受けた IP パケットのグループです。通常、特定のパケットに置かれたラベルは、そのパケットが割り当てられている FEC を表します。MoFRR では、2 つのルートが FEC ごとに mpls.0 テーブルに配置されます。1 つのルートがプライマリ ラベルに、もう 1 つのルートがバックアップ ラベルに配置されます。

同じ当面のアップストリーム デバイスに向かう平行リンクがある場合、デバイスは両方の平行リンクがプライマリと見なされます。任意の時点で、アップストリーム デバイスは複数のパラレル リンクの 1 つでのみトラフィックを送信します。

ノード は、LSR ノードで、エグレス ノードLSR、1 つ以上のダウンストリーム LSRS が直接接続されたノードです。ノードの場合、プライマリ アップストリーム パスからのトラフィックはダウンストリームのノードにLSR。アップストリームのプライマリパスに障害が発生した場合、バックアップの上流側のパスからの MPLS トラフィックが下流の LSR に転送されます。つまり、ダウンストリーム LSR 次ホップは、両方の MPLS ルートに追加され、出口のネクストホップとなります。

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

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

  • 対象としている ldp セッションが存在しない場合は、そのターゲットとして行われます。対象となる ldp セッションが1つでもある場合は、対象の ldp セッションが選択されますが、対応するポイントツーマルチポイント FEC は、ターゲットの LDP セッションに関連するインターフェースが存在しないため、MoFRR の機能を失うことになります。

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

  • ルートノードルートの更新については、IGP からの最新ホップ数に基づいて、上流のパスが変更されます。より優れたパスが使用できる場合、multipoint LDP は、より優れたパスへの切り替えを試みます。

パケット転送

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

  • ファブリック全体で重複したストリームを送信しないようにする

  • 複数のルート ルックアップを回避します(その結果、パケットがドロップされます)。

PIM については、各 IP マルチキャストストリームには同じ宛先アドレスが含まれています。パケットが到達したインターフェイスに関係なく、パケットは同じルートを持つことになります。デバイスは、各パケットが到着するインターフェイスをチェックし、プライマリ インターフェイスから来たパケットのみを転送します。インターフェイスがバックアップ ストリーム インターフェイスと一致している場合、デバイスはパケットをドロップします。インターフェイスがプライマリ ストリーム インターフェイスまたはバックアップ ストリーム インターフェイスと一致しない場合、デバイスはパケットをデバイスの例外としてコントロール プレーン。

図 13 は、このプロセスと、PIM を使用するルーター用のプライマリ インターフェイスとバックアップ インターフェイスの例を示しています。 図 14 は、PIM を使用するスイッチでも同様にこれを示しています。

図 13: ルーター上のデバイスでの MoFRR パケット転送エンジン ルックアップルーター上のデバイスでの MoFRR パケット転送エンジン ルックアップ
図 14: ポート上のポートでの MoFRR パケット転送エンジン処理スイッチポート上のポートでの MoFRR パケット転送エンジン処理スイッチ

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

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

図 15: MoFRR MPLS パケット転送エンジンでのルートルックアップMoFRR MPLS パケット転送エンジンでのルートルックアップ

制限事項と注意事項

MoFRR の制限とスイッチング デバイスとルーティング デバイスに関する注意点

MoFRR には、ルーティングデバイスとスイッチング デバイスに関する以下の制限と注意点があります。

  • MoFRR 障害検出は、MoFRR が有効になっているルーティング デバイスのリンク保護を即座に行い、マルチキャスト トラフィック パス内のすべてのリンク(エンドツーエンド)では有効にしません。

  • MoFRR は、高速再ルートに向けて選択された 2 つの一方のパス上でマルチサービスをサポートします。選択されたアップストリーム ネイバーの 2 つを、同じインターフェイス上にすることはできません。言い換えると、LAN セグメント上の 2 つのアップストリーム ネイバーです。アップストリームインターフェイスがマルチキャストトンネルインターフェイスである場合も、同じことが言えます。

  • 最大のエンドツーエンドの上流側パスの検知はサポートされていません。レシーバ側(エグレス)ルーティング デバイスは、離間したアップストリーム デバイス(前のホップ)が確実に機能することのみを確認します。PIM と multipoint LDP は、このような明示的ルートオブジェクト (EROs) と同等の機能をサポートしていません。そのため、一方のアップストリーム パス検出は、直ちに前のホップ デバイスを制御する制限があります。この制限により、プライマリおよびバックアップとして選択された前ホップのアップストリーム デバイスへのパスが共有される場合があります。

  • 次のシナリオでトラフィック ロスが発生する可能性があります。

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

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

  • PIM join のロードバランシングは、バックアップパスの参加メッセージに対する負荷分散をサポートしていません。

  • マルチキャストグループ G では、(S, G) と (*, G) join メッセージの両方に対して MoFRR を使用することはできません。(S, G) join メッセージが、(*, G) よりも優先されています。

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

  • 双方向 PIM 範囲は、MoFRR ではサポートされていません。

  • PIM デンス モードは MoFRR ではサポートされていません。

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

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

PIM を使用したスイッチング デバイスの MoFRR の制限

PIM を使用する MoFRR には、スイッチング デバイスに関する以下の制限があります。

  • アップストリーム インターフェイスが IRB(統合型ルーティングおよびブリッジング)インターフェイスである場合、MoFRR はサポートされません。これは、IGMPv3(Internet Group Management Protocol Version 3)スヌーピングなどの他のマルチキャスト機能に影響を与えます。

  • マルチキャスト トラフィックを転送している間のパケット 複製とマルチキャスト ルックアップにより、パケットが PFEs を何度も再循環する可能性があります。その結果、コマンドからのマルチキャスト パケット 数の値が表示される場合、および などの出力フィールドには予想よりも高い数字 show pfe statistics traffic が表示される Input packets 場合 Output packets があります。MoFRR のシナリオでは、この動作が頻繁に行われるのに気付く場合があります。これは、プライマリ とバックアップのストリームが複製され、一般的にトラフィック フローが増加するからです。

マルチポイント LDP を使用したルーティング デバイスに関する MoFRR の制限と注意点

マルチポイント LDP で使用する場合、MoFRR には以下の制限およびルーターに関する注意点があります。

  • Rsvp Frr は rsvp トンネルによって受信されるマルチポイント LDP トラフィックには適用されません。

  • 複数のアップストリーム MoFRR サポートされていません。これは、1つのアップストリームパスがマルチポイント LDP を通過し、2つ目のアップストリームパスが PIM を通過している、PIM multipoint LDP の帯域内シグナリングを指しています。

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

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

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

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

マルチキャストのみの高速再ルーティングの構成

リンク障害が発生した場合に、ネットワーク内のパケットロスを最小限に抑えるようにマルチキャストのみの高速再ルーティング (MoFRR) を構成できます。

高速再ルーティングがユニキャストストリームに適用されると、上流ルーターは、ラベルスイッチパス (Lsp) を MPLS 事前に設定するか、IP ループフリーの代替 (LFA) を事前に計算しています。高速再ルーティングバックアップパスは、ダウンストリームパス内のセグメントの障害に対応します。

マルチキャストルーティングでは、トラフィック分散グラフは通常、受信者によって生成されます。これは、通常、送信元から受信側へのパスを確立するユニキャストルーティングとは異なります。マルチキャスト分散グラフを確立できるプロトコルは、PIM (IP)、マルチポイント LDP (MPLS)、および RSVP TE (MPLS) です。このうち、PIM と multipoint LDP レシーバーのうち、ディストリビューショングラフの設定を開始します。したがって、以下のようなことができます。

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

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

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

(MX シリーズルーターのみ)MoFRR は、MX シリーズルーターで、MPC ラインカードを使用してサポートされています。前提条件として、ルーター内のすべてのラインカードが MPCs になっている必要があります。

ルーターまたはスイッチ上で MoFRR を構成するには、次のようにします。

  1. (MX シリーズおよび SRX シリーズルーターのみ)ルーターを拡張 IP モードに設定します。
  2. MoFRR を有効にします。
  3. ナさまざまなマルチキャストストリームをフィルタリングして、MoFRR 構成の影響を受けるようにルーティングポリシーを設定します。

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

    たとえば、以下のように記述します。

  4. ナMoFRR の構成によって影響を受けるマルチキャストグループのセットをフィルタリングするようにルーティングポリシーを設定した場合は、MoFRR ストリーム保護のポリシーを適用します。

    たとえば、以下のように記述します。

  5. ナPIM ドメインで MoFRR を使用すると、任意の送信元マルチキャスト (ASM) (*, G) 結合に、MoFRR が適用されるようになります。

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

  6. ナPIM ドメインでは、MoFRR を使用することで、RPF (独立したプレーン上の RPF) だけがバックアップ RPF パスとして選択されるようにすることができます。

    これはマルチポイント LDP MoFRR ではサポートされていません。マルチポイント LDP MoFRR では、同一のラベルは、同じ上位の近隣ノードへの並列リンク間で共有されます。PIM ドメインでは、各リンクが近隣ノードを形成しているわけではありません。このmofrr-disjoint-upstream-only文では、パスがプライマリ RPF パスと同じ上流の隣接ノードに到達した場合、backup RPF path を選択することはできません。これにより、MoFRR は、複数の RPF アップストリーム近隣ノードを持つトポロジでのみトリガーされます。

  7. ナPIM ドメインで MoFRR を使用すると、バックアップパスで join メッセージを送信することはできませんが、その他のすべての MoFRR 機能はそのまま維持されます。

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

  8. ナPIM ドメインでは、ソースへのユニキャストルート用のユニキャストゲートウェイの選択に基づいて新しいプライマリパスを選択できます。また、バックアップパスをプライマリとして昇格するのではなく、ユニキャストの選択に変更があった場合は変更します。これにより、プライマリ RPF ホップが常に最適なパスになります。

    このmofrr-primary-selection-by-routing文を指定すると、プライマリパスがダウンしたときに、バックアップパスが新しいプライマリパスとして昇格されることは保証されません。

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

例:Multipoint LDP ドメインでのマルチキャストのみの高速再ルーティングの構成

この例では、マルチキャストのみの高速再接続 (MoFRR) を構成して、リンク障害が発生した場合にネットワーク内のパケットロスを最小限に抑える方法を示します。

マルチポイント LDP MoFRR、パケットが IP ネットワークに転送される MPLS ネットワークの送信ノードで使用されます。マルチポイント LDP MoFRR の場合、上流のプロバイダエッジ (PE) ルーターへの2つのパスは、ラベルエッジルーター (コントローラー a) で2つの MPLS パケットのストリームを受信するために確立されています。ストリームの1つ (プライマリ) が受け入れられ、もう1つは (バックアップ) がその後にドロップされます。プライマリパスに障害が発生した場合、バックアップストリームが受け入れられます。

要件

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

マルチポイント LDP ドメインでは、MoFRR が機能するには、送信 PE ルーターだけが有効になっている必要があります。その他のルーターは、MoFRR をサポートする必要はありません。

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

この例では、送信 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 の構成には、この例では示されていないポリシーオプションが含まれていますが、説明は別に記載されています。このオプションは次のように設定されています。

Topology

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

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

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

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

CLI クイック構成

CLI クイック構成

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

デバイス src1

デバイス src2

デバイス R1

デバイス R2

デバイス R3

デバイス R4

デバイス R5

デバイス R6

デバイス R7

デバイス R8

構成

手順

順を追った手順

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

デバイス R3 を構成するには、次のようにします。

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

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

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

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

  5. PIM を構成します。

  6. LDP を構成します。

  7. IGP または静的ルートを構成します。

  8. 内部 BGP を構成します。

  9. MPLS と、必要に応じて RSVP を構成します。

  10. MoFRR を有効にします。

結果

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

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

検証

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

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

目的

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

アクション

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

ラベル情報の検証

目的

送信デバイスにマルチキャストグループ結合用の2つのアップストリームインターフェイスがあることを確認してください。

アクション

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

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

目的

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

アクション

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

LDP ポイントツーマルチポイントトラフィック統計を確認します。

目的

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

アクション

ラベルを使用して、プライマリとバックアップの両方のルートを示しています。

例:LDP のダウンストリームの設定

この例では、必要に応じてLDPダウンストリームを設定する方法を示しています。一般的に LDP は非要請通知モードを使用して設定されます。これは、すべての LDP ピアから、すべてのルートのラベル提供情報を受信することを意味します。サービスプロバイダは、アクセスとアグリゲーションのネットワークを単一の MPLS ドメインに統合しているため、LDP 下流のダウンストリームでアクセスとアグリゲーションのネットワーク間のバインドを分散させ、制御プレーンの処理要件を削減する必要があります。

下流ノードは、上流のアグリゲーションノードから数万のラベルバインドを受信する可能性があります。すべてのラベルバインドを学習して、MPLS ネットワーク全体ですべてのループバックアドレスを格納するのではなく、LDP ダウンストリームを使用して、下位アグリゲーションノードをオンデマンドで設定し、対応する FECs のラベルバインドを要求することができます。ループバックアドレスは、サービスが構成されている送信ノードを対象としています。

要件

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

  • M Series ルーター

  • Junos OS 12.2

概要

LDP セッションで LDP ダウンストリームの通知を有効にするには、 [edit protocols ldp session]階層レベルでダウンストリームステートメントを含める必要があります。ダウンストリームをオンデマンドで設定している場合、ジュニパーネットワークスルーターは下流方向の要求をピアルーターにアドバタイズします。2つのルーター間で下流のオンデマンドセッションを確立するには、LDP セッションの確立中にダウンストリームモードでの通知が必要になります。1つのルーターが下流の非要請モードをアドバタイズし、もう一方が下流の一方的なモードを通知する場合。

構成

LDP のダウンストリームの設定

順を追った手順

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

  1. この例では、下流のオンデマンドポリシー (DOD 要求-Loopbacks) を設定します。

    このポリシーによって、ルーターは DOD 要求-Loopbacks ポリシーに一致する FECs にのみラベル要求メッセージを転送します。

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

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

  3. LDP セッションdownstream-on-demandの構成に記載されているステートメントを使用して、下流のオンデマンド配布モードを有効にします。

LDP ダウンストリームへのルートを、ラベル付き BGP に配信

順を追った手順

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

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

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

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

順を追った手順

下流のオンデマンドではなく下流の一方的なモードで構成された他のルーターへのラベルの伝達を制限するには、以下のポリシーを構成します。

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

  2. 近隣do-not-propagate-du-sessions1.1.1.12.2.2.2、、にルートを転送しないように3.3.3.3ポリシーを設定します。

  3. ポリシーにfilter-dod-on-du-sessionsよってdod-routes確認されたルートが、 do-not-propagate-du-sessionsポリシーに定義されている近隣ルーターに送られるのを防止するように、ポリシーを設定します。

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

結果

設定モードから、 show policy-optionsshow 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 modeDownstream unsolicitedすなわちデフォルト値であることを示しています (これは、下流のオンデマンドがローカルセッションに設定されていないことを意味します)。反対に、 Remote Label Advertisement mode and Negotiated Label Advertisement modeは、リモートセッションDownstream on demandで設定されていることを示しています。

LDP ネイティブ IPv6 サポートの構成

LDP は IPv6 専用ネットワークと 、RFC 7552に記載されている IPv6 または IPv4 デュアルスタック ネットワークでサポートされています。inet IPv4 またinet6は IPv6 のいずれか、または両方のアドレスファミリを構成し、トランスポートのIPv4優先IPv6度を or に設定します。このdual-transportステートメントにより、Junos OS LDP は ipv4 隣接ノードを使用して ipv4 経由で TCP 接続を確立し、ipv6 近隣ルーターを単一スタック LSR として構築できます。inet-lsr-idおよびinet6-lsr-id ids は、IPv4 および IPv6 TCP トランスポート上で LDP セッションを確立するために構成する必要がある2つの LSR id です。この2つの Id は0以外にする必要があり、異なる値で構成する必要があります。

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

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

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

    たとえば、10.255.0.1 として inet-lsr id を設定し、inet6-lsr id を1.1.1.1 として構成します。

例:LDP ネイティブ IPv6 サポートの構成

この例では、Junos OS ラベル配布プロトコル (LDP) を使用して、ipv4 隣接ノードを使用して IPv4 経由で TCP 接続を確立する方法、および単一スタック LSR として ipv6 近隣ルーターを使用する方法を示します。これにより、ipv4 で ipv4 MPLS コアのトンネリングを使用していないことを MPLS ラベルスイッチパス (Lsp) で防止できます。

要件

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

  • 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 経由で TCP 接続を確立し、ipv6 近隣ルーターを単一スタック LSR として使用できます。And inet-lsr-idinet6-lsr-idは、IPv4 および IPv6 TCP トランスポート上で LDP セッションを確立するために構成する必要がある2つの LSR id です。この2つの Id は0以外にする必要があり、異なる値で構成する必要があります。

Topology

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

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

構成

CLI クイック構成

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

R1

R2

R1 の構成

順を追った手順

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

デバイス R1 を構成するには、次のようになります。

  1. インターフェイスを構成します。

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

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

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

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

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

結果

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

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

CLI クイック構成
順を追った手順

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

  • ナLDP 接続に対するトランスポートの基本設定を構成します。

順を追った手順
結果

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

Ipv4 近傍と ipv6 近隣ノードを使用して IPv4 の個別セッションを確立するためのデュアルトランスポートを構成します。

順を追った手順

このdual-transportステートメントを設定して、LDP が ipv4 近傍に別の ipv4 セッションと ipv6 の近隣ノードとの ipv6 セッションを確立できるようにすることができます。そのためには、 inet-lsr-id IPv4 の LSR id としてのinet6-lsr-id 構成と IPv6 の LSR id が必要です。

  • ナサードトランスポートを構成して、LDP が ipv4 近隣ルーターを使用して IPv4 経由で TCP 接続を確立できるようにします。また、ipv6 近隣を単一スタック LSR として使用します。

結果

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

検証

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

Mpls のルートエントリを検証しています。0テーブル
目的

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

アクション

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

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

Inet. 3 テーブルのルートエントリを確認しています
目的

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

アクション

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

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

Inet 6.3 テーブルのルートエントリを確認する
目的

Inet 6.3 のルートテーブル情報を表示します。

アクション

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

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

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

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

アクション

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

この出力には、LDP データベースのエントリが表示されます。

LDP の近傍ノード情報の確認
目的

LDP 近隣ノード情報を表示します。

アクション

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

この出力は、IPv4 と IPv6 の両方のアドレスの LDP 近隣ノード情報を示しています。

LDP セッション情報の確認
目的

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

アクション

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

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

検証

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

LDP の近傍ノード情報の確認
目的

LDP 近隣ノード情報を表示します。

アクション

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

この出力には、IPv4 と IPv6 の両方のアドレスの LDP 近隣ノード情報が表示されます。

LDP セッション情報の確認
目的

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

アクション

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

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

検証

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

LDP の近傍ノード情報の確認
目的

LDP 近隣ノード情報を表示します。

アクション

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

この出力には、IPv4 と IPv6 の両方のアドレスの LDP 近隣ノード情報が表示されます。

LDP セッション情報の確認
目的

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

アクション

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

例:ポイントからマルチポイント Lsp へのマルチオブバンドの LDP の信号の構成

ポイントツー Multipoint Lsp の Multipoint LDP Inband シグナリングについて

インバンドシグナリングを使用したポイントツーマルチポイントラベル交換プロトコル (Lsp) のためのマルチネーム・ラベル・ディストリビューション・プロトコールは、既存の IP/MPLS バックボーンを導入する場合に役立ちます。これは、IPTV 用にマルチキャストトラフィックを実行する必要がある場合です。

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

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

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

-LDP の仕組み

# LDP シグナリングにおけるラベルバインド

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

図 18: # LDP シグナリングにおけるラベルバインド# LDP シグナリングにおけるラベルバインド
PIM 無料の MPLS コアにある-LDP

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

図 19: PIM フリーの MPLS コアでのサンプル M LDP トポロジPIM フリーの MPLS コアでのサンプル M LDP トポロジ
構成

ラベルエッジルーター (管理側) の構成ステートメント mldp-inband-signallingを使用すると、pim が pim 上流の近隣ノードを検出していない場合でも、その近隣ノードのインオブバンドシグナリングを管理できます。MPLS LSP ルートの静的構成は、ポリシーを使用して PIM 構成に含まれています。これは、IBGP がコアサイトで使用できない場合、または IBGP ベースの LSP ルート検知を上書きする場合に必要です。

たとえば、以下のように記述します。

PIM を使用した MPLS コアにおける-LDP

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

図 20: PIM 対応 MPLS コアでのサンプル M LDP トポロジPIM 対応 MPLS コアでのサンプル M LDP トポロジ

このシナリオでmldp-inband-signalingは、を構成することで、ソースへの PIM が存在しない場合にのみ、-LDP シグナリングが開始されます。しかし、送信 PE のアップストリームインターフェイスで PIM が非アクティブになっていない場合、pim はソースに向かって近隣に存在しているため、PIM-SM は、1 ~ ldp では有効になりません。

構成

チャネルから inband core へのチャネル MPLS への移行を段階的に行うことができるのは、少なくとも、既存の PIM を使用selected-mldp-egressしているストリームが少ない場合です。のポリシーフィルターには、グループベースのフィルターとともに構成ステートメントを含めてください。信号.

注:

Inband シグナリングポリシーフィルターは、 source-address-filterステートメントまたはroute-filterステートメント、あるいはその両方の組み合わせを含むことができます。

たとえば、以下のように記述します。

注:

上記の設定には、以下のような制限があります。

  • このselected-mldp-egressステートメントを構成するのは、・コントローラーだけです。送信不可能selected-mldp-egressな PIM ルーターでステートメントを構成すると、パスのセットアップエラーが発生する可能性があります。

  • ポリシーを変更して、PIM アップストリームから M LDP までのトラフィックを、その逆方向に切り替えると、制御プレーンで中断メカニズムが実行されるため、パケットロスが発生する可能性があります。

関連

以下の条件は、マルチキャストトラフィックの M と LDP 内の帯域内シグナリングについて理解するうえで重要です。

ポイントツーポイント LSP

1つの入口ラベルスイッチルーター (LSR) と1つの送信 LSR を持つ LSP。

Multipoint LSP

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

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

1つの入口 LSR と1つまたは複数の送信 LSRs を持つ LSP。

Multipoint ツーポイント LSP

1つ以上の受信・ Srs とユニークな送信 LSR を1つ以上備えている LSP。

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

LSP 内のいずれかのノードによって送信されるトラフィックが他のすべてに配信されるように、一連のノードを接続する LSP。

受信 LSR

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

出口 LSR

特定の LSP の送信 LSR は、その LSP からのデータパケットを削除して、さらに処理できるようにする LSR です。ポイントツーポイントおよびマルチポイント間の Lsp は、1つの送信ノードのみを持ちます。Point-to-point およびマルチポイントツーマルチポイント Lsp は、複数の送信ノードを持つことができます。

輸送 LSR

直接接続された上流の LSR と、1つまたは複数の直接接続された下流 LSRs を通じて、multipoint LSP のルートに到達できる LSR。

.Bud LSR

送信でありながら、1つまたは複数の直接接続された下流 LSRs を持つ LSR。

リーフノード

ポイントツー multipoint LSP のコンテキストで送信または .bud LSR。マルチポイント LSP のコンテキストでは、LSR は、同じマルチポイント LSP を使用して受信と送信の両方を実行します。また、.bud の LSR にすることもできます。

入口結合変換と擬似インターフェイス処理

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

受信スプライス

LDP は、各 (S, G) エントリに関連付けられた次のホップを PIM に提供しています。PIM は、PIM のネクストホップとその他の PIM 受信者との間に、pim-sm マルチキャストルートをインストールします。ネクストホップとは、ローカルレシーバーの複合の次ホップ + PIM ダウンストリームの近隣ノードのリストと、LDP トンネルの次の hopfor のサブレベルです。

逆方向パス転送

PIM の RPF(Reverse-Path-Forwarding)計算はエグレス ノードで実行されます。

以下のすべての条件に該当する場合、PIM は、サード LDP の帯域内シグナリングを実行します。

  • そのソースを指す PIM はありません。

  • -LDP インバンドシグナリングステートメントが設定されています。

  • ネクストホップは BGP から学習されるか、静的なマッピングに含まれています (これは、-LDP インバンドシグナリングポリシーで指定されています)。

そうでない場合、LSP ルート検出が失敗した場合、PIM は RPF 状態が未解決である (S, G) エントリを保持します。

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

LSP ルート検知

RPF の運用では、LSP のインバンドシグナリングアップの必要性が検知された場合に、管理者ルート (受信) が検出されるようになっています。このルートは LDP LSP シグナリングのパラメーターです。

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

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

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

    Junos OS リリース16.1 より前は、受信 LSR のルートアドレスを使用して、出口からマルチポイント LSP が送信されています。このルートアドレスは IGP からのみアクセスできます。そのため、confining のポイントツー multipoint LSP は単一の自律システムによって管理されます。ルートアドレスに IGP を介して到達できず、BGP 経由で到達可能である場合、その BGP ルートが MPLS LSP で再帰的に解決されると、ポイントツーマルチポイント LSP は受信 LSR のルートアドレスに向かって、その時点から先にシグナルを受信していません。

    このようなセグメント化されていないポイントツーマルチポイント Lsp は、複数の自律システムにわたって信号を通知する必要があります。これは、以下のアプリケーションで使用できます。

    • セグメント化されていないポイントツーマルチポイント Lsp を使用した MVPN として機能します。

    • MPLS のコアネットワークによって接続されたクライアントネットワーク間の間の inband の通知です。

    • セグメント化されていないポイントツーマルチポイント Lsp (シームレス MPLS マルチキャスト) を使用した、エリア間 MVPN または M-LDP inband シグナリング

    Junos OS リリース16.1 から開始します。ルートアドレスが、MPLS LSP を介して再帰的に解決される BGP のルートである場合は、ASBR または送信または出口でポイントツーマルチポイント Lsp に通知できます。

出口結合変換と擬似インターフェイス処理

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

送信スプライス

ダウンストリームサイトからの (S, G) join メッセージを受信したコアネットワークの送信ノードでは、この結合メッセージは、M の LDP 内シグナリングパラメーターに変換され、LDP は通知を受けます。さらに、LSP の破棄は、(S, G) エントリが失われた場合、LSP ルートが変更された場合、または PIM の近傍を介して (S, G) エントリに到達した場合に発生します。

サポートされる機能

Junos OS は、以下の機能をサポートしています。

  • PIM 次ホップの送信スプライス (LDP ルート)

  • PIM のルートと LDP のネクストホップとの間の受信スプライス

  • PIM から LDP のポイントツーマルチポイント LSP 設定パラメーターへの変換

  • M-LDP インバンド LSP パラメーターの翻訳 PIM の結合メッセージを設定するには

  • 静的に構成され、BGP プロトコル次ホップベースの LSP ルート検知

  • Pim のソース固有のマルチキャスト (SSM) およびすべてのソース multicsast (ASM) 範囲に含まれる PIM の状態

  • 受信および送信 LERs の構成ステートメントがエッジルーターとして機能するようにします。

  • LERs での IGMP join メッセージ

  • IPv6 の送信元とグループのアドレスを、IPv4 ルートノードへの透過的な情報として伝送

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

サポートされない機能

Junos OS は、以下の機能をサポートしていません

  • PIM ASM を完全にサポート

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

  • 無着陸アクティブルーティングNSR

  • PIM 向けの MBB (故障の解消)

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

  • 直接接続されていない PIM スピーカー間の近隣関係

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

  • PIM 高密度モード

  • PIM 双方向モード

LDP 機能

PIM (S, G) 情報は、TLV (形式が制限された) の符号化方式であるとして扱われます。FEC エレメントは、ルートノードアドレスで構成されています。次世代のマルチキャスト Vpn (NGEN MVPNs) の場合、ポイントツー multipoint LSP は、ルートノードアドレスと LSP ID によって識別されます。

送信のための機能

送信において、PIM は LDP を以下の情報でトリガーし、ポイントツー multipoint LSP を作成します。

  • ルートノード

  • (S, G)

  • 次ホップ

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

LDP は、ルートノードをベースにした上流ノードを見つけ、ラベルを割り当て、ラベルマッピングをアップストリームノードに送信します。LDP は、penultimate のホップ・ポップ (PHP) を使用して帯域内の M-LDP シグナリングを行いません。

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

伝送 LSR 機能

転送 LSR では、ポイントツー multipoint FEC の送信元に向かって上流の LSR にラベルをアドバタイズし、パケットを転送するために必要な転送状態をインストールします。転送 LSR には、すべての M LDP 対応ルーターを使用できます。

受信した・コントローラーの機能

受信した場合、LDP はラベルマッピングを受け取ったときに以下の情報を PIM に提供します。

  • (S, G)

  • 次ホップを氾濫

その後、PIM は転送状態をインストールします。新しい支社が追加または削除されると、それに応じて次ホップのオーバーフローが更新されます。ラベルが引き出されたことによってすべての枝が削除された場合、LDP は更新情報を PIM に送信します。上位と下位の両方の近隣ノード間に複数のリンクがある場合、ポイントツーポイント LSP は負荷分散されません。

例:ポイントからマルチポイント Lsp へのマルチオブバンドの LDP の信号の構成

この例では、プロトコルに依存しないマルチキャスト (PIM) プロトコルへの拡張として、または PIM の代わりとして、マルチポイント LDP (M-LDP) 内帯域内シグナリングを構成する方法について説明します。

要件

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

  • Junos OS リリース13.2 以降

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

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

  • コアルーター用のコアルーターの T Series

注:

また、PE ルーターをコアルーター T Series することもできますが、通常はそうではありません。拡張要件に応じて、コアルーターは MX シリーズ5G ユニバーサルルーティングプラットフォームまたは M Series マルチサービスエッジルーターとしても使用できます。顧客エッジ (CE) デバイスは、他のルーターまたはジュニパーネットワークスやその他のベンダーのスイッチである場合があります。

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

概要

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

図 21: M: ポイントツーマルチポイント Lsp を対象とした LDP インバンドシグナリングの例トポロジーM: ポイントツーマルチポイント Lsp を対象とした LDP インバンドシグナリングの例トポロジー

構成

手順
CLI クイック構成

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

デバイス src1

デバイス・、Resspe

デバイス EgressPE

デバイス p6

デバイス pr3

デバイス pr4

デバイス pr5

順を追った手順

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

デバイス EgressPE を構成するには、次のようにします。

  1. インターフェイスを構成します。

    コアに接しているインターフェイスで MPLS を有効にします。出口の次ホップでは、MPLS を有効にする必要はありません。

  2. 送信インターフェイスで IGMP を構成します。

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

  3. コアに接しているインターフェイスで MPLS を構成します。

  4. BGP を構成します。

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

    たとえば、静的なルートを BGP にエクスポートすることが考えられます。

  5. ナさまざまな PIM ドメインを相互接続するために、デバイス pr5 との間に MSDP ピア接続を構成して、冗長な RPs を有効にします。

  6. OSPF を構成します。

  7. コアに接しているインターフェイスとループバックインターフェイスで LDP を構成します。

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

  9. 下位インターフェイスで PIM を構成します。

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

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

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

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

結果

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

デバイス EgressPE

同様に、他の送信デバイスを構成します。

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

検証

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

PIM の参加状況を確認しています
目的

PIM の結合状態に関する情報を表示し、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 データベースの確認
目的

ルートから (S show ldp database 、G) バインディングが必要なコマンドが表示されることを確認します。

アクション
MPLS ラベルのルート情報を検索しています
目的

ポイントからマルチポイントの FEC 情報を表示します。

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

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

アクション

Ldp マッピングサーバーによるセグメントルーティングの相互運用性の詳細について

LDP ネットワークでセグメントルーティングを段階的に導入している場合は、LDP のみ、またはセグメントルーティングのみをサポートする孤立したデバイスが存在する可能性があります。デバイスを連係するためには、LDP マッピングサーバー機能がセグメントルーティングネットワーク内の任意のデバイス上で設定されている必要があります。

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

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

OSPF を使用して、LDP でセグメントルーティングの相互運用性を実現するには、すべての LDP プレフィックスの範囲タイプ、長さ、値 (TLV) を含む拡張プレフィックスリンク状態アドバタイズメント (LSA) が生成され、そのプレフィックスに対応するマッピングルートがインストールされます。inet. 3 と mpls. 0 ルーティングテーブル

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

図 22: OSPF を使用した LDP でのセグメントルーティングの相互運用性を備えた LDP トポロジの例OSPF を使用した LDP でのセグメントルーティングの相互運用性を備えた LDP トポロジの例

前述のトポロジでは、デバイス R1、R2、R3 はセグメントルーティングのみに対応し、デバイス R5 と R6 は LDP のみに対応し、デバイス R4 は LDP とセグメントルーティングの両方をサポートします。この場合、デバイス R1 は、相互運用性に問題があるため、デバイス R6 と連係することはできません。

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

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

注:

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

LDP マッピングサーバーの設定がデバイス R2 でコミットされると、拡張されたプレフィックス範囲 TLV が OSPF 領域であふれてしまいます。セグメントルーティングが可能なデバイス (デバイス R1、R2、R3) は、指定されたループバックアドレスにセグメント ID (SID) インデックスを持つ OSPF セグメントルーティングルートをインストールします。SID インデックスも、mpls で更新されます。0セグメントルーティングデバイスによって、ルーティングテーブルを作成します。

Junos OS リリース 19.1 R1 では、セグメントルーティング-LDP 境界ルーターは、LDP の次ホップにセグメントルーティングトラフィックを転送できます。またその逆も同様です。

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

  • プレフィックスの競合は、ソース構成でのみ検出されます。プレフィックス範囲の競合が発生した場合、下位のルーター ID prevails のプレフィックス SID が付けられます。このような場合は、システム ログ エラー メッセージ— RPD_OSPF_PFX_SID_RANGE_CONFLICT が生成されます。

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

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

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

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

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

  • セグメントルーティングマッピングサーバーの基本設定 TLV はサポートされていません。

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

ISIS を使用した LDP とのセグメントルーティングの相互運用性を実現するには、プロトコル ISIS と LDP のそれぞれにサーバークライアント構成が必要です。0ルーティングテーブルは LDP でセグメントルーティング LSP をつなぎ合わせるために使用されています。LSP とその逆

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

図 23: ISIS を使用した LDP とのセグメントルーティングの相互運用性を備えた LDP トポロジの例ISIS を使用した LDP とのセグメントルーティングの相互運用性を備えた LDP トポロジの例

デバイス PE3、PE4、P6、P7、P8 は LDP 対応デバイスです。デバイスの PE1、PE2、P5、P6 は、セグメントルーティンググローバルブロック (SRGB) 値を100と200に、ノードセグメント Id (Sid) 値を使用して、それぞれ101、102105、106に対応します。

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

LDP Mapping Client Functionality (LDP to Segment Routing)

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

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

デバイス P7 は、その次ホップの PE1 FEC から LDP ラベルバインディングを持っています。その結果、デバイス P7 は従来の LDP 動作に従ってデバイス P6 に転送されます。

デバイス P6that は、PE1 FEC の LDP 送信として機能し、PE1 FEC の受信した送信 LDP ラベルと同等のセグメントルーティングノード SID (この例では 101) を交換して、トラフィックをデバイス P5 に転送します。

デバイス P5 が 101 SID をポップするのは、デバイス PE1 がノードセグメント101を penultimate-pop フラグセットを使用して通知し、トラフィックをデバイス PE1 に転送することを前提としています。PE1receives は、トンネリングされたパケットをデバイスにし、サービスラベルを処理します。

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

LDP Mapping Server Functionality (Segment Routing to LDP)

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

ここでは、デバイス P6 は SRMS(セグメント ルーティング マッピング サーバー)として機能し、(P7、107)、(P8、108)、(PE3、103)、(PE4、104)、(P7、107)のマッピングをアドバタイズします。セグメントルーティングがデバイス PE3 でサポートされていた場合、ノード SID 103 はデバイス PE3 で構成されていました。デバイスの PE3 ではセグメントルーティングがサポートされていないため、ポリシーはデバイス P6 の SRMS で設定され、デバイス P6 はマッピングの広告を担当しています。

マッピングサーバーの提供情報は、セグメントルーティングデバイスによってのみ認識されます。セグメントルーティングデバイスは、MPLS のデータプレーンに関連ノードの Sid をインストールして、ノードのセグメントがノードによってどのように提供されているかを正確に把握します。たとえば、デバイス PE1 は、P5 next ホップに、デバイス PE3 が SID 103 をアドバタイズしているかのように、ノード SID 103 をインストールします。

デバイス PE1 には、プロトコルのネクストホップとして PE3 を使用したサービスルートがあります。デバイス PE1 には、このルートのノード IGP – P5 のネクスト ホップを持つ 103 があります。その結果、デバイス PE1 は、2 つのラベル(サービス ラベルである最下のラベル)と、SID 103 の上位ラベルという 2 つのラベルを使用して、デバイス P5 にサービス パケットを送信します。デバイス P5 は103に対して103をスワップし、デバイス P6 への転送を行います。デバイス P6 のネクストホップは IGP ルート PE3 です。これはセグメントルーティングには対応していません。(デバイス P7 はセグメントルーティング機能を提供していません)。ただし、デバイス P6 には、同じ FEC の次ホップからの LDP ラベルバインディングが割り当てられています (たとえば、LDP ラベル 1037)。その結果、デバイス P6 の場合、IGP は1037に103をスワップし、デバイス P7 に転送します。

デバイス P7 は、このラベルをデバイス P8 から受け取った LDP ラベルと交換してから、デバイス P8 に転送します。LDP ラベルは、デバイス P8 によってポップされ、デバイスの PE3 に送られるようになっています。

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

Segment Routing to LDP Stitching

IGP セグメント ルーティング LSP の IP ネクスト ホップがセグメント ルーティングをサポートしていない場合、IGP は inet.3 ルーティング テーブル を参照して、同じプレフィックスに LDP LSP が存在しないか確認します。LDP LSP が存在する場合、この IGP は、セグメントルーティングラベルと ldp のラベルを交換し、セグメントルーティングドメインから LDP ドメインへのスイッチトラフィックを切り替えるための、MPLS 伝送ルートを ldp LSP に提供して、セグメントルーティング LSP を stitches にします。

図 24は、相互運用性を実現するためのセグメントルーティングと LDP Lsp のつなぎ方を示しています。

図 24: セグメントルーティングと LDP Lsp のつなぎセグメントルーティングと LDP Lsp のつなぎ

トポロジーでは、デバイス PE3 は LDP に対応しており、セグメントルーティングをサポートしていません。セグメントルーティングドメイン内のマッピングサーバーは、デバイス P7、P8、PE4 のラベルバインド TLV をアドバタイズできます。このようなシナリオでは、デバイスの PE1 は接頭語 SID とリモートラベルバインド TLV と SID の両方をデバイス PE4 に到達させることができます。しかし、デバイス PE1 は、リモートラベルバインド TLV を介してプレフィックス SID を使用し、プログラムがデバイス PE4 に対する入口セグメントルーティングルートを推奨します。その結果、デバイスの PE1 は、エンドツーエンドでセグメントルーティング LSP を使用して、デバイスの PE4 にトラフィックを送信し、セグメントルーティングツー LDP を使用してデバイス PE3 にトラフィックを送信しています。

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

  • ラベルバインド TLV の Penultimate のホップ・ポップ動作はサポートされていません。

  • ラベルバインド TLV でのプレフィックスの範囲のアドバタイズはサポートされていません。

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

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

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

  • ISIS インターレベルはサポートされていません。

  • RFC 7794, IS-IS Prefix Attributes for Extended IPv4 は サポートされていません。

  • 「つなぎノードでの接頭辞/sid としての LDP ルートの再配布はサポートされていません。

LDP のその他のプロパティの設定

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

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

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

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

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

Inet に受信ルートが追加されないようにします。0ルーティングテーブル

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

注:

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

受信ルートを inet .0 ルーティングテーブルから除外するには、以下no-forwardingのステートメントを含めます。

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

複数のインスタンスを持つ LDP Vpn およびキャリアオブ通信事業者/キャリア・スタンド

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

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

最終ホップルーターでラベルをポップするための MPLS と LDP の構成

デフォルトのアドバタイズラベルはラベル 3 (暗黙的な Null ラベル) です。ラベル3がアドバタイズされている場合、penultimate ホップルーターはそのラベルを削除して、パケットを発信ルーターに送信します。究極のホップ・ポップ機能が有効になっている場合は、ラベル 0 (IPv4 明示的 Null ラベル) が通知されます。究極のホップ・ポップアップにより、MPLS ネットワークを通過するパケットにラベルが含まれるようになります。

最終ホップのポップアップを構成するにはexplicit-null 、以下のステートメントを含めます。

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

注:

ジュニパーネットワークスルーターは、着信ラベルに基づいてパケットをキューに入れます。他のベンダーのルーターは、パケットを別のキューに置いてしまうことがあります。複数のベンダーのルーターを含むネットワークを使用する際には、このことを念頭に置いてください。

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

RSVP で確立された Lsp を使用した LDP の有効化

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

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

異種混在ネットワークにおける、RSVP で確立された Lsp を使用した LDP の有効化

その他のベンダーでは、ループバックアドレスとして OSPF メトリック1を使用しています。ジュニパーネットワークスルーターは、ループバックアドレスとして0の OSPF メトリックを使用します。このため、異種混在ネットワークの RSVP Lsp に LDP トンネリングを導入する場合は、手動で RSVP メトリックを設定する必要があります。

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

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 署名を設定して、スプーフィングされた TCP セグメントを LDP セッション接続ストリームに導入しないように保護できます。

MD5 署名オプションを使用するルーターは、認証が必要な各ピアのパスワードを使用して設定されます。パスワードは暗号化されます。

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

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

サブネットマッチ認証のサポートにより、自動ターゲット LDP (TLDP) セッションに対して認証を柔軟に設定できるため、リモートループフリーの代替 (LFA) と FEC の129擬似ワイヤの導入が容易になります。

LDP TCP 接続に対する MD5 署名を設定するには、 session-group and authentication-keyステートメントを使用します。

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

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

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

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

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

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

LDP セッション保護の構成

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

2つのルーター間で LDP セッションを維持するように Junos OS を設定できます。このsession-protection文を構成することで、この2台のルータを接続しているリンクに hello 隣接関係が存在しない場合でも、timeoutオプションを使用して時間を秒単位で指定することもできます。ルーターが IP ネットワーク接続を維持している限り、セッションは継続して実行されます。

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

LDP の SNMP トラップを無効にする

LDP LSP が、上から下へ、またはそれから上へと移行すると、いつでもルーターが SNMP トラップを送信するようになります。ただし、ルーター、論理システム、またはルーティングインスタンスで LDP SNMP トラップを無効にすることもできます。

LDP SNMP トラップおよびプロプライエタリ LDP トラップのMIBについては、 SNMP MIB Explorer を参照してください

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

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

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.exe が待機する時間を設定できます。多数の FECs がある大規模ネットワークでは、LDP ラベルデータベースの交換に十分な時間を確保するために長い値を設定しなければならない場合があります。

Ldp の近隣ノードとセッションが運用されていることを IGP に通知する前に LDP がigp-synchronizationその時間を設定するには、以下holddown-intervalのステートメントを含め、オプションの秒単位の時間を指定します。

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

ラベル引き取りタイマーの設定

ラベル引き取りタイマーは、FEC のラベル引き取りメッセージを近傍に送信します。近隣ノードへの IGP リンクに障害が発生した場合は、FEC のネクストホップである場合に、FEC に関連付けられたラベルをすべてのアップストリームルーターから撤回する必要があります。IGP が集約され、新しいネクストホップからラベルを受信すると、ラベルはすべてのアップストリームルーターに readvertised されます。これは典型的なネットワークの行動です。IGP が収束してから、下位の次ホップから FEC の新しいラベルを受信するまでの間など、ラベルの引き取りな引出時間をわずかに遅らせることで、すぐにラベルを引き取りにしてラベルマッピングを送信することを回避できます。ステートメントlabel-withdrawal-delayを使用すると、この遅延時間を設定できます。デフォルトでは遅延は60秒です。

タイマーが動作する前に新しいラベルを受信したルーターは、ラベル引き取りタイマーがキャンセルされます。ただし、タイマーが実行されると、FEC のラベルはすべてのアップストリームルーターから引き出されます。

デフォルトでは、ラベルを取り下げるまで 60 秒待機し、ラベルを取り消す前に LSP の位置を何度も合IGP回避します。ラベルの取り出し遅延時間を数秒で設定するには、 ステートメントを含 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 Traceroute の構成

ルートをトレースし、LDP シグナル LSP を追跡することができます。LDP LSP traceroute は RFC 4379, Detecting Multi-Protocol Label Switched(MPLS) Data Plane Failuresをベースにしています。この機能により、FEC 内のすべてのパスを定期的に追跡できます。FEC トポロジー情報は、CLI からアクセス可能なデータベースに格納されています。

トポロジの変更によって LDP LSP のトレースが自動的にトリガーされるわけではありません。ただし、traceroute を手動で開始することもできます。Traceroute request が現在データベース内にある FEC に対応している場合は、データベースの内容が結果とともに更新されます。

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

このステートメントは、以下の階層レベルで設定できます。

  • [edit protocols ldp oam]

  • [edit protocols ldp oam fec address]

periodic-traceroute文は単独で設定することも、以下のオプションとともに構成できます。

  • exp—プローブのサービス クラス使用するデバイス を指定します。

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

  • frequency—traceroute 試行間隔を指定します。

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

  • retries— プローブを特定のノードに送信してから実行する試行回数を指定します。

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

  • ttl—最大ライブ時間値を指定します。この値を越えているノードはトレースされません。

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

LDP の統計情報の収集

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

traffic-statistics階層レベルで[edit protocols ldp]明細書を設定すると、LDP トラフィック統計情報が定期的に収集され、ファイルに書き込まれるようになります。オプションを使用して、統計情報が収集される頻度を(秒)設定 interval できます。デフォルトの収集間隔は5分です。LDP 統計ファイルを構成する必要があります。それ以外の場合、LDP トラフィック統計は収集されません。LSP がダウンすると、LDP の統計情報がリセットされます。

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

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

ここでは、以下のトピックについて説明します。

LDP 統計出力

LDP 統計ファイルからのサンプル出力を以下に示します。

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

  • FEC—LDP トラフィック統計情報が収集される FEC。

  • Type—(このルーターから送信された)または(このルーターを介して転送される)ルーターから送信されるトラフィック IngressTransit のタイプ。

  • Packets—LSP が設定された後に FEC によって通過されたパケット数。

  • Bytes—LSP がインストールされた後に FEC によって渡されるデータのバイト数。

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

  • read—この数字(日付と時刻の横に表示)が、表示されている統計情報の実際の数と異なる可能性があります。統計情報の一部は、表示される前に集約されています。

Penultimate ホップルーターで LDP の統計を無効にする

Penultimate ホップルーターで LDP トラフィック統計を収集すると、特に、次ホップルートで過剰なシステムリソースが消費される可能性があります。deaggregate文に加えてtraffic-statisticsステートメントを設定していると、この問題はさらに悪化します。ルーターが next-hop ルートの使用制限に到達するためには、以下のno-penultimate-hoptraffic-statisticsステートメントのオプションを設定することをお勧めします。

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

注:

このno-penultimate-hopオプションを設定すると、このルーターの penultimate ホップである fecs には統計が利用できなくなります。

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

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

LDP 統計の制限事項

以下は、文をtraffic-statistics設定して LDP の統計情報を収集する際に関連する問題です。

  • LDP の統計をクリアすることはできません。

  • 指定した間隔を短くすると、新しい LDP 統計要求が発行されるのは、統計タイマーが新しい期間よりも後に期限切れになった場合のみです。

  • 新しい LDP 統計の収集操作は、前のものが終了するまで開始できません。間隔が短すぎる場合、または LDP 統計情報の数が多い場合は、2つの統計コレクション間の時間差が間隔より長くなることがあります。

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

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

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

プロトコルおよびルーティングインスタンスレベルでの LDP プロトコルトラフィックのトレース

LDP プロトコルトラフィックを追跡するには、グローバルtraceoptionsステートメントのオプションを[edit routing-options]階層レベルで指定し、次のtraceoptions文を使用して ldp 固有のオプションを指定できます。

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

このfile文を使用して、トレーシング操作の出力を受信するファイルの名前を指定します。すべてのファイルは/var/log. ディレクトリに配置されます。LDP トレース出力をファイルldp-logに保存することをお勧めします。

次のトレースフラグは、さまざまな LDP メッセージの送信と受信に関連する操作を表示します。各修飾子には、以下のいずれかまたは両方を実行できます。

  • address—アドレスの操作をトレースし、取り出しメッセージをアドレスします。

  • binding:トレース ラベル バインディング操作。

  • error:トレース エラーの状態。

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

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

  • label—ラベル要求、ラベル マップ、ラベルの取り出し、ラベル リリース メッセージの動作を追跡します。

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

  • packets—アドレス、アドレスの取り出し、初期化、ラベル要求、ラベル マップ、ラベルの取り出し、ラベル のリリース、通知、および定期的なメッセージの運用をトレースします。この修飾子は、、、、 addressnotificationinitializationおよびlabelperiodic修飾子を設定するのと同じです。

    フラグのfiltermatch-on addresspacketsサブオプションを使用して flag 修飾子を設定することもできます。これにより、パケットの送信元と宛先のアドレスに基づいてトレースを行うことができます。

  • path:ラベルスイッチ パスの操作をトレースします。

  • path:ラベルスイッチ パスの操作をトレースします。

  • periodic—hello およびキープアリスト メッセージの動作をトレースします。

  • route—ルート メッセージの動作をトレースします。

  • state:プロトコルの状態の変化をトレースします。

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

LDP は、転送の同等クラス (FEC) を、作成した各 LSP に関連付けます。LSP に関連付けられている FEC は、その LSP にマップされるパケットを指定します。各ルーターは、FEC のネクストホップによって通知されたラベルを選択し、それを他のすべてのルーターにアドバタイズするラベルとスプライスしているため、ネットワークを通じて Lsp を拡張しています。

特定の FEC 内で LDP プロトコルトラフィックをトレースし、LDP トレースステートメントを FEC に基づいてフィルタリングすることができます。これは、FEC に関連する LDP プロトコルトラフィックをトレースまたはトラブルシューティングする場合に便利です。この目的には、以下のトレースフラグを使用できます。routepath、およびbindingです。

次の例は、FEC に基づいて LDP traceoptionsトレースステートメントをフィルタリングするために、ldp ステートメントを設定する方法を示したものです。

この機能には次のような制限があります。

  • フィルタリング機能は、IPv4(IPバージョン4)プレフィックスで構成されたFECでのみ使用できます。

  • レイヤー 2 回線 FEC はフィルタリングできません。

  • ルートトレースとフィルタリングの両方を設定した場合、MPLS ルートは表示されません (フィルターによってブロックされます)。

  • フィルタリングは、ポリシーとそのmatch-onオプションに設定された値によって決定されます。ポリシーを設定するときは、デフォルトの動作が常rejectに実行されるようにしてください。

  • 唯一match-onのオプションはfec、です。したがって、ルートフィルターポリシーを追加する必要があるのは、唯一のポリシーです。

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

LDP path メッセージを詳細にトレースします。

すべての LDP 送信メッセージを追跡します。

すべての LDP エラー条件をトレースします。

すべての LDP 受信メッセージとすべてのラベルバインド操作を追跡します。

LSP に関連付けられた FEC の LDP プロトコルトラフィックをトレースします。

リリース履歴テーブル
リリース
説明
19.1
Junos OS リリース 19.1 R1 では、セグメントルーティング-LDP 境界ルーターは、LDP の次ホップにセグメントルーティングトラフィックを転送できます。またその逆も同様です。
16.1R1
Junos OS リリース 16.1 R1 では、LDP セッションでのハッシュメッセージ認証コード (HMAC) および MD5 認証のサポートが、セッションごとの構成からサブネットのマッチング (つまり、最長プレフィックスマッチ) 構成に拡張されています。
16.1
Junos OS リリース16.1 から開始します。ルートアドレスが、MPLS LSP を介して再帰的に解決される BGP のルートである場合は、ASBR または送信または出口でポイントツーマルチポイント Lsp に通知できます。
14.1
Junos OS リリース14.1 から開始し、既存の IPTV サービスをネイティブ IP マルチキャストから MPLS マルチキャストに移行するために、最小限の停止で PIM から、LDP のポイントツー multipoint Lsp への移行をスムーズに行う必要があります。