Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

PCEP 構成

PCEP の概要

パス計算要素(PCE)とは、ネットワーク グラフに基づいてネットワーク パスまたはルートを計算し、計算上の制約を適用できるエンティティ(コンポーネント、アプリケーション、またはネットワーク ノード)です。パス計算クライアント(PCC)は、PCE によって実行されるパス計算を要求する任意のクライアント アプリケーションです。PATH Computation Element Protocol(PCEP)により、PCC と PCE 間、または 2 つの PCE 間(RFC 5440 で定義)間の通信が可能になります。

PCEP は IETF PCE 作業グループによって定義される TCP ベースのプロトコルであり、PCEP セッションの管理や、マルチドメイン トラフィックエンジニアリング LSP(TE LSP)のパスの要求と送信に使用されるメッセージとオブジェクトのセットを定義します。PCE が PCC の外部 LSP のパス計算を実行するメカニズムを提供します。PCEP のやり取りには、PCC から PCE に送信される LSP ステータス レポートと、外部 LSP の PCE アップデートが含まれます。

図 1 は、MPLS RSVP-TE 対応ネットワークにおけるステートフル PCE アーキテクチャのクライアント側実装における PCEP の役割を示しています。

図 1: PCEP セッションPCEP セッション

TCP ベースの PCEP セッションは、PCC を外部 PCE に接続します。PCC は PCEP セッションを開始し、PCEP セッションの間 PCE に接続された状態を維持します。PCEP セッション中に、PCC はステートフル PCE から LSP パラメーターを要求します。PCE から 1 つ以上の LSP パラメーターを受信すると、PCC は TE LSP に再信号を送ります。PCEP セッションが終了すると、基盤となる TCP 接続は即時に閉じられ、PCC は PCEP セッションの再確立を試みます。

したがって、PCEP 機能には次のものが含まれます。

  • PCC とステートフル PCE 間の LSP トンネル状態同期 — アクティブなステートフル PCE 接続が検出されると、PCC は LSP 状態同期と呼ばれる手順ですべての LSP をこの PCE に委任しようとします。PCEP により、PCC LSP 状態と PCE の同期が可能になります。

  • LSP トンネルの制御をステートフル PCE に委譲— アクティブなステートフル PCE は、帯域幅、パス(ERO)、優先度(設定と保持)などのコンピューティング パスの 1 つ以上の LSP 属性を制御します。PCEP では、パス計算のための LSP のこのような委任が可能になります。

  • PCEP セッション内および PCEP セッション間のパス計算のタイミングとシーケンスのステートフル PCE 制御–アクティブなステートフル PCE は、帯域幅、パス(ERO)、優先度(設定と保持)などの 1 つ以上の LSP 属性を変更します。PCEP は、これらの新しい LSP 属性を PCE から PCC に通信し、その後、PCC は指定されたパスで LSP に再信号を送ります。

RSVP-TE のパス計算要素プロトコルのサポート概要

MPLS RSVP-TE について

トラフィック エンジニアリング(TE)は、主にトラフィック フローを既存の物理トポロジーにマッピングし、運用ネットワークのパフォーマンスを最適化します。トラフィック エンジニアリングにより、内部ゲートウェイ プロトコル(IGP)によって選択された最短パスから離れ、輻輳の少ない物理パスにトラフィック フローを移動できます。

大規模で密度の高いネットワークのトラフィック エンジニアリングでは、MPLS 機能を実装できます。なぜなら、オーバーレイ モデルから入手可能なほとんどの機能を統合的に提供し、現在競合している代替製品よりも低コストで提供される可能性があるためです。MPLS トラフィック エンジニアリングを実装する主な理由は、トラフィックがネットワークを流れるパスを制御することです。MPLS トラフィック エンジニアリングを実装する主な利点は、ATM のトラフィック エンジニアリング機能と IP のサービス クラス(CoS)の差別化を組み合わせて提供することです。

MPLS ネットワークでは、データ プレーン情報はラベル スイッチングを使用して転送されます。カスタマー エッジ(CE)ルーターからプロバイダ エッジ(PE)ルーターに到着するパケットには、ラベルが適用され、エグレス PE ルーターに転送されます。ラベルはエグレス ルーターで削除され、IP パケットとして適切な宛先に転送されます。MPLS ドメインのラベル スイッチング ルーター(LSR)は、ラベル配布プロトコルを使用して、LSR 間および LSR を介してトラフィックを転送するために使用されるラベルの意味を伝えます。RSVP-TE は、LSR ピアが他のピアのラベル マッピングについて学習できるようにする、そのようなラベル配布プロトコルの 1 つです。

ルーターで MPLS と RSVP の両方が有効になっている場合、MPLS は RSVP のクライアントになります。Junos OS RSVP ソフトウェアの主な目的は、ラベルスイッチ パス(LSP)内で動的シグナリングをサポートすることです。RSVP は、IP ユニキャストおよびマルチキャスト フローなどのリソースを予約し、アプリケーションのサービス品質(QoS)パラメーターを要求します。プロトコルは MPLS トラフィック エンジニアリングで拡張され、RSVP は MPLS ネットワークのトラフィック エンジニアリングに使用できる LSP を設定できます。

MPLS と RSVP を組み合わせると、ラベルは RSVP フローに関連付けられます。LSP が確立されると、パスを通過するトラフィックは、LSP のイングレス ノードに適用されたラベルによって定義されます。トラフィックへのラベルのマッピングは、さまざまな基準を使用して実行されます。特定のノードによって同じラベル値が割り当てられたパケットのセットは、同じ FEC(転送同等値クラス)に属し、RSVP フローを効果的に定義します。この方法でトラフィックが LSP にマッピングされている場合、LSP は LSP トンネルと呼ばれます。

LSP トンネルは、単一方向ラベルスイッチ パスを確立する方法です。RSVP-TE は、新しいオブジェクトを定義し、LSP 確立のために PATH および RESV オブジェクトで使用されている既存のオブジェクトを変更することにより、RSVP コア プロトコル上に構築されます。新しいオブジェクト(LRO(LABEL-REQUEST オブジェクト)、RRO(RECORD-ROUTE オブジェクト)、LABEL オブジェクト、および EXPLICIT-ROUTE オブジェクト(ERO)は、LRO および LABEL オブジェクト(どちらも LSP トンネルの確立に必須)を除き、RSVP プロトコルに関してオプションです。

一般に、RSVP-TE は、受信ルーターからエグレス ルーターへのフレーム配信を保証するラベルスイッチ パスを確立します。ただし、新しいトラフィック エンジニアリング機能では、MPLS ドメインで次の機能がサポートされています。

  • 完全または部分的な明示的ルート(RFC 3209)を使用してラベルスイッチ パスを確立する可能性。

  • 帯域幅やリンクプロパティなどの要件を満たすリンク上の制約ベースのLSP確立。

  • エンドポイント制御:受信ルーターとエグレス ルーターでの LSP トンネルの確立と管理に関連します。

  • リンク管理:リンク リソースを管理して、トラフィック エンジニアリング LSP のリソース認識型ルーティングを実行し、MPLS ラベルをプログラムします。

  • 保護が必要な LSP を管理し、これらの LSP にバックアップ トンネル情報を割り当てる MPLS 高速リルート(FRR)。

現在の MPLS RSVP-TE の制限事項

トラフィック エンジニアリングの RSVP 拡張により、ネットワークの使用率が向上し、トラフィック クラスの要件を満たすことができますが、今日の MPLS RSVP-TE プロトコル スイートには、分散性に固有のいくつかの問題があります。これにより、特に LSP の優先度クラス内では、二重化容量の競合中に多くの問題が発生し、LSP のサブセットが共通の設定を共有し、優先度値を保持します。RSVP-TE の制限事項は次のとおりです。

  • 個々の LSP、デバイス単位の帯域幅需要の可視化の欠如:MPLS RSVP-TE ネットワークのイングレス ルーターは、ネットワークの帯域幅需要をグローバルに把握することなく、LSP を確立します。ネットワーク リソースの使用率に関する情報は、インターフェイスごとにトラフィック クラス別に合計予約容量としてのみ使用できます。個々の LSP 状態は、各ラベル エッジ ルーター(LER)で独自の LSP でのみローカルで使用できます。その結果、特に共通の設定と保持優先度内で、需要パターンに関連する多くの問題が発生します。

  • RSVP シグナリングの非同期的で独立した性質 : RSVP-TE では、パス確立の制約は管理者によって制御されます。そのため、LSP トンネル用に予約された帯域幅は管理者によって設定され、トンネル経由で送信されるトラフィックの制限を自動的に意味するものではありません。そのため、トラフィック エンジニアリング リンクで使用可能な帯域幅は、リンクで行われたすべての予約の合計を除く、リンク用に設定された帯域幅です。したがって、LSP トンネルに対する未署名の要求は、過剰な帯域幅を必要とする LSP と、トラフィック エンジニアリング リンクの帯域幅要件を満たすその他の LSP のサービス低下につながります。

  • ダイナミック パス オプションまたは明示的パス オプションに基づいて設定された LSP(優先度順)—MPLS RSVP-TE ネットワークのイングレス ルーターは、到着順に基づいて需要に対して LSP を確立します。イングレス ルーターはネットワークの帯域幅需要をグローバルに把握していないため、好みの順序で LSP を確立すると、帯域幅需要が過剰になるとトラフィックがドロップしたり、LSP がまったく確立されない可能性があります。

たとえば、 図 2 MPLS RSVP-TE で設定され、A と G が LER(ラベル エッジ ルーター)です。これらのイングレスルーターは、需要の順序に基づいて独立してLSPを確立し、お互いのLSPに関する知識や制御を持っていません。ルーター B、C、D は、エグレス ルーター E および F に接続する中間ルーターまたはトランジット ルーターです。

図 2: MPLS トラフィック エンジニアリングの例 MPLS トラフィック エンジニアリングの例

イングレス ルーターは、要求が到着する順序に基づいて LSP を確立します。ルーター G が G-F 用にそれぞれ 5 個の容量を要求する場合、G は 2 つの LSP(LSP1 と LSP2)を G-B-D-F 経由で信号します。同様に、ルーターAがA-Eの容量10の3番目の需要を受け取ると、A-B-C-Eを介してLSP、LSP3に信号を送ります。ただし、A-E LSP の需要が 10 から 15 に増加すると、B-C リンクの容量が低いため、ルーター A は同じ(A-B-C-E)パスを使用して LSP3 に信号を送ることはできません。

ルーター A は、A-B-D-C-E パスを使用して LSP3 に対する需要の増加を示しているはずです。LSP1 と LSP2 は受信した需要の順序に基づいて B-D リンクを利用しているため、LSP3 は信号を受信しません。

したがって、すべての LSP に対して適切な最大フロー帯域幅が利用可能ですが、LSP3 はサービスの低下が長期化する可能性があります。これは、ルーターAがグローバルな需要の可視化に欠け、イングレスルーターAとGによる需要配置における全身的な調整が欠如しているためです。

外部パス コンピューティング エンティティの使用

MPLS RSVP-TE パス計算に見られる現在の制限に対する解決策として、利用可能な容量に依存しない、LSP 単位、デバイス単位の需要をグローバルに表示する外部パス コンピューティング エンティティが必要です。

現在、MPLS RSVP-TE ネットワークでは、オンラインおよびリアルタイムの制約ベースのルーティング パス計算のみが提供されています。各ルーターは、ネットワーク内の他のルーターに関係なく、制約ベースのルーティング計算を実行します。これらの計算は、現在利用可能なトポロジ情報(通常は最新ですが、完全には正確ではない情報)に基づいています。LSP 配置は、現在のネットワーク ステータスに基づいてローカルに最適化されます。MPLS RSVP-TE トンネルは、CLI を使用して設定されます。オペレーターは TE LSP を設定します。この LSP はイングレス ルーターによってシグナリングされます。

既存のトラフィック エンジニアリング機能に加え、MPLS RSVP-TE 機能が拡張され、外部パス コンピューティング エンティティ(PCE(Path Computation Element)と呼ばれるエンティティが含まれます。PCE は、外部制御用に設定されたイングレス ルーターの TE LSP のパスを計算します。PCE に接続するイングレス ルーターは、PCC(Path Computation Client)と呼ばれます。PCC は、PCE による外部パス コンピューティングを容易にするために、パス計算クライアント プロトコル(PCEP)で構成されています。

詳細については、 を参照してください 外部パス コンピューティングのコンポーネント

PCC の TE LSP の外部パス コンピューティングを有効にするには、ステートメントをlsp-external-controller pccd階層レベルと[edit mpls lsp lsp-name]階層レベルに[edit mpls]含めます。

外部パス コンピューティングのコンポーネント

外部パス コンピューティング システムを構成するコンポーネントは次のとおりです。

パス計算要素

パス計算要素(PCE)は、ネットワーク グラフに基づいてネットワーク パスまたはルートを計算し、計算上の制約を適用できる任意のエンティティ(コンポーネント、アプリケーション、またはネットワーク ノード)です。ただし、PCE は、外部制御用に設定された PCC の TE LSP のみのパスを計算できます。

PCE はステートフルでもステートレスでもかまいません。

  • ステートフル PCE—ステートフル PCE は、PCE とネットワークの状態(トポロジーとリソース情報の観点から)と、ネットワークで使用されている計算パスと予約リソースのセットとの間で厳密な同期を維持します。つまり、ステートフル PCE は、PCC からの新しいリクエストを処理する際に、トラフィック エンジニアリング データベースからの情報と、ネットワーク内の既存のパス(TE LSP など)に関する情報を利用します。

    ステートフル PCE には、次の 2 種類があります。

    • パッシブステートフルPCE:PCCとの同期を維持し、PCC LSPの状態を学習して、パスの計算をより適切に最適化しますが、制御することはできません。

    • アクティブなステートフル PCE—PCC LSP の状態を学習するだけでなく、PCC LSP をアクティブに変更します。

      注:

      メインおよびバックアップアクティブステートフルPCEを備えた冗長構成では、バックアップアクティブステートフルPCEは、フェイルオーバー時にメインPCEになるまで、委任されたLSPの属性を変更できません。スイッチオーバーの場合、PCE のプリエンプションはありません。メイン PCE はバックアップ PCE によって支えられ、メイン PCE がダウンしても、バックアップ PCE はメイン PCE の役割を引き受け、以前はメイン PCE が再び動作していた PCE が再び動作した後も、メイン PCE のままです。

    ステートフル PCE は、次の機能を提供します。

    • オフライン LSP パス計算を提供します。

    • ネットワークの再最適化が必要な場合に、LSP の再ルートをトリガーします。

    • アプリケーションからの帯域幅需要が増加すると、LSP 帯域幅を変更します。

    • ルーター上の他の LSP 属性(ERO、設定の優先度、保持優先度など)を変更します。

    PCE は、ネットワークの帯域幅需要をグローバルに把握し、パス計算を実行するトラフィックエンジニアリングデータベースを維持します。SNMP と NETCONF を使用して、MPLS ドメイン内のすべてのルーターから統計収集を実行します。これにより、PCC の TE LSP をオフラインで制御するメカニズムが提供されます。オフライン LSP パス計算システムをネットワーク コントローラに組み込むことができますが、PCE は、コンピューティング パスに加えて PCC の TE LSP を制御する本格的なネットワーク コントローラのように動作します。

    ステートフル PCE では最適なパス計算とパス計算の成功が可能ですが、信頼性の高い状態同期メカニズムが必要です。これには、制御プレーンのオーバーヘッドが大きくなる可能性があり、TE LSP のフル メッシュの場合と同様に、状態に関して大量のデータが維持される可能性があります。

  • ステートレス PCE—ステートレス PCE は計算されたパスを記憶せず、リクエストの各セットは互いに独立して処理されます(RFC 5440)。

パス計算クライアント

パス計算クライアント(PCC)は、PCE によって実行されるパス計算を要求する任意のクライアント アプリケーションです。

PCC は、一度に最大 10 個の PCE に接続できます。PCC から PCE への接続には、到達可能性を確立する静的ルートまたは TCP 接続を設定できます。PCC は、接続されている各 PCE に優先度番号を割り当てます。LSP 状態同期と呼ばれるプロセスで、現在の LSP に関する情報を含むすべての接続された PCE にメッセージを送信します。外部制御が有効になっている TE LSP の場合、PCC はこれらの LSP をメイン PCE に委譲します。PCC は、メイン PCE、最も優先度の低い PCE、または優先番号がない場合に最初に接続する PCE を選択します。

PCC は、PCE から受信した計算パスに基づいて LSP に再信号を送ります。メイン PCE との PCEP セッションが終了すると、PCC は新しいメイン PCE を選択し、以前のメイン PCE に委任されたすべての LSP が新しく利用可能なメイン PCE に委任されます。

Path Computation Element Protocol

Path Computation Element Protocol(PCEP)は、PCC と PCE(および 2 つの PCE 間)間の通信に使用されます(RFC 5440)。PCEP は IETF PCE 作業グループによって定義される TCP ベースのプロトコルであり、PCEP セッションの管理や、マルチドメイン TE LSP のパスの要求と送信に使用される一連のメッセージとオブジェクトを定義します。PCEP のやり取りには、PCC メッセージに加え、MPLS RSVP-TE のコンテキストでの PCE の使用に関連する特定の状態の通知が含まれます。PCE と PCE 間の通信に PCEP を使用する場合、要求する PCE は PCC の役割を引き受けます。

したがって、PCEP 機能には次のものが含まれます。

  • PCC とステートフル PCE 間の LSP トンネル状態同期。

  • LSP トンネルの制御をステートフル PCE に委譲。

PCEP を使用した PCE と PCC の相互作用

図 3 は、MPLS RSVP-TE のコンテキストにおける PCE、PCC、PCEP の役割の関係を示しています。

図 3: PCC および RSVP-TE PCC および RSVP-TE

PCE から PCC への通信は、TCP ベースの PCEP によって有効になります。PCC は PCEP セッションを開始し、PCEP セッションの間 PCE に接続された状態を維持します。

注:

Junos OS リリース 16.1 以降では、RFC 5440 に従って TCP-MD5 認証を使用して PCEP セッションを保護できます。PCEP セッションの MD5 セキュリティー メカニズムを有効にするには、PCEP セッションの階層レベルで MD5 認証キーを [edit protocols pcep pce pce-id] 定義してバインドすることをお勧めします。ただし、階層レベルから事前定義されたキーチェーンを [edit security authentication-key-chains key-chain] 使用して、PCEP セッションを保護することもできます。この場合、事前定義されたキーチェーンを階層レベルの PCEP セッションにバインドする [edit protocols pcep pce pce-id] 必要があります。

PCE と PCC は、同じキーを使用して PCEP セッションの TCP 接続で送信された各セグメントの信頼性を検証します。これにより、攻撃の対象となり、ネットワーク上のサービスを中断する可能性があるデバイス間の PCEP 通信を保護します。

MD5認証を使用したPCEPセッションの保護の詳細については、を参照してください PCEP セッション用の TCP-MD5 認証

PCEP セッションが確立されると、PCC は次のタスクを実行します。

  1. LSP 状態同期— PCC は、すべての LSP(ローカルおよび外部)に関する情報をすべての接続された PCE に送信します。外部 LSP の場合、PCC は設定変更、RRO 変更、状態変更などに関する情報を PCE に送信します。

    PCE によって開始される LSP の場合、PCC には LSP 設定がありません。LSP を開始する PCE は、PCE によって開始された LSP をサポートする機能を示す LSP パラメーターを PCC に送信します。

    注:

    PCE 開始 LSP のサポートは、Junos OS リリース 13.3 以降のリリースで提供されています。

  2. LSP 委任 — LSP 状態情報が同期されると、PCC は外部 LSP を 1 つの PCE(主なアクティブなステートフル PCE)に委譲します。外部 LSP のパラメータを設定できるのは、メイン PCE だけです。メイン PCE が変更するパラメーターには、帯域幅、パス(ERO)、および優先度(設定と保持)が含まれます。ローカル構成で指定されたパラメーターは、メイン PCE によって設定されたパラメーターによって上書きされます。

    注:

    メイン PCE との PCEP セッションが終了すると、PCC は新しいメイン PCE を選択し、以前のメイン PCE に委任されたすべての LSP が新しく利用可能なメイン PCE に委任されます。

    PCE 開始 LSP の場合、PCC は PCE から受信したパラメーターを使用して LSP を作成します。PCC は、PCE によって開始された LSP に固有の LSP-ID を割り当て、その LSP を PCE に自動的に委譲します。PCC は、アクティブな PCEP セッションの PCE によって開始された LSP の委任を取り消すことはできません。

    PCEP セッションが終了すると、PCC は PCE によって開始された LSP を直ちに削除することなく、2 つのタイマーを開始します。 delegation cleanup timeout また lsp cleanup timer 、サービスの中断を回避します。この間、アクティブなステートフル PCE は、LSP の作成要求を送信することで、障害が発生した PCE によってプロビジョニングされた LSP の制御を取得できます。

    PCE によって開始された LSP の制御は、 の有効期限が切れた時点で PCC に delegation cleanup timeout戻ります。期限切 delegation cleanup timeout れになり、障害が発生した PCE から他の PCE が LSP の制御を取得していない場合、PCC は委任されていない PCE から LSP をローカルに制御します。その後、元のまたは新しいアクティブなステートフル PCE が、ローカルで制御された PCE によって開始される LSP の制御を取得したい場合、PCC はこれらの LSP を PCE に委譲し、 lsp cleanup timer タイマーが停止します。

    PCE は、PCE が開始した LSP の委任を PCC に返して、PCE 間の LSP 転送を許可できます。これにより、 lsp cleanup timer PCE が開始した LSP がトリガーされます。PCC は、LSP クリーンアップ タイマーが期限切れになるのを待ってから、障害が発生した PCE から非代理 PCE によって開始された LSP を削除します。

    期限切 lsp cleanup timer れになり、他の PCE が障害が発生した PCE から LSP の制御を取得していない場合、PCC は障害が発生した PCE によってプロビジョニングされたすべての LSP を削除します。

    注:

    draft-ietf-pce-stateful-pce-09 に準拠して、PCC による PCE 開始 LSP 委任の取り消しは、LSP が代替 PCE に再承認される前に、事前対応型で行われます。Junos OS リリース 18.1R1 以降、 lsp-cleanup-timer PCC が LSP 委任を delegation-cleanup-timeout 取り消すには、 以上の値を指定する必要があります。指定されていない場合は、PCC の再エレメントタイムアウト間隔を無限大に設定できます。この場合、PCC が PCE によって設定されたパラメーターを変更するまで、その PCE への LSP 委任はそのまま残ります。

  3. LSP シグナリング:メイン アクティブ ステートフル PCE から 1 つ以上の LSP パラメータを受信すると、PCC は、PCE が提供するパスに基づいて TE LSP に再信号を送ります。PCC が LSP の設定に失敗した場合、PCE にセットアップエラーを通知し、メイン PCE がその LSP に新しいパラメーターを提供するのを待ってから、再信号を送ります。

    PCE が、パス エンドポイントのみが指定されている不完全またはルーズ ホップを持つパスを指定した場合、PCC はローカル制約ベースのルーティングを実行して、ホップの完全なセットを見つけることはありません。代わりに、PCC はシグナリング用として PCE が提供するパスを RSVP に提供し、IGP ホップバイホップ ルーティングを使用してパスが設定されます。

図 2使用されるトポロジーを考慮すると、 図 4 MPLS RSVP-TE 対応ネットワークにおける部分的なクライアント側 PCE 実装を示しています。イングレス ルーター A と G は、TCP 接続を介して外部ステートフル PCE に接続するように設定された PCC です。

PCE は、ネットワーク内の帯域幅需要をグローバルに把握し、トラフィック エンジニアリング データベースを調べてから外部パス計算を実行します。次に、アクティブなステートフル PCE は、1 つ以上の LSP 属性を変更し、PCC に更新を送信します。PCC は、PCE から受信したパラメーターを使用して LSP に再信号を送ります。

図 4: MPLS RSVP-TE の PCE の例 MPLS RSVP-TE の PCE の例

このように、ステートフル PCE は、最短のドメイン間制約パス計算の特定の課題に対処するために使用される分散機能の協調運用を提供します。これにより、トラフィック ストリームが利用可能なリソースに非効率的にマッピングされ、ネットワーク リソースの一部のサブセットが過剰に使用され、その他のリソースは十分に活用されていないという輻輳シナリオが排除されます。

外部コンピューティングによる LSP 動作

LSP タイプ

クライアント側の PCE 実装では、次の 3 種類の TE LSP があります。

  • CLI 制御 LSP—ステートメントが設定されていない lsp-external-controller pccd LSP は、CLI 制御 LSP と呼ばれます。これらの LSP はローカル制御下にありますが、PCC は、最初の LSP 同期プロセス中に、CLI が制御する LSP に関する情報を使用して、接続された PCE を更新します。最初の LSP 同期の後、PCC は新しい LSP および削除された LSP も PCE に通知します。

  • PCE 制御 LSP—ステートメントが設定されている lsp-external-controller pccd LSP は、PCE 制御 LSP と呼ばれます。PCC は、PCC によって開始された LSP をメイン PCE に委譲して、外部パスを計算します。

    PCC は、帯域幅、ERO、優先度など、PCE が制御する LSP の設定パラメータについて PCE に通知します。また、利用可能な場合は、RRO を含む LSP を設定するためにこれらのパラメーターに使用される実際の値についても PCE に通知します。

    PCC は、再構成が発生した場合、または外部制御下にある PCE 制御 LSP の ERO、RRO、またはステータスに変更が発生した場合にのみ、このような LSP ステータス レポートを PCE に送信します。

    PCE の LSP の CLI 設定には、次の 2 種類のパラメーターがあります。

    • PCE によって上書きされず、即座に適用されるパラメーター。

    • PCE によって上書きされるパラメーター。これらのパラメーターには、帯域幅、パス、優先度(設定と保持の値)が含まれます。制御モードが外部からローカルに切り替わると、次の機会にこれらのパラメータのCLI設定値が適用され、LSPに再信号が送られます。値はすぐには適用されません。

  • 外部プロビジョニング LSP(または PCE 開始 LSP):ステートメントが設定されている LSP は lsp-provisioning 、PCE 開始 LSP と呼ばれます。PCE によって開始された LSP は、外部 PCE によって動的に作成されます。その結果、PCC には LSP 設定が存在しません。PCC は、PCE によって提供されるパラメーターを使用して PCE 開始 LSP を作成し、その LSP を PCE に自動的に委譲します。

    注:

    PCE 開始 LSP のサポートは、Junos OS リリース 13.3 以降のリリースで提供されています。

CLI 制御 LSP、PCE 制御 LSP、PCE 開始 LSP は、PCC 上で共存できます。

CLI 制御 LSP と PCE 制御 LSP は、PCC 上で共存できます。

LSP 制御モード

クライアント側の PCE 実装では、PCC 制御 LSP には 2 種類の制御モードがあります。

  • 外部 — デフォルトでは、PCE が制御するすべての LSP が外部制御下にあります。LSP が外部制御下にある場合、PCC は PCE が提供するパラメーターを使用して LSP を設定します。

  • ローカル:PCE が制御する LSP をローカルで制御できます。LSP が外部制御からローカル制御に切り替わると、CLI で設定されたパラメーターと制約ベースのルーティングを使用してパス計算が実行されます。このような切り替えは、LSP に再信号を送るトリガーがある場合にのみ発生します。それまで、PCC は PCE が提供するパラメーターを使用して PCE が制御する LSP に信号を送りますが、LSP はローカル制御の下に残ります。

PCE に接続しない場合や、PCE が LSP の委任を PCC に戻す場合など、PCE が制御する LSP スイッチは、デフォルトの外部制御モードからローカル制御に切り替えます。

CLI 制御 LSP および PCE 制御 LSP の詳細については、 を参照してください LSP タイプ

外部コンピューティングでサポートされる設定ステートメント

表 1 は、PCE が制御する LSP に適用される MPLS および既存の LSP 設定ステートメントを示しています。

表 1: PCE 制御 LSP への MPLS および既存の LSP 構成の適用性

PCE 制御 LSP のサポート

該当する LSP 設定ステートメント

該当する MPLS 設定ステートメント

これらの設定ステートメントは、PCE 設定とともに設定できます。ただし、ローカル設定が使用中の場合にのみ有効になります。PCE 制御中は、これらの設定ステートメントは非アクティブなままです。

  • admin-group

  • 自動帯域幅

  • ホップ制限

  • 最小塗りつぶし

  • 最も盛り上がり

  • ランダム

  • admin-group

  • 管理者グループ

  • admin-group-extended

  • ホップ制限

  • cspf なし

  • スマートオプティマイズタイマー

これらの設定ステートメントは PCE 設定とともに設定できますが、PCE が制御する LSP 属性によって上書きされます。ただし、ローカル設定を使用している場合は、これらの設定ステートメントの設定値が適用されます。

注:

LSP がステートフル PCE の制御下にある間に CLI を使用してローカル設定を変更しても、LSP には影響しません。これらの変更は、ローカル設定が適用されている場合にのみ有効になります。

  • 帯域 幅

  • 一番目

  • 優先度

  • 優先度

これらの設定ステートメントは、PCE 設定と一緒に設定することはできません。

  • P2mp

  • テンプレート

  • p2mp-lsp-next-hop

残りの LSP 設定ステートメントは、既存の LSP と同じ方法で適用できます。PCE が制御する LSP に対して上記のいずれかの設定ステートメントを設定すると、設定されたパラメータがいつ有効にするかを示す MPLS ログ メッセージが生成されます。

PCE 制御 LSP 保護

高速再ルートとバイパス LSP を含む保護パスは、制約ベースのルーティングを使用して PCC によってローカルに計算されます。ステートフル PCE はプライマリ パス(ERO)のみを指定します。また、ローカル設定に LSP 保護用の非スタンバイ セカンダリ パスがない場合でも、PCE は非スタンバイセカンダリ パスをトリガーできます。

PCE 制御 LSP ERO

PCE 制御 LSP(PCC 代理 LSP および PCE 非インティゲート LSP)の場合、本格的な ERO(Explicit Route Object)オブジェクトのみを PCE から PCC に送信する必要があります。それ以外の場合、PCC は PCUpdate または PCEP セッションのメッセージを作成することを拒否します。

Junos OS リリース 17.2 以降では、PCE が制御する external cspfLSP には、2 種類の新しいパス計算タイプが導入されています。local cspfそして.no cspf

  • local cspf— PCC が計算タイプを local cspf 使用するのは、PCE がジュニパー のベンダー TLV(エンタープライズ番号: 0x0a4c) タイプ 5.

  • no cspf— PCE も PCC も、制約のあるパス計算を実行しません。エンドポイントと制約は、IGP パスを使用して LSP を設定するために RSVP モジュールに渡されます。

    PCC は、次の場合に計算タイプを使用 no cspf します。

    • PCE が TLV を送信 local cspf するとき、およびこの LSP の Junos OS 設定または一致するテンプレートが PCC によって委任された LSP に含まれる no-cspf 場合。

    • PCE が TLV を送信 local cspf するとき、およびこの LSP の Junos OS 設定テンプレートが PCE によって開始された LSP に含まれる no-cspf 場合。

    • PCE が空の ERO またはルーズ ERO を使用して TLV を送信 local cspf しない場合(ERO オブジェクトにルーズ・ビットが設定されている場合)。

これらの新しい計算タイプでは、PCC はルーズ ERO または空の ERO として ERO オブジェクトを受け入れることができます。パスを計算できない外部パス コンピューティング エンティティは、分析に基づいて帯域幅や色などのパラメーターを変更できます。このような場合、空のEROオブジェクトまたはルーズEROが使用され、取得するパスがPCCによって決定されます。

PCE 制御ポイントツーマルチポイント RSVP-TE LSP

PCE と PCC の間に PCEP セッションが確立されると、PCC はシステム内のすべての LSP を PCE に報告して LSP 状態を同期します。これには、PCC 制御、PCE 代行、PCE によって開始されるポイントツーポイント LSP が含まれます。Junos OS リリース 15.1F6 および 16.1R1 以降、この機能はポイントツーマルチポイント LSP のレポートにも拡張されています。PCE の場合、ポイントツーマルチポイント LSP は RSVP ポイントツーマルチポイント LSP と似ています。ポイントツーマルチポイント LSP は、ポイントツーマルチポイント識別子の下でグループ化されたポイントツーポイント LSP の集まりとして扱われます。

デフォルトでは、ポイントツーマルチポイント LSP の PCE 制御は PCC ではサポートされていません。この機能を追加するには、ステートメントをp2mp-lsp-report-capability階層レベルまたは[edit protocols pcep pce-group group-id]階層レベルに[edit protocols pcep pce pce-name]含めます。ポイントツーマルチポイント レポート機能が PCC 上で設定されると、PCC はこの機能を PCE にアドバタイズします。PCE が見返りとして同じポイントツーマルチポイント レポート機能をアドバタイズする場合、PCC はポイントツーマルチポイント LSP ツリー全体を PCE に報告して LSP 状態を同期します。

ポイントツーマルチポイント TE LSP 機能を備えた PCC は、ステートフル PCE、ポイントツーマルチポイント更新、ポイントツーマルチポイント LSP 名をキーとしてサポートする LSP データベースのポイントツーマルチポイント TE LSP のレポートをサポートします。ただし、Junos OS リリース 15.1F6 および 16.1 では、以下の機能はサポートされていません。

  • 静的ポイントツーマルチポイント LSP

  • PCE 代理 LSP および PCE によって開始されるポイントツーマルチポイント LSP

  • 自動帯域幅

  • TE++

  • PCE 要求および応答メッセージ

  • テンプレートを使用したポイントツーマルチポイント LSP の作成

  • PCE が開始するポイントツーマルチポイント LSP での前方入力の設定

  • プロビジョニングされた LSP を指すルーターでの前方入力の設定。

PCE によって開始されるポイントツーポイント LSP

Junos OS リリース 16.1 以降では、PCEP 機能が拡張され、ステートフル PCE が PCC を介してトラフィック エンジニアリング LSP を開始およびプロビジョニングできるようになります。以前は、LSP は PCC 上で設定され、PCC は外部 LSP の制御を PCE に委譲しました。LSP 状態の所有権は PCC によって維持されました。PCE が開始した LSP の導入により、PCE は、PCC 上でローカルに設定された LSP を必要とせずに、トラフィック エンジニアリングのポイントツーポイント LSP を動的に開始およびプロビジョニングできます。PC を受信すると PCE からメッセージを作成すると、PCC は PCE によって開始された LSP を作成し、その LSP を PCE に自動的に委譲します。

デフォルトでは、PCC は PCE から PCE によって開始されたポイントツーポイント LSP のプロビジョニング要求を拒否します。PCC で PCE を使用しない LSP のサポートを有効にするには、lsp-provisioning ステートメントを階層レベルまたは[edit protocols pcep pce-group group-id]階層レベルで[edit protocols pcep pce pce-id]含めます。

PCC は、PCE で Path Computation Element Protocol(PCEP)セッションを確立しながら、PCE によって開始されるポイントツーポイント LSP をサポートする機能を示します。PCE は、この機能を備えた PCC を選択して LSP を開始します。PCE は、PCE によって開始される LSP パラメーターを PCC に提供します。PCE が開始したポイントツーポイント LSP パラメーターを受信すると、PCC は LSP を設定し、LSP ID を割り当て、LSP を PCE に自動的に委譲します。

LSP を開始する PCE が PCE によって開始されるポイントツーポイント LSP パラメーターを提供していない場合、PCC はデフォルト パラメーターを使用します。オプションの LSP テンプレートは、PCE によって LSP パラメーターが指定されていない場合に、PCE によって開始されるポイントツーポイント LSP の値を指定するように構成することもできます。PCC 上で PCE が開始したポイントツーポイント LSP の LSP テンプレートを設定するには、階層レベルで ラベルスイッチパステンプレート ステートメントを [edit protocols mpls lsp-external-controller lsp-external-controller] 含めます。

PCEP セッションが終了すると、PCC は PCE によって開始されたLSP を直ちに削除することなく、2 つのタイマーを開始します。またlsp cleanup timerdelegation cleanup timeoutサービスの中断を回避します。この間、アクティブなステートフル PCE は、障害が発生した PCE によってプロビジョニングされた LSP の制御を取得できます。

PCE は、PCE が開始したポイントツーポイント LSP の委任を PCC に返して、PCE 間の LSP 転送を許可できます。委任クリーンアップ タイムアウトの期限が切れた時点で、PCE によって開始された LSP の制御が PCC に戻ります。委任クリーンアップ タイムアウトが期限切れになり、障害が発生した PCE から他の PCE が LSP の制御を取得していない場合、PCC は非委任 PCE によって開始された LSP をローカルで制御します。その後、元のまたは新しいアクティブなステートフル PCE が、ローカルで制御された PCE によって開始されるポイントツーポイント LSP の制御を取得する場合、PCC はこれらの LSP を PCE に委譲し、LSP クリーンアップ タイマーが停止します。

PCC は、LSP クリーンアップ タイマーが期限切れになるのを待ってから、障害が発生した PCE から非委任 PCE によって開始されたポイントツーポイント LSP を削除します。LSP クリーンアップ タイマーが期限切れになり、他の PCE が障害のある PCE から LSP の制御を取得していない場合、PCC は障害が発生した PCE によってプロビジョニングされたすべての LSP を削除します。

Junos OSリリース21.1R1以降、PCEが開始するRSVPベースのポイントツーポイントおよびポイントツーマルチポイントLSP向けのノンストップアクティブルーティング(NSR)をサポートしています。プライマリ ルーティング エンジンのみがコントローラとの PCEP セッションを維持します。PCE によって開始されたすべての RSVP LSP(PCE が開始する P2MP LSP のマルチキャスト フロー仕様など)をバックアップ ルーティング エンジンと同期します。スイッチオーバー中、PCEP セッションはダウンし、バックアップ ルーティング エンジンがプライマリ ルーティング エンジンになったときに再確立します。これにより、ルーティング エンジンの切り替え中に PCE が開始した RSVP LSP 上で転送されるトラフィックのトラフィック ロスが減少します。この機能は、NSR が設定されている場合に有効になります。

PCE によって開始されるバイパス LSP

PCE によって開始されるバイパス LSP について

ネットワーク内のバックアップ保護パスにトラフィックを処理するのに十分な帯域幅がないため、リンクまたはノード障害時にトラフィックが停止する可能性があります。このようなネットワークでは、PCE を使用してすべてのパスを計算し、ネットワーク パフォーマンスを最適化できますが、ローカル保護パスも PCE を介して制御する必要があります。

Junos OS リリース 19.2R1 以降のリリースでは、インターネット ドラフト draft-cbrt-pce-stateful-local-protection-01(2018 年 12 月有効期限)、 PCE ステートフルを使用した RSVP-TE Local-Protection の PCEP 拡張機能の一部がサポートされています。PCEP 機能が拡張され、ステートフル PCE で保護されたインターフェイスのバイパス LSP の開始、プロビジョニング、管理が可能になります。帯域幅予約を備えた複数のバイパス LSP を PCE が開始して、リンクまたはノードを保護できます。バイパス LSP の帯域幅は、保護するプライマリ LSP の総帯域幅よりも小さいと予想されます。

動的バイパス LSP よりも手動バイパス LSP(使用可能な場合)を優先する既存のバイパス選択メカニズムが拡張され、動的バイパス LSP よりも PCE プロビジョニングのバイパス LSP(使用可能な場合)が優先されます。PCE がプロビジョニングしたバイパス LSP は、動的バイパス LSP よりも優先度が高くなりますが、手動バイパス LSP よりも優先度が低くなります。

運用バイパス LSP などの clear rsvp session実行に使用される一連の操作は、PCE によって開始されたバイパス LSP でも実行できます。PCE によって開始されたバイパス LSP 統計情報を表示するコマンドなどshow path-computation-client status extensiveshow path-computation-client lsp、を使用できます。

PCE によって開始されるバイパス LSP のサポートにより、次のことができます。

  • 外部コントローラから PCEP を介して RSVP バイパス LSP を作成します。ここでは、バイパス LSP:

    • リンク保護またはノード保護が可能です。

    • ゼロ以外の帯域幅を持つ必要があります。

    • 指定された厳密なEROを持っている必要があります。

  • 既存の PCE が作成したバイパス LSP の帯域幅と ERO を更新します。

  • プライマリ LSP のアドミッション コントロールのために、バイパス LSP 帯域幅をオーバーサブスクリプションします。これはバイパス単位のパラメーターでなければならず、バイパス LSP ごとにサブスクリプションを更新できるようにする必要があります。

PCE によって開始されるバイパス LSP のメリット

PCE によって開始されるバイパス LSP には、以下のメリットがあります。

  • 障害が発生した後のトラフィックの制御を改善し、保護パスのより決定的なパス計算を行います。

  • LSP の多様なパスやローカル保護パスの維持など、複雑な制約や多様性の要件を満たします。

  • 障害イベント中にリンクが過負荷にならないようにします。

PCEP セッション障害時の PCE 開始バイパス LSP の動作

PCEP セッション障害が発生すると、PCE が開始したバイパス LSP は、状態タイムアウト タイマーの有効期限が切れるまで孤立状態になります。PCE によって開始されたバイパス LSP は、ステート タイムアウト タイマーの期限切れでクリーンアップされます。PCE 開始バイパス LSP の制御を取得するには(PCEP セッションが失敗した後)、PCE(プライマリ PCE またはセカンダリ PCE のいずれか)が、状態タイムアウト タイマーの期限切れ前に PCInitiate メッセージを送信します。

PCE によって開始されるポイントツーマルチポイント LSP

ポイントツーマルチポイント PCE 開始 LSP の導入により、PCE はポイントツーマルチポイント LSP を動的に開始およびプロビジョニングできます。PCC でのローカル LSP 設定は不要です。これにより、PCE は、PCEP(Path Computation Element Protocol)セッション内および間のポイントツーマルチポイント パス計算のタイミングとシーケンスを制御できるため、一元的に制御および導入される動的ネットワークが構築されます。

詳細については、「 PCE によって開始されるポイントツーマルチポイント LSP をサポートする MPLS RSVP-TE のパス計算要素プロトコルについて」を参照してください

PCEP の SRv6 LSP

セグメント ルーティングは、MPLS および IPv6 転送プレーンの両方に適用できます。パス計算要素(PCE)は、MPLS と IPv6 の両方の転送プレーンの SR パスを計算します。PCEP のセグメント ルーティングは、IPv6 転送プレーンで、PCE が開始し、ローカルで作成され、委任された SR LSP などの SR LSP をサポートします。

PCEP の SRv6 LSP のメリット

  • PCE 開始 SRv6 LSP を作成できます。
  • ルーターで作成された SRv6 LSP をコントローラに委任します。
  • ルーターでローカルに作成された LSP をコントローラに報告します。
  • SRv6 ネットワーク プログラミングにより、MPLS を導入せずにセグメント ルーティングを柔軟に活用できます。

PCEP は、PCE によって開始された色付きおよび色なし SRv6 LSP の作成、更新、削除をサポートしています。PCE が SRv6 LSP を開始すると、同じ IP またはカラーベースの IP に対する静的 SRv6 LSP が共存する場合、静的 SRv6 TE LSP 貢献ルートが PCE 開始 SRv6 TE LSP 貢献ルートよりも優先されます。

PCEP セッションを SRv6 に対応するよう設定するには、[編集プロトコル pcep pce pce pce-id] または [edit protocols pcep pce-group pce-id] 階層レベルで設定ステートメントを有効にするsrv6-capability必要があります。設定ステートメントが srv6-capability 有効になっている場合は、コミット中に[edit protocols source-packet-routing]階層レベルでsrv6設定ステートメントを有効にする必要があります。そうしないとエラーが表示されます。

SR-TE に SRv6 を設定するには、[edit protocols source-packet-routing] 階層レベルで srv6 設定ステートメントを追加する必要があります。

[詳細については、「 SRv6 トンネルの SR-TE ポリシー について」を参照してください。

SRv6 LSP の最大セグメント リスト深度を設定するには、[] 階層レベルで設定ステートメントをedit protocols pcep有効にするmaximum-srv6-segment-list-depth必要があります。

自動帯域幅と PCE 制御 LSP

Junos OS リリース 14.2R4 以降では、PCE が制御する LSP 向けに自動帯域幅のサポートが提供されています。以前のリリースでは、自動帯域幅オプションは PCE 制御 LSP には適用されませんでしたが、自動帯域ルーティングと制約ベースのルーティングを制御している LSP は、PCE が制御する LSP と共存できました。自動帯域幅の統計収集は、PCE が制御する LSP の制御モードが外部からローカルに変更された場合にのみ有効でした。これは、PCE への接続がない場合や、PCE が LSP の委任を PCC に戻す場合などに発生していました。

PCEP セッション用の TCP-MD5 認証

ステートフルPCEサーバーは、ネットワーク全体のトラフィックエンジニアリングパスの作成を自動化し、ネットワークの利用率を高め、PCCとのPCEP通信を使用してカスタマイズされたプログラム可能なネットワークエクスペリエンスを可能にします。PCC は LSP レポートを PCE サーバーに送信し、PCE は LSP を更新またはプロビジョニングして PCC に戻します。PCE サーバーが外部パス コンピューティングを実行するには、PCEP セッションを介して送信されるデータが不可欠です。その結果、PCEP 通信への攻撃によってネットワーク サービスが中断する可能性があります。変更された PCEP メッセージが PCC に送信されると、不適切な LSP を設定できます。同様に、変更された PCEP メッセージが PCE に送信されると、ネットワークの誤ったビューが PCE によって学習されます。

PCE 機能を効果的に実行するうえで PCE と PCC 間の PCEP 通信の重要性を考慮すると、Junos OS リリース 16.1 では、RFC 5440 に従って TCP-MD5 認証を使用して PCEP セッションを保護する機能を紹介しています。この機能は、攻撃の対象となる可能性のある PCEP セッションを介して PCE と PCC 間の通信を保護し、ネットワーク サービスを中断する可能性があります。

PCEP セッションの MD5 セキュリティー メカニズムを有効にするには、PCEP セッションの階層レベルで MD5 認証キーを [edit protocols pcep pce pce-id] 定義してバインドすることをお勧めします。ただし、階層レベルから事前定義されたキーチェーンを [edit security authentication-key-chains key-chain] 使用して、PCEP セッションを保護することもできます。この場合、事前定義されたキーチェーンを階層レベルの PCEP セッションにバインドする [edit protocols pcep pce pce-id] 必要があります。

PCE とのセキュアな PCEP セッションを確立するために、PCC で次の設定が実行されます。

  • MD5 認証キーの使用:

  • 事前定義された認証キーチェーンの使用:

セキュアな PCEP セッションを正常に確立するには、PCE サーバーと PCC の両方で事前共有認証キーを使用して MD5 認証を設定する必要があります。PCE と PCC は、同じキーを使用して、PCEP セッションの TCP 接続で送信された各セグメントの信頼性を検証します。

注:
  • Junos OS リリース 16.1 では、盗聴、改ざん、メッセージフォージェリに対する保護など、TLS と TCP-AO のサポートを拡張することなく、PCEP セッションで TCP-MD5 認証のみをサポートします。

  • PCEP セッションにセキュリティー メカニズムを最初に適用すると、セッションがリセットされます。

  • MD5 が PCEP セッションの片側で設定されていないか、設定されていない場合、セッションは確立されません。PCC と PCE の設定が一致していることを確認します。

  • この機能は、セッション認証メカニズムをサポートしていません。

  • PCEP セッションで使用される認証キーチェーンを表示するには、and show protocols pcep コマンド出力をshow path-computation-client status使用します。

  • コマンドを show system statistics tcp | match auth 使用して、認証エラーが原因で TCP によって破棄されたパケットの数を表示します。

  • キーチェーンの操作は、コマンド出力を使用して show security keychain detail 検証できます。

クライアント側 PCE 実装がネットワーク パフォーマンスに与える影響

ステートフル データベースの保守は簡単ではありません。単一の一元化された PCE 環境では、ステートフル PCE は、PCE が計算したすべての TE LSP、実際に設定された TE LSP(これがわかっている場合)、TE LSP がいつ取り壊されたかを記憶する必要があります。しかし、これらの要件により、状態、ネットワークの使用と処理、ネットワーク全体のリンクの最適化という点で、制御プロトコルのオーバーヘッドが大幅に発生します。したがって、ステートフル PCE 実装の懸念事項は次のとおりです。

  • 信頼性の高い同期メカニズムを使用すると、制御プレーンのオーバーヘッドが大幅に増加します。PCE は相互に通信して状態を同期できますが、複数の PCE 間で分散計算を使用して TE LSP を設定すると、同期や競合状態回避の問題がますます複雑になります。

  • アウトオブバンドトラフィックエンジニアリングデータベースの同期は、分散したPCE計算モデルに複数のPCEを設定すると複雑になる可能性があり、競合状態や拡張性の懸念などが発生する可能性があります。

  • すべてのパス、優先度、レイヤーに関する詳細情報が PCE に含まれている場合でも、ネットワークの状態全体を組み込むパスの計算は非常に複雑です。

上記の懸念にもかかわらず、ステートフル PCE の部分的なクライアント側の実装は、大規模なトラフィック エンジニアリング システムにおいて極めて効果的です。TE LSP 状態をグローバルに可視化し、制御するシステム内のデバイス間でパス予約を順序付け制御する必要が生じ、最適なリソース使用量の面で迅速なコンバージェンスと大きなメリットが得られます。

例:MPLS RSVP-TE のパス計算要素プロトコルの設定

この例では、パス計算クライアント(PCC)上のトラフィックエンジニアリングされたラベルスイッチパス(TE LSP)に対して、パス計算要素(PCE)による外部パスコンピューティングを有効にする方法を示しています。また、PCC でパス計算要素プロトコル(PCEP)を設定して PCE から PCC への通信を有効にする方法も示しています。

要件

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

  • ACX シリーズ ルーター、M シリーズ マルチサービス エッジ ルーター、MX シリーズ 5G ユニバーサル ルーティング プラットフォーム、T シリーズ コア ルーター、または PTX シリーズ トランスポート ルーターを組み合わせて使用できる 3 つのルーター(そのうちの 1 つが PCC として設定されています)。

  • PCC からの外部ステートフル PCE への TCP 接続。

  • JUNOS OS リリース 12.3 以降は、JSDN アドオン パッケージとともに PCC で実行されています。

注:

JSDN アドオン パッケージは、Junos OS のコア インストール パッケージとともにインストールする必要があります。

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

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

  2. MPLS と RSVP-TE を設定します。

  3. IS-IS またはその他の IGP プロトコルを設定します。

概要

Junos OS リリース 12.3 以降では、MPLS RSVP-TE 機能が拡張され、PCC 上のステートフル PCE アーキテクチャ(draft-ietf-pce-stateful-pce)のクライアント側の実装の一部が提供されます。

注:

ステートフル PCE アーキテクチャの部分的なクライアント側の実装は、バージョン 2 のインターネット ドラフト draft-ietf-pce-stateful-pce に基づいています。Junos OSリリース16.1以降、この実装は、インターネットドラフト-ietf-pce-stateful-pce-07で定義されているように、バージョン7をサポートするようにアップグレードされています。16.1 より前のリリースでは、以前のバージョンの PCE ドラフトがサポートされており、以前のリリースを実行している PCC と、インターネット draft-ietf-pce-stateful-pce-07 に準拠したステートフル PCE サーバーとの相互運用性の問題が発生しています。

PCE による外部パス コンピューティングを有効にするには、PCC のステートメントと階層レベルを[edit mpls][edit mpls lsp lsp-name]含めますlsp-external-controller

ステートメントで lsp-external-controller 設定された LSP は PCE 制御 LSP と呼ばれ、デフォルトでは PCE の外部制御下にあります。アクティブなステートフル PCE は、PCC の PCE 制御 LSP の帯域幅、パス(ERO)、優先度など、CLI から設定されたパラメーターをオーバーライドできます。

PCE から PCC への通信を有効にするには、階層レベルで PCC 上で PCEP を [edit protocols] 設定します。

PCC で PCEP を構成する場合は、以下の考慮事項に注意してください。

  • JSDN アドオン パッケージは、Junos OS のコア インストール パッケージとともにインストールする必要があります。

  • Junos OS リリース 12.3 は、ステートフル PCE のみをサポートしています。

  • PCC は、最大 10 個のステートフル PCE に接続できます。どの時点でも、PCC がパス計算のために LSP を代行するメイン PCE(優先度が最も低い PCE、または PCE の優先度がない場合は PCC に最初に接続する PCE)を 1 つだけ使用できます。

  • Junos OS リリース 12.3 では、PCC は常に PCEP セッションを開始します。リモート PCE によって開始された PCEP セッションは、PCC によって受け入れまれません。

  • LSP 保護やブレーク前の作成などの既存の LSP 機能は、PCE が制御する LSP で機能します。

  • PCE が制御する LSP では自動帯域幅オプションがオフになっていますが、自動帯域ルーティングと制約ベースのルーティングを制御している LSP は、PCE が制御する LSP と共存できます。

  • PCE 制御 LSP は、ルートへの lsp-nexthop、転送隣接関係、CCC 接続、論理トンネルなど、他の CLI 設定で参照できます。

  • PCE 制御 LSP は GRES をサポートしていません。

  • 論理システムの PCE 制御 LSP はサポートされていません。

  • PCE 制御 LSP は、ポイントツーマルチポイント LSP にすることはできません。

  • 双方向 LSP はサポートされていません。

  • PCE が制御する LSP は、プライマリ パスを持たないセカンダリ パスを持つことはできません。

  • PCE が制御する LSP は外部パスの計算に依存するため、全体的な設定時間、再ルート、ブレーク前の機能に影響を与えます。

  • LSP を拡張するための設定時間とコンバージェンス時間(リルート、MBB)は、PCE が制御する LSP がない場合でも、以前のリリースと同じです。ただし、PCE が制御する LSP の場合には、わずかな影響が見られます。

  • EROの計算時間は、ローカルCSPFよりも大幅に高いと予想されます。

トポロジ

図 5: MPLS RSVP-TE 用 PCEP の設定MPLS RSVP-TE 用 PCEP の設定

この例では、PCC は外部アクティブステートフル PCE に接続するイングレス ルーターです。

ルーター PCC の外部 LSP は、次のように計算されます。

  1. ルーター PCC は、CLI を使用して設定された LSP トンネル設定を受信します。受信した設定が外部パス コンピューティングで有効になっていると仮定すると、ルーター PCC は、帯域幅、パス、優先度などの LSP 属性の一部がステートフル PCE の制御下にあり、LSP を PCE に委譲していることに気付きます。

    この例では、外部 LSP が呼び出 PCC-to-R2 され、ルーター PCC からルーター R2 に設定されています。CLI 設定 ERO は PCC-to-R2 PCC-R0-R1-R2 です。の帯域幅 PCC-to-R2 は10mで、セットアップとホールドの両方の優先度値は4です。

  2. ルーター PCC は、PCE が制御する LSP 属性を取得しようとします。これを行うために、ルーター PCC は、LSP が設定されていることを示す PCRpt メッセージをステートフル PCE に送信します。PCRpt メッセージは LSP のステータスを伝え、LSP のローカル設定パラメータが含まれています。

  3. ステートフル PCE は、委任された LSP 属性の 1 つ以上を変更し、PCUpd メッセージを介してルーター PCC に新しい LSP パラメーターを送信します。

  4. 新しい LSP パラメーターを受信すると、ルーター PCC は新しい LSP を設定し、PCE が提供するパスを使用して LSP を再信号します。

    この例では、PCE が提供する PCC-to-R2 ERO は PCC-R3-R2 です。の帯域幅 PCC-to-R2 は8mで、セットアップとホールドの両方の優先度値は3です。

  5. ルーター PCC は、新しい RRO を持つ PCRpt をステートフル PCE に送信します。

設定

CLI クイック設定

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

PCC

R0

R1

R2

R3

手順

手順

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

ルーター PCC を設定するには、次の手順に応えます。

注:

各ルーターの適切なインターフェイス名、アドレス、およびその他のパラメーターを変更した後、MPLS ドメイン内のすべてのジュニパーネットワークスイングレス ルーターに対してこの手順を繰り返します。

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

    MPLS を有効にするには、インターフェイスにプロトコル ファミリーを含め、インターフェイスが受信 MPLS トラフィックを破棄しないようにします。

  2. 管理インターフェイスを除く、ルーター PCC のすべてのインターフェイスで RSVP を有効にします。

  3. ルーター PCC からルーター R2 への LSP(ラベルスイッチ パス)を設定し、PCE による LSP の外部制御を有効にします。

  4. ローカル制御を備え、PCE が提供する LSP パラメーターによって上書きされるルーター PCC からルーター R2 に LSP を設定します。

  5. 管理インターフェイスを除く、ルーター PCC のすべてのインターフェイスで MPLS を有効にします。

  6. 管理インターフェイスを除く、ルーター PCC のすべてのインターフェイスで IS-IS を設定します。

  7. ルーター PCC が接続する PCE を定義し、PCE の IP アドレスを設定します。

  8. TCP ベースの PCEP を使用して PCE に接続するルーター PCC の宛先ポートを設定します。

  9. PCE タイプを設定します。

結果

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

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

検証

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

PCEP セッション ステータスの検証

目的

PCE ステータスが稼働している場合、PCE とルーター PCC 間の PCEP セッション ステータスを検証します。

対処

動作モードから、コマンドを show path-computation-client active-pce 実行します。

意味

出力には、ルーター PCC が接続されている現在アクティブなステートフル PCE に関する情報が表示されます。出力フィールドは PCE status 、PCE とルーター PCC 間の PCEP セッションの現在の状態を示します。

の場合 pce1、PCEP セッションの状態は PCE_STATE_UP、PCEP ピア間で PCEP セッションが確立されたことを示します。

PCRpts 統計情報は、LSP の現在のステータスを報告するためにルーター PCC から PCE に送信されるメッセージの数を示します。この統計は PCUpdates 、PCE からルーター PCC が受信したメッセージの数を示しています。メッセージには PCUpdates 、PCE が制御する LSP の PCE 変更パラメーターが含まれます。

LSP 制御が外部である場合の PCE 制御 LSP ステータスの検証

目的

LSP が外部制御下にある場合、PCE が制御する LSP の状態をルーター PCC からルーター R2 に検証します。

対処

動作モードから、コマンドを show mpls lsp name PCC-to-R2 extensive 実行します。

意味

出力では、 LSPtype および LSP Control Status 出力フィールドは LSP が外部制御されていることを示しています。出力には、ルーター PCC と PCE 間で送信された PCEP メッセージのログも表示されます。

PCE とルーター PCC 間の PCEP セッションが稼働し、ルーター PCC は次の PCE 制御 LSP パラメーターを受信します。

  • ERO(パス)—20.31.4.2 および 20.31.5.2

  • Bandwidth—8Mbps

  • 優先度 — 3 3(設定および保持値)

LSP 制御がローカルの場合の PCE 制御 LSP ステータスの検証

目的

LSP 制御がローカルになったときに、PCE が制御する LSP の状態をルーター PCC からルーター R2 に検証します。

対処

動作モードから、コマンドを show mpls lsp name PCC-to-R2 extensive 実行します。

意味

出力では、出力フィールドは LSP Control Status LSP がローカル制御下にあることを示しています。PCE が制御する LSP はローカル制御下にありますが、ルーター PCC は PCE が提供するパラメーターを引き続き使用し、次に LSP に再信号を送るまで使用します。

出力には、使用している実際の値として LSP を確立するために使用した PCE 提供のパラメーターと共に、CLI を使用して設定された LSP パラメーターが表示されます。

  • 帯域幅—10 Mbps(実際の帯域幅: 8 Mbps)

  • 優先度 — 4 4(実際の優先度 3 3)

ルーター PCC は、LSP に再信号を送るトリガーで、ローカル設定パラメーターを使用して PCE が制御する LSP を確立します。

Computed ERO 20.31.1.2、20.31.2.2、20.31.8.2 です。PCE 制御 LSP は、ローカル構成パラメーターを使用して確立されます。

例:PCE によって開始されるポイントツーポイント LSP をサポートする MPLS RSVP-TE のパス計算要素プロトコルの設定

この例では、パス計算クライアント(PCC)を、PCE(Path Computation Element)が開始するトラフィックエンジニアリングのポイントツーポイント ラベルスイッチ パス(LSP)をサポートする機能を使用して構成する方法を示しています。

要件

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

  • ACX シリーズ、M シリーズ、MX シリーズ、または T シリーズ ルーターの組み合わせが可能な 3 つのルーター。

  • イングレス ルーター(PCC)から 2 つの外部ステートフル PCE への TCP 接続。

  • PCC で実行されている Junos OS リリース 16.1 以降。

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

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

  • MPLS および RSVP-TE(RSVP-Traffic Engineering)を設定します。

  • OSPF またはその他の IGP プロトコルを設定します。

概要

Junos OS リリース 16.1 以降では、PCEP 機能が拡張され、ステートフル PCE が PCC を介してトラフィック エンジニアリング LSP を開始およびプロビジョニングできるようになります。以前は、LSP は PCC 上で設定され、PCC は外部 LSP の制御を PCE に委譲しました。LSP 状態の所有権は PCC によって維持されました。PCE が開始した LSP の導入により、PCE は、PCC 上でローカルに設定された LSP を必要とせずに、トラフィック エンジニアリングのポイントツーポイント LSP を動的に開始およびプロビジョニングできます。PC を受信すると PCE からメッセージを作成すると、PCC は PCE によって開始された LSP を作成し、その LSP を PCE に自動的に委譲します。

PCC の PCE 開始ポイントツーポイント LSP のサポートを構成する場合は、以下の考慮事項に注意してください。

  • Junos OS リリース 13.3 は、ステートフル PCE のみをサポートしています。

  • Junos OS リリース 13.3 では、PCC は常に PCEP セッションを開始します。リモート PCE によって開始された PCEP セッションは、PCC によって受け入れまれません。

  • LSP 防御や make-before-break などの既存の LSP 機能は、PCE が開始する LSP で機能します。

  • PCE 開始 LSP は、グレースフル ルーティング エンジン スイッチオーバー(GRES)をサポートしていません。

  • 論理システムの PCE 開始 LSP はサポートされていません。

  • PCE によって開始される LSP は、ポイントツーマルチポイント LSP にすることはできません。

  • 双方向 LSP はサポートされていません。

  • 番号なしリンクの RSVP-TE はサポートされていません。PCE によって開始される LSP は、番号付きリンクのみをサポートします。

  • セグメント ルーティング LSP を開始する PCE は、色なしセグメント ルーティング LSP に関連付けられたバインド セグメント ID(SID)ラベルを使用して、PCE によって開始されるセグメント ルーティング LSP パスをプロビジョニングできます。

    Junos OSリリース18.2R1以降、イングレスデバイス上で静的に設定された非カラーセグメントルーティングLSPは、PCEPセッションを介してPCEに報告されます。これらの色なしセグメント ルーティング LSP には、バインド SID ラベルが関連付けられている場合があります。この機能を使用すると、PCE はラベル スタックでこのバインド SID ラベルを使用して、PCE によって開始されたセグメント ルーティング LSP パスをプロビジョニングできます。

トポロジ

図 6: MPLS RSVP-TE の PCE 非立ち上がりポイントツーポイント LSP の例MPLS RSVP-TE の PCE 非立ち上がりポイントツーポイント LSP の例

この例では、PCC は 2 つの外部ステートフル PCE に接続するイングレス ルーターです。PCE1 および PCE2。

新しい需要が生じると、アクティブなステートフル PCE が LSP を動的に開始して要件を満たします。PCC は PCE 開始 LSP をサポートする機能で構成されているため、PCC でのパス計算は次のように実行されます。

  1. PCE が PC を送信します。PCC にメッセージを作成して、LSP を開始してプロビジョニングします。PCC は、PCE から受信したパラメーターを使用して PCE 開始 LSP を設定し、PCE を開始した LSP を PCE に自動的に委譲します。

    この例では、PCE1 は PCC で PCE によって開始された LSP を開始およびプロビジョニングするアクティブなステートフル PCE です。PCE 開始 LSP パラメーターを受信すると、PCC は LSP を設定し、PCE が開始した LSP を PCE1 に自動的に委譲します。

  2. PCC と PCE1 間の PCEP セッションが終了すると、PCC は PCE1 から開始された LSP の 2 つのタイマーを開始します。デルゲーション クリーンアップ タイムアウトと LSP クリーンアップ タイマーです。この間、PCE1 または PCE2 は PCE によって開始された LSP の制御を取得できます。

  3. PCE2 が LSP クリーンアップ タイマーの期限切れ前に PCE 開始 LSP の制御を取得した場合、PCC は PCE によって開始された LSP を PCE2 に委譲し、LSP クリーンアップ タイマーと委任クリーンアップ タイムアウトが停止します。

  4. 委任クリーンアップ タイムアウトが期限切れになり、PCE1 も PCE2 も PCE2 が PCE によって開始された LSP の制御を取得していない場合、PCC は LSP クリーンアップ タイマーの期限が切れるまで、非委任 PCE 開始 LSP をローカル制御します。

  5. LSP クリーンアップ タイマーの有効期限が切れた後、PCC は PCE1 によってプロビジョニングされた PCE によって開始された LSP を削除します。

設定

CLI クイック設定

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

PCC

R1

R2

手順

手順

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

PCC ルーターを設定するには、以下の手順にしたがってください。

注:

各ルーターの適切なインターフェイス名、アドレス、およびその他のパラメーターを変更した後、MPLS ドメイン内のすべてのジュニパーネットワークスイングレス ルーターに対してこの手順を繰り返します。

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

    MPLS を有効にするには、インターフェイスにプロトコル ファミリーを含め、インターフェイスが受信 MPLS トラフィックを破棄しないようにします。

  2. 管理インターフェイスを除く、PCC のすべてのインターフェイスで RSVP を有効にします。

  3. PCE による LSP の外部制御を可能にします。

  4. 管理インターフェイスを除く、PCC のすべてのインターフェイスで MPLS を有効にします。

  5. 管理インターフェイスを除く、PCC のすべてのインターフェイスで OSPF を設定します。

  6. PCE グループを定義し、PCE グループの PCE 開始 LSP のサポートを有効にします。

  7. PCC に接続する PCE を定義します。

結果

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

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

検証

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

PCC ステータスの検証

目的

PCC と接続された PCE 間の PCEP セッション ステータスと LSP サマリーを検証します。

対処

動作モードから、コマンドを show path-computation-client status 実行します。

意味

出力には、アクティブなステートフル PCE と PCC の間の PCEP セッションのステータスが表示されます。また、PCC 上のさまざまなタイプの LSP に関する情報、および接続された PCE によってプロビジョニングされ、その LSP に委任された LSP の数も表示されます。

PCE1 は、主なアクティブ PCE であり、PCC によって自動的に委任された 1 つの PCE 開始 LSP を持っています。

PCE1 ステータスの検証

目的

メインのアクティブなステートフル PCE のステータスを検証します。

対処

動作モードから、コマンドを show path-computation-client active-pce detail 実行します。

意味

出力には、PCC が接続されている現在アクティブなステートフル PCE に関する情報が表示されます。出力フィールドは PCE status 、PCE と PCC 間の PCEP セッションの現在の状態を示します。

PCE1 の場合、PCEP セッションの状態は PCE_STATE_UP、PCEP セッションが PCC で確立されたことを示します。

LSP が外部プロビジョニングされている場合の PCE 開始 LSP ステータスの検証

目的

PCE によって開始された LSP のステータスを検証します。

対処

動作モードから、コマンドを show mpls lsp externally-provisioned detail 実行します。

意味

出力では、 LSPtype 出力フィールドは LSP が外部からプロビジョニングされていることを示しています。

PCC と PCE1 間の PCEP セッションが稼働し、PCC は次の PCE 開始 LSP パラメーターを受信します。

  • ERO(パス)—10.0.102.10 および 10.0.101.9

  • 帯域幅:8 Mbps

  • 優先度 — 7 0(設定および保持値)

PCE によって開始されるポイントツーポイント LSP をサポートする MPLS RSVP-TE のパス計算要素プロトコルの設定

一元化された外部パス コンピューティング エンティティから動的に作成されたラベルスイッチ パス(LSP)をサポートする機能を使用して、パス計算クライアント(PCC)を設定できます。ステートフル パス コンピューティングエレメント(PCE)を使用して、外部パス計算を実行し、需要が増加した場合に動的 LSP を生成できます。

PCC は、PCE が提供する LSP パラメーター、または PCE が LSP をプロビジョニングしない場合に事前に設定された LSP テンプレートのパラメーターを使用して PCE 開始ポイントツーポイント LSP を作成し、PCE が開始したポイントツーポイント LSP をそれぞれの PCE に自動的に委譲します。その結果、PCE によって開始される LSP では、PCC 上でローカルに設定された LSP は必要ありません。

CLI 制御 LSP、PCE 制御 LSP、PCE 開始 LSP は、PCC 上で相互に共存できます。

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

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

  • MPLS と RSVP-TE を設定します。

  • OSPF またはその他の IGP プロトコルを設定します。

PCE によって開始されるポイントツーポイント LSP をサポートするように PCC を構成するには、以下のタスクを実行します。

  1. 設定モードで、次の階層レベルに移動します。
  2. PCC が最大で受信できる 1 分間のメッセージ数を指定します。
  3. PCC が最大で受け入れ可能なすべての接続 PCE 上で、外部からプロビジョニングされたラベルスイッチ パス(LSP)の数を指定します。
  4. PCE パラメーターを設定するには、接続された PCE の固有のユーザー定義 ID を指定します。
  5. PCEP セッションが切断された後に LSP の制御をルーティング プロトコル プロセスに戻す前に、PCC が待機する必要がある時間(秒単位)を指定します。
  6. 接続する PCE の IPv4 アドレスを指定します。
  7. PCE が使用している TCP ポート番号を指定します。

    値の範囲は 1~65535 で、デフォルト値は 4189 です。

  8. PCEP セッションが終了した後に、PCE によって開始された非委任 LSP を失敗した PCE から削除する前に、PCC が待機する時間(秒単位)を指定します。
  9. PCC を設定して、接続された PCE によって外部からプロビジョニングされた SP を受け入れます。デフォルトでは、PCC は PCE によって開始された LSP を拒否します。
  10. PCEP セッションがクローズされた後に PCC が最大で受信できる 1 分間の不明なメッセージの数を指定します。

    値の範囲は 1~16384 で、デフォルト値は 0(無効または制限なし)です。

  11. PCEP セッションが終了した後に PCC が最大で受け取ることができる未知の要求数を 1 分間に指定します。

    値の範囲は 0 から 16384 までで、デフォルト値は 5 です。0 の値は、このステートメントを無効にします。

  12. PCE タイプを設定します。
  13. PCCが要求を再送信する前に応答を待つ必要がある時間(秒単位)を指定します。

    値の範囲は 0~65535 秒です。

  14. 設定を検証してコミットします。

サンプル出力

例:PCE 制御ポイントツーマルチポイント LSP をサポートする MPLS RSVP-TE のパス計算要素プロトコルの設定

この例では、ポイントツーマルチポイント トラフィックエンジニアリングされたラベルスイッチ パス(TE LSP)をパス計算要素(PCE)にレポートする機能を使用して、パス計算クライアント(PCC)を設定する方法を示しています。

要件

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

  • ACX シリーズ、M シリーズ、MX シリーズ、または T シリーズ ルーターの組み合わせが可能な 3 つのルーター。

  • 仮想ルート リフレクタ(VRR)機能を使用して構成された 1 台の仮想マシン。

  • VRR から外部ステートフル PCE への TCP 接続。

  • PCC で実行されている Junos OS リリース 16.1 以降。

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

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

  • MPLS と RSVP-TE を設定します。

  • OSPF またはその他の IGP プロトコルを設定します。

概要

PCE と PCC の間に PCEP セッションが確立されると、PCC はシステム内のすべての LSP を PCE に報告して LSP 状態を同期します。これには、PCC 制御、PCE 代行、PCE によって開始されるポイントツーポイント LSP が含まれます。Junos OS リリース 15.1F6 および 16.1R1 以降、この機能はポイントツーマルチポイント LSP のレポートにも拡張されています。

デフォルトでは、ポイントツーマルチポイント LSP の PCE 制御は PCC ではサポートされていません。この機能を追加するには、ステートメントをp2mp-lsp-report-capability階層レベルまたは[edit protocols pcep pce-group group-id]階層レベルに[edit protocols pcep pce pce-name]含めます。

トポロジ

図 7: PCE 制御ポイントツーマルチポイント LSP の例PCE 制御ポイントツーマルチポイント LSP の例

この例では、PCC はイングレス ルーター、ルーター R1 はトランジット ルーター、ルーター R2 はエグレス ルーターです。PCC は、PCE に接続されている VRR(仮想ルート リフレクタ)に接続されています。PCC、ルーター R1、ルーター R2 の間には、多くのポイントツーマルチポイント インターフェイスがあります。

ポイントツーマルチポイント LSP のレポートは、次のように実行されます。

  1. ポイントツーポイントおよびポイントツーマルチポイント LSP でルーター PCC が設定されている場合、ポイントツーマルチポイント レポート機能をサポートしていない場合、ポイントツーポイント LSP のみが接続された PCE に報告されます。デフォルトでは、PCC はポイントツーマルチポイント LSP レポート機能をサポートしていません。

  2. ルーター PCC にポイントツーマルチポイント LSP レポート機能が設定されている場合、PCC はまずこの機能をレポート メッセージを通じて PCE にアドバタイズします。

  3. デフォルトでは、PCE はポイントツーマルチポイント LSP 機能をサポートします。ポイントツーマルチポイント LSP 機能に関する PCC のアドバタイズメントを受信すると、PCE はその機能を PCC にアドバタイズします。

  4. PCE のポイントツーマルチポイント機能のアドバタイズメントを受信すると、PCC はポイントツーマルチポイント LSP のすべてのブランチを更新メッセージを使用して PCE に報告します。

  5. すべての LSP が PCE に報告されると、PCE と PCC の間で LSP 状態が同期されます。

設定

CLI クイック設定

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

PCC

R1

R2

R3

手順

手順

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

PCC ルーターを設定するには、以下の手順にしたがってください。

  1. ルーター PCC のインターフェイスを設定します。MPLS を有効にするには、インターフェイスにプロトコル ファミリーを含め、インターフェイスが受信 MPLS トラフィックを破棄しないようにします。

  2. ルーター PCC の自律システム番号を設定します。

  3. 管理インターフェイスを除く、ルーター PCC のすべてのインターフェイスで RSVP を有効にします。

  4. 管理インターフェイスを除く、ルーター PCC のすべてのインターフェイスで MPLS を有効にします。

  5. 動的 LSP を設定し、LSP の自動パス計算を無効にします。

  6. ポイントツーマルチポイント LSP を設定し、LSP の外部パス コンピューティング エンティティを定義します。

  7. MPLS LSP の外部パス コンピューティングを有効にし、外部プロビジョニング LSP 用のテンプレートを割り当てます。

  8. ローカル制御を持ち、PCE 提供の LSP パラメーターによって上書きされる LSP を設定します。

  9. MPLS 管理グループ ポリシーを設定して、制約のあるパス LSP 計算を行います。

  10. 設定した管理グループ ポリシーをルーター PCC インターフェイスに割り当てます。

  11. トラフィック エンジニアリング データベース(TED)インポート ポリシーを設定します。

  12. BGP 内部グループを設定します。

  13. BGP のトラフィック エンジニアリングを設定し、エクスポート ポリシーを割り当てます。

  14. ルーター PCC のすべてのポイントツーマルチポイント インターフェイスで OSPF エリア 0 を設定します。

  15. ルーター PCC のポイントツーポイント インターフェイスで OSPF エリア 0 を設定します。

  16. OSPF のトラフィック エンジニアリングを有効にします。

  17. ルーター PCC が接続する PCE を定義し、PCE パラメーターを設定します。

  18. 外部パス コンピューティングでポイントツーマルチポイント LSP 機能を有効にするようルーター PCC を設定します。

  19. トラフィック エンジニアリング ポリシーを設定します。

結果

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

検証

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

PCC での LSP 設定の検証

目的

ポイントツーマルチポイント LSP の LSP タイプと実行状態を検証します。

対処

動作モードから、コマンドを show mpls lsp extensive 実行します。

意味

出力には、PCE が制御する LSP として lsp2-pcc LSP が表示されます。

PCC での PCE 設定の検証

目的

PCE パラメーターの構成と PCE の状態を検証します。

対処

動作モードから、コマンドを show path-computation-client active-pce 実行します。

意味

出力には、ルーター PCC が接続されているアクティブな PCE、および pce1 PCE パラメーターと状態が表示されます。

PCE によって開始されるポイントツーマルチポイント LSP をサポートする MPLS RSVP-TE のパス計算要素プロトコルについて

ポイントツーマルチポイント PCE 開始 LSP の導入により、PCE はポイントツーマルチポイント LSP を動的に開始およびプロビジョニングできます。PCC でのローカル LSP 設定は不要です。これにより、PCE は、PCEP(Path Computation Element Protocol)セッション内および間のポイントツーマルチポイント パス計算のタイミングとシーケンスを制御できるため、一元的に制御および導入される動的ネットワークが構築されます。

PCE によって開始されるポイントツーマルチポイント LSP のメリット

ポイントツーマルチポイント LSP の動的な作成と破棄により、アプリケーションの要求に応じてポイントツーマルチポイント トラフィック エンジニアリング LSP 配置の要件を満たし、一元的に制御および導入される動的なネットワークを構築します。

PCE によって開始されるポイントツーマルチポイント LSP のシグナリング

PCE によって開始されるポイントツーマルチポイント LSP のシグナリングは次のとおりです。

  • When a new branch is added (Grafting)—新しいブランチ サブ LSP のみがシグナリングされ、ポイントツーマルチポイント ツリー全体の再シグナリングにはなりません。

    新しいサブ LSP のプロビジョニング前にトポロジの変更が発生した場合、PCS(Path Computation Server)はポイントツーマルチポイント ツリー全体を再計算し、PC 更新メッセージを使用してポイントツーマルチポイント LSP を更新します。

  • When a branch is deleted (Pruning)—削除されたブランチ サブ LSP は取り壊され、ポイントツーマルチポイント ツリー全体の再シグナリングにはなりません。

  • When a branch sub-LSP parameter is changed—ERO(Explicit Route Object)、帯域幅、優先度などのサブ LSP パラメータの変更は、最適化のために、またはユーザーの要求に応じて行われる可能性があります。サブ LSP に対する再シグナリング要求がある場合、ポイントツーマルチポイント ツリー全体が再シグナリングされ、すべてのブランチの新しいインスタンスが稼働すると、新しいインスタンスへの切り替えが行われます。

  • When a branch sub-LSP path fails—障害が発生したブランチ サブ LSP の PCS にエラーが報告されます。PCS から新しい ERO を受信すると、ポイントツーマルチポイント ツリー全体が、障害が発生したブランチ サブ LSP とともに再信号が送られ、新しいインスタンスへの切り替えは、MBB(make-before-break)の方法で行われます。

PCEP セッション障害後の PCE 開始ポイントツーマルチポイント LSP の動作

PCEP セッションが失敗すると、PCE が開始したポイントツーマルチポイント LSP は、タイマーの state timeout 有効期限が切れるまで孤立します。タイマーが state timeout 期限切れになると、PCE によって開始された LSP がクリーンアップされます。

PCEP セッション障害が発生した後に PCE が開始したポイントツーマルチポイント LSP の制御を取得するには、タイマーが期限切れになる前にプライマリまたはセカンダリ PCE からメッセージがstate timeout送信PCInitiateされます。

PCE によって開始されるポイントツーマルチポイント LSP 機能の設定

デフォルトでは、PCE によるポイントツーマルチポイント LSP の作成とプロビジョニングは、PCC ではサポートされていません。この機能を有効にするには、or [edit protocols pcep pce-group group-id] 階層レベルで p2mp-lsp-init-capability and p2mp-lsp-update-capability ステートメントを[edit protocols pcep pce pce-name]含めます。

このステートメントは p2mp-lsp-init-capability 、PCE によってポイントツーマルチポイント RSVP-TE LSP をプロビジョニングする機能を提供します。このステートメントは p2mp-lsp-update-capability 、ポイントツーマルチポイント RSVP-TE LSP パラメーターを PCE によって更新する機能を提供します。

PCE が開始するポイントツーマルチポイント LSP のサポートおよびサポートされていない機能

PCE が開始するポイントツーマルチポイント LSP では、以下の機能がサポートされています。

  • インターネット ドラフト draft-ietf-pce-stateful-pce-p2mp(2018 年 10 月期限)、 Point-to-Multipoint Traffic Engineering Label Switched Path のステートフル PCE 使用向け Path Computation Element(PCE)プロトコル拡張機能の一部に準拠しています。

  • Junos OSリリース21.1R1以降、PCEが開始するRSVPベースのポイントツーマルチポイントLSP向けのノンストップアクティブルーティング(NSR)をサポートしています。プライマリ ルーティング エンジンのみがコントローラとの PCEP セッションを維持します。PCE によって開始されたすべての RSVP LSP(PCE が開始する P2MP LSP のマルチキャスト フロー仕様など)をバックアップ ルーティング エンジンと同期します。スイッチオーバー中、PCEP セッションはダウンし、バックアップ ルーティング エンジンがプライマリ ルーティング エンジンになったときに再確立します。これにより、ルーティング エンジンの切り替え中に PCE が開始した RSVP LSP 上で転送されるトラフィックのトラフィック ロスが減少します。この機能は、NSR が設定されている場合に有効になります。

PCE が開始するポイントツーマルチポイント LSP では、以下の機能はサポートされていません。

  • ポイントツーマルチポイントローカル制御 LSP の委任。

  • LSP 制御委任。

  • IGP ルーティング ドメイン内の PCE 検出用 IGP(内部ゲートウェイ プロトコル)拡張。

  • 要求/応答メッセージ。

  • 1 つのポイントツーマルチポイント ツリーから別のポイント ツー マルチポイント ツリーへのブランチ サブ LSP の直接移動。

    これは、最初のポイントツーマルチポイント ツリーからブランチ サブ LSP を削除し、メッセージがデバイスから LSP を削除したことを示した後に、別の PCReport ポイントツーマルチポイント ツリーに再度追加することでも可能です。

  • IPv6 はサポートされていません。

  • SERO ベースのシグナリングはサポートされていません。

  • Empty-ERO機能はサポートされていません。

  • リンク保護はサポートされていません。

PCE が開始したポイントツーマルチポイント LSP を MVPN にマッピング

1 つまたは複数の MVPN マルチキャスト フロー(S、G)を、動的に作成された PCE 開始のポイントツーマルチポイント ラベルスイッチ パス(LSP)に関連付けることができます。この機能を機能させるフローの選択タイプのみを指定できます。以下はその例です。

  • MVPN ルーティング インスタンスにマッピングされた RD(ルート識別)

  • (S,G)マルチキャスト パケットおよび宛先マルチキャスト グループ アドレスの送信元です。これは、受信トラフィックをフィルタリングしてトンネルにマッピングするために使用されます。

  • 前述のフロー仕様に一致するトラフィックを送信するために使用されるポイントツーマルチポイント LSP。

詳細については、Internet draft-ietf-pce-pcep-flowspec-05(2020 年 2 月 16 日に期限切れ) フロー仕様用 PCEP Extension を参照してください。

この機能の現在の実装では、ドラフトの次のセクションは実装されていません。

  • セクション 3.1.2 — IGP における PCE の広告

  • セクション 3.2 — PCReq および PCRep メッセージ

  • セクション 7 :ルートディスタンスを除くほとんどのフロー仕様この機能の現在の実装は、サポートされていません。IPv4 マルチキャスト フローの仕様はサポートされていません。

PCE によって開始されたポイントツーマルチポイント LSP から MVPN へのマッピングを有効にするには、次の手順にしたがってください。

  • pce_traffic_steering PCC によるフロー仕様機能(トラフィック ステアリングとも呼ばれる)のサポートを示すステートメント[edit protocols pcep pce pce-id]を階層レベルに含めます。

  • 階層レベルで external-controller ステートメントを [edit routing-instances routing-instance-name provider-tunnel] 含めます。

    MVPN の external-controller プロバイダ トンネル設定に存在する場合、この MVPN インスタンスのポイントツーマルチポイント LSP および(S,G)を外部コントローラが提供できることを示しています。これにより、外部コントローラは MVPN 用に(S、G)およびポイントツーマルチポイント LSP を動的に設定できます。

PCE が開始するポイントツーマルチポイント LSP から MVPN へのマッピングについては、以下を考慮してください。

  • 特定の MVPN インスタンスに対してステートメントを external-controller pccd 有効にしない場合、PCCD プロセスは(S、G)を動的に設定しません。

  • CLI から設定を external-controller pccd 無効にした場合、その特定の MVPN インスタンスの動的に学習されたマルチキャスト フロー(S、G)が削除され、外部コントローラに報告されます。

  • (S、G)が CLI からすでに設定されている場合、ローカル設定の優先度が高いほど、PCC は(S、G)を動的に設定できません。

  • 特定の(S、G)が外部コントローラから動的に学習され、同じMVPNインスタンスに対して同じ(S、G)を設定すると、動的に学習した(S、G)が削除され、PCCを介して外部コントローラに報告されます。

  • ルーティング プロトコル プロセスが再起動すると、PCCD プロセスはすべての(S、G)を再度再設定します。

  • PCCD プロセスが再起動すると、MVPN は設定されたすべての PCCD(S、G)を外部コントローラに報告します。

  • ユーザーが特定の MVPN インスタンスを有効に external-controller pccd した場合、MVPN は PCCD プロセスに設定(S、G)を要求します(存在する場合)。

  • 特定の MPVN インスタンスに大きな設定変更がある場合、MVPN は PCCD プロセスにその特定の MVPN インスタンスのすべて(S、G)を再設定するよう要求します。

  • PCE が開始するポイントツーマルチポイント LSP に関連するすべてのフロー仕様には、同じ RD が必要です。すべてのフロー仕様に同じRDがない場合、PCの初期化中に、PC開始メッセージはエラーで削除されます。

  • ポイントツーマルチポイント LSP は、フロー指定の選択タイプにのみ関連付けることができます。そうしないと、PC 開始メッセージがエラーでドロップされます。

  • 新しいフロー仕様の追加、または既存のフロー仕様の更新により、すべてのフロー仕様がRDを同じでない場合、PCの更新中に、PCCは更新メッセージを破棄します。

  • 新しいフロー仕様の追加、または既存のフロー仕様の更新により、すべてのフロー仕様が選択条件を満たしていない場合、PC の更新中に、PCC は更新メッセージをドロップします。

  • PCE 開始のポイントツーマルチポイント LSP と MVPN ルーティング インスタンスのマッピングと、MVPN インスタンスを使用した静的(ローカル設定)ポイントツーマルチポイント LSP のマッピングの動作は、ユーザー レベルで同じです。

  • フロー仕様 ID は、1 つのポイントツーマルチポイント LSP にのみ関連付けることができます。同じ RD および(S、G)を複数のポイントツーマルチポイント LSP に関連付けるには、異なる ID と同じ RD(S、G)を持つ複数のフロー仕様を追加できます。

  • PCEP マップド ダイナミック(S、G)の場合、しきい値は常に 0 のデフォルト値 です

  • 単一の PCE 開始ポイントツーマルチポイント LSP にマッピングされたフロー仕様の数に制限はありません。

  • この機能の現在の実装では、サポートされていません。

    • ポイントツーマルチポイント LSP に関連付けられた転送状態のレポート。

    • 包括的なプロバイダ トンネル動的構成

    • MVPN イングレス レプリケーション トンネルのマッピング

    • プログラム可能なルーティング プロトコル プロセス(prpd)

    • MVPN マルチキャスト フロー(S、G)にマッピングされた CLI 設定ポイントツーマルチポイント LSP のレポート作成。

パス計算要素プロトコルのセグメント ルーティングを有効にする

SUMMARY セグメント ルーティングまたは SPRING(Networking)のソース パケット ルーティングは、トラフィック ステアリング用に PCEP(Path Computation Element Protocol)を使用して SR-TE(トラフィック エンジニアリング)を有効にできます。このサポートにより、セグメント ルーティングの利点は、PCE(Path Computation Element)によって外部制御されるラベルスイッチ パス(LSP)まで拡張されます。

パス計算要素プロトコルのセグメント ルーティングの概要

PCEP 向けセグメント ルーティングのメリット

  • 外部コントローラを使用して LSP を設定すると、ネットワーク上の LSP 単位およびデバイス単位の帯域幅需要がグローバルビューに表示され、オンラインおよびリアルタイムの制約ベースのパス計算が可能になります。

    セグメント ルーティングの利点は、PCE(Path Computation Element)とも呼ばれる外部コントローラによって開始される LSP まで拡張され、MPLS ネットワークにおける外部パス コンピューティングのメリットを高めます。

  • 委任機能を備えたパス計算クライアント(PCC、イングレスMXシリーズルーター)は、PCEPセッションがダウンしたときに、PCEから代理セグメントルーティングLSPの制御を取り戻すことができます。LSP は PCC から削除されます。したがって、パケットが通知なく破棄または破棄される状況(null ルート条件とも呼ばれます)を回避することで、LSP データ保護を確実に行うことができます。

トラフィック エンジニアリング向けセグメント ルーティング

セグメント ルーティングは、IPv4 または IPv6 データ プレーン上で動作し、ECMP(等価コスト マルチパス)をサポートします。IGP 拡張機能が組み込まれていると、セグメント ルーティングは、レイヤー 3 VPN、VPWS(仮想プライベート ワイヤ サービス)、VPLS(仮想プライベート LAN サービス)、EVPN(イーサネット VPN)など、MPLS の豊富なマルチサービス機能と統合されます。

セグメント ルーティング トラフィック エンジニアリング(SR-TE)ソリューションの概要コンポーネントには、以下のものがあります。

  • リンクの特性をアドバタイズするための IGP の使用。この機能は RSVP-TE と似ています。

  • イングレス デバイスまたは PCE での制約付き最短パス ファースト(CSPF)の使用。

  • リンクの広告ラベルに IGP を使用します。

    SR-TE 機能:

    1. イングレス デバイスは、通過するリンクのラベルをスタックして LSP を構築します。

    2. リンク単位の IGP アドバタイズメントとラベル スタックを組み合わせてイングレス デバイス上に送信元ルーティング LSP を作成するため、トランジット デバイスはエンドツーエンド LSP を認識しません。

    3. LSP は、トランジット デバイス上で LSP ごとのメモリ要件を設定することなく、エッジ ノード間で作成されます。(SR-TE では LSP 単位のシグナリングがないため、このような LSP の作成が有効になります)。

    4. ネイバー単位のラベルは積み重ねられ、結果として多数のラベルを管理し、制御プレーンのスケーリングにつながります。

Junos OS の PCEP 向けセグメント ルーティングの実装

Junos OS は、PCE 開始 LSP と PCE 代理 LSP の 2 種類の LSP に対して PCEP のセグメント ルーティングを実装します。

PCE によって開始されるセグメント ルーティング LSP

PCE が開始するセグメント ルーティング LSP は、隣接関係セグメントとノード セグメント用に PCE が作成する LSP です。

PCE は、以下の機能を実行します。

  1. セグメント ルーティング LSP のパスを計算します。

  2. PCEP セグメント ルーティング拡張機能を使用して、パス計算クライアント(PCC)で LSP をプロビジョニングします。

  3. PCEP セグメント ルーティング拡張機能を解析します。

  4. 独自の優先度値を持ち、inet.3 ルーティング テーブルで使用可能な PCC 上にトンネル ルートを作成し、他のトンネル ルートと同様に IP トラフィックとサービスを解決します。

PCC は、以下の機能を実行します。

  1. 送信元 S-ERO(Explicit Route Object)の最初のネットワーク アクセス識別子(NAI)に基づいて発信インターフェイスを選択します。

    Junos OS は、ストリクト ホップとして最初のホップを含む S-ERO をサポートしています。Junos OS は、ルーズホップ ノード セグメント ID(SID)に基づいて PCC 上の発信インターフェイスの選択をサポートしていません。ただし、残りのホップは緩い場合があります。ネクスト ホップ作成にラベルを使用する以外に、最初のホップを超える S-ERO に対して特定の処理は行いません。

  2. 以下の場合、S-EROを拒否します。

    • S-EROにはラベルがありません。

    • S-ERO は 6 ホップ以上を伝送します。

    同じメトリックを持つ同じ宛先への複数の LSP がある場合、PCC は等価コスト マルチパス(ECMP)ルートを作成します。

  3. PCE がプロビジョニング後にセグメント ルーティング LSP の変更につながるイベントを処理するまで待機します。たとえば、ラベルが変更または取り消された場合、または LSP が通過するインターフェイスのいずれかがダウンした場合などです。

PCEP セッションがダウンすると、PCE によって開始されるセグメント ルーティング LSP:

  1. 300 秒間稼働します。

  2. 300 秒後に PCC から削除されます。

詳細については、インターネット ドラフト draft-ietf-pce-lsp-setup-type-03.txt(2015 年 12 月 25 日に期限切れ)、 PCEP メッセージのパス設定タイプの伝達を参照してください。draft-ietf-pce-segment-routing-06.txt(2016 年 2 月 10 日に期限切れ)、 セグメント ルーティング用 PCEP 拡張機能

PCE 代理セグメント ルーティング LSP

PCE 代理セグメント ルーティング LSP は、PCC がローカルで設定し、PCE コントローラに委譲する LSP です。

注:

Junos OS リリース 20.1R1 は、以下をサポートしています。

  • PCE 委任機能は、IPv4 宛先を持つ非色付きセグメント ルーティング LSP に対してのみ行います。

  • 外部コントローラへのセグメント リストの最初のセグメントのみの委任と報告。複数のセグメントは、PCE 委任ではサポートされていません。

PCC は、次の方法で、セグメント ルーティング LSP を外部コントローラ(PCE)に委譲できます。

  • Initial delegation—ローカル LSP はまだ PCC で設定されておらず、LSP の委任は LSP が設定された時点で行われます。

  • Delegation of existing LSP—ローカル LSP は PCC で設定され、LSP の委任は送信元ルーティング パスが設定された後に行われます。つまり、委任機能は既存のセグメント ルーティング LSP で有効になります。

セグメント ルーティング LSP を委任した後、PCE は代理 LSP を制御し、パス計算のために LSP 属性を変更できます。PCC と PCE 間の PCEP セッションがダウンすると、LSP 制御は PCC に戻ります。PCE 代理 LSP は、PCEP セッションがダウンした場合に備えて、PCE によって開始される LSP よりも優位に立っています。PCE が開始した LSP の場合、PCEP セッションがダウンすると、LSP が PCC から削除されます。ただし、PCE 委任 LSP の場合、PCEP セッションがダウンすると、PCC は代行 LSP の制御を PCE から取り戻します。その結果、PCE によって委任された LSP では、セッションがダウンすると、パケットが通知なく破棄される状況(null ルート条件とも呼ばれます)を回避します。

次のタイプのセグメント ルーティング LSP は、PCE 委任機能をサポートしています。

  • Static LSPs— ラベル スタック全体を静的に設定したソース ルーティング パスを静的に設定します。

  • Auto-translated LSPs—自動的に変換される静的に設定された送信元ルーティング パス。

  • Computed LSPs—分散型の制約付き最短パス ファースト(CSPF)で計算される、静的に設定されたソース ルーティング パス。

  • Dynamic LSPs—ラストホップ ERO 解決を備えた動的トンネル モジュールを介してトリガーされる動的に作成されたトンネル。

セグメント ルーティング LSP のソースに応じて、PCC で委任機能を設定できます。セグメント ルーティング LSP の委任を有効にするには、階層の lsp-external-controller pccd 適切なレベルにステートメントを [edit protocols source-packet-routing] 含めます。

表 2 は、委任機能が有効になっている対応する設定階層レベルへの LSP ソースのマッピングを示しています。

注:

PCC で委任機能を lsp-external-controller pccd 構成する前に、ステートメントを [edit protocols source-packet-routing] 階層レベルと [edit protocols mpls] 階層レベルに含める必要があります。

表 2: セグメント ルーティング LSP ソースと設定階層のマッピング

セグメント ルーティング LSP のソース

設定階層

  • 自動変換 LSP

  • 静的 LSP

1 次セグメント・リスト [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

計算された LSP(分散型 CSPF)

送信元ルーティング パスのプライマリ セグメント リスト:

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name]

  • [edit protocols source-packet-routing source-routing-path lsp-name primary path-name]

動的 LSP

送信元ルーティング パス テンプレートのプライマリ セグメント リスト:

  • [edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name]

  • [edit protocols source-packet-routing source-routing-path-template template-name]

show spring-traffic-engineering コマンド出力から SR-TE LSP の制御ステータスを表示できます。

表 3 は、ステートメントが送信元ルーティング パスに対して lsp-external-controller 設定されている場合の PCEP 相互作用を表示します。

表 3: PCEP インタラクション LSP 委任

lsp-external-controller 設定階層

source-routing-pathの委任状態

PCC と PCE 間の PCEP 相互作用

送信元ルーティング パスのプライマリ セグメント リスト

最初の委任

  1. 委任のために PCReport メッセージが PCE に送信されます。PCReport には、制約とパスの詳細(ERO など)のみが含まれています。

  2. PCE は LSP のパスを計算し、ダウン状態のパスを報告します。

  3. コントローラがEROを計算し、PCUpdateを介して結果をPCCに通知するまで、ローカルLSPによってプログラムされたルートはありません。

ルーティング プロトコル プロセス(rpd)の再起動またはルーティング エンジンの切り替えが発生した場合も、同じ動作が見られます。

送信元ルーティング パスのプライマリ セグメント リスト

既存のパスの委任

  1. PCReport が委任のために PCE に送信されます。PCReport には、制約とパスの詳細(ERO など)のみが含まれています。

  2. 対応するプライマリ セグメントが PCE に委譲されます。

  3. PCE は LSP のパスを計算します。

  4. PCUpdate が PCE から受信されるまで、プライマリ セグメントはローカル構成または計算によって決定されたルートに貢献し続けます。

    • プライマリ セグメントにシームレス BFD(S-BFD)が設定されていない場合、ルートに対するそれ以上の更新はなく、LSP 状態も監視されず、PCE に報告されます。この時点の LSP 状態は、その時点でパス計算が成功したかどうかに応じて、アップまたはダウンとして報告されます。

    • S-BFD がプライマリ セグメントに対して設定されている場合、プライマリ セグメントの状態が追跡され、PCE に報告されます。BFD がダウンするプライマリ セグメントを検出すると、対応するプライマリ パスがルートから削除されます。そのパスが現在稼働している場合、以前に計算されたルートが再プログラムされます。

  5. PCE から PCUpdate メッセージを受信した場合、SR-TE は受信したパラメーターを使用して PCReport メッセージが送信されたパスを設定します。その後、プログラムされたパスには、PCE から受信したセグメント リストのみが含まれるため、以前にプログラムされたその他のすべてのセグメント リストが削除されます。このルートの再プログラミングは、ブレーク前の作成方法で行われます。

送信元ルーティング パスのプライマリ セグメント

委任が構成されていないか、削除されました。

PCE のセグメント リスト (使用可能な場合) は使用されなくなり、ローカル構成からの計算結果が使用されます。セグメント リストのローカル結果が使用可能な場合、対応するセグメント リストを使用して、ブレーク前の作成方法でルートをプログラムします。

ソース ルーティング パスのセグメント リスト

LSP の構成後に委任が有効になります。

送信元ルーティング パスのプライマリ セグメント リストに対して、委任機能がトリガーされます。

ソース ルーティング パスのセグメント リスト

委任が構成されていないか、削除されました。

委任機能は、送信元ルーティング パスのプライマリ セグメント リストから削除されます。

ソース ルーティング パス テンプレートのプライマリ セグメント リスト

LSP の構成後に委任が有効になります。

  • 送信元ルーティング パス テンプレートの下で —委任機能は送信元ルーティング パス全体に対してトリガーされます。

    テンプレート設定は、動的トンネル モジュールにのみ適用できます。

  • 送信元ルーティング パス テンプレートのプライマリ パスの下 — 設定に従って、その特定のプライマリ パスに対して委任機能がトリガーされます。

ソース ルーティング パス テンプレートのプライマリ セグメント リスト

委任が構成されていないか、削除されました。

テンプレート構成に一致するすべてのソース ルーティング パスとプライマリ パスから委任機能が削除されます。

PCEP 制限およびサポートされていない機能のセグメント ルーティング

PCEP のセグメント ルーティングをサポートしても、システムのパフォーマンス上の負担は増えません。ただし、以下の制限があります。

  • SR-TE LSP は、PCC でローカルで保護されていません。LSP が 6 ホップを超える場合、プレーン IP トラフィックを伝送する以外に、LSP にサービスは提供されません。

  • グレースフル ルーティング エンジン スイッチオーバー(GRES)と統合型無停止ソフトウェア アップグレード(統合型 ISSU)はサポートされていません。

  • ノンストップ アクティブ ルーティング(NSR)はサポートされていません。

  • IPv6 はサポートされていません。

  • PCE 代理 LSP は、以下をサポートしていません。

    • 有色 SR-TE LSP

    • IPv6 LSP

    • 送信元ルーティング パスのセカンダリ セグメント リスト。委任できるのは、セグメント リストの 1 つのパスのみです。

    • マルチセグメント標準。セグメント リストの最初のセグメントのみが委任され、コントローラに報告されます。

例:パス計算要素プロトコルのセグメント ルーティングを設定する

この例では、セグメント ルーティングまたは SOURCE Packet Routing in Networking(SPRING)トラフィック エンジニアリング(SR-TE)を、PCEP(Path Computation Element Protocol)に設定する方法を示しています。構成では、セグメント ルーティングの利点と外部パス コンピューティングのメリットを活用して、効率的なトラフィック エンジニアリングを実現します。

要件

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

  • 4 つの MX シリーズ 5G ユニバーサル ルーティング プラットフォーム(イングレス MX シリーズ ルーターが PCC(Path Computation Client)です。

  • PCC から外部ステートフル パス計算要素(PCE)への TCP 接続。

  • PCE 開始 LSP の実装用に PCC で実行されている Junos OS リリース 17.2 以降。

    PCE 委任機能の場合、Junos OS リリース 20.1R1 以降のリリースを実行する必要があります。

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

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

  • MPLS を設定します。

  • IS-IS を設定します。

概要

PCEP 向けセグメント ルーティングの Junos OS 実装には、PCE が開始した SR-TE LSP が含まれています。

  • PCE 開始 LSP の実装は Junos OS リリース 17.2R1 で導入され、セグメント ルーティングのトラフィック エンジニアリング機能は、PCE によって開始された LSP の PCEP セッションでサポートされます。PCE は隣接関係セグメントとノード セグメントの LSP を作成します。PCE によって開始された SR-TE LSP に対応する PCC の inet.3 ルーティング テーブルにトンネル ルートが作成されます。

  • PCE 代理 LSP の実装は Junos OS リリース 20.1R1 で導入され、PCC 上でローカルに設定された IPv4 非色セグメント ルーティング LSP を PCE コントローラに委任できます。次に、PCE は LSP を制御し、パス計算のために LSP 属性を変更できます。

PCE 代理 LSP は、PCEP セッションがダウンした時点で PCE が開始した LSP よりも優位に立っています。PCE が開始した LSP の場合、PCEP セッションがダウンすると、LSP が PCC から削除されます。ただし、PCE 委任 LSP の場合、PCEP セッションがダウンすると、PCC は代行 LSP の制御を PCE から取り戻します。その結果、PCE 委任 LSP では、PCEP セッションがダウンすると、パケットが通知なく破棄される(null ルート条件とも呼ばれる)状況を回避できます。

PCEP のセグメント ルーティングを有効にするには、次の手順に示します。

PCE によって開始されるセグメント ルーティング LSP の場合:

  1. ステートメントを階層レベルに含 lsp-external-controller めて、MPLS の外部パス コンピューティングを [edit protocols mpls] 有効にします。

    この設定は、RSVP-TE 拡張機能を備えた PCEP にも必要です。PCEP のセグメント ルーティングが有効になっている場合、RSVP-TE を使用して PCEP を無効にすることはできません。

  2. ステートメントを階層レベルに含 lsp-external-controller pccd めて SR-TE の外部パス コンピューティングを [edit protocols spring-traffic-engineering] 有効にします。

  3. ステートメントを階層レベルに含めて、PCE の spring-capability セグメント ルーティングを [edit protocols pcep pce pce-name] 有効にします。

  4. 必要に応じて、階層レベルでステートメントを含めて、PCE の max-sid-depth number 最大 SID 深度を [edit protocols pcep pce pce-name] 設定します。

    SID の最大深度は、ノードまたはノード上のリンクでサポートされる SID の数です。構成されていない場合、デフォルトの最大 SID 値 5 が適用されます。

  5. 必要に応じて、階層レベルに含めてセグメント ルーティングの preference preference-value プリファレンス値を [edit protocol spring-te] 設定します。

    プリファレンス値は、候補パスの間でパスがアクティブパスフォームとして選択される順序を示します。この場合、値が大きいほど優先度が高くなります。未構成の場合、デフォルトのプリファレンス値 8 が適用されます。

  6. 必要に応じて、ステートメントを階層レベルに含 traceoptions めて、トラブルシューティングのためにセグメント ルーティング ロギングを [edit protocols spring-te] 設定します。

前述の手順に加えて、セグメント ルーティング LSP の PCE 委任については、次の手順を実行します。

  1. ラベル パラメータを使用してセグメント リストを定義します。これにより、PCC 上でローカルにセグメント ルーティング LSP が作成されます。

  2. セグメント ルーティング LSP ソースに応じて、次の階層のいずれかにステートメントを lsp-external-controller pccd 含め、PCC でローカルに設定された LSP の委任機能を有効にします。

    • 分散型 CSPF で[edit protocols source-packet-routing source-routing-path lsp-name primary path-name compute profile-name] 計算される静的に構成されたソース ルーティング パスと [edit protocols source-packet-routing source-routing-path lsp-name primary path-name] 階層レベルの場合。

    • ラベル スタック全体が静的に設定されている静的に設定されたソース ルーティング パスと、自動的に変換されるソース ルーティング パスの[edit protocols source-packet-routing source-routing-path lsp-name primary path-name] 階層レベル。

    • ラストホップERO解決[edit protocols source-packet-routing source-routing-path-template template-name primary primary-segment-list-name] レベルと [edit protocols source-packet-routing source-routing-path-template template-name] 階層レベルを持つ動的トンネルモジュールを介してトリガーされる動的に作成されたトンネルの場合。

トポロジ

図 8 は、PCE と PCC(イングレス MX シリーズ ルーター)の間で PCEP セッションが実行されているネットワーク トポロジーの例を示しています。ルーター R1、R2、R3 は、ネットワーク内の他の MX シリーズ ルーターです。この例では、PCC 上で PCEP のセグメント ルーティングを設定します。また、PCC からルーター R3 への静的ルートを設定して、静的ルートのトラフィックをルーティングする際に SR-TE トンネル ルートを使用することを検証します。

図 8: PCEP のセグメント ルーティングPCEP のセグメント ルーティング

設定

CLI クイック設定

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

このセクションでは、すべてのデバイス(PCC と 3 台のルーター)の設定を示しますが、手順は PCC の設定のみを文書化しています。

PCC

ルーターR1

ルーター R2

ルーターR3

手順
手順

この例では、PCC のみを設定します。

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

PCC を設定するには、次の手順にしたがっています。

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

  2. ルーター ID を設定し、PCC の自律システム番号を割り当てます。

  3. PCC からルーター R3 への静的ルートを設定します。

    静的ルートは検証専用に作成され、機能には影響しません。

  4. 管理インターフェイスを除く、PCC のすべてのインターフェイスで RSVP を設定します。

  5. 管理インターフェイスを除く、PCC のすべてのインターフェイスで MPLS を設定します。

  6. MPLS の外部パス コンピューティング機能を有効にします。

  7. 管理インターフェイスとループバック インターフェイスを除く、PCC のすべてのインターフェイスで IS-IS レベル 2 を設定します。

  8. セグメント ルーティングの SRGB(セグメント ルーティング グローバル ブロック)属性を設定します。

  9. SR-TE の外部パス コンピューティング機能を有効にします。

  10. PCE パラメーターを設定し、PCE とセグメント ルーティング機能による LSP のプロビジョニングを有効にします。

  11. PCE によるセグメント ルーティング LSP のプロビジョニングを有効にします。

  12. PCE のセグメント ルーティング機能を有効にします。

  13. 静的セグメント リスト パラメータを定義します static_seg_list_1

  14. PCE 委任用に、PCC からルーター R3 への静的セグメント ルーティング LSP を設定します。

  15. 送信元ルーティング パスの委任機能を static_srte_lsp_1 有効にします。

    ステップ 13、14、15 を完了すると、PCC はセグメント ルーティング LSP を PCE に委譲できます。

  16. 設定をコミットします。

結果

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

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

検証

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

IS-IS 隣接関係とラベルの検証
目的

PCC 上の IS-IS 隣接関係を検証します。SRGB ラベル範囲、隣接関係とノード のセグメント値、SPRING 機能の出力フィールドをメモします。

対処

動作モードから、 、 show isis database extensive、 および コマンドをshow isis overviewshow isis adjacency extensive実行します。

意味

PCC と PCE の間の IS-IS 隣接関係と、PCC とルーター R1 の間の隣接関係が稼働し、動作しています。出力には、隣接セグメントとノード セグメントのラベル割り当ても表示されます。

トラフィック エンジニアリング データベースの検証
目的

PCC 上のトラフィック エンジニアリング データベース エントリを検証します。

対処

動作モードから、コマンドを show ted database extensive 実行します。

意味

トラフィック エンジニアリング データベースには、ルーター R1、R2、R3 からアドバタイズされたエントリーが含まれています。このエントリーは、PCE が PCC の外部パス コンピューティングに使用します。

SR-TE LSP の検証
目的

PCC での SR-TE LSP の作成を検証します。

対処

動作モードから、 、 show spring-traffic-engineering lsp detail、 および コマンドをshow route protocol spring-teshow path-computation-client lsp実行します。

意味

出力は、隣接関係セグメントとノード セグメントに対して、それぞれ 2 つの SR-TE LSPadj_sid_lsp (および node_sid_lsp—)が PCE によって作成されていることを示しています。

セグメント ルーティング LSP は、 static_srte_lsp_1委任機能で有効になっています。このフィールドは Delegation info 、PCE 委任 LSP Externally controlled の制御およびルーティング ステータスを示しています。PCE が LSP を Externally routed 制御していることを示します。これは、PCE がソース ルーティング パスに ERO を提供したことを示しています。

トンネル ルート作成の検証
目的

PCC の inet.3 ルーティング テーブルに含まれている SR-TE LSP 用に作成されたトンネル ルートを検証します。

対処

動作モードからコマンドを show route table inet.3 extensive 実行します。

意味

SR-TE をプロトコル ラベルとして使用して、PCE が制御する LSP 宛先に対してトンネル ルートが作成されました。

転送テーブル エントリの検証
目的

ルーター R3 への SR-TE LSP 宛先が PCC の転送テーブルにインストールされていることを確認します。

対処

動作モードからコマンドを show route forwarding-table destination ip-address extensive 実行します。

意味

ルーター R3 への SR-TE LSP 宛先 IP アドレスは、転送エントリとしてインストールされます。

スタティック ルート転送にトンネル ルートを使用する検証
目的

静的ルートが SR-TE LSP 用に作成されたトンネル ルートを取得していることを確認します。

対処

動作モードから、and show route forwarding-table destination ip-address コマンドをshow route ip-address実行します。

意味

出力は、ルーター R3 への静的ルートが SR-TE LSP 用に作成されたトンネル ルートを使用していることを示しています。

スタティック セグメント ルーティング ラベル スイッチ パス

セグメント ルーティング アーキテクチャにより、コア ネットワークのイングレス デバイスは、明示的なパスを通じてトラフィックを誘導できます。これらのパスは、セグメント リストを使用して、受信トラフィックが実行するパスを定義するために設定できます。受信トラフィックのラベル付けや IP トラフィックにより、イングレス デバイスでの転送操作はラベル スワップまたは宛先ベースのルックアップのいずれかになります。

MPLS ネットワークにおける静的セグメント ルーティング LSP について

送信元パケット ルーティングまたはセグメント ルーティングは、イングレス ルーターが、ネットワーク内の中間ノードに依存せずに、ネットワーク内の特定のノードとリンクを介してパケットを誘導できる制御プレーン アーキテクチャです。

セグメント ルーティング LSP の概要

セグメント ルーティングは、ソース ルーティング パラダイムを活用します。デバイスは、セグメントと呼ばれる命令の順序付けされたリストからパケットを誘導します。セグメントは、任意の命令、トポロジー、またはサービスベースを表すことができます。セグメントは、セグメント ルーティング ノードまたはセグメント ルーティング ドメイン内のグローバル ノードに対するローカル セマンティックを持ちます。セグメント ルーティングは、セグメント ルーティング ドメインへのイングレス デバイスでのみフローごとの状態を維持しながら、トポロジパスとサービス チェーンを通過するフローを適用します。セグメント ルーティングは、転送プレーンに変更を加えずに MPLS アーキテクチャに直接適用できます。セグメントは MPLS ラベルとしてエンコードされます。セグメントの順序付けされたリストは、ラベルのスタックとしてエンコードされます。処理するセグメントはスタックの最上部にあります。セグメントが完了すると、関連するラベルがスタックからポップされます。

セグメント ルーティング LSP は、本質的に動的でも静的でもかまいません。

Dynamic segment routing LSPs—セグメント ルーティング LSP が外部コントローラによって作成され、パス計算要素プロトコル(PCEP)拡張を介してイングレス デバイスにダウンロードされるか、BGP セグメント ルーティング拡張を介した BGP セグメント ルーティング ポリシーからダウンロードされると、LSP は動的にプロビジョニングされます。動的セグメント ルーティング LSP のセグメント リストは、PCEP ERO(Explicit Route Object)または LSP の BGP セグメント ルーティング ポリシーに含まれています。

Static segment routing LSPs—セグメント ルーティング LSP がローカル設定を介してイングレス デバイス上に作成されると、LSP は静的にプロビジョニングされます。

静的セグメント ルーティング LSP は、階層レベルでの[edit protocols source-packet-routing source-routing-path lsp-name]ステートメントのcolor設定に基づいて、色付き LSP と非カラー LSP に分類できます。

例えば、

[edit protocols]
    source-packet-routing {
    source-routing-path lsp_name {
        to destination_address;
        color color_value;
        binding-sid binding-label;
        primary segment_list_1_name weight weight;
        ...
        primary segment_list_n_name weight weight;
        secondary segment_list_n_name;
        sr-preference sr_preference_value;
    }
}

ここでは、各 1 次および 2 次ステートメントがセグメント・リストを参照します。

[edit protocols]
source-packet-routing {
    segment-list segment_list_name {
        hop_1_name label sid_label;
        ...
        hop_n_name label sid_label;
    }
}

セグメント ルーティング LSP を使用するメリット

  • 静的セグメント ルーティングは、トランジット ルーターの LSP 転送状態に依存しません。そのため、コア内の LSP 転送状態ごとにプロビジョニングと保守を行う必要がなくなり、

  • MPLS ネットワークの拡張性を高めます。

有色スタティック セグメント ルーティング LSP

ステートメントで color 設定された静的セグメント ルーティング LSP は、有色 LSP と呼ばれます。

有色スタティック セグメント ルーティング LSP について

BGP セグメント ルーティング ポリシーと同様に、色付き LSP のイングレス ルートは、IP トラフィックをinetcolor.0マッピングするためのキーとして、destincation-ip-address, colorテーブルまたはinet6color.0ルーティング テーブルにインストールされます。

静的な色付けされたセグメント ルーティング LSP には、ルーティング テーブルにルートがインストールされている mpls.0 バインド SID が含まれる場合があります。このバインディング SID ラベルは、ラベル付けされたトラフィックをセグメント ルーティング LSP にマッピングするために使用されます。ルートのゲートウェイは、プライマリ パスとセカンダリ パスの下のセグメント リスト設定から派生します。

色付きセグメント ルーティング LSP のセグメント リスト

色付けされた静的セグメント ルーティング LSP は、LSP を解決するための最初のホップ ラベル モードのサポートをすでに証明しています。ただし、第 1 ホップ IP モードは、有色セグメント ルーティング LSP ではサポートされていません。Junos OS リリース 19.1R1 以降では、コミット チェック機能が導入され、色付きルートに関与するすべてのセグメント リストに、すべてのホップの最小ラベルが存在することを確認します。この要件を満たさない場合、コミットはブロックされます。

非カラースタティック セグメント ルーティング LSP

ステートメントなしで color 設定された静的セグメント ルーティング LSP は、非カラー LSP です。PCEP セグメント ルーティング トンネルと同様に、イングレス ルートは、またはinet6.3ルーティング テーブルにinet.3インストールされます。

Junos OS は、イングレス ルーター上で、色なし静的セグメント ルーティング LSP をサポートします。1 つのソース ルーテッド パスと 1 つ以上のセグメント リストを設定することで、色なし静的セグメント ルーティング LSP をプロビジョニングできます。これらのセグメント リストは、複数の色なしセグメント ルーティング LSP で使用できます。

非色付きセグメント ルーティング LSP について

色なしセグメント ルーティング LSP には、一意の名前と宛先 IP アドレスがあります。宛先へのイングレス ルートは inet.3 ルーティング テーブルにインストールされ、デフォルト設定は 8、メトリックは 1 です。このルートでは、非カラー サービスを宛先に関連するセグメント ルーティング LSP にマッピングできます。色なしセグメント ルーティング LSP にイングレス ルートが必要ない場合は、イングレス ルートを無効にできます。色なしセグメント ルーティング LSP は、バインド SID ラベルを使用してセグメント ルーティング LSP スティッチングを実現します。セグメント ルーティング LSP をセグメントとしてモデル化するために使用できるこのラベルは、他のセグメント ルーティング LSP を階層的な方法で構築するためにさらに使用できます。バインド SID ラベルのトランジットは、既定では、優先度は 8、メトリックは 1 です。

Junos OS リリース 18.2R1 以降では、イングレス デバイス上で静的に設定された色なしセグメント ルーティング LSP は、PCEP(Path Computation Element Protocol)セッションを介して、PCE(Path Computation Element Protocol)セッションに報告されます。これらの色なしセグメント ルーティング LSP には、それらに関連付けられた SID(バインディング サービス識別子)ラベルが含まれる場合があります。この機能を使用すると、PCE はラベル スタックでこのバインド SID ラベルを使用して、PCE によって開始されたセグメント ルーティング LSP パスをプロビジョニングできます。

色なしセグメント ルーティング LSP は、最大 8 個のプライマリ パスを持つ場合があります。複数の運用プライマリ パスがある場合、パケット転送エンジン(PFE)は、パスに設定された重み付けなどのロード バランシング要因に基づいて、パスを介してトラフィックを分散します。パスのいずれも重み付けされていない場合はECMP(等価コストマルチパス)、パスに少なくとも1つのパスにゼロ以外の重みが設定されている場合は、ECMP(重み付けECMP)になります。どちらの場合も、パスの 1 つまたは一部に障害が発生した場合、PFE は残りのパスを介してトラフィックを再調整し、自動的にパス保護を実現します。色なしセグメント ルーティング LSP には、専用のパス保護用のセカンダリ パスを使用できます。プライマリ パスに障害が発生すると、PFE は残りの機能するプライマリ パスにトラフィックを再調整します。それ以外の場合、PFE はトラフィックをバックアップ パスに切り替え、パス保護を実現します。色なしセグメント ルーティング LSP は、イングレスおよびバインディング SID ルートのメトリック [edit protocols source-packet-routing source-routing-path lsp-name] を指定できます。複数の色なしセグメント ルーティング LSP は、イングレス ルートのネクスト ホップに貢献する同じ宛先アドレスを持ちます。

複数の色なしセグメント ルーティング LSP は、イングレス ルートのネクスト ホップに貢献する同じ宛先アドレスを持ちます。各セグメント ルーティング LSP の各パス(プライマリまたはセカンダリ)は、パスが機能していて、セグメント ルーティング LSP がこれらすべてのセグメント ルーティング LSP の最適な優先度を持っている場合、ゲートウェイ候補と見なされます。ただし、ネクスト ホップが保持できるゲートウェイの最大数は、デフォルトで 128 である RPD マルチパス制限を超えることはできません。余分なパスは、最初に 2 次パス、次にプライマリ パスを削除します。特定のセグメント リストは、これらのセグメント ルーティング LSP によってプライマリ パスまたはセカンダリ パスと複数回呼ばれます。この場合、複数のゲートウェイがあり、それぞれ固有のセグメント ルーティング LSP トンネル ID を持ちます。ゲートウェイは異なりますが、出力ラベル スタックとインターフェイスは同一です。非色付きセグメント ルーティング LSP と色付きセグメント ルーティング LSP も、同じ宛先アドレスを持つ場合があります。ただし、色付きのセグメント ルーティング LSP の宛先アドレスは宛先アドレスと色の両方で構築されるため、イングレス ルートの異なる宛先アドレスに対応します。

注:

静的な非色付きセグメント ルーティング LSP と PCEP が作成したセグメント ルーティング LSP が共存し、同じイングレス ルートに貢献するアドレスが同じである場合でも、同じ優先度を持つ場合。それ以外の場合、最適な優先度のセグメント ルーティング LSP がルートにインストールされます。

非色付きセグメント ルーティング LSP のセグメント リスト

セグメント・リストは、ホップのリストで構成されます。これらのホップは、SID ラベルまたは IP アドレスに基づいています。セグメント リスト内の SID ラベルの数は、最大セグメント リストの制限を超えてはなりません。LSP トンネルへの最大セグメント リスト バインディングは 8 から 128 に増加し、システム当たり最大 1,000 トンネル。静的セグメント ルーティング LSP ごとに最大 128 個のプライマリ パスがサポートされています。最大セグメント リスト制限は、階層レベルで [edit protocols source-packet-routing] 設定できます。

Junos OS リリース 19.1R1 より前のバージョンでは、色なしスタティック セグメント ルーティング LSP を使用可能にするには、セグメント リストの最初のホップが発信インターフェイスの IP アドレスである必要があり、2 番目から n 番目のホップは SID ラベルである可能性があります。Junos OS リリース 19.1R1 以降では、色なし静的 LSP の最初のホップが IP アドレスに加えて SID ラベルのサポートを提供するため、この要件は適用されません。最初のホップ ラベルのサポートにより、MPLS 高速リルート(FRR)と重み付き等価コスト マルチパスが有効になり、有色スタティック LSP と同様に、静的な非カラー セグメント ルーティング LSP を解決できます。

最初のホップ ラベル モードを有効にする場合は、セグメント リストに対してステートメントを inherit-label-nexthops グローバルまたは個別に含める必要があり、セグメント リストの最初のホップには IP アドレスとラベルの両方を含める必要があります。最初のホップに IP アドレスのみが含まれている場合、 inherit-label-nexthops ステートメントは影響を与えません。

次のいずれかの階層で構成 inherit-label-nexthops できます。ステートメントは inherit-label-nexthops 、セグメント・リストの最初のホップに IP アドレスとラベルの両方が含まれている場合にのみ有効になります。

  • Segment list level—階層レベルで [edit protocols source-packet-routing segment-list segment-list-name]

  • Globally—階層レベルで [edit protocols source-packet-routing]

ステートメントが inherit-label-nexthops グローバルに設定されている場合、ステートメントはセグメント リスト レベルの設定よりも優先され inherit-label-nexthops 、設定はすべてのセグメント リストに適用されます。ステートメントがグローバルに設定されていない場合、最初の inherit-label-nexthops ホップにラベルと IP アドレスの両方が存在し、ステートメントで inherit-label-nexthops 設定されたセグメント リストのみが SID ラベルを使用して解決されます。

PCEP 駆動型セグメント ルーティング LSP である動的な非色付き静的 LSP の場合、 inherit-label-nexthops セグメント レベルの設定が適用されないので、ステートメントをグローバルに有効にする必要があります。

表 4 は、最初のホップ仕様に基づいたセグメント ルーティング LSP 解決のモードについて説明します。

表 4: ファースト ホップ仕様に基づく非カラースタティック LSP 解決

ファーストホップ仕様

LSP 解決モード

IP アドレスのみ

例えば、

segment-list path-1 {
    hop-1 ip-address 172.16.12.2;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

セグメント リストは IP アドレスを使用して解決されます。

SID のみ

例えば、

segment-list path-2 {
    hop-1 label 1000011;
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

セグメント リストは SID ラベルを使用して解決されます。

IP アドレスと SID(設定なし inherit-label-nexthops )

例えば、

segment-list path-3 {
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

デフォルトでは、セグメント リストは IP アドレスを使用して解決されます。

IP アドレスと SID(設定あり inherit-label-nexthops )

例えば、

segment-list path-3 {
    inherit-label-nexthops;
    hop1 {
        label 801006;
        ip-address 172.16.1.2;
    }
    hop-2 label 1000012;
    hop-3 label 1000013;
    hop-4 label 1000014;
}

セグメント リストは SID ラベルを使用して解決されます。

コマンドを show route ip-address protocol spring-te active-path table inet.3 使用すると、inet.3 ルーティング テーブルに複数のセグメント リストがインストールされている、色なしセグメント ルーティング トラフィックエンジニアリング LSP を表示できます。

例えば、

注:

静的セグメント ルーティング LSP の最初のホップ タイプのセグメント リストは、次の場合にコミットが失敗する可能性があります。

  • トンネルのセグメント リストが異なると、最初のホップ解決タイプが異なります。これは、有色および非カラーの静的セグメント ルーティング LSP の両方に適用されます。ただし、これは PCEP ドリブン LSP には当てはまりません。パスのコンピューティング時に、最初のホップ解決タイプの不一致に対してシステム・ログ・メッセージが生成されます。

    例えば、

    パス-1 は IP アドレス モードで、パス 2 はラベル モードであるため、トンネル lsp1 のコミットは失敗します。

  • バインド SID は、セグメント リストの種類が SID ラベルである静的な色なし LSP に対して有効になります。

    例えば、

    ラベル セグメント リスト上のバインド SID の構成は、色付き静的 LSP でのみサポートされ、色なし静的 LSP ではサポートされていません。

静的セグメント ルーティング LSP プロビジョニング

セグメント プロビジョニングは、ルーターごとに実行されます。ルーター上の特定のセグメントでは、隣接関係 SID ラベルの動的ラベル プールから、またはプレフィックス SID またはノード SID のセグメント ルーティング グローバル ブロック(SRGB)から、必要なラベル プールから固有のサービス識別子(SID)ラベルが割り当てられます。隣接関係 SID ラベルは、既定の動作である動的に割り当てることも、ローカルの静的ラベル プール(SRLB)から割り当てることもできます。その後、SID ラベルのルートが mpls.0 テーブルにインストールされます。

Junos OS では、ステートメントを階層レベルで設定することで、 segment 静的セグメント ルーティング LSP を [edit protocols mpls static-label-switched-path static-label-switched-path] 使用できます。静的セグメント LSP は、Junos OS スタティック ラベル プールに該当する一意の SID ラベルによって識別されます。ステートメントを階層レベルで設定することで、Junos OS 静的ラベル プールを[edit protocols mpls label-range]設定static-label-range static-label-rangeできます。

スタティック セグメント ルーティング LSP の制限事項

  • 現在、Junos OS には、最大セグメント リストの奥行きラベルを超えてプッシュするようにネクスト ホップを構築できないという制限があります。そのため、最大 SID ラベルを超えるセグメント リスト(転送ネクスト ホップの解決に使用される最初のホップの SID ラベルを除く)は、色付きセグメント ルーティング LSP または非色付きセグメント ルーティング LSP には使用できません。また、MPLS サービスがセグメント ルーティング LSP 上にある場合、またはセグメント ルーティング LSP がリンクまたはノード保護パス上にある場合、特定のセグメント ルーティング LSP で許可される実際の数は、最大制限よりもさらに小さい場合があります。いずれの場合も、サービス ラベル、SID ラベル、リンクまたはノード保護ラベルの合計数は、最大セグメント リストの奥行きを超えてはなりません。最大セグメント リスト制限は、階層レベルで [edit protocols source-packet-routing] 設定できます。最大 SID ラベル以下の複数の色なしセグメント ルーティング LSP をつなぎ合わせて、より長いセグメント ルーティング LSP を構築できます。これをセグメントルーティングLSPスティッチングと呼んでいます。バインディング SID ラベルを使用して達成できます。

  • セグメント ルーティング LSP スティッチングは、実際にはパス レベルで実行されます。色なしセグメント ルーティング LSP に複数のセグメント リストである複数のパスがある場合、各パスをスティッチング ポイントで別の色なしセグメント ルーティング LSP に個別にスティッチできます。スティッチング専用の非色付きセグメント ルーティング LSP では、階層レベルで[edit protocols source-packet-routing source-routing-path lsp-name] ステートメントを設定no-ingressすることでイングレス ルートのインストールが無効になる場合があります。

  • 最大 128 個のプライマリ パスと 1 個のセカンダリ パスが、色なしスタティック セグメント ルーティング LSP ごとにサポートされます。設定に違反があった場合、コミット チェックはエラーで失敗します。

  • LSP トンネルへの最大セグメント リスト バインディングは 8 から 128 に増加し、システム当たり最大 1,000 トンネル。静的セグメント ルーティング LSP ごとに最大 128 個のプライマリ パスがサポートされています。制限として、LSP パスの最大センサー サポートは 32000 のみです。

  • セグメント リストが最大セグメント リストの奥行きを超えるラベルで設定されている場合、設定コミット チェックは失敗し、エラーが発生します。

セグメント ルーティング LSP の動的な作成

各プロバイダ エッジ(PE)デバイスが他のすべての PE デバイスに接続されているセグメント ルーティング ネットワークでは、セグメント ルーティングラベルスイッチ パス(LSP)の設定に大量の設定が必要になりますが、使用できるのは少数のセグメント ルーティング トラフィックエンジニアリング(SR-TE)パスのみです。これらの LSP の BGP トリガー化された動的な作成を有効にして、このような導入における設定量を削減できます。

動的セグメント ルーティング LSP テンプレートの設定

セグメント ルーティング LSP の動的な作成を有効にするテンプレートを構成するには、 spring-te ステートメントを階層に [edit routing-options dynamic-tunnels] 含める必要があります。

  • 次に、カラー ダイナミック セグメント ルーティング LSP テンプレートの設定例を示します。

  • 次に、非カラー ダイナミック セグメント ルーティング LSP テンプレートの設定例を示します。

動的セグメント ルーティング LSP の解決
色付き動的セグメント ルーティング LSP の解決

BGP プレフィックスがカラー コミュニティで割り当てられると、最初は catch-all-route-for-the-particular-color ポリシーで解決され、さらに BGP プレフィックスを解決する SR-TE テンプレートが識別されます。その後、宛先 SID は BGP ペイロード プレフィックスのネクスト ホップ属性から派生します。たとえば、BGP ペイロード プレフィックスのネクスト ホップがデバイス A に属する IP アドレスである場合、デバイス A の node-SID が取得され、対応するラベルが準備され、スタックの一番下にプッシュされます。BGP ペイロード プレフィックスはカラーのみモードで解決されます。ここでは、デバイス A の node-SID が最終ラベル スタックの最下部にあり、SR-TE パス ラベルが上にあります。

最後の LSP テンプレート名は、プレフィックス、色、トンネル名の組み合わせです。例えば. <prefix>:<color>:dt-srte-<tunnel-name> LSP 名の色は 16 進形式で表示され、トンネル名の形式は RSVP トリガー トンネル LSP 名と似ています。

色付きの宛先ネットワークを正常に解決するには、カラーに、特定の色またはテンプレートを介した有効なテンプレート マッピングが color-any 必要です。有効なマッピングがない場合、トンネルは作成されず、解決を要求する BGP ルートは未解決のままです。

色なし動的セグメント ルーティング LSP の解決

カラーなし LSP のキャッチオール ルートが inet.3 ルーティング テーブルに追加されます。色なしトンネル宛先は、マッピング リストにテンプレート名を 1 つだけ持つ別 spring-te の設定で設定する必要があります。このテンプレート名は、同じ spring-te 設定で設定されたすべての宛先ネットワークに一致するすべてのトンネル ルートに使用されます。これらのトンネルは、機能における RSVP トンネルと似ています。

最後の LSP テンプレート名は、プレフィックス名とトンネル名の組み合わせです。例えば. <prefix>:dt-srte-<tunnel-name>

動的セグメント ルーティング LSP の設定例

動的セグメント ルーティング LSP テンプレートは、常に部分的なパスを伝送します。最後のホップ ノード SID は、プロトコルの PNH(ネクスト ホップ アドレス)ノード SID に応じて、トンネルの作成時に自動的に生成されます。同じテンプレートは、異なる宛先への複数のトンネルで使用できます。このような場合、部分パスは同じままで、PNH に応じて最後のホップのみが変更されます。動的セグメント ルーティング LSP テンプレートは、1 つのトンネルでは一般的ではありません。そのため、フル パスを伝送できません。完全なパスを使用する場合は、セグメント リストを使用できます。

色付き動的セグメント ルーティング LSP

色付き動的セグメント ルーティング LSP の設定例:

前述のサンプル設定では、ルート エントリーは次のとおりです。

  1. inetcolor.0 tunnel route:10.22.44.0-0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(プレフィックス) -> 10。22.44.55-101(PNH)LSP トンネル名 = 10。22.44.55:65:dt-srte-tunnel1

    R1(プレフィックス) ->ff::10.22.44.55-101(PNH)LSP トンネル名 = 10。22.44.55:65:dt-srte-tunnel1

    R1(プレフィックス) ->ff::10.22.44.55-124(PNH)LSP トンネル名 = 10。22.44.55:7c:dt-srte-tunnel1

  4. inetcolor.0 tunnel route:

    10.22.44.55-101/64 --> <next-hop>

    10.22.44.55-124/64 --> <next-hop>

  5. inetcolor6.0 tunnel route:

    ffff::10.22.44.55-101/160 --> <next-hop>

    ffff::10.22.44.55-124/160 --> <next-hop>

非色付き動的セグメント ルーティング LSP

カラーなし動的セグメント ルーティング LSP の設定例:

前述のサンプル設定では、ルート エントリーは次のとおりです。

  1. inet.3 tunnel route:10.33.44.0/24 --> RT_NH_TUNNEL

  2. inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping:

    R1(プレフィックス) -> 10.33.44.55(PNH) LSP テンプレート名 = LSP1 --- 10.33.44.55:dt-srte-tunnel2

    R1(プレフィックス) ->ffff::10.33.44.55(PNH)LSP テンプレート名 = LSP1 --- 10.33.44.55:dt-srte-tunnel2

  4. inet.3 tunnel route:10.33.44.55/32 --> <next-hop>

  5. inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>

未解決の動的セグメント ルーティング LSP

未解決の動的セグメント ルーティング LSP の設定例:

前述のサンプル設定では、ルート エントリーは次のとおりです。

  1. inetcolor.0 tunnel route:10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0/24 --> RT_NH_TUNNEL

  2. inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0/24 --> RT_NH_TUNNEL

  3. BGP prefix to tunnel mapping: R1(プレフィックス)-> 10.33.44.55-124(PNH)トンネルは作成されません。(色のテンプレートが見つかりません)。

セグメント ルーティング LSP の動的作成の構成に関する考慮事項

セグメント ルーティング LSP の動的な作成を構成する場合は、以下を考慮してください。

  • テンプレートは、カラー オブジェクトを使用して割り当てることができます。動的トンネル spring-te 設定にカラー オブジェクトを持つテンプレートが含まれている場合は、他のすべてのテンプレートもカラー オブジェクトで設定する必要があります。すべての宛先は、その設定内で色付けされたものと見なされます。

  • テンプレートには色のリストを定義することも、オプションで color-any 設定することもできます。どちらのオプションも同じ spring-te 設定で共存できます。このような場合、特定の色で割り当てられたテンプレートの優先度が高くなります。

  • spring-te設定では、オプションでcolor-any定義できるテンプレートは 1 つだけです。

  • 色からテンプレートへのマッピングは、1 対 1 で行われます。1 つの色を複数のテンプレートにマッピングできません。

  • テンプレート名は、階層の下のspring-teステートメントで設定し、オプションを有効にするprimary必要[edit protocols]があります。

  • 色付き宛先と色なし宛先を同じ spring-te 設定に共存することはできません。

  • 異なる spring-te 設定ステートメントの下で、色の有無にかかわらず、同じ宛先ネットワークを設定することはできません。

  • spring-te なし設定では、カラー オブジェクトなしで設定できるテンプレートは 1 つだけです。

動的セグメント ルーティング LSP でサポートされるサービス

次のサービスは、色付き動的セグメント ルーティング LSP でサポートされています。

  • レイヤー 3 VPN

  • BGP EVPN

  • 輸出ポリシー サービス

以下のサービスは、色なし動的セグメント ルーティング LSP でサポートされています。

  • レイヤー 3 VPN

  • レイヤー 2 VPN

  • マルチパス構成

セグメント ルーティングにおける複数のトンネル ソースでの動作

2 つのソースがセグメント ルーティングから同じ宛先にルートをダウンロードする場合(静的トンネルや動的送信元トンネルなど)、アクティブ ルート エントリの選択にセグメント ルーティングの優先度が使用されます。値が大きいほど優先度が高くなります。プリファレンスが変わらない場合は、トンネル ソースを使用してルート エントリを決定します。

動的セグメント ルーティング LSP の制限事項

動的 SR-TE LSP は、以下の機能をサポートしていません。

  • IPv6 セグメント ルーティング トンネル。

  • 静的トンネル。

  • 6PE はサポートされていません。

  • 分散型 CSPF

  • sBFD および LDP トンネリングは、動的 SR-TE LSP およびテンプレートではサポートされていません。

  • テンプレートにインストールし、B-SID ルートを作成します。

VPN サービスの色ベースのマッピング

カラーをプロトコルのネクスト ホップ制約(IPv4 または IPv6 アドレスに加えて)として指定し、静的な色付き BGP セグメント ルーティング トラフィックエンジニアリング(SR-TE)LSP を介してトランスポート トンネルを解決できます。これは color-IP プロトコルのネクスト ホップ解決と呼ばれ、解決マップを設定して VPN サービスに適用する必要があります。この機能を使用すると、レイヤー 2 およびレイヤー 3 VPN サービスのカラーベースのトラフィック ステアリングを有効にできます。

Junos OS は、単一のカラーに関連付けられたカラー付 き SR-TE LSP をサポートしています。VPN サービス機能の色ベースのマッピングは、静的な色付き LSP と BGP SR-TE LSP でサポートされています。

VPNサービスカラーリング

一般的に、VPN NLRI がアドバタイズされているエグレス ルーターや、VPN NLRI を受信して処理するイングレス ルーターでは、VPN サービスに色を割り当てることができます。

VPN サービスには、次の異なるレベルで色を割り当てることができます。

  • ルーティング インスタンス単位。

  • BGP グループ単位。

  • BGP ネイバー単位。

  • プレフィックス当たり。

色を割り当てると、BGP カラー拡張コミュニティの形式で VPN サービスに色がアタッチされます。

マルチカラー VPN サービスと呼ばれる複数の色を VPN サービスに割り当てることができます。このような場合、最後にアタッチされた色は VPN サービスの色と見なされ、その他のすべての色は無視されます。

複数のポリシーを使用して、エグレス デバイスまたはイングレス デバイスによって、次の順序で複数の色が割り当てられます。

  • エグレス デバイス上の BGP エクスポート ポリシー。

  • イングレス デバイス上の BGP インポート ポリシー。

  • イングレス デバイス上の VRF インポート ポリシー。

VPN サービスカラーリングの 2 つのモードは次のとおりです。

エグレス カラーの割り当て

このモードでは、エグレス デバイス(VPN NLRI の広告主)が VPN サービスのカラーリングを行います。このモードを有効にするには、ルーティング ポリシーを定義し、階層レベルで VPN サービスのルーティング インスタンス vrf-export、グループ エクスポート、またはグループ ネイバーエクスポートに [edit protocols bgp] 適用します。VPN NLRI は、指定されたカラー拡張コミュニティを使用して BGP によってアドバタイズされます。

例えば、

または

注:

ルーティング ポリシーを BGP グループまたは BGP ネイバーのエクスポート ポリシーとして適用する場合、ポリシーが VPN NLRI に影響を与えるためには、BGP、BGP グループ、または BGP ネイバー レベルにステートメントを含める vpn-apply-export 必要があります。

ルーティング ポリシーは、レイヤー 3 VPN プレフィックス NLRIs、レイヤー 2 VPN NRRI、EVPN NLRI に適用されます。カラー拡張コミュニティは、すべての VPN ルートによって継承され、1 つまたは複数のイングレス デバイス上のターゲット VRF にインポートされ、インストールされます。

イングレスカラーの割り当て

このモードでは、イングレス デバイス(つまり、VPN NLRI のレシーバ)が VPN サービスのカラーリングを行います。このモードを有効にするには、ルーティングポリシーを定義し、階層レベルでVPNサービスのルーティングインスタンス vrf-import、グループインポート、またはグループネイバーインポートに [edit protocols bgp] 適用します。ルーティング ポリシーに一致するすべての VPN ルートが、指定された色の拡張コミュニティにアタッチされます。

例えば、

または

VPN サービス マッピング モードの指定

柔軟なVPNサービスマッピングモードを指定するには、ステートメントを使用してポリシーを resolution-map 定義し、階層レベルでVPNサービスのルーティングインスタンス vrf-import、グループインポート、またはグループネイバーインポートでポリシーを参照する [edit protocols bgp] 必要があります。ルーティング ポリシーに一致するすべての VPN ルートが、指定された解決マップにアタッチされます。

例えば、

VPN サービスのルーティング インスタンスにインポート ポリシーを適用できます。

また、BGP グループまたは BGP ネイバーにインポート ポリシーを適用することもできます。

注:

各 VPN サービス マッピング モードでは、解決マップで一意の名前を定義する必要があります。解決マップでは IP-color の 1 つのエントリーのみがサポートされ、VPN ルートは次の ip-address:color形式で色付き IP プロトコルのネクスト ホップを使用して解決されます。

Color-IP プロトコルのネクスト ホップ解決

プロトコルのネクスト ホップ解決プロセスが拡張され、有色 IP プロトコルのネクスト ホップ解決がサポートされます。カラー付き VPN サービスの場合、プロトコルのネクスト ホップ解決プロセスは、色と解像度マップを取得し、 IP-address:color という形式で色付き IP プロトコルのネクスト ホップを構築し、inet6color.0 ルーティング テーブル内のプロトコルのネクスト ホップを解決します。

色付き LSP 上の色付きレイヤー 2 VPN、レイヤー 3 VPN、または EVPN サービスのマルチパス解決をサポートするようにポリシーを設定する必要があります。その後、リゾルバーのインポート ポリシーとして、関連する RIB テーブルにポリシーを適用する必要があります。

例えば、

IP プロトコルのネクスト ホップ解決にフォールバック

色付き VPN サービスに解像度マップが適用されていない場合、VPN サービスはその色を無視し、IP プロトコルのネクスト ホップ解決に戻ります。反対に、色なし VPN サービスに解像度マップが適用されている場合、解決マップは無視され、VPN サービスは IP プロトコルのネクスト ホップ解決を使用します。

フォールバックは、カラー付き SR-TE LSP から LDP LSP へのシンプルなプロセスで、LDP 用の RIB グループを使用して inet{6}color.0 ルーティング テーブルにルートをインストールします。色付き IP プロトコルのネクスト ホップで最も長いプレフィックスが一致すると、有色 SR-TE LSP ルートが存在しない場合は、一致する IP アドレスを持つ LDP ルートが返されます。

SR-TE 上の BGP ラベル付きユニキャスト カラーベース マッピング

Junos OSリリース20.2R1以降、BGPラベル付きユニキャスト(BGP-LU)は、IPv4およびIPv6アドレスファミリーの両方のセグメントルーティングトラフィックエンジニアリング(SR-TE)を介してIPv4またはIPv6ルートを解決できます。BGP-LU は、BGP コミュニティ カラーのマッピングと SR-TE の定義を resolution map サポートしています。色付きプロトコルのネクスト ホップが構築され、or inet6color.0 テーブルのカラー付き SR-TE トンネルでinetcolor.0解決されます。BGPは、非カラーベースのマッピングに使用およびinet6.3テーブルを使用inet.3します。これにより、ルーターにIPv4アドレスが設定されていないIPv6のみのネットワークで、IPv6のネクストホップアドレスを持つBGP-LU IPv6およびIPv4プレフィックスをアドバタイズできます。この機能により、現在、IS-ISアンダーレイを使用して、SR-TE上のBGP IPv6 LUをサポートしています。

では 図 9、コントローラは SR-TE で設定された IPv6 コア ネットワークで 4 つの色付きトンネルを設定します。色付きの各トンネルは、定義された解決マップに応じて、宛先ルーターDへの異なるパスを取得します。コントローラは、ルーター D の 2001:db8::3701:2d05 インターフェイスに色付き SR-TE トンネルを設定します。BGP はポリシーをインポートして、受け取ったプレフィックス 2001:db8::3700:6/128 にカラー マップと解決マップを割り当てます。割り当てられたコミュニティ カラーに基づいて、BGP-LU は、割り当てられた解決マップ ポリシーに従って、BGP IPv6 LU プレフィックスの色付きネクスト ホップを解決します。

図 9: BGP IPv6 LU オーバーカラー IPv6 SR-TE BGP IPv6 LU オーバーカラー IPv6 SR-TE

BGP-LU は、次のシナリオをサポートします。

  • BGP IPv4 LU over colored BGP IPv4 SR-TE、ISIS/OSPF IPv4 SR 拡張機能。

  • ISIS/OSPF IPv4 SR 拡張機能を備えた BGP IPv4 LU(静的カラー付きおよび非カラー IPv4 SR-TE)

  • BGP IPv6 LU over 有色 BGP IPv6 SR-TE、ISIS IPv6 SR 拡張機能付き。

  • ISIS IPv6 SR拡張機能を備えた、静的な色付きおよび非カラーのIPv6 SR-TE上のBGP IPv6 LU。

  • IPv6 ローカル アドレスと IPv6 ネイバー アドレスを備えた IPv6 レイヤー 3 VPN サービス。

  • BGP IPv6 SR-TE 上の IPv6 レイヤー 3 VPN サービスと ISIS IPv6 SR 拡張機能。

  • IPv6 レイヤー 3 VPN サービスは、ISIS IPv6 SR 拡張機能を備えた静的な色付きおよび非カラーの IPv6 SR-TE を介します。

VPNサービスのカラーベースマッピングのサポートおよびサポートされていない機能

VPN サービスの色ベースのマッピングでは、以下の機能がサポートされています。

  • BGP レイヤー 2 VPN(Kompella レイヤー 2 VPN)

  • BGP EVPN

  • 単一の IP カラー オプションを使用した解像度マップ。

  • 色付き IPv4 および IPv6 プロトコルのネクスト ホップ解決。

  • ルーティング情報ベース(ルーティング テーブルとも呼ばれます)グループベースの、inetcolor.0 ルーティング テーブルの LDP LSP へのフォールバック。

  • カラー付き SR-TE LSP。

  • 仮想プラットフォーム。

  • 64 ビット Junos OS。

  • 論理システム。

  • ユニキャストとラベル付けされたBGP。

VPN サービスの色ベースのマッピングでは、以下の機能はサポートされていません。

  • 有色 MPLS LSP(RSVP、LDP、BGP-LU、静的など)。

  • レイヤー 2 回線

  • FEC-129 BGP 自動検出および LDP 信号レイヤー 2 VPN

  • VPLS

  • MVPN

  • 解決マップを使用した IPv4 および IPv6。

PCE によって開始されるセグメント ルーティング LSP のトンネル テンプレート

PCE が開始するセグメント ルーティング LSP のトンネル テンプレートを設定して、これらの LSP(BFD(双方向転送検出)と LDP トンネリングの 2 つの追加パラメーターを引き渡すことができます。

PCE 開始セグメント ルーティング LSP が作成されている場合、ポリシー ステートメント(存在する場合)に対して LSP がチェックされ、一致する場合は、その LSP に対して設定されたテンプレートが適用されます。テンプレート設定は、LSP ソース(PCEP)によって提供されていない場合にのみ継承されます。たとえば、メトリックです。

テンプレートを設定するには、以下の手順に応じ、テンプレートを設定します。

  1. 階層レベルで source-routing-path-template ステートメントを [edit protocols source-packet-routing] 含めます。追加の BFD および LDP トンネリング パラメータは、ここで設定できます。

  2. ソースルーティングパステンプレートマップステートメントを階層レベルに[edit protocols source-packet-routing]含め、PCEが開始するLSPをチェックするポリシーステートメントをリストします。

  3. テンプレートを適用する LSP を一覧表示するポリシーを定義します。

    ステートメントにはfrom、and lsp-regex 照合条件を使用して、LSP 名または LSP 正規表現のいずれかを含lspめることができます。これらのオプションは相互に排他的であるため、特定の時点で 1 つのオプションのみを指定できます。

    ステートメントには then 、accept アクションを sr-te-template 含むオプションを含める必要があります。これにより、PCE によって開始された LSP にテンプレートが適用されます。

PCE が開始する LSP 用のテンプレートを構成する場合は、以下を考慮してください。

  • テンプレートの設定は、静的に設定されたセグメント ルーティング LSP、またはその他のクライアントのセグメント ルーティング LSP には適用されません。

  • PCEP が提供する設定は、テンプレート設定よりも優先されます。

  • PCEP LSP は、テンプレート のセグメント リスト構成を継承しません。

例:スタティック セグメント ルーティング ラベルスイッチ パスの設定

この例では、MPLS ネットワークで静的セグメント ルーティング ラベルスイッチ パス(LSP)を設定する方法を示しています。この構成は、MPLS ネットワークの拡張性を高めるのに役立ちます。

要件

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

  • 7 つの MX シリーズ 5G ユニバーサル ルーティング プラットフォーム

  • すべてのルーターで実行されている Junos OS リリース 18.1 以降

開始する前に、必ずデバイス インターフェイスを設定してください。

概要

Junos OS では、ステートメントを階層レベルで設定することで、色なし静的セグメント ルーティング トンネルのイングレス ルーター上に、一連の明示的なセグメント ルーティング パスが[edit protocols source-packet-routing]設定segment-list されます。ステートメントを階層レベルで[edit protocols source-packet-routing]設定することで、セグメント ルーティング トンネルをsource-routing-path設定できます。セグメント ルーティング トンネルには、宛先アドレスと 1 つ以上のプライマリ パス、およびオプションでセグメント リストを参照するセカンダリ パスがあります。各セグメント・リストは、ホップのシーケンスで構成されています。色なし静的セグメント ルーティング トンネルの場合、セグメント リストの最初のホップは即時のネクスト ホップ IP アドレスを指定し、2 番目から N 番目のホップは、パスが通過するリンクまたはノードに対応する SID(セグメント識別)ラベルを指定します。セグメント ルーティング トンネルの宛先へのルートは、inet.3 テーブルにインストールされています。

トポロジ

この例では、プロバイダ エッジ ルーター PE1 と PE5 でレイヤー 3 VPN を設定します。すべてのルーターで MPLS プロトコルを設定します。セグメント ルーティング トンネルは、ルーター PE1 とルーター PE5 にプライマリ パスを設定して、ルーター PE1 からルーター PE5 に設定されます。ルーター PE1 は、パス保護用にセカンダリ パスも設定されています。トランジット ルーター PE2~PE4 は、ラベル pop と発信インターフェイスを備えた隣接 SID ラベルを使用して設定されています。

図 10: スタティック セグメント ルーティング ラベル スイッチ パス スタティック セグメント ルーティング ラベル スイッチ パス

設定

CLI クイック設定

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

デバイス PE1 の設定
手順

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

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

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

  2. 自律システム番号と、パケット転送ルーティング オプションを制御するオプションを設定します。

  3. MPLS プロトコルでインターフェイスを設定し、MPLS ラベル範囲を設定します。

  4. 更新時のNLRIのピアグループ、ローカルアドレス、プロトコルファミリーのタイプ、ピアグループのネイバーのIPアドレスを設定します。

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

  6. プロトコル ソース パケット ルーティング(SPRING)のソース ルーティング トラフィック エンジニアリング(TE)ポリシーのプライマリ パスとセカンダリ パスの IPv4 アドレスとラベルを設定します。

  7. プロトコル SPRING の宛先 IPv4 アドレス、バインド SID ラベル、プライマリ、セカンダリ ソース ルーティング パスを設定します。

  8. ポリシー オプションを設定します。

  9. BGP コミュニティ情報を設定します。

  10. インスタンス タイプ、インターフェイス、ルーター識別機能、VRF インポート、エクスポート、テーブル ラベルを使用して、ルーティング インスタンス VRF1 を設定します。プロトコル OSPF のエリアのエクスポート ポリシーとインターフェイスを設定します。

結果

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

デバイス PE2 の設定
手順

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

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

  2. プロトコル MPLS の静的 LSP を設定します。

  3. プロトコル MPLS のインターフェイスと静的ラベル範囲を設定します。

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

結果

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

検証

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

ルーター PE1 のルーティング テーブル inet.3 のルート エントリの検証
目的

ルーター PE1 のルーティング テーブル inet.3 のルート エントリを検証します。

対処

動作モードから、コマンドを show route table inet.3 入力します。

意味

出力には、セグメント ルーティング トンネルのイングレス ルートが表示されます。

ルーター PE1 のルーティング テーブル mpls.0 のルート テーブル エントリーの検証
目的

ルーティング テーブル mpls.0 のルート エントリーを検証します。

対処

動作モードから、コマンドを show route table mpls.0 入力します。

意味

出力には、セグメント ルーティング トンネルの SID ラベルが表示されます。

ルーター PE1 の SPRING トラフィック設計 LSP の検証
目的

イングレス ルーター上で SPRING トラフィックが設計された LSP を検証します。

対処

動作モードから、コマンドを show spring-traffic-engineering overview 入力します。

意味

出力には、イングレス ルーター上で設計された SPRING トラフィック LSP の概要が表示されます。

ルーター PE1 のイングレス ルーター上の SPRING トラフィック設計 LSP の検証
目的

イングレス ルーター上で SPRING トラフィックが設計された LSP を検証します。

対処

動作モードから、コマンドを show spring-traffic-engineering lsp detail 入力します。

意味

出力には、イングレス ルーター上で設計された SPRING トラフィック LSP の詳細が表示されます。

ルーター PE2 のルーティング テーブル mpls.0 のルーティング テーブル エントリーの検証
目的

ルーター PE2 のルーティング テーブル mpls.0 のルーティング テーブル エントリーを検証します。

対処

動作モードから、コマンドを show route table mpls.0 入力します。

ルーター PE2 の静的 MPLS LSP セグメントのステータスの検証
目的

ルーター PE2 の MPLS LSP セグメントのステータスを検証します。

対処

動作モードから、コマンドを show mpls static-lsp 入力します。

意味

出力には、ルーター PE2 の静的 MPLS LSP セグメントのステータスが表示されます。

セグメント ルーティング LSP の分散型 CSPF の有効化

Junos OS リリース 19.2R1S1 より前は、セグメント ルーティング パスのトラフィック エンジニアリング用に、静的パスを明示的に設定するか、外部コントローラからの計算パスを使用できます。セグメント ルーティング LSP 用の分散型制約付き最短パス ファースト(CSPF)機能を使用すると、設定した制約に従って、イングレス デバイス上でセグメント ルーティング LSP をローカルに計算できます。この機能により、LSP は設定された制約とメトリック タイプ(トラフィック エンジニアリングまたは IGP)に基づいて最適化されます。LSP は、セグメント ルーティング ラベル スタック圧縮が有効または無効になっている宛先への使用可能な ECMP パスを使用するように計算されます。

分散型 CSPF 計算の制約

セグメント ルーティング LSP パスは、設定されたすべての制約が満たされると計算されます。

分散型 CSPF 計算機能は、インターネット ドラフト、draft-ietf-spring-segment-routing-policy-03.txt、 トラフィック エンジニアリング用セグメント ルーティング ポリシーで指定された制約の次のサブセットをサポートします。

  • 管理グループのインクルージョンと除外。

  • ルーズ ホップ IP アドレスまたはストリクト ホップ IP アドレスの組み込み。

    注:

    ルーズ ホップ制約またはストリクト ホップ制約では、ルーターの ID のみを指定できます。Junos OS リリース 19.2R1-S1 では、ラベルおよびその他の IP アドレスをルーズ ホップまたはストリクト ホップ制約として指定することはできません。

  • セグメント リスト内のセグメント ID(SID)の最大数。

  • 候補セグメント ルーティング パスあたりのセグメント リストの最大数。

セグメント ルーティング LSP の分散型 CSPF 計算機能は、以下のタイプの制約と導入シナリオをサポートしていません。

  • IPV6 アドレス。

  • ドメイン間セグメント ルーティング トラフィック エンジニアリング(SR-TE)LSP。

  • 番号なしインターフェイス。

  • OSPF、ISIS、BGP-LS などの複数のプロトコル ルーティング プロトコルが同時に有効になります。

  • プレフィックスまたはエancastアドレスを宛先として計算します。

  • インターフェイス IP アドレスを制約として含め、除外する。

分散型 CSPF 計算アルゴリズム

セグメント ルーティング LSP の分散型 CSPF 計算機能では、CSPF を使用してラベル スタック圧縮アルゴリズムを使用します。

ラベル スタック圧縮が有効

圧縮ラベル スタックは、ソースから宛先へのパスのセットを表します。通常、ノード SID と隣接 SID で構成されています。ラベル スタック圧縮が有効になっている場合、計算の結果は、制約に従いながら、スタック内の最小 SID 数を使用して宛先への ECMP を最大化する一連のパスになります。

ラベル スタック圧縮が無効

ラベル スタック圧縮を無効にしたマルチパス CSPF 計算では、宛先に対して最大 N 個のセグメント リストが検索されます。

  • すべてのセグメント リストのコストは、宛先に到達する最も短いトラフィック エンジニアリング メトリックと同じです。

  • 各セグメント リストは隣接関係 SID で構成されます。

  • N の値は、設定によって候補パスに許可されるセグメント リストの最大数です。

  • 2 つのセグメント リストが同一ではありません。

  • 各セグメント リストは、設定されたすべての制約を満たします。

分散型 CSPF 計算データベース

SR-TE 計算に使用されるデータベースには、それらのアドバタイズ ノードでトラフィック エンジニアリングが有効になっているかどうかに関係なく、すべてのリンク、ノード、プレフィックス、特性が含まれます。つまり、コンピューティング ノードが学習したすべてのドメインのトラフィック エンジニアリング データベース(TED)と IGP リンク状態データベースの和集合です。その結果、CSPF を機能させるためには、階層レベルでステートメントをigp-topology[edit protocols isis traffic-engineering]含める必要があります。

分散型 CSPF 計算制約の設定

コンピューティング プロファイルを使用して、計算制約を論理的にグループ化できます。これらのコンピューティング プロファイルは、プライマリおよびセカンダリ セグメント ルーティング LSP をコンピューティングするためのセグメント ルーティング パスによって参照されます。

コンピューティング プロファイルを設定するには、階層レベルで compute-profile ステートメントを [edit protocols source-packet-routing] 含めます。

サポートされる計算制約の構成には、以下のものがあります。

  • Administrative groups

    管理者グループは、階層レベルで[edit protocols mpls]設定できます。Junos OS は、管理グループ設定をセグメント ルーティング トラフィック エンジニアリング(SR-TE)インターフェイスに適用します。

    計算制約を構成するには、一連の管理グループに 3 つのカテゴリーを指定できます。計算制約の構成は、すべての候補セグメント ルーティング パスに共通することも、個々の候補パスの下に配置することもできます。

    • include-any— リスト内の構成済み管理グループの少なくとも 1 つを持つリンクが、パスを通過できるように指定します。

    • include-all— リスト内のすべての構成済み管理グループとのリンクが、パスを通過できるように指定します。

    • exclude— リストに構成済みの管理グループがないリンクが、パスを通過できるように指定します。

  • Explicit path

    SR-TE 候補パスを計算するための制約として、コンピューティング プロファイルに一連のルーター ID を指定できます。各ホップは IPv4 アドレスである必要があり、タイプは strict またはルーズです。ホップのタイプが構成されていない場合は、strict が使用されます。明示的なパス制約を compute 指定する場合は、 segment-list ステートメントの下にオプションを含める必要があります。

  • Maximum number of segment lists (ECMP paths)

    候補パスを多数の動的セグメント リストに関連付けることができます。パスは ECMP パスで、各セグメント リストはアクティブ ウェイトを持つネクスト ホップ ゲートウェイに変換されます。これらのパスは、圧縮の有無にかかわらずパス計算の結果です。

    この属性は、コンピューティング プロファイル構成ステートメントのmaximum-computed-segment-lists maximum-computed-segment-listsオプションを使用して設定できます。この設定により、特定のプライマリ LSP とセカンダリ LSP について計算される、このようなセグメント リストの最大数が決定されます。

  • Maximum segment list depth

    最大セグメント・リスト奥行き計算パラメーターを使用すると、管理グループなどの他のすべての制約を満たす ECMP パスのうち、セグメント・リストの最大奥行き以下のパスのみが使用されます。このパラメーターをコンピューティング プロファイルの制約として設定すると、階層レベル( maximum-segment-list-depth 存在する場合)の [edit protocols source-packet-routing] 設定が上書きされます。

    この属性は、コンピューティング プロファイル構成ステートメントのmaximum-segment-list-depth maximum-segment-list-depthオプションを使用して設定できます。

  • Protected or unprotected adjacency SIDs

    指定された SID タイプのリンクを回避するには、 コンピュート プロファイル の下で保護または保護されていない隣接関係 SID を制約として構成できます。

  • Metric type

    計算に使用するリンク上のメトリックのタイプを指定できます。デフォルトでは、SR-TE LSP はリンクのトラフィック エンジニアリング メトリックを計算に使用します。リンクのトラフィックエンジニアリングメトリックは、IGPプロトコルのトラフィックエンジニアリング拡張によってアドバタイズされます。ただし、コンピューティング プロファイルでメトリック タイプの設定を使用して、IGP メトリックを計算に使用することもできます。

    この属性は、コンピューティング プロファイル構成ステートメントのmetric-type (igp | te)オプションを使用して設定できます。

分散型 CSPF 計算

SR-TE 候補パスは、設定された制約を満たすようにローカルで計算されます。ラベル スタック圧縮が無効になっている場合、マルチパス CSPF の計算結果は隣接 SID スタックのセットになります。ラベル スタック圧縮が有効になっている場合、結果は一連の圧縮ラベル スタックになります(隣接する SID とノード SID で構成されます)。

セカンダリ パスを計算すると、プライマリ パスによって取得されたリンク、ノード、SRLG は計算に使用されません。プライマリ パスとセカンダリ パスの詳細については、「 プライマリ LSP とセカンダリ LSP の設定」を参照してください

計算に失敗した LSP の場合、計算は TED(トラフィック エンジニアリング データベース)の変更として再試行されます。

分散型 CSPF 計算と SR-TE 機能間の相互作用

SR-TE ポリシーのパスに関連付けられた重み付け

ルートのネクスト ホップに貢献する計算された静的 SR-TE パスに対して重み付けを設定できます。ただし、計算が有効になっている 1 つのパスでは、複数のセグメント リストが発生する可能性があります。これらの計算されたセグメント リストは、その間で ECMP として扱われます。設定された各プライマリに割り当てられた重みを考慮して、これらのセグメントに階層 ECMP 重み付けを割り当てることができます。

BFD ライブライン検知

計算されたプライマリ パスまたはセカンダリ パスの BFD ライブライン検出を設定できます。計算されたすべてのプライマリ パスまたはセカンダリ パスが複数のセグメント リストになる可能性があります。その結果、セグメント リストに対して設定された BFD パラメータは、計算されたすべてのセグメント リストに適用されます。アクティブなすべてのプライマリ パスがダウンすると、事前にプログラムされたセカンダリ パス(指定されている場合)がアクティブになります。

inherit-label-nexthops

計算されたプライマリ パスまたはセカンダリ パスの階層で設定を[edit protocols source-packet-routing segment-list segment-list-name]明示的に有効にするinherit-label-nexthops必要はありません。これはデフォルトの動作であるためです。

自動変換機能

セグメント リストで自動変換機能を設定し、自動変換機能を使用してプライマリ パスまたはセカンダリ パスがこれらのセグメント リストを参照するように設定できます。一方、コンピューティング機能が有効になっているプライマリまたはセカンダリは、どのセグメント リストも参照できません。その結果、指定されたプライマリ パスまたはセカンダリ パスに対してコンピューティング機能と自動変換機能の両方を有効にすることはできません。ただし、コンピューティング タイプを持つプライマリ パスで LSP を設定し、もう 1 つの LSP を自動変換タイプで設定することもできます。

分散型 CSPF 計算のサンプル構成

例 1

実施例1では、

  • 計算されていないプライマリ パスは、設定されたセグメント リストを参照します。この例では、設定されたセグメント リスト static_sl1 が参照され、このプライマリ パスの名前としても機能します。

  • 計算されたプライマリには名前を設定し、この名前は設定されたセグメント リストを参照しないようにする必要があります。この例では、 compute_segment1 は設定されたセグメント リストではありません。

  • compute_profile_red コンピューティング プロファイルは、名前compute_segment1を持つプライマリ パスに適用されます。

  • compute_profile_redコンピューティングプロファイルには、計算の明示的なパス制約を指定するために使用されるタイプcomputeのセグメントリストが含まれています。

計算されたパスのネクスト ホップと静的ネクスト ホップの重みは、それぞれ 2 と 3 です。計算されたパスのネクスト ホップが comp_nh1comp_nh2comp_nh3で、静的パスのネクスト ホップが static_nhされている場合、重み付けは次のように適用されます。

ネクストホップ

重量

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

例 2

例 2 では、プライマリ パスとセカンダリ パスの両方をコンピューティング タイプにすることができ、独自のコンピューティング プロファイルを持つことができます。

例 3

実施例3において、コンピューティングがプライマリまたはセカンダリパスの下で言及されている場合、それは制約や計算のための他のパラメータを伴わない宛先へのパスのローカル計算をもたらす。

例:SR-TE LSP の CoS ベースの転送およびポリシーベース ルーティングの設定

SUMMARY CoS ベースの転送(CBF)とポリシーベース ルーティング(PBR(フィルターベースの転送とも呼ばれます)を有効にすると、非色のセグメント ルーティング トラフィック(SR-TE)LSP が明示的な SR-TE パスを介して選択的なトラフィックを誘導できます。これにより、サービス クラスまたはポリシーに基づいてトラフィックをサービスするメリットが得られます。

SR-TE LSP 向け CoS ベースの転送およびポリシーベース ルーティングの概要

SR-TE LSP の CoS ベース転送(CBF)とポリシーベース ルーティング(PBR)のメリット

CBF と PBR を使用すると、次のことができます。

  • セグメント ルーティング トラフィック エンジニアリング(SR-TE)パスの組み合わせを使用して、コア内のサービス トラフィックを誘導します。

  • 選択した SR-TE パスで解決するサポート サービスを選択します。

CBF と PBR をサポートするセグメント ルーティング パス ソース

次のセグメント ルーティング パス ソースは、CoS ベースの転送とポリシーベースのルーティングをサポートしています。

  • Static SR–TE paths— ラベル スタック全体を静的に設定したソース ルーティング パスを静的に設定します。

  • PCEP—コントローラ上に作成され、PCEPセグメントルーティング拡張を介して、またはBGPセグメントルーティング拡張を介したBGPセグメントルーティングポリシーを介してERO内のイングレスルーターにダウンロードされたソースルーティングパスを動的にプロビジョニングします。

  • Dynamic LSPs—ラストホップ ERO 解決を備えた動的トンネル モジュールを介してトリガーされる動的に作成されたトンネル。

  • Auto-translated paths—自動的に変換される静的に設定された送信元ルーティング パス。

SR-TE LSP の CBF および PBR の設定に関する考慮事項

覚えて:

  • CBF と PBR は、静的または動的に設定されている非カラー SR-TE LSP でのみ有効になります。

  • SR-TE LSP の CBF 設定と PBR 設定の両方をデバイスに共存できます。ルートが転送されるタイプは、設定の順序によって決定されます。

  • PBR の場合、SR-TE LSP の最初のホップがラベルである場合は、ステートメントを resolution preserve-nexthop-hiearchy 階層レベルに [edit routing-options] 含める必要があります。

  • CBF のクラスベースのルート転送は、転送テーブルでのみ表示され、ルートでは表示されません。

  • PBR のポリシーベースのルート転送は、ルート上で実行され、コマンド出力に show route 表示されます。

SR-TE LSP の CoS ベースの転送およびポリシーベース ルーティングの設定

SUMMARY CoS ベースの転送(CBF)とポリシーベースのルーティング(PBR(フィルターベースの転送 FBF とも呼ばれる)を使用して、明示的なセグメント ルーティング トラフィックエンジニアリング(SR-TE)ラベル swtiched パス(LSP)を使用して、選択的なトラフィックを誘導できます。第 1 ホップ ラベルまたは IP アドレスとしてネクスト ホップが設定されている非色付きセグメント ルーティング LSP のみが、CBF および PBR をサポートします。

開始する前に

  • 色なし SR-TE LSP で CBF と PBR を有効にするには、Junos OS リリース 20.1 以降のリリースを実行している必要があります。

  • デバイス インターフェイスを設定し、デバイスがネットワークに接続されていることを確認します。

  • セグメント リストを定義し、SR-TE LSP とその関連パラメーターを設定します。

SR-TE LSP を設定するには、次の手順に従います。

  1. ラベル パラメータを使用してセグメント リストを定義します。

    例えば、

  2. SR-TE LSP の送信元ルーティング パスを設定し、パスのプリファレンス値とプライマリ セグメントを指定します。

    例えば、

設定された SR-TE LSP の CBF と PBR を設定できるようになりました。

CBF を設定するには、次の手順に従います。

  1. 受信 IPv4 パケット、転送クラス、オプション値を処理する DSCP(差別化サービス コード ポイント)分類子を定義します。

    例えば、

  2. 転送用のパケットをグループ化するための転送クラス(FC)を定義し、パケットを出力キューに割り当てます。

    例えば、

  3. 設定した分類子をデバイス インターフェイスに割り当てます。

    例えば、

  4. LSP ネクスト ホップを SR-TE LSP として使用して、CoS ベースの転送ポリシー オプションを定義します。

    例えば、

  5. ネクスト ホップ マップ内の転送クラスを満たさないトラフィックを破棄します。

    例えば、

  6. ルート フィルターに一致するルートが map-name で指定された CoS ネクスト ホップ マッピングの対象になることを指定するポリシー ステートメントを設定します。

    例えば、

  7. ルーティング テーブルから転送テーブルにエクスポートされるルートにポリシーを適用します。これにより、SR-TE LSP の CBF が可能になります。

    例えば、

  8. 設定をコミットします。

Verify CBF Configuration

コマンドを使用して CBF 設定を show route forwarding-table destination ip-address vpn vpn-name extensive 検証できます。

CBF では、フィルタリングされたルートがコマンド出力に表示される PBR とは異なり、ルートのクラスベースの転送は転送テーブルでのみ表示されます show route

PBR を設定するには、次の手順に従います。

  1. プロトコルとルート フィルタに一致するルートが LSP ネクスト ホップの対象であるか、転送テーブルの ECMP(等価コスト マルチパス)として負荷分散されることを指定するポリシー ステートメントを設定します。

    例えば、

  2. ルートのプロトコルのネクスト ホップでカスタム ルート解決を実行するようにデバイスを設定します。

    注:

    resolution preserve-nexthop-hierarchy SR-TE LSP の最初のホップがラベルである場合、PBR が機能するには、ステートメントが必須です。

  3. ルーティング テーブルから転送テーブルにエクスポートされるルートにポリシーを適用します。これにより、SR-TE LSP の PBR が有効になります。

    例えば、

  4. 設定をコミットします。

Verify PBR Configuration

コマンドを使用して、PBR 設定を show route destination-prefix 検証できます。

出力には、宛先プレフィックス 4.0.0.1 のすべてのネクスト ホップが表示されます。オプションは expanded-nh extensive 、フィルター処理されたネクスト ホップを出力フィールドの下に Krt_inh 表示します。

PBR の場合、 show route コマンド出力はルートのポリシーベースのフィルタリングを実行します。

リリース履歴テーブル
リリース
説明
21.R1
Junos OS リリース 21.1R1 以降、Junos OS は PCE によって開始される RSVP ベースのポイントツーポイント LSP およびポイントツーマルチポイント LSP 向けのノンストップ アクティブ ルーティング(NSR)をサポートしています。
21.R1
Junos OS リリース 21.1R1 以降、Junos OS は、PCE によって開始された RSVP ベースのポイントツーマルチポイント LSP 向けのノンストップ アクティブ ルーティング(NSR)をサポートしています。
20.2R1
Junos OSリリース20.2R1以降、BGPラベル付きユニキャスト(BGP-LU)は、IPv4およびIPv6アドレスファミリーの両方のセグメントルーティングトラフィックエンジニアリング(SR-TE)を介してIPv4またはIPv6ルートを解決できます。
19.4R1
1 つまたは複数の MVPN マルチキャスト フロー(S、G)を、動的に作成された PCE 開始のポイントツーマルチポイント ラベルスイッチ パス(LSP)に関連付けることができます。
19.4R1
PCE が開始するセグメント ルーティング LSP のトンネル テンプレートを設定して、これらの LSP(BFD(双方向転送検出)と LDP トンネリングの 2 つの追加パラメーターを引き渡すことができます。
19.1R1
Junos OS リリース 19.1R1 以降では、コミット チェック機能が導入され、色付きルートに関与するすべてのセグメント リストに、すべてのホップの最小ラベルが存在することを確認します。
19.1R1
Junos OS リリース 19.1R1 以降では、色なし静的 LSP の最初のホップが IP アドレスに加えて SID ラベルのサポートを提供するため、この要件は適用されません。最初のホップ ラベルのサポートにより、MPLS 高速リルート(FRR)と重み付き等価コスト マルチパスが有効になり、有色スタティック LSP と同様に、静的な非カラー セグメント ルーティング LSP を解決できます。
18.2R1
Junos OS リリース 18.2R1 以降では、イングレス デバイス上で静的に設定された色なしセグメント ルーティング LSP は、PCEP(Path Computation Element Protocol)セッションを介して、PCE(Path Computation Element Protocol)セッションに報告されます。
17.2R1
Junos OS リリース 17.2 以降では、PCE が制御する external cspfLSP には、2 種類の新しいパス計算タイプが導入されています。local cspfそして.no cspf
16.1
Junos OS リリース 16.1 以降では、RFC 5440 に従って TCP-MD5 認証を使用して PCEP セッションを保護できます。
16.1
Junos OS リリース 16.1 では、RFC 5440 に従って TCP-MD5 認証を使用して PCEP セッションを保護する機能を紹介しています。
14.2R4
Junos OS リリース 14.2R4 以降では、PCE が制御する LSP 向けに自動帯域幅のサポートが提供されています。