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つの PCEs 間 (RFC 5440 で定義) の間の通信を可能にします。

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

図 1MPLS 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 の概要を示した Path Computation 要素プロトコルのサポート

MPLS RSVP TE について

トラフィックエンジニアリング (TE) は運用ネットワークのパフォーマンスを最適化し、主にトラフィックフローを既存の物理トポロジにマッピングします。トラフィックエンジニアリングは、トラフィックフローを、内部ゲートウェイプロトコル (IGP) によって選択された最短パスから離れた場所に移動し、混雑していない物理パスにネットワーク全体に移行する機能を提供します。

大規模で高密度なネットワークのトラフィックエンジニアリングでは、MPLS 機能を実装できるため、現在競合する場合よりも低コストで、オーバーレイモデルから利用可能な機能のほとんどが提供される可能性があります。おける代替ソリューション. MPLS トラフィックエンジニアリングを実装する主な理由は、トラフィックがネットワークを通って流れるパスを制御することです。MPLS トラフィックエンジニアリングを実装する主なメリットは、ATM のトラフィックエンジニアリング機能と、サービスクラス (CoS) による IP の違いを組み合わせて実現することです。

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

ルーター上で 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)、RECORD-ROUTE オブジェクト(RRO)、ラベル オブジェクト、EXPLICIT-ROUTE オブジェクト(ERO)は、RSVP プロトコルに関してオプションです。ただし、LRO オブジェクトとラベル オブジェクトは両方とも LSP トンネル確立に必須です。

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

  • 完全に明確なルート (RFC 3209) を使用して、ラベルスイッチパスを確立する可能性があります。

  • 帯域幅やリンクのプロパティなど、要件を満たすリンクに対して制約ベースの LSP が確立している。

  • エンドポイント制御。入口および出口ルーターでの LSP トンネルの確立と管理に関連付けられています。

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

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

現在 MPLS RSVP TE の制限

トラフィック制御 の RSVP 拡張により、ネットワークの利用率が向上し、トラフィック クラスの要件を満たしますが、今日の MPLS RSVP-TE プロトコル スイートには、分散した性質に固有のいくつかの問題があります。これにより、bisection 容量の競合で多くの問題が発生します。特に LSP の優先度クラスでは、Lsp のサブセットが共通の設定を共有し、優先度の値を保持している場合があります。RSVP TE には次のような制約があります。

  • デバイス単位の帯域幅需要に対する個々の LSP の可視性が欠如— MPLS RSVP-TE ネットワークのイングレス ルーターは、ネットワーク上の帯域幅需要のグローバル ビューを持つことなく LSP を確立します。ネットワークリソースの利用状況に関する情報は、インターフェイスごとに、トラフィッククラスによって確保された合計容量としてのみ利用可能です。個々の LSP の状態は、各自の Lsp 専用の各ラベルエッジルーター (コントローラー) でローカルに使用できます。その結果、特に共通のセットアップと停止の優先度において、需要パターンに関連する多くの問題が発生します。

  • RSVP シグナリングの非同期的で独立した性質 - RSVP-TEでは、パス確立の制約を管理者が制御します。そのため、LSP トンネル用に予約された帯域幅は管理者が設定し、トンネルを介して送信されるトラフィックの制限を自動的に暗示するものではありません。したがって、トラフィックエンジニアリングリンクで利用可能な帯域幅は、リンクに対して設定されたすべての予約の合計を除いて、接続に対して構成した帯域幅です。そのため、LSP トンネルに対する unsignaled の要求により、過剰な帯域幅を必要とする LSP と、トラフィックエンジニアリングリンクの帯域幅要件に準拠する他の Lsp がサービス劣化を招きます。

  • 動的または 明示的パス オプションに基づいて設定された LSP は、好み順に設定されます。MPLS RSVP-TE ネットワークのイングレス ルーターは到着順に基づいて LSP を確立します。受信ルーターはネットワーク上の帯域幅需要のグローバルなビューを持たないため、Lsp を確立するために優先順を使用すると、トラフィックが欠落したり、帯域幅需要が過剰に発生した場合でも Lsp が確立されていないことがあります。

例として図 2 、A と G をラベルエッジルーター (LERs) として使用する MPLS RSVP TE で構成しています。これらのイングレス ルーターは、需要の順序に基づいて LSP を独自に確立し、互いの LSP に対する知識や制御を行う必要はありません。ルーター B、C、D は、送信ルーター E および F に接続する中間ルーターです。

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

受信ルーターは、要求が到着した順序に基づいて Lsp を確立します。ルーター G が G-F に対してそれぞれ容量 5 の 2 つの需要を受信した場合、G は 2 つの LSP( LSP1 と LSP2 )を G-B-D-F まで信号を送信します。同様に、A-E の場合、ルーター A が容量10の3番目の要求を受信すると、A-B-E を介して LSP、LSP3 に通知します。しかし、A-E LSP における需要が10から15へとなると、ルーター A は、B C リンクの方が容量が少ないため、同じ (A-B-E) パスを使用して LSP3 に信号を送ることができません。

ルーター A は、A-B-C-E パスを使用して、LSP3 に対する需要の増加を通知する必要があります。LSP1 と LSP2 は、受信した需要の順序に基づいて B-1 のリンクを利用しているため、LSP3 はシグナル状態ではありません。

したがって、すべての Lsp で適切な最大フロー帯域幅を利用できますが、LSP3 はサービス低下の可能性があることを示しています。これは、ルーター A のグローバルな需要可視化の欠如と、イングレス ルーター A と G による需要位置のシステム調整が不足している原因です。

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

MPLS の RSVP TE パスの計算における現在の制限事項の解決策として、利用可能な容量に依存しないネットワークにおける、LSP ごとのグローバルビューを備えた外部パスコンピューティングエンティティが必要です。

現在、MPLS の RSVP TE ネットワークで提供されているのは、オンラインおよびリアルタイムの制約ベースのルーティングパス計算のみです。各ルーターは、ネットワーク内の他のルーターに依存せずに、制約ベースのルーティング計算を実行します。これらの計算は、現在利用可能なトポロジー情報に基づいており、通常は最新の情報ですが、完全に正確ではありません。LSP の配置は、現在のネットワークステータスに基づいてローカルに最適化されています。MPLS の RSVP TE トンネルは、CLI を使用してセットアップされています。運用担当者は、TE LSP を構成します。これは受信ルーターによって通知されます。

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

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

PCC のリモート LSP に対して外部パス コンピューティングを有効TE、 および 階層 lsp-external-controller pccd レベルに [edit mpls] ステートメント [edit mpls lsp lsp-name] を含める必要があります。

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

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

パスの計算要素

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

PCE は、ステートフルまたはステートレスのいずれかにできます。

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

    ステートフル PCE のタイプは次の2つです。

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

    • アクティブステートフルPCE —PCC LSPの状態に関する学習に加え、PCC LSPをアクティブに変更します。

      注:

      メインとバックアップのアクティブなステートフル PCEs を備えた冗長構成では、フェイルオーバー時にメイン PCE になるまで、PCE のアクティブステートフルが委任された Lsp の属性を変更することはできません。スイッチオーバーの場合、PCEs は不要になります。メイン PCE はバックアップ PCE によって支えられており、メイン PCE がダウンすると、バックアップ PCE はメイン PCE の役割を担い、メイン PCE がこれまでに実行されていた PCE が再び動作していても、メイン PCE を維持します。

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

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

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

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

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

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

    ステートフル PCE は、最適なパス計算と成功したパス計算を可能にしますが、優れた状態同期メカニズムを必要としています。これにより、制御プレーンのオーバーヘッドが大幅に増加し、膨大な量のデータを使用して保守されます。TE Lsp のフルメッシュの場合の状態のことです。

  • ステートレス PCE:ステートレス PCE は計算されたパスを覚えておいておらない。各リクエストのセットは、互いに独立して処理されます(RFC 5440)。

パス計算クライアント

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

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

PCC は、PCE から受け取った、計算されたパスに基づいて LSP を再通知します。メイン PCE との PCEP セッションが終了すると、PCC は新しいメイン PCE を決め、以前のメイン PCE のすべての委任された Lsp を、新たに利用可能なメイン PCE に委任します。

パスの計算要素プロトコル

パス計算要素プロトコル (PCEP) は、PCC と PCE の間 (および2つの PCEs 間の通信) (RFC 5440) 間のコミュニケーションに使用されます。PCEP は、IETF PCE ワーキンググループによって定義される TCP ベースのプロトコルであり、PCEP セッションを管理したり、マルチドメイン TE Lsp のパスを要求および送信したりするために使用される一連のメッセージおよびオブジェクトを定義します。PCEP の相互作用には、PCC のメッセージのほか、MPLS RSVP TE のコンテキストで PCE を使用するための特定の状態に関する通知が含まれています。PCE から PCE への通信に PCEP が使用されている場合、リクエスト PCE は PCC の役割を担います。

したがって、PCEP の機能には以下のものがあります。

  • LSP トンネル状態同期は PCC とステートフル PCE の間で行います。

  • LSP トンネルの制御をステートフルな PCE に委任します。

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

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

図 3: PCC と RSVP-TE PCC と RSVP-TE

PCC 通信への PCE は、TCP ベースの PCEP によって実現されています。PCC は PCEP セッションを開始し、PCEP セッションの間、PCE への接続を維持します。

注:

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

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 は、LSP パラメーターを PCC に送信します。これは、PCE が開始した Lsp をサポートする機能を示しています。

    注:

    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 は、PCE によって開始された Lsp のアクティブな PCEP セッションの委任を取り消すことはできません。

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

    PCE によって開始された Lsp を制御することで、 delegation cleanup timeoutの期限切れになった PCC に戻ります。PCE がdelegation cleanup timeout期限切れになり、他に LSP に対する制御機能が失敗した PCE から取得されていない場合、PCC は、委任されていない PCE 開始 lsp のローカル制御を行います。その後、オリジナルまたは新しいアクティブなステートフル PCE がローカルで制御された Lsp の制御を取得しようとすると、PCC はこれらの Lsp lsp cleanup timerを PCE に委任し、タイマーを停止します。

    PCE は、PCE が開始した LSP を PCC に委任して、LSP が PCEs 間で転送できるようにすることができます。これによりlsp cleanup timer 、PCE が開始した LSP のがトリガーされます。PCC は、LSP クリーンアップタイマーが期限切れになるのを待ってから、委任されていない PCE が開始した Lsp を失敗した PCE から削除します。

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

    注:

    draft-ietf-pce-stateful-pce-09に準拠している場合、PCC による PCE 開始 LSP 委譲は、LSP が代替 PCE に再送信される前に、変更前に行う必要があります。Junos OS リリース18.1 から開始していlsp-cleanup-timerます。 LSP 委任を失効させるdelegation-cleanup-timeoutには、PCC が for と同じかそれ以上を使用する必要があります。それ以外の場合は、PCC の redelegation timeout interval を無限大に設定できます。この場合、PCE の LSP 委任は、PCE によって設定されたパラメーターを変更するために、PCC によって実行される特定のアクションが完了するまでそのままではありません。

  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 に接続するように設定された PCCs です。

PCE は、ネットワーク内の帯域幅需要をグローバルに表示し、トラフィックエンジニアリングデータベースを検索した後、外部パスの計算を実行します。その後、アクティブなステートフル PCE は、1つ以上の LSP 属性を変更し、PCC に更新を送信します。PCC は、PCE から受け取ったパラメーターを使用して LSP を再通知します。

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

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

外部コンピューティングを使用した LSP の行動

LSP タイプ

クライアント側 TE の PCE 実装には、以下の3種類の Lsp があります。

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

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

    PCC は、帯域幅、ERO、優先度など、PCE コントロール LSP の設定されたパラメーターについて PCE に通知します。また、これらのパラメーターに使用される実際の値を PCE に通知し、RRO などを含む LSP を設定することもできます。

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

    PCE の LSP の CLI 構成によって、次の2つのタイプのパラメーターが用意されています。

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

    • PCE によってオーバーライドされるパラメーターこれらのパラメーターには、帯域幅、パス、優先度 (設定および保持の値) が含まれます。制御モードが外部からローカルに切り替わると、これらのパラメーターの CLI 設定値が、次の機会に適用されます。 LSP を再通知します。値は直ちに適用されるわけではありません。

  • 外部プロビジョニングされた LSP(または PCE 開始 LSP)—ステートメントが設定されている LSP は、PCE 開始 LSP と呼ばれる名前です lsp-provisioning 。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 制御 LSP は、PCE への接続がない場合、PCE が Lsp を PCC に委任した場合、デフォルトの外部コントロールモードからローカルコントロールに切り替わります。

CLI 制御 Lsp および PCE コントロール Lsp の詳細については、をLSP タイプ参照してください。

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

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

表 1: PCE および既存の LSP 構成の適用性と管理対象の LSP への MPLS

PCE コントロール LSP のサポート

適用可能な LSP 構成ステートメント

適用可能な MPLS 構成ステートメント

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

  • 管理グループ

  • 自動帯域幅

  • ホップ制限

  • 最小-塗りつぶし

  • 最も高い塗りつぶし

  • random

  • 管理グループ

  • 管理グループ

  • 管理者グループ-拡張

  • ホップ制限

  • なし-cspf

  • スマート最適化-タイマー

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

注:

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

  • よる

  • primary

  • 事項

  • 事項

これらの構成文は、PCE 構成とともに設定することはできません。

  • p2mp

  • テンプレート

  • p2mp-lsp-next-hop

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

PCE 制御された LSP 保護

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

PCE 管理された LSP ERO

PCE コントロール Lsp (PCC 委任 Lsp および PCE-initated Lsp) については、PCE から PCC に送信する必要があるのは、本格的な明示的なルートオブジェクト (ERO) オブジェクトのみです。それ以外の場合、PCC はその PCEP セッションに対して PCUpdate または Pcupdate メッセージを拒否します。

Junos OS リリース17.2 から開始します。さらexternal cspfに、PCE 制御 lsp には2つの新しいパス計算タイプが導入されています。local cspfand no cspf.

  • local cspf—PCC が計算タイプを使用する場合のみ、PC ジュニパー E が 1 つのベンダー local cspf TLV(エンタープライズ番号: 0x0a4c) 型は5になります。

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

    PCC は、 no cspf次のような場合に、計算型を使用します。

    • PCE が TLV をlocal cspf送信した場合、およびこの lsp の Junos OS 構成または照合no-cspfテンプレートが、PCC の lsp に含まれている場合。

    • PCE が TLV をlocal cspf送信した場合、およびこの lsp の Junos OS 構成テンプレートno-cspfが PCE 開始 LSP に含まれている場合

    • PCE が、空の ero またはルース ERO (ERO オブジェクトに設定されたルースビットを持つ) で TLV を送信local cspfしていない場合。

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

PCE が管理するポイントツーマルチポイント RSVP-TE Lsp

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

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

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

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

  • PCE が委任され、PCE によって開始されたポイントツー multipoint Lsp

  • 自動帯域幅

  • TE + +

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

  • テンプレートによるポイントツーマルチポイント Lsp の作成

  • PCE で開始されるポイントツー multipoint 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 を動的に開始およびプロビジョニングできます。PCE から PCCreate メッセージを受信すると、PCC は PCE から開始された LSP を作成し、LSP を自動的に PCE に委任します。

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

PCC は、PCE で開始されるポイントツーポイント Lsp をサポートする機能を備えており、PCE とともにパス計算要素プロトコル (PCEP) セッションを確立することを意味します。PCE は、この機能を使用して LSP を開始する PCC を選択しています。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 つのタイマーを開始します。そして、サービスの中断を回避 delegation cleanup timeoutlsp cleanup timer します。この間、アクティブなステートフル PCE は、障害が発生した PCE によってプロビジョニングされた Lsp の制御を取得できます。

PCE は、PCE によって開始されたポイントツーポイント LSP の委任を PCC に返して、LSP が PCEs 間で転送できるようにすることができます。PCE によって開始された Lsp を制御することで、委任クリーンアップタイムアウトの期限が切れたときに PCC に戻ります。委任のクリーンアップがタイムアウトになり、その他の PCE が LSP の制御を失敗した PCE から取得していない場合、PCC は、委任されていない PCE 開始 LSP のローカル制御を行います。その後、オリジナルまたは新しいアクティブなステートフル PCE が、ローカルに制御された PCE で開始されるポイントツーポイント Lsp の制御を取得しようとした場合、PCC はこれらの Lsp を PCE に委任し、LSP クリーンアップタイマーを停止します。

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

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

PCE が開始したバイパス LSP

PCE が開始したバイパス Lsp の理解

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

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

既存のバイパス選択のメカニズムは、ダイナミックバイパス Lsp を介して手動のバイパス Lsp (利用可能な場合) を優先しています。これにより、PCE でプロビジョニングされたバイパス Lsp (利用可能な場合) が動的バイパス Lsp を経由して優先します。PCE プロビジョニングされたバイパス Lsp は、動的バイパス Lsp よりも高い優先度を持っていますが、手動のバイパス Lsp より優先されることは少なくなっています。

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

PCE が開始するバイパス LSP をサポートすることで、以下のことが可能になります。

  • バイパス LSP を使用して、外部コントローラから PCEP 経由で RSVP バイパス LSP を作成します。

    • リンクまたはノードの保護に対応できます。

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

    • 指定した strict o が必要です。

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

  • バイパス LSP 帯域幅をオーバーサブスクライブして、プライマリ Lsp の受付制御を行います。これはバイパス単位のパラメーターである必要があり、バイパスされる LSP ごとにサブスクリプションの更新を許可する必要があります。

PCE が開始したバイパス LSP のメリット

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

  • 障害発生後のトラフィック制御と、明確なパスの保護パスの計算を強化します。

  • Lsp の多様なパスと、そのローカル保護パスを維持するなど、複雑な制約と多様性要件に対応します。

  • 障害発生時にリンクが過負荷状態にならないようにします。

PCE が開始した、PCEP セッションの失敗時における Lsp のバイパスを回避する動作

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

PCE 開始型ポイントツーマルチポイント Lsp

ポイントツーマルチポイントの PCE によって開始された Lsp を紹介することで、PCE は、ポイントツーポイント LSP の開始とプロビジョニングを、PCC のローカル LSP 設定を必要とせずに動的に実行できます。これにより、PCE は、Path Computation Element Protocol (PCEP) セッション内またはパスの間での、ポイントツーマルチポイントパス計算のタイミングとシーケンスを制御し、その結果、集中管理された動的なネットワークを構築できます。

詳細については、PCE で開始されるポイントツー Multipoint lsp をサポートする、MPLS RSVP-TE の Path Computation 要素プロトコルについて説明します。

自動帯域幅と PCE コントロール LSP

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

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

ステートフル PCE サーバーは、ネットワーク全体でトラフィックエンジニアリングパスの作成を自動化し、ネットワークの利用状況を向上させるとともに、PCC と PCEP の通信を使用してプログラム可能なネットワークエクスペリエンスのカスタマイズを可能にします。PCC は LSP レポートを PCE サーバーに送信し、PCE は更新または PCC への Lsp のプロビジョニングを行います。PCEP セッションで送信されるデータは、外部のパスコンピューティングを実行するために PCE サーバーにとって非常に重要です。その結果、PCEP 通信を攻撃することで、ネットワークサービスを中断させることができます。PCEP のメッセージが PCC に送信された場合、不適切な Lsp を設定することができます。同様に、改変された PCEP メッセージが PCE に送られると、ネットワークの不正な表示が PCE によって学習されます。

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

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

次の構成は、PCE を使用してセキュアな PCEP セッションを確立するために PCC で実行されます。

  • MD5 認証キーを使用します。

  • 定義済み認証キーチェーンを使用します。

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

注:
  • Junos OS リリース16.1 は、PCEP セッションで TCP-MD5 認証のみをサポートし、盗聴、改ざん、メッセージ偽造からの保護など、TLS および TCP/AO のサポートを拡張することはありません。

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

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

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

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

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

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

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

ステートフルなデータベースを保守するのは簡単ではありません。一元化された1つの PCE 環境では、ステートフル PCE は、PCE が TE 計算したすべての Lsp、実際に設定した Lsp (そのことがわかっている場合)、TE Lsp を破棄したことを TE すべて覚えておく必要があります。しかし、これらの要件により、状態、ネットワークの使用率、処理、ネットワーク全体でグローバルなリンクの最適化など、制御プロトコルのオーバーヘッドが大幅に増加します。そのため、ステートフルな PCE 実装には以下の問題があります。

  • 信頼性の高い同期メカニズムにより、制御プレーンのオーバーヘッドが大きくなります。PCEs は、相互に通信することで状態を同期できますが、TE Lsp が複数の PCEs で実行される分散計算を使用している場合、同期と競合状態の回避の問題は、より大規模かつ複雑になります。

  • 分散型の PCE 計算モデルに複数の PCEs が設定されているため、アウトオブバンドトラフィックエンジニアリングが複雑になり、競合状態や拡張性の問題などが発生する可能性があります。

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

上記の問題にもかかわらず、ステートフルな PCE の部分的クライアント側実装は、大規模なトラフィックエンジニアリングシステムで非常に効果的です。TE LSP の状態をグローバルに可視化し、制御されるシステム内のデバイス全体でパス予約を制御するという要件を提供することで、迅速なコンバージェンスと大きなメリットが得られます。

例:MPLS RSVP TE 用の Path Computation 要素プロトコルの構成

この例では、パス計算クライアント (PCC) でトラフィックエンジニアリングパス (TE Lsp) を対象とした、Path Computation 要素 (PCE) による外部パスコンピューティングを有効にする方法を示します。また、PCC で Path Computation Element Protocol (PCEP) を設定して、PCE を PCC 通信に対応する方法についても説明します。

要件

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

  • ACX シリーズルーター、M Series マルチサービスエッジルーター、MX シリーズ5G ユニバーサルルーティングプラットフォーム、T Series コアルーター、または PTX シリーズトランスポートルーターの組み合わせである3つのルーターは、PCC として構成されています。

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

  • PCC 上でリリース12.3 以降を JSDN アドオンパッケージとともに実行していることを Junos OS します。

注:

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

開始する前に:

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

  2. MPLS と RSVP-TE を構成します。

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

概要

Junos OS リリース12.3 から始めると、MPLS の RSVP TE 機能が拡張され、PCC のステートフル PCE アーキテクチャ (draft-ietf-PCE) の部分的なクライアント側の実装を提供します。

注:

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

PCE による外部パスコンピューティングを可能にするにlsp-external-controllerは、PCC レベルの[edit mpls]および[edit mpls lsp lsp-name]階層ごとにステートメントを追加します。

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

PCE が PCC 通信を実現できるようにするには、 [edit protocols]階層レベルで PCC で PCEP を構成します。

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

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

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

  • PCC は、最大10個のステートフル PCEs に接続できます。どの時点でも、1つのメイン PCE (優先度値が最も低い PCE)、または PCE の優先度がない状態で PCC に初めて接続する PCE は、パス計算用に Lsp を委任することができます。

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

  • Lsp の保護や前への作成などの既存の LSP 機能は、PCE コントロール Lsp に適しています。

  • 自動帯域幅オプションは、PCE 制御された Lsp では無効になっています。 bandwdith と制約ベースのルーティングの制御下にある Lsp は、PCE が制御する Lsp と共存できます。

  • PCE 制御された Lsp は、lsp-nexthop からルート、転送隣接関係、CCC 接続、および論理トンネルなど、他の CLI 構成によって参照できます。

  • PCE 制御された Lsp は GRES をサポートしていません。

  • 論理システムの PCE 管理された Lsp はサポートされていません。

  • PCE 制御された Lsp は、ポイントツー multipoint Lsp になることはできません。

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

  • PCE 制御された Lsp は、プライマリパスなしのセカンダリパスを持つことはできません。

  • PCE が制御する Lsp は、外部パスの計算に依存します。これは、全体的な設定時間、再ルーティング、および休憩の機能に影響を及ぼします。

  • 既存の Lsp に対する段取り時間とコンバージェンス時間 (ルート変更、MBB) は、PCE コントロール Lsp が存在しない場合の以前のバージョンと同じです。ただし、PCE 制御 Lsp の存在には、小さな影響が見られます。

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

Topology

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

この例では、PCC は、外部のアクティブなステートフル PCE に接続する受信ルーターを示しています。

外部 Lsp のルーター PCC は、以下のように計算されます。

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

    この例では、外部 LSP が呼び出さPCC-to-R2れ、それがルーター PCC からルーター R2 に設定されています。CLI で設定された ERO は、PCC ~ R0-R2 にPCC-to-R2対応しています。帯域幅PCC-to-R2は1,000万であり、setup と hold の両方の優先度値は4です。

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

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

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

    この例でPCC-to-R2は、PCE が提供している PCC-R3-R2 に対応しています。のPCC-to-R2帯域幅は8m であり、setup と hold の両方の優先度値は3です。

  5. ルーター PCC は、新しい RRO とステートフル PCE を使用して PCRpt を送信します。

構成

CLI クイック構成

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

PCC

R0

R1

R2

R3

手順

順を追った手順

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

ルーター PCC を構成するには、次のようになります。

注:

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

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

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

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

  3. ラベルスイッチパス (LSP) をルーター PCC からルーター R2 に構成し、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 のタイプを設定します。

結果

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

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

検証

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

PCEP セッションステータスの確認

目的

PCE ステータスが up のときに、PCE とルーター PCC 間の PCEP セッションステータスを確認します。

アクション

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

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

pce1PCEP セッションのステータスは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 は、次に LSP を再通知するまで PCE が提供するパラメーターを使用し続けることができます。

この出力には、CLI を使用して設定された LSP パラメーターが、使用中の実際の値として LSP を確立するために使用される PCE 指定のパラメーターとともに表示されるようになりました。

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

  • 優先度 - 4 4(ActualPriorities 3 3)

このトリガーで LSP に再通知するために、ルーター PCC はローカル構成パラメーターを使用して PCE コントロール LSP を確立します。

20.31.1.2 Computed ERO 、20.31.2.2、20.31.8.2 があります。PCE コントロール LSP は、ローカルの構成パラメーターを使用して確立されます。

例:PCE によって開始されるポイントツーポイント Lsp をサポートし、MPLS RSVP TE 用の Path Computation 要素プロトコルを構成しています。

この例では、path computation 要素 (PCE) が開始したトラフィックエンジニアリングのポイントツーポイントラベルスイッチパス (Lsp) をサポートする機能を使用して、Path Computation Client (PCC) を設定する方法を示します。

要件

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

  • ACX シリーズ、M Series、MX シリーズ、T Series ルーターを組み合わせた3つのルーターがあります。

  • 受信ルーター (PCC) からの2つの外部ステートフル PCEs への TCP 接続。

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

開始する前に:

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

  • MPLS と RSVP-TE (RSVP トラフィックエンジニアリング) を構成します。

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

概要

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

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

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

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

  • LSP の保護や前への作成などの既存の LSP 機能は、PCE で開始された Lsp に適しています。

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

  • 論理システムで PCE によって開始された Lsp はサポートされていません。

  • PCE で開始された Lsp は、ポイントツー multipoint Lsp になることはできません。

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

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

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

    Junos OS のリリース18.2 で起動すると、受信デバイス上で静的に構成された、非カラーセグメントルーティング Lsp が PCEP セッションを通じて PCE に通知します。このような非色付きセグメントルーティング Lsp は、関連付けられている SID ラベルをバインドしている場合があります。この機能を使用すると、PCE はラベルスタックでこのバインド SID ラベルを使用して、PCE によって開始されるセグメントルーティング LSP パスをプロビジョニングできます。

Topology

図 6: 例: MPLS RSVP TE の PCE の Initated のポイントツーポイント LSP例: MPLS RSVP TE の PCE の Initated のポイントツーポイント LSP

この例では、PCC は受信ルーターとして、次の2つの外部ステートフル PCEs に接続しています。PCE1 と PCE2 です。

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

  1. PCE は、LSP を開始し、プロビジョニングするために、PCCreate メッセージを PCC に送信します。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つのタイマーを開始します。delgation のクリーンアップタイムアウトと LSP クリーンアップタイマーです。この間、PCE1 または PCE2 は、PCE が開始した LSP の制御を取得できます。

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

  4. 委任クリーンアップタイムアウトが経過し、PCE が開始した LSP に対して PCE1 と PCE2 はどちらも制御を取得していない場合、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. Lsp の外部制御を PCEs で有効にします。

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

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

  6. PCE グループを定義し、PCE グループの PCE が開始した Lsp をサポートできるようにします。

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

結果

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

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

検証

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

PCC のステータスを確認する

目的

PCC と接続されている PCEs との間の PCEP セッションステータスと LSP の概要を確認します。

アクション

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

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

PCE1 はメインの active PCE であり、PCC によって自動的に委任された PCE 開始 LSP を1つ備えています。

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 用の Path Computation 要素プロトコルを構成しています。

パス計算クライアント (PCC) は、一元的な外部パスコンピューティングエンティティから動的に作成されたラベル交換パス (Lsp) をサポートする機能を使用して構成できます。ステートフルな Path Computaiton Element (PCE) を使用すると、外部のパス計算を実行し、要求が増加したときに動的な Lsp を生成できます。

PCC は、PCE によって提供される LSP パラメーターを使用して PCE で開始されるポイントツーポイント LSP を作成し、PCE が LSP をプロビジョニングしない場合、事前設定 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 が最大受信可能なメッセージ数 (分単位) を指定します。
  3. PCC が最大許容する、接続されたすべての PCEs 上で、外部でプロビジョニング済みのラベル交換パス (Lsp) の数を指定します。
  4. PCE のパラメーターを設定するには、接続された PCE に対して一意のユーザー定義 ID を指定します。
  5. PCEP セッションが切断された後に Lsp の制御をルーティングプロトコルプロセスに返す前に、PCC が待機する時間 (秒) を指定します。
  6. 接続する PCE の IPv4 アドレスを指定します。
  7. PCE が使用している TCP ポート番号を指定します。

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

  8. PCEP セッションが終了した後、PCC が、失敗した PCE から委任されていない PCE が開始した Lsp を削除するまでの時間 (秒) を指定します。
  9. 接続された PCEs によって外部でプロビジョニングされる Sp を受け入れるように PCC を設定します。デフォルトでは、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 用の Path Computation 要素プロトコルの構成

この例では、PCC (Path Computation Client) を構成し、ポイントツーマルチポイントトラフィックを設計したラベルスイッチパス (TE Lsp) を Path Computation 要素 (PCE) にレポートする方法を示します。

要件

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

  • ACX シリーズ、M Series、MX シリーズ、T Series ルーターを組み合わせた3つのルーターがあります。

  • バーチャルルートリフレクタ (VRR) 機能で構成されたバーチャルマシンが1台

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

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

開始する前に:

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

  • MPLS と RSVP-TE を構成します。

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

概要

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

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

Topology

図 7: PCE が管理するポイントツーマルチポイント Lsp の例PCE が管理するポイントツーマルチポイント Lsp の例

この例では、PCC は入口ルーターであり、ルーター R1 は通過ルーターで、ルーター R2 は送信ルーターです。PCC は、PCE に接続された仮想ルートリフレクタ (VRR) に接続されています。PCC、ルーター R1、ルーター R2 の間には、多くの点からマルチポイントへのインターフェイスが用意されています。

ポイントツー multipoint Lsp のレポートは、以下のように実行されます。

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

  2. ポイントツー multipoint LSP レポート機能を備えたルーター PCC が構成されている場合、PCC はこの機能をレポートメッセージを使用して PCE するために初めてアドバタイズします。

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

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

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

構成

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. ローカルコントロールを持つ Lsp を設定し、PCE が提供する LSP パラメーターによって上書きされます。

  9. 制限されたパス LSP 計算用に MPLS 管理グループポリシーを構成します。

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

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

  12. BGP 内部グループを構成します。

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

  14. PCC のすべてのポイントツー multipoint インターフェイス上で OSPF エリア0を構成します。

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

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

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

  18. ルーター PCC を構成して、外部パスコンピューティングにおけるポイントツー multipoint LSP 機能を有効にします。

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

結果

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

検証

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

PCC の LSP 構成を検証しています

目的

LSP タイプを確認し、ポイントツー multipoint LSP の稼働状態を検証します。

アクション

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

この出力には、lsp2-pcc LSP が PCE コントロール LSP として表示されます。

PCC の PCE 構成を検証しています

目的

PCE パラメーターの設定と PCE の状態を確認します。

アクション

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

この出力には、ルーター PCC が接続されているアクティブな PCE と、pce1 PCE parameters and state が表示されます。

PCE で開始されるポイントツー Multipoint Lsp のサポートにより、MPLS RSVP TE の Path Computation 要素プロトコルについて説明します。

ポイントツーマルチポイントの PCE によって開始された Lsp を紹介することで、PCE は、ポイントツーポイント LSP の開始とプロビジョニングを、PCC のローカル LSP 設定を必要とせずに動的に実行できます。これにより、PCE は、Path Computation Element Protocol (PCEP) セッション内またはパスの間での、ポイントツーマルチポイントパス計算のタイミングとシーケンスを制御し、その結果、集中管理された動的なネットワークを構築できます。

PCE によって開始されるポイントツー Multipoint Lsp のメリット

ポイントツーマルチポイント Lsp を動的に作成して破棄することによってアプリケーションのニーズに対応し、ポイントツーマルチポイントトラフィックエンジニアリング LSP の要件を満たします。これにより、一元管理されたダイナミックネットワークを構築し、れ.

PCE 開始型ポイントツーマルチポイント Lsp の通知

PCE 開始型ポイントツーマルチポイント Lsp の通知は、以下のとおりです。

  • When a new branch is added (Grafting)—新しいブランチ サブ LSP だけがシグナリングされ、ポイント対マルチポイント ツリー全体の再シグナリングは発生しない。

    新しいサブ LSP をプロビジョニングする前にトポロジの変更が発生した場合、パス計算サーバー (PC) によってポイントツー multipoint ツリー全体が再計算され、PC 更新メッセージを使用してポイントツー multipoint LSP を更新します。

  • When a branch is deleted (Pruning)—削除した支社/支社のサブ LSP は取り古され、ポイント to マルチポイント ツリー全体の再シグナリングは発生しない。

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

  • When a branch sub-LSP path fails—障害が発生した支社/支社のサブ LSP で PCS にエラーが報告されます。PC から新しい ERO を受信すると、障害が発生したブランチのサブ LSP とともにポイントツー multipoint ツリー全体が再通知され、新しいインスタンスへのスイッチオーバーは、MBB (make before) の方法で行われます。

PCEP セッション失敗後の PCE 開始型ポイントツーマルチポイント Lsp の動作

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

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

PCE が開始されたポイントツー Multipoint LSP 機能の設定

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

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

PCE が開始するポイントツーマルチポイント Lsp に対応し、サポートされていない機能

PCE によって開始される、次の機能がサポートされています。ポイントツーマルチポイント Lsp:

  • インターネット ドラフト draft-ietf-pce-stateful-pce-p2mp(2018 年 10 月に期限切れ)、ポイント to-マルチポイント トラフィック エンジニアリング用ステートフル PCE 使用のパス計算要素 (PCE)プロトコル拡張に対する部分的なコンプライアンス ラベル スイッチ パス 。

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

次の機能は、PCE が開始するポイントツーマルチポイント Lsp によってサポートされていません。

  • Point-to-point ローカルコントロール LSP の委任。

  • LSP 制御の委任。

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

  • 要求/応答メッセージング

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

    同じことを実現するには、最初のポイントツーマルチポイントツリーから支社のサブ LSP を削除し、メッセージがPCReport LSP をデバイスから削除した後でもう一方に再追加するという方法もあります。

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

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

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

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

PCE が開始されたポイントツーマルチポイント Lsp から MVPN へのマッピング

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

  • MVPN ルーティングインスタンスにマップされている Route 識別子 (RD)

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

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

詳細については、 インターネット ドラフト draft-ietf-pce-pcep-flow-05(有効期限 2020 年 2 月 16 日) を参照してください。 PCEP Extension for Flow Specification(

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

  • セクション 3.1.2 — 広告 PCE capabilties in IGP

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

  • セクション 7 — ルートを除くフロー仕様の大部分は、この機能の現在の実装は、支持および IPv4 マルチキャスト フローの仕様に対応していない。

PCE 開始されたポイントツーマルチポイント Lsp から MVPN へのマッピングを有効にするには、次の操作を行います。

  • PCC にpce_traffic_steeringよってフロー [edit protocols pcep pce pce-id]仕様機能 (トラフィックステアリングとも呼ばれる) がサポートされていることを示すために、階層レベルに明細書を追加します。

  • 階層レベルexternal-controller[edit routing-instances routing-instance-name provider-tunnel]明細書を含めます。

    MVPN 用external-controllerのプロバイダトンネル構成の存在は、この mvpn インスタンスのポイントツー multipoint 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) が外部コントローラーに設定します。

  • ユーザーが特定external-controller pccdの mvpn インスタンスに対して有効にすると、mvpn は、構成するために pccd プロセスを要求します (存在する場合)。

  • 特定の MPVN インスタンスに構成が大幅に変更された場合、MVPN はその特定の MVPN インスタンスの PCCD プロセスに対して、すべて (S、G) の再設定を要求します。

  • PCE が開始するポイントツーマルチポイント LSP に関連付けられたすべてのフロー仕様は、同じ RD を保有している必要があります。PC の開始時に、すべてのフロー仕様が同じ RD になっていない場合、PC initiate メッセージがエラーでドロップされます。

  • ポイントツーマルチポイント LSP は、選択的なフロー仕様にのみ関連付けることができます。それ以外の場合は、PC initiate メッセージがエラーでドロップされます。

  • PC の更新中、フロー仕様の新規追加または既存のフロー仕様の更新によって、すべてのフロー仕様が同じ RD でない場合は、PCC によって更新メッセージがドロップされます。

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

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

  • フロー仕様 ID は、1つのポイントツー multipoint LSP のみに関連付けることができます。同一の RD と (S, G) を複数のポイントツー multipoint Lsp に関連付けるために、Id と同じ RD & (S, G) を持つ複数のフロー仕様を追加できます。

  • PCEP マッピング動的(S,G)の場合、しきい値は常にデフォルト値 の 0 です

  • 1つの PCE 開始ポイントツー multipoint LSP にマッピングされるフロー仕様の数に制限はありません。

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

    • ポイントツー multipoint LSP に関連付けられている転送状態のレポート。

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

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

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

    • MVPN マルチキャストフロー (S, G) にマップされている CLI 構成ポイントツーマルチポイント LSP のレポートを作成しています。

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

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

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

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

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

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

  • 権限委譲機能を持つパス計算クライアント(イングレス MX シリーズ ルーターである PCC)は、PCEP セッションがダウンすると、PCE から委任されたセグメント ルーティング LSP を制御できます。LSP は PCC から削除されます。したがって、パケットが無音で破棄または破棄される状況(NULL ルート条件とも呼ばれる)を回避することで、LSP データ保護を保証できます。

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

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

セグメント ルーティング–ルーティング(SR–トラフィック制御)ソリューションのハイレベル コンポーネントには、次TEがあります。

  • 広告リンク特性に IGP を使用します。この機能は RSVP-TE に似TE。

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

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

    SR-TE機能:

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

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

    3. トランジット デバイスに LSP 単位のメモリ要件を設定せずに、エッジ ノード間に LSP が作成されます。(SR-TE に LSP シグナリングがない場合、このような LSP の作成が有効になっています。

    4. ネイバーごとにラベルが積み重ねられた結果、多数のラベルが管理され、コントロール プレーンになります。

Junos OSパーネットワークスのセグメント ルーティングの実装

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-EROs をサポートしています。Junos OS SID(ルーズホップ ノード セグメント ID)に基づいて PCC 上の送信インターフェイスを選択できません。ただし、残りのホップはゆるんでしまう可能性があります。単に、次ホップの作成にラベルを使用するだけでなく、S-EROs の最初のホップを超えた特定の処理は行われません。

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

    • S-EROにはラベルが含になっていません。

    • S-ERO は 6 ホップ以上を運ぶ。

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

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

PCEP セッションがダウンすると、PCE が開始したセグメント ルーティング LSP は次の通りになります。

  1. 300 秒間維持されます。

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

詳細については、 インターネット ドラフト draft-ietf-pce-lsp-setup-type-03.テキスト(有効期限は 2015 年 12 月 25 日 )、PCEPメッセージでの搬送パス設定タイプおよび draft-ietf-pce-segment-routing-06.テキスト(有効期限は 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:PCC 上でローカル LSP が設定され、LSP の委譲はソース ルーティング パスの設定後に行います。つまり、既存のセグメント ルーティング LSP で委譲機能が有効になっています。

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

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

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

  • Auto-translated LSPs—静的に設定されたソースルーティング パスが自動的に変換されます。

  • Computed LSPs:分散型の Constrained Shortest Path First(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 コマンド出力TEの SR-トラフィック LSP の制御ステータスを確認できます。

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

表 3: PCEP 相互作用 LSP 委譲

lsp-external-controller の構成階層

ソースルーティングパス委譲状態

PCC と PCE の PCEP インタラクション

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

初期委譲

  1. PCReport メッセージが PCE に送信され、委譲されます。PCReport には、制約とパスの詳細(ERO など)だけが含まれます。

  2. PCE は、ダウン状態になる LSP およびレポート パスのパスを計算します。

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

ルーティング プロトコル プロセス(rpd)が再起動した場合や、スイッチオーバーが実行された場合ルーティング エンジン同じ動作が見られます。

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

既存のパスの委譲

  1. PCReport が PCE に送信され、委譲されます。PCReport には、制約とパスの詳細(ERO など)だけが含まれます。

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

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

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

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

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

  5. PCE から PCUpdate メッセージを受信した場合、SR-TE は受信したパラメーターを使用して、PCReport メッセージが送信されたパスを設定します。その後、PCE から受け取ったセグメント リストだけがプログラムされたパスに含まれるだけでなく、以前にプログラムされた他のすべてのセグメント リストが削除されます。このルートの再プログラミングは、入れ入れ前に行います。

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

委譲は構成されていません。また、削除されていません。

PCE からのセグメント リスト(使用可能な場合)は使用されなく、ローカル設定による計算結果が使用されます。セグメント リストのローカル結果が使用可能な場合、対応するセグメント リストが make-before-break 方法でルートをプログラムするために使用されます。

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

LSP を設定した後、委譲は有効になります。

委譲機能は、送信元ルーティング パスのプライマリ セグメント リストでトリガーされます。

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

委譲は構成されていません。また、削除されていません。

ソースルーティング パスのプライマリ セグメント リストから、委譲機能が削除されます。

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

LSP を設定した後、委譲は有効になります。

  • ソースルーティングパステンプレートの下で — 委譲機能は、ソースルーティングパス全体でトリガーされます。

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

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

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

委譲は構成されていません。また、削除されていません。

テンプレートの設定に一致するソース ルーティング パスおよびプライマリ パスすべてから、委譲機能が削除されます。

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

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

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

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

  • 無着陸アクティブルーティング (NSR) はサポートされていません。

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

  • PCE によって委託された LSP は、以下をサポートしていない。

    • 色付き SR-TE LSP

    • IPv6 LSP

    • ソースルーティング パスのセカンダリ セグメント リスト。セグメント リストのパスは 1 つしか委任されません。

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

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

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

要件

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

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

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

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

    PCE の委譲機能を使用するには、Junos OS リリース 20.1R1以降のリリースを実行する必要があります。

開始する前に:

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

  • MPLS を構成します。

  • IS-IS を構成します。

概要

PCEP Junos OSルーティングの実装には、PCE から開始し、PCE が委託した SR-TE LSP が含まれます。

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

  • 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 は、PCE から委託された LSP を制御し戻します。その結果、PCE が委任された LSP では、PCEP セッションがダウンするとパケットが無音で破棄される(NULL ルート条件とも呼ばれる)状況を回避します。

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

PCE 開始セグメント ルーティング LSP の場合:

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

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

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

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

  4. 必要に応じて、 階層レベルに ステートメントを含めて、PCE の最大 SID max-sid-depth number 奥行き [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 ソースに応じて、次の階層にステートメントを含め、PCC 上でローカルに設定された LSP の委譲機能を lsp-external-controller pccd 有効にします。

    • 分散 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] 動的に作成する場合。

Topology

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

図 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-optionsshow protocolsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

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

検証

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

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

PCC 上IS-ISの隣接関係を検証します。SRGB ラベル範囲、隣接関係およびノード セグメント値、SPRING 機能出力フィールドに注意してください。

アクション

運用モードから、、、 show isis adjacency extensiveおよびshow isis database extensiveshow isis overviewコマンドを実行します。

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

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

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

アクション

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

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

SR-TE LSP の検証
目的

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

アクション

運用モードから、、、 show path-computation-client lspおよびshow spring-traffic-engineering lsp detailshow route protocol spring-teコマンドを実行します。

出力は、2 つの SR-TE LSP( と - )が、隣接関係セグメントとノード セグメントについて、それぞれ PCE によって作成された形を adj_sid_lspnode_sid_lsp 示しています。

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

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

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

アクション

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

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

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

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

アクション

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

SR-TE LSP 宛先 IP アドレスをルーター R3 に転送エントリとしてインストールします。

静的ルート転送にトンネル ルートが使用されているのを検証する
目的

静的ルートが SR-ルーティング LSP 用に作成されたトンネル ルートを使用TEします。

アクション

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

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

静的なセグメントルーティングラベルスイッチパス

セグメントルーティングアーキテクチャにより、コアネットワーク内の入口デバイスは、明示的なパスを介してトラフィックを誘導できます。セグメントリストを使用してこれらのパスを構成することで、受信トラフィックが取るパスを定義できます。受信トラフィックがラベル付けされていたり、IP トラフィックであったりすると、入口デバイスでの転送操作がラベルスワップまたは宛先ベースのルックアップになります。

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

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

セグメントルーティング Lsp について

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

セグメントルーティング Lsp は、動的または静的な性質を持つことができます。

Dynamic segment routing LSPs:セグメント ルーティング LSP が外部コントローラによって作成され、PATH Computation Element Protocol(PCEP)拡張を介してイングレス デバイスにダウンロードされた場合、または BGP セグメント ルーティング ポリシー から BGP セグメント ルーティングの拡張まで、LSP が動的にプロビジョニングされます。ダイナミックセグメントルーティング LSP のセグメントリストは、PCEP の明示的ルートオブジェクト (ERO) または LSP の BGP セグメントルーティングポリシーに含まれています。

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

静的なセグメントルーティング LSP は、 color[edit protocols source-packet-routing source-routing-path lsp-name]階層レベルでのステートメントの設定に基づいて、カラーの 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;
    }
}

ここでは、各プライマリステートメントと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 の受信ルートは、 inetcolor.0またはルーティングテーブルにinet6color.0インストールされますdestincation-ip-address, color 。また、IP トラフィックをマッピングするための鍵となります。

静的な色が付いたセグメントルーティング LSP には、 mpls.0ルーティングテーブルにルートがインストールされているバインディング SID が含まれる場合があります。このバインド SID ラベルは、セグメントルーティング LSP にラベル付きトラフィックをマップするために使用されます。ルートのゲートウェイは、プライマリおよびセカンダリパスのセグメントリスト構成から取得されます。

色分けされたセグメントのセグメントリストルーティング Lsp

色分けされた静的セグメントルーティング Lsp は、すでに provde が LSP を解決する第1ホップラベルモードをサポートしています。ただし、1ホップ IP モードは、カラーセグメントルーティング Lsp ではサポートされていません。Junos OS リリース 19.1 R1 から開始すると、カラールートに関与するすべてのセグメントリストがすべてのホップに対して最小ラベルを持つように、コミットチェック機能が導入されます。この要件が満たされていない場合、コミットはブロックされます。

非色付きスタティックセグメントルーティング LSP

colorステートメントを使用せずに構成された静的セグメントルーティング LSP は、非色付き LSP です。PCEP セグメントルーティングトンネルと同様に、受信ルートは、 inet.3またはinet6.3ルーティングテーブルにインストールされます。

Junos OS は、受信ルーター上で、色が付いていない静的セグメントルーティング Lsp をサポートします。1つのソースルーティングパスと1つ以上のセグメントリストを構成することで、色のない静的セグメントルーティング LSP をプロビジョニングできます。これらのセグメントリストは、色分けされていない複数のセグメントルーティング Lsp で使用できます。

色が付いていないセグメントルーティング Lsp を理解する

色分けされていないセグメントルーティング LSP は、固有の名前と宛先 IP アドレスを持っています。宛先への入口として、デフォルトの優先度が8、メトリックが1である inet. 3 ルーティングテーブルにインストールされています。このルートにより、宛先に関連するセグメントルーティング LSP に、非色付きサービスをマッピングできます。非色付きセグメントルーティング LSP が受信ルートを必要としない場合、受信ルートを無効にできます。色が付いていないセグメントルーティング LSP は、バインド SID ラベルを使用して、セグメントルーティング LSP を実現します。このラベルを使用すると、セグメントルーティング LSP をセグメントとしてモデル化して、他のセグメントルーティング Lsp を階層的に構成するためにさらに使用できるようになります。バインド SID ラベルの転送は、デフォルトでは優先度が8、メトリックは1になっています。

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

色が付いていないセグメントルーティング LSP は、最大8個のプライマリパスを持つことができます。複数の動作時のプライマリパスが存在する場合、PFE (パケット転送エンジン) は、パスに設定された重みと同様に負荷分散係数に基づいて、トラフィックをパス上に分散させます。少なくとも1つのパスに重みが設定されていない場合、またはパスにゼロ以外の重み付けがある場合、そのパスのいずれかに重み付けがない場合は、cost マルチパス (ECMP) になります。どちらの場合も、パスの1つまたは一部に障害が発生すると、PFE は、パスの保護を実現するために自動的に通過する、残りのパスを経由してトラフィックを rebalances します。非色付きセグメントルーティング LSP は、専用のパス保護のためのセカンダリパスを持つことができます。プライマリパスに障害が発生した場合、PFE は、その他の機能的なプライマリパスにトラフィックを rebalances します。そうでない場合、PFE はトラフィックをバックアップパスに切り替えて、パスの保護を実現します。色が付いていないセグメントルーティング LSP は、受信[edit protocols source-packet-routing source-routing-path lsp-name]およびバインド SID ルート用のメトリックを指定できます。複数の色が付いていないセグメントルーティング Lsp は、受信ルートの次ホップに寄与する宛先アドレスが同じになっています。

複数の色が付いていないセグメントルーティング Lsp は、受信ルートの次ホップに寄与する宛先アドレスが同じになっています。パスが機能しており、セグメントルーティング LSP がこれらすべてのセグメントルーティング Lsp に最適な優先度を持っている場合、各セグメントルーティング LSP のプライマリまたはセカンダリの各パスがゲートウェイの候補と見なされます。ただし、ネクストホップで保持できるゲートウェイの最大数は RPD マルチパス制限値を超えてはなりません。デフォルトでは128になっています。その他のパスは、「排除」、「最初のセカンダリパス」、「プライマリパス」があります。これらのセグメントリストは、これらのセグメントルーティング 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.1 R1 では、この要件は適用されず、非カラーの静的 Lsp の最初のホップが SID ラベルと IP アドレスのサポートを提供できるようになったため、該当するものではありません。第1ホップラベルをサポートしている場合は、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: 第1ホップの仕様をベースにした非色付きの静的 LSP の解決

第1ホップの仕様

LSP 解決のモード

IP アドレスのみ

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

segment-list path-1 {
    hop-1 ip-address 172.0.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.24.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.24.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 にも適用できます。ただし、これは PCEP 駆動型 Lsp には適用されません。パスを計算する時点での最初のホップの解決タイプの不一致について、システムログメッセージが生成されます。

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

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

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

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

    ラベルセグメントリストによるバインド SID の設定は、カラー型静的 Lsp に対してのみサポートされており、色なしの静的 Lsp には対応していません。

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

セグメントのプロビジョニングはルーター単位で実行されます。ルーター上の特定のセグメントでは、目的のラベルプールから、ナチュラル SID ラベルの場合は動的ラベルプール、プレフィックス SID またはノード SID の場合はセグメントルーティンググローバルブロック (SRGB) から、一意のサービス識別子 (SID) ラベルが割り当てられます。ナチュラル SID ラベルは、動的に割り当てたり、デフォルトの動作にしたり、ローカルの静的ラベルプール (SRLB) から割り当てたりすることができます。その後、SID ラベルのルートが mpls. 0 テーブルにインストールされます。

Junos OS は、 segment[edit protocols mpls static-label-switched-path static-label-switched-path]階層レベルでステートメントを構成することで、静的なセグメントルーティング lsp を許可します。静的なセグメント LSP は、Junos OS スタティックラベルプールの下にある一意の SID ラベルによって識別されます。static-label-range static-label-range階層レベルでステートメントを[edit protocols mpls label-range]構成することで、Junos OS 静的なラベルプールを構成できます。

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

  • 現在 Junos OS には、最大セグメント数の深さラベルを超える数をプッシュするように、次ホップを構築することができない制限があります。そのため、最大数の SID ラベルを持つセグメントリスト (転送のネクストホップを解決するために使用される第1ホップの SID ラベルを除く) は、色が指定されていたり、色が付いていないセグメントルーティング Lsp に対して使用することはできません。また、特定のセグメントルーティング LSP に許可される実際の数は、MPLS サービスがセグメントルーティング LSP に存在する場合や、セグメントルーティング LSP がリンクまたはノード保護パス上にある場合には、最大制限よりも低くなる場合があります。いずれの場合も、サービスラベル、SID ラベル、リンクまたはノード保護ラベルの総数は、最大セグメントリストの深さを超えないようにする必要があります。階層レベルで[edit protocols source-packet-routing]最大セグメントリスト制限を構成できます。最大の SID ラベル以下の複数の非色付きセグメントルーティング Lsp を断片して、長いセグメントルーティング LSP を構築できます。これは、「セグメントルーティング LSP」と呼ばれています。この機能は、バインド SID ラベルを使用して実現できます。

  • セグメントルーティング LSP は、実際にはパスレベルで実行されます。色が付いていないセグメントルーティング LSP が複数のセグメントリストを持つ複数のパスを持つ場合、各パスは、断片のセグメントルーティング LSP とは、1つの線をつなぎながら、非色分けで個別に管理できます。つなぎ専用ではないセグメントルーティング LSP は、階層レベルでno-ingress[edit protocols source-packet-routing source-routing-path lsp-name] 文を設定することで、受信ルートのインストールを無効にすることができます。

  • 最大で 12 8 のプライマリ パスと 1 つのセカンダリ パスが、非色の静的セグメント ルーティング LSP ごとにサポートされています。構成に違反がある場合、コミットチェックはエラーで失敗します。

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

  • セグメントリストが最大セグメントリストの深さよりも多くのラベルで構成されている場合、構成コミットチェックはエラーによって失敗します。

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

各プロバイダエッジ (PE) デバイスが各 PE デバイスに接続されているセグメントルーティングネットワークでは、セグメントルーティングラベル交換パス (Lsp) の設定には、わずか数セグメントルーティングのみで十分な構成が必要です。トラフィックエンジニアリング (SR TE) パスが使用される場合があります。このような Lsp の BGP trigerred ダイナミックな作成を有効にすることで、こうした導入における構成の量を削減できます。

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

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

  • 以下は、カラーダイナミックセグメントルーティング LSP テンプレートの構成例です。

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

動的セグメントルーティング Lsp の解決
色分けされた動的セグメントルーティング LSP の解決

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

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

色分けされた宛先ネットワークを正常に解決するには、色を特定の色にするか、 color-anyテンプレートを使用して有効なテンプレートマッピングにする必要があります。有効なマッピングがなければ、トンネルは作成されず、解決を要求する BGP ルートは未解決のままになります。

未色付けの動的セグメントルーティング Lsp の解決

非色付き Lsp のキャッチオールルートが inet. 3 ルーティングテーブルに追加されます。非色付きトンネルの宛先は、マッピングリストにテンプレート名spring-teが1つだけ含まれている別の構成で構成する必要があります。このテンプレート名は、同じspring-te構成で構成された宛先ネットワークのいずれかと一致するすべてのトンネルルートに使用されます。これらのトンネルは、機能の RSVP トンネルに類似しています。

最終的な LSP テンプレート名は、プレフィックスとトンネル名を組み合わせたものです。たとえば、 <prefix>:dt-srte-<tunnel-name>のようになります。

ダイナミックセグメントルーティング LSP のサンプル構成

ダイナミックセグメントルーティング LSP テンプレートは、常に部分的なパスを実行します。最後のホップノード SID は、プロトコルのネクストホップアドレス (PNH) ノード SID に応じて、トンネルの作成時に自動的に生成されます。同一のテンプレートは、異なる宛先への複数のトンネルで使用できます。そのような場合、部分パスはそのまま変わりません。さらに、最後のホップだけが PNH に応じて変化します。ダイナミックセグメントルーティング LSP テンプレートは、単一のトンネルに共通ではないため、フルパスを通過することはできません。フルパスが使用されている場合は、セグメントリストを使用できます。

カラーダイナミックセグメントルーティング Lsp

カラー動的セグメントルーティング Lsp の構成例:

前述のサンプル構成では、ルートエントリは以下のようになります。

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

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

  3. BGP prefix to tunnel mapping:

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

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

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

  4. inetcolor.0 tunnel route:

    22.33.44.55-101/64 --><ネクスト ホップ>

    22.33.44.55-124/64 --><ネクスト ホップ>

  5. inetcolor6.0 tunnel route:

    ffff:22.33.44.55-101/160 --><ネクスト ホップ>

    ffff:22.33.44.55-124/160 --><ネクストホップ>

非カラーダイナミックセグメントルーティング Lsp

非カラー動的セグメントルーティング Lsp の構成例:

前述のサンプル構成では、ルートエントリは以下のようになります。

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

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

  3. BGP prefix to tunnel mapping:

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

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

  4. inet.3 tunnel route: 22.33.44.55/32 --><ネクスト ホップ>

  5. inet6.3 tunnel route: ffff:22.33.44.55/128 --><ネクスト ホップ>

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

未解決の動的セグメントルーティング Lsp のサンプル設定:

前述のサンプル構成では、ルートエントリは以下のようになります。

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

  2. inetcolor6.0 tunnel route: ffff:22.33.44.0 - 0/120 --> RT_NH_TUNNEL ff::1.1.1.0 - 0 /24 --> RT_NH_TUNNEL

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

セグメントルーティング Lsp の動的な作成を構成する際の考慮事項

セグメントルーティング Lsp の動的な作成を設定する場合は、以下の点に注意してください。

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

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

  • spring-te構成では、 color-anyオプションを使用して1つのテンプレートのみを定義できます。

  • カラーからテンプレートへのマッピングは、1対1ベースで行われます。1つの色を複数のテンプレートに割り当てることはできません。

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

  • カラーと非カラーの宛先は同じ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 セグメントルーティングトラフィックエンジニアリング (SRTE) Lsp を介してトランスポートトンネルを解決することができます。これをカラー IP プロトコルのネクストホップと呼んでいます。ここで、解決マップを設定し、VPN サービスに適用する必要があります。この機能を使用すると、レイヤー2およびレイヤー 3 VPN サービスのカラーベースのトラフィックステアリングを有効にできます。

Junos OS は、1つのカラーに関連付けられたカラー SRTE Lsp をサポートしています。VPN サービス機能のカラーベースマッピングは、静的なカラー Lsp および BGP SRTE Lsp でサポートされています。

VPN サービスカラーリング

一般に、vpn サービスには、VPN NLRI がアドバタイズされている送信ルーター上で色を割り当てることができ、vpn NLRI を受信して処理する入口ルーターであることもあります。

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

  • ルーティングインスタンスごと

  • BGP グループ単位。

  • BGP 隣接しています。

  • 接頭辞ごと

色が割り当てられると、その色は BGP カラーの拡張コミュニティーとして VPN サービスに適用されます。

VPN サービスには複数の色を割り当てることができます。これは、マルチカラー VPN サービスと呼ばれます。このような場合、最後に付加されたカラーが VPN サービスのカラーと見なされ、その他のすべてのカラーは無視されます。

複数のカラーは、出力または受信デバイスによって、以下の順序で複数のポリシーによって割り当てられます。

  • 出力デバイスのエクスポートポリシーを BGP します。

  • 受信デバイスのインポートポリシーを BGP します。

  • 受信デバイスの VRF インポートポリシー。

VPN サービスカラーリングには、以下の2つのモードがあります。

送信カラーの割り当て

このモードでは、送信デバイス (VPN NLRI の広告主) が VPN サービスの色分けを行います。このモードを有効にするには、階層レベルで ルーティング ポリシー を定義し、VPN サービスの routing-instance、グループ エクスポート、グループネイバー エクスポートに適用 vrf-export[edit protocols bgp] します。VPN NLRI は、指定されたカラーの拡張コミュニティーを使用して BGP によって通知されます。

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

および

注:

ルーティングポリシーを BGP グループまたは BGP の近隣ノードのエクスポートポリシーとして適用する場合は、 vpn-apply-exportポリシーが VPN nlri に影響を与えるように、BGP、BGP グループ、または BGP の近傍レベルに記載されているステートメントを使用する必要があります。

ルーティングポリシーは、レイヤー 3 VPN プレフィックス NLRIs、レイヤー 2 VPN NRLIs、および EVPN NLRIs に適用されます。カラーの拡張コミュニティーは、すべての VPN ルートに継承され、インポートされるとともに、1つまたは複数の受信デバイス上にターゲットの VRFs に取り付けられます。

受信カラーの割り当て

このモードでは、入口デバイス (VPN NLRI の受信側) が VPN サービスの色分けを担当します。このモードを有効にするには、階層レベルで ルーティング ポリシー を定義し、これを VPN サービスの routing-instance、グループ インポート、またはグループネイバー インポートに vrf-import[edit protocols bgp] 適用します。ルーティングポリシーに一致するすべての VPN ルートが、指定されたカラーの拡張コミュニティーにアタッチされます。

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

および

VPN サービスマッピングモードの指定

柔軟な VPN サービス マッピング モードを指定するには、 ステートメントを使用してポリシーを定義し、VPN サービスのルーティング インスタンス、グループ インポート、または階層レベルでのグループネイバー インポートでポリシーを参照する必要 resolution-mapvrf-import[edit protocols bgp] があります。ルーティングポリシーに一致するすべての VPN ルートが、指定された解決マップに関連付けられています。

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

VPNサービスのルーティングインスタンスにインポートポリシーを適用できます。

また、インポートポリシーを BGP グループまたは BGP の近隣に適用することもできます。

注:

各 VPN サービスマッピングモードには、解決マップで定義された一意の名前を付ける必要があります。解決マップでは IP 色の単一のエントリのみがサポートされています。ここでは、のip-address:color形式で、色付き ip プロトコルのネクストホップを使用して VPN ルートを解決します。

Color-IP プロトコルのネクストホップの解決

プロトコルのネクストホップ解決プロセスが拡張され、カラー IP プロトコルのネクストホップの解決が可能になります。カラー付き VPN サービスの場合、プロトコルのネクスト ホップ解決プロセスでは、カラー マップと解決マップを使用し、カラー付き IP プロトコルのネクスト ホップを IP アドレス:colorの形式で構築し、inet6 color.0 ルーティング テーブル でプロトコルのネクスト ホップを解決します。

色付きの Lsp を使用したカラーレイヤー 2 VPN、レイヤー 3 VPN、または EVPN サービスのマルチパス解決をサポートするために、ポリシーを設定する必要があります。その後、ポリシーは、リゾルバーインポートポリシーとして関連するリブテーブルとともに適用する必要があります。

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

フォールバックツー IP プロトコルのネクストホップの解決

色付きの VPN サービスに解像度マップが適用されていない場合、VPN サービスはその色を無視し、IP プロトコルのネクストホップ解決にフォールバックします。逆に、色が付いていない VPN サービスに解像度マップが適用されている場合、解決マップは無視されるため、VPN サービスは IP プロトコルのネクストホップの解決を使用します。

フォールバックは、LDP の RIB グループを使用して inet {6} color にルートをインストールすることで、色が付いた SRTE Lsp から LDP Lsp までのシンプルなプロセスです。0ルーティングテーブル。最も長いプレフィックスと IP プロトコルのネクストホップを組み合わせることで、カラーの SRTE LSP ルートが存在しない場合、一致する IP アドレスを持つ LDP ルートが返されます。

BGP SR-TE 上のユニキャスト カラーベース マッピングのラベル付TE

Junos OSリリース20.2R1から、BGPのラベル付きユニキャスト(BGP-LU)は、IPv4およびIPv6アドレス ファミリーの両方について、セグメントルーティングトラフィック制御(SR-TE)を使ってIPv4またはIPv6ルートを解決できます。BGP-LU は、ネットワーク コミュニティカラーのマッピング resolution map BGP、SR-LU の定義をサポートTE。色付きプロトコルのネクスト ホップが構築され、またはテーブル内の色付き SR-TE上で inetcolor.0 解決 inet6color.0 されます。BGP マッピング inet.3inet6.3 には複数の用途とテーブルがあります。これにより、ルーターにIPv4アドレスが設定されていないIPv6専用ネットワークで、BGP-LU IPv6およびIPv4プレフィックスをIPv6ネクストホップアドレスでアドバタイズできます。この機能により、現在サポートされているのが、BGPを使用した SR-TE IPv6 LU IS-ISサポートされています。

では、コントローラは SR-TE で設定された IPv6 コア ネットワークで 4 つの色付きトンネル 図 9 を設定TE。各色付きトンネルは、指定された解決マップに応じて、宛先ルーター D へのパスが異なります。コントローラは、ルーター D で色付き SR-TE トンネルを abcd:3701:2d05 インターフェイスに設定します。BGPポリシーをインポートして、受信したプレフィックスabcd:3700:6/128に色および解決マップを割り当てる。割り当てられたコミュニティの色に基づいて、BGP-LUは、割り当てられた解決マップポリシーに従って、BGP IPv6 LUプレフィックスの色付きネクストホップを解決します。

図 9: BGP IPv6 LU over colored IPv6 SR-TEBGP IPv6 LU over colored IPv6 SR-TE

BGP-LUは、次のシナリオをサポートしています。

  • BGP IPv4 LU は、IPv4 SR-BGP、OSPF IPv4 SR 拡張TE IPv4 SR 拡張のカラー付きを使用します。

  • BGP IPv4 LU は、静的な色付きおよび非色の IPv4 SR-TE 上で実行され、IPv4 SR を拡張した ISIS/OSPFを使用します。

  • BGP IS IPv6 SR 拡張を使用した、BGPされた IPv6 SR-TEを使用した IPv6 LU のサポートを行います。

  • BGPは、ISIS IPv6 SR 拡張を使用し、静的な色付きおよび非色の IPv6 SR-TE上で IPv6 LU をサポートします。

  • IPv6 レイヤー 3 VPN サービスと、IPv6 ローカル アドレスと IPv6 ネイバー アドレス。

  • IPv6 レイヤー 3 VPN サービスを IPv6 SR-BGP使用して、ISIS IPv6 SR TEを拡張します。

  • ISIS IPv6 SR 拡張を使用した、静的カラーおよび非色の IPv6 SR-TEを使用した IPv6 レイヤー 3 VPN サービス。

VPN サービスのカラーベースのマッピングのサポート対象およびサポート非対象の機能

以下の機能は、VPN サービスのカラーベースのマッピングでサポートされています。

  • BGP レイヤー 2 VPN (コンペラレイヤー 2 VPN)

  • BGP EVPN

  • 解像度-単一の IP カラーオプションを使用したマップ

  • 色付き IPv4 および IPv6 プロトコルのネクストホップの解決。

  • ルーティング情報ベース (ルーティングテーブルとも呼ばれる) グループベースで、inetcolor で LDP LSP にフォールバックします。0ルーティングテーブル。

  • カラーの SRTE LSP。

  • 仮想プラットフォームです。

  • 64ビット Junos OS

  • 論理システム

  • ユニキャストというラベル BGP ます。

以下の機能は、VPN サービスのカラーベースのマッピングではサポートされていません。

  • RSVP、LDP、BGP-LU、静的な MPLS Lsp。

  • レイヤー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. ソースルーティングパスのテンプレートステートメントを[edit protocols source-packet-routing]階層レベルに含めます。ここで、追加の BFD と LDP のトンネリングパラメーターを設定できます。

  2. PCE が開始した LSP のチェック対象となるポリシーステートメントの[edit protocols source-packet-routing]リストを表示するには、ソースルーティングパスのテンプレートマップステートメントを階層レベルに含めます。

  3. テンプレートを適用する Lsp をリストするポリシーを定義します。

    ステートメントfromには、 lsp and lsp-regex MATCH 条件を使用した lsp 名または lsp 正規表現を含めることができます。これらのオプションは相互に排他的なため、任意の時点でオプションを1つだけ指定できます。

    このthenステートメントには、 sr-te-template accept アクションを含むオプションが含まれている必要があります。このテンプレートは、PCE が開始した LSP に適用されます。

PCE が開始した Lsp のテンプレートを構成する際には、以下の点に注意してください。

  • テンプレートの設定は、静的に設定されたセグメント ルーティング LSP や他のクライアントのセグメント ルーティング LSP には適用されません。

  • PCEP が提供する構成は、テンプレート構成よりも優先されます。

  • PCEP LSP は、テンプレートセグメントリストの構成を継承しません。

例:静的セグメントルーティングラベルスイッチパス

この例では MPLS ネットワーク内の静的なセグメントルーティングラベル交換パス (Lsp) を設定する方法を示します。この構成により、MPLS ネットワークにより高い拡張性を実現できます。

要件

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

  • 7個の MX シリーズ5G ユニバーサルルーティングプラットフォーム

  • すべてのルーターで Junos OS リリース18.1 以降を実行している場合

開始する前に、デバイスインターフェイスを構成しておく必要があります。

概要

一連の明示的セグメントルーティングパスは、 segment-list [edit protocols source-packet-routing]階層レベルでステートメントを構成することにより、色のない静的セグメントルーティングトンネルの受信ルーター上で構成されます。 Junos OS セグメントルーティングトンネルを構成するには、 source-routing-path階層レベル[edit protocols source-packet-routing]でステートメントを構成します。セグメントルーティングトンネルには、宛先アドレスと、1つ以上のプライマリパス、およびオプションでセグメントリストを参照する二次的なパスが含まれています。各セグメントリストは、一連のホップで構成されています。色が付いていない静的なセグメントルーティングトンネルでは、セグメントリストの最初のホップは、すぐ次ホップ IP アドレスを指定し、2つ目から n 個ホップは、パスが走査するリンクまたはノードに対応するセグメントを識別するラベルを指定します。セグメントルーティングトンネルの宛先へのルートは、inet. 3 テーブルにインストールされています。

Topology

この例では、プロバイダエッジルーター PE1 および PE5 でレイヤー 3 VPN を構成します。すべてのルーター上で MPLS プロトコルを構成します。このセグメントルーティングトンネルは、ルーター PE1 とルーター PE5 で構成されたプライマリパスを使用して、ルーター PE5 からルーター PE1 に設定されています。ルーター PE1 は、パス保護のためのセカンダリパスでも構成されています。PE4 への PE2 ルーターは、ラベル 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. ピアグループ、ローカルアドレス、プロトコルファミリー、更新時に NLRIs を使用するためのタイプ、ピアグループの場合は IP アドレスを設定します。

  5. プロトコルエリアインターフェイスを構成します。

  6. プロトコルソースパケットルーティング (SPRING) のソースルーティングトラフィックエンジニアリング (TE) ポリシーの IPv4 アドレスとセカンダリパスを構成します。

  7. プロトコル SPRING の宛先 IPv4 アドレス、バインド SID ラベル、プライマリおよびセカンダリソースルーティングパスを構成します。

  8. ポリシーオプションを構成します。

  9. BGP コミュニティー情報を設定します。

  10. インスタンスタイプ、インターフェイス、ルーター識別子、VRF import、エクスポート、およびテーブルラベルを使用して、ルーティングインスタンス VRF1 を構成します。プロトコル OSPF のために、領域のエクスポートポリシーとインターフェイスを構成します。

結果

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

デバイス PE2 の構成
順を追った手順

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

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

  2. 静的 LSP をプロトコル MPLS 用に構成します。

  3. インターフェイスと、プロトコル MPLS 用の静的なラベル範囲を構成します。

  4. プロトコル OSPF のためのインターフェイスを構成します。

結果

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

検証

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

ルーティングテーブルのルートエントリを確認しています。3ルーター PE1
目的

ルーティングテーブルのルートエントリを確認します。3ルーターの PE1 です。

アクション

動作モードから、 show route table inet.3コマンドを入力します。

この出力には、セグメントルーティングトンネルの受信ルートが表示されます。

ルーティングテーブル mpls のルートテーブルエントリを検証しています。ルーター PE1 の0
目的

ルーティングテーブル mpls のルートエントリを確認します。0

アクション

動作モードから、 show route table mpls.0コマンドを入力します。

セグメントルーティングトンネルの SID ラベルが出力に表示されます。

PE1 のルーターの LSP を検証しています。
目的

受信ルーター上で、SPRING トラフィックが Lsp をエンジニアリングしていることを確認します。

アクション

動作モードから、 show spring-traffic-engineering overview コマンドを入力します。

この出力には、受信ルーターで Lsp を設計する、SPRING トラフィックの概要が表示されます。

PE1 が受信したルーターの Lsp トラフィックを検証します。
目的

受信ルーターで、SPRING トラフィックが Lsp をエンジニアリングしていることを確認します。

アクション

動作モードから、 show spring-traffic-engineering lsp detailコマンドを入力します。

この出力には、受信ルーター上での Lsp をエンジニアリングする、SPRING トラフィックの詳細が表示されます。

ルーティングテーブル mpls のルーティングテーブルエントリを検証しています。ルーター PE2 の0
目的

ルーティングテーブル mpls のルーティングテーブルエントリを確認します。 PE2 のルーターの0。

アクション

動作モードから、 show route table mpls.0コマンドを入力します。

ルーター PE2 の静的 MPLS LSP セグメントのステータスの確認
目的

MPLS LSP のルーター PE2 セグメントの状態を検証します。

アクション

動作モードから、 show mpls static-lspコマンドを入力します。

この出力には、ルーター PE2 の静的 MPLS LSP セグメントのステータスが表示されます。

セグメントルーティング Lsp に対して分散 CSPF を有効にする

Junos OS Release 19.2 の R1S1 の前は、セグメントルーティングパスのトラフィックエンジニアリングでは、静的パスを明示的に設定するか、外部コントローラからの計算されたパスを使用することができました。セグメントルーティング LSP 機能を提供する分散型最短パスファースト (CSPF) では、設定した制約に応じて、受信デバイスでローカルにセグメントルーティング LSP を計算できます。この機能を使用すると、Lsp は構成された制約とメトリックの種類 (トラフィックエンジニアリングまたは IGP) に基づいて最適化されます。Lsp は、セグメントルーティングラベルスタック圧縮が有効または無効になっている場合に、宛先への利用可能な ECMP パスを利用するために計算されます。

分散 CSPF 計算制約

セグメントルーティング LSP パスは、構成されたすべての制約が満たされたときに計算されます。

分散型の CSPF 計算機能は、インターネット ドラフトで指定されている制約の次のサブセットをサポートしています。 draft-ietf-spring-segment-routing-policy-03.テキスト,トラフィック エンジニアリング用セグメント ルーティング ポリシー:

  • 管理グループの包含と除外。

  • 緩やかなホップ IP アドレスまたは、高レベルの tcp/ip を含めることができます。

    注:

    緩やかな、または厳しいホップ制約ではルーター Id のみを指定できます。ラベルとその他の IP アドレスは、Junos OS リリース19.2 の R1-S1 で、緩やかな、または厳しいホップ制約として指定することはできません。

  • セグメントリスト内の最大セグメント Id 数 (Sid)。

  • 1つの候補セグメントのルーティングパスごとのセグメントリストの最大数。

セグメントルーティング Lsp の分散 CSPF 計算機能は、以下のタイプの制約と導入シナリオをサポートしていません。

  • IPV6 アドレスです。

  • ドメインセグメントルーティングトラフィックエンジニアリング (SRTE) Lsp

  • 番号なしのインターフェイス。

  • 複数のプロトコルルーティングプロトコル、OSPF、ISIS、BGP-LS などが同時に有効になっています。

  • 宛先としてのプレフィックスまたはエニーキャストアドレスを使用した計算。

  • インターフェイス IP アドレスを制約として含めて除外します。

分散 CSPF 計算アルゴリズム

セグメントルーティング Lsp 用の分散 CSPF 計算機能は、CSPF とともにラベルスタック圧縮アルゴリズムを使用します。

ラベルスタック圧縮を有効にする

圧縮されたラベルスタックは、送信元から宛先までの一連のパスを表します。通常、ノード Sid と隣接する Sid で構成されています。Label stack compression が有効になっている場合、制約に準拠すると同時に、スタック内の最小限の Sid 数を使用して、宛先への ECMP を最大化するパスのセットが計算の結果として得られます。

ラベルスタック圧縮無効

ラベル スタックの圧縮を無効にしたマルチパス CSPF の計算では、最大 N のセグメント リストから宛先までを検索できます。

  • すべてのセグメントリストのコストは、宛先に到達するための最短トラフィックエンジニアリングメトリックと同じです。

  • 各セグメントリストは、隣接する Sid で構成されています。

  • Nの値は、構成別の受験者パスで許可されるセグメント リストの最大数です。

  • 2つのセグメントリストは同一ではありません。

  • 各セグメントリストは、構成されたすべての制約を満たします。

分散 CSPF 計算データベース

SRTE 計算に使用されるデータベースは、トラフィックエンジニアリングがこれらの広告ノードで有効になっているかどうかにかかわらず、すべてのリンク、ノード、プレフィックス、およびその特性を持ちます。つまり、トラフィックエンジニアリングデータベース (TED) と、コンピューティングノードによって習得されたすべてのドメインの IGP リンク状態データベースの和集合であるということです。

分散 CSPF 計算制約の設定

コンピューティングプロファイルを使用して、計算制約を論理的にグループ化することができます。これらのコンピューティングプロファイルは、プライマリおよびセカンダリセグメントルーティング Lsp をコンピューティングするためのセグメントルーティングパスによって参照されます。

コンピューティングプロファイルを構成するには、 [edit protocols source-packet-routing]階層レベルでコンピューティングプロファイルステートメントを含めます。

サポートされている計算制約の設定は以下のとおりです。

  • Administrative groups

    [edit protocols mpls]階層レベルで管理グループを構成できます。Junos OS は、セグメントルーティングトラフィックエンジニアリング (SRTE) インターフェイスに管理グループの構成を適用します。

    計算制約を設定するには、一連の管理グループに対して3つのカテゴリーを指定できます。コンピュテーション制約の構成は、すべての候補セグメントのルーティングパスに共通することも、個別の候補パスの下にあることもあります。

    • include-any—リストに設定された管理グループの少なくとも 1 つを持つリンクが、通過するパスに対して許容可能なリンクを指定します。

    • include-all—リストに設定済みのすべての管理グループを持つリンクが、パスを通過するために許容可能なリンクを指定します。

    • exclude—リストに設定された管理グループが含されていないリンクを通過するパスに対して許容可能なリンクを指定します。

  • Explicit path

    SRTE のパスを計算するための制約として、コンピューティングプロファイル内の一連のルーター Id を指定できます。各ホップは、IPv4 アドレスである必要があり、タイプ strict またはルースにすることができます。ホップのタイプが構成されていない場合は、strict が使用されます。明示的な path compute制約を指定する場合は、このオプションをセグメント-リストステートメントの下に含める必要があります。

  • Maximum number of segment lists (ECMP paths)

    候補パスを多数の動的セグメントリストに関連付けることができます。パスは ECMP パスで、各セグメントリストは、アクティブな重みを持つ next-hop ゲートウェイに変換されます。これらのパスは、圧縮なしのパス計算の結果です。

    この属性を構成するにはmaximum-computed-segment-lists maximum-computed-segment-listsコンピューティングプロファイルの設定ステートメントのオプションを使用します。この設定では、指定されたプライマリおよびセカンダリ 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 計算

SRTE 候補パスは、設定された制約を満たすようにローカルに計算されます。ラベルスタック圧縮が無効になっている場合、マルチパスの CSPF 計算結果は、一連の隣接 SID スタックとなります。ラベルスタック圧縮が有効になっている場合、その結果は、一連の圧縮されたラベルスタック (隣接する Sid とノード Sid で構成) になります。

セカンダリパスが計算される場合、プライマリパスによって取得されたリンク、ノード、SRLGs は計算には使用できません。プライマリとセカンダリのパスの詳細については、「プライマリおよびセカンダリ lsp を設定する」を参照してください。

計算結果が失敗した Lsp については、トラフィックエンジニアリングデータベース (TED) の変更に応じて、計算が再試行されます。

分散型の CSPF 計算と SRTE 機能の間の相互作用

SRTE ポリシーのパスに関連付けられている重み付け

計算された静的な SRTE パスを使用して、ルートの次のホップに重みを設定することができます。ただし、計算が有効になっている単一のパスでは、複数のセグメントリストが生成されることがあります。これらの計算セグメントリストは、自らの間で ECMP として扱われます。構成された各原色に割り当てられた重量を考慮して、これらのセグメントに階層 ECMP 重量を割り当てることができます。

BFD Liveliness 検知

BFD の liveliness 検出を構成して、プライマリまたはセカンダリパスを計算できます。すべての計算されたプライマリまたはセカンダリパスで複数のセグメントリストが生成される結果として、セグメントリストに対して設定した BFD パラメーターがすべての計算済みセグメントリストに加えられます。アクティブなプライマリパスがすべてダウンすると、プログラム済みのセカンダリパス (指定されている場合) がアクティブになります。

inherit-ラベル-nexthops

デフォルトの動作であるため、計算inherit-label-nexthopsされた[edit protocols source-packet-routing segment-list segment-list-name]プライマリまたはセカンダリパスの階層下で設定を明示的に有効にする必要はありません。

自動翻訳機能

セグメントリストに自動翻訳機能を設定し、自動変換機能を備えたプライマリパスまたは二次的道筋によって、これらのセグメントリストが参照されるようにすることができます。一方で、compute 機能が有効になっているプライマリまたはセカンダリでは、セグメントリストを参照することはできません。その結果、指定されたプライマリまたはセカンダリパスに対して、コンピューティング機能と自動変換機能の両方を有効にすることはできません。しかし、LSP は、計算タイプを使用するプライマリパスと、自動翻訳タイプを使用して設定することができます。

分散 CSPF 計算のサンプル構成

例1

例1では、

  • 非計算のプライマリパスは、構成されているセグメントリストを参照します。この例では、設定済みのセグメント リストstatic_sl1 参照され、このプライマリ パスの名前として機能します。

  • 算出されたプライマリには名前を設定する必要があり、この名前は構成済みのセグメントリストを参照してはなりません。この例 では、compute_segment1 は設定されたセグメント リストではありません。

  • コンピューティングcompute_profile_redは、名前が 1 のプライマリ パスにcompute_segment1。

  • コンピューティング compute_profile_red プロファイルには、計算の制約の指定に使用されるタイプ明示的パス compute リストが含まれています。

計算パスの次ホップと静的な次ホップの重みは、それぞれ2と3です。計算されたパスのネクスト ホップがcomp_nh1comp_nh2、 comp_nh3 で、静的パスのネクスト ホップがstatic_nhである場合、重みは次のように適用されます。

次ホップ

重量

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

例2

たとえば2の例では、プライマリパスとセカンダリアドレスの両方が計算タイプであり、独自のコンピューティングプロファイルを持つことができます。

例3

例3では、計算がプライマリまたはセカンダリパスで示されている場合に、計算に制約やその他のパラメーターを指定せずに、宛先へのパスをローカルに計算します。

例:SR-CoS LSP 向けリモート ベースのフォワーディングおよびTEルーティングの設定

SUMMARY CoS ベースのフォワーディング(CBF)およびポリシーベース ルーティング(PBR(フィルターベースのフォワーディング)を有効にすることで、SR–TE(非色付きセグメント ルーティング トラフィック エンジニアリング)LSP は、明示的な SR-TE パスを使って選択的トラフィックをステアリングし、サービス クラスまたはポリシーに基づいてトラフィックをサービスを提供するメリットを提供できます。

CoS SR-based Forwarding and Policy-Based Routing for SR-TE LSP の概要

SR-CoS LSP 向け cBF(CoS転送)と PBR(ポリシーベース ルーティング)TE のメリット

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-CoS LSP の設定とポリシーベースのフォワーディングTE設定

SUMMARY CoS ベースのフォワーディング(CBF)およびポリシーベース ルーティング(PBR(フィルターベースのフォワーディング FBF)を使用すると、SR-TE(Explicit Segment routing-traffic engineered)ラベル swtiched Path(LSP)を使用して、選択的なトラフィックをステアリングできます。ネクスト ホップをファースト ホップ ラベルまたは IP アドレスとして設定した非色セグメント ルーティング LSP だけが、CBF と PBR をサポートします。

開始する前に

  • カラーリングされていない SR-Junos OS LSP に CBF と PBR を有効にするには、Junos OS リリース 20.1 以降のリリースを実行する TE必要があります。

  • デバイス インターフェイスを設定し、デバイスがネットワークに接続されていることを確認します。

  • セグメント リストを定義し、LSP とその関連TE SR-TEを設定します。

SR-TE LSP を設定するには、以下の手順に従います。

  1. ラベル パラメータを使用してセグメント リストを定義します。

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

  2. SR-TE LSP のソース ルーティング パスを設定し、パスの優先値とプライマリ セグメントを指定します。

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

これで、設定済みの SR-TE LSP に CBF と PBR を設定できます。

CBF を設定するには、以下の手順に従います。

  1. DSCP(Differentiated Services Code Point)分類子を定義して、受信 IPv4 パケット、転送クラス、およびオプション値を処理します。

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

  2. 転送パケットを転送用にグループ化する FCS(転送クラス)を定義し、パケットを出力キューに割り当てる。

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

  3. 設定した分類子をデバイス インターフェイスに割り当てる。

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

  4. LSP CoS ホップを SR ベースの LSP として使用する、ルーティング ベースのフォワーディング ポリシー オプションTEします。

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

  5. ネクスト ホップ マップ内で転送クラスを満たしていないトラフィックを破棄します。

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

  6. ルート フィルターに一致するルートが map-name で指定されたネクスト CoS マッピングの対象となるルートを指定するポリシー ステートメントを設定します。

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

  7. ルートからエクスポートするルートにポリシーを適用ルーティング テーブルテーブルに追加します。これにより、SLSP の CBF をTEできます。

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

  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-デバイスのファーストホップがLSPの場合、PBRが動作TE必須です。

  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 ベースのポイント to-ポイント LSP およびポイント to-マルチポイント LSP のノンストップ アクティブ ルーティング(NSR)をサポートします。
21.R1
Junos OS リリース 21.1R1 から、Junos OS は PCE 開始 RSVP ベースのポイント to マルチポイント LSP のノンストップ アクティブ ルーティング(NSR)をサポートします。
20.2R1
Junos OSリリース20.2R1から、BGPのラベル付きユニキャスト(BGP-LU)は、IPv4およびIPv6アドレス ファミリーの両方について、セグメントルーティングトラフィック制御(SR-TE)を使ってIPv4またはIPv6ルートを解決できます。
19.4R1
MVPN マルチキャストフロー (S, G) の1つまたは複数の範囲を、動的に作成された PCE で開始するポイントツー multipoint ラベルスイッチパス (LSP) に関連付けることができます。
19.4R1
PCE が開始するセグメントルーティング Lsp のトンネルテンプレートを設定して、これらの Lsp 双方向転送検知 (BFD) および LDP トンネリング用の2つの追加パラメーターを渡すことができます。
19.1R1
Junos OS リリース 19.1 R1 から開始すると、カラールートに関与するすべてのセグメントリストがすべてのホップに対して最小ラベルを持つように、コミットチェック機能が導入されます。
19.1R1
Junos OS リリース 19.1 R1 では、この要件は適用されず、非カラーの静的 Lsp の最初のホップが SID ラベルと IP アドレスのサポートを提供できるようになったため、該当するものではありません。第1ホップラベルをサポートしている場合は、MPLS 高速ルート転送 (FRR) および重み付けされた同等コストのマルチパスが有効になり、カラーの静的 Lsp と同様に、色の付いていないセグメントルーティング Lsp を解決できます。
18.2R1
Junos OS のリリース18.2 で始まって、受信デバイスで静的に設定された非カラーセグメントルーティング Lsp が、Path Computation Element Protocol (PCEP) セッションを介して Path Computation 要素 (PCE) に報告しています。
17.2R1
Junos OS リリース17.2 から開始します。さらexternal cspfに、PCE 制御 lsp には2つの新しいパス計算タイプが導入されています。local cspfand 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.2 R4 以降では、PCE コントロール Lsp に自動帯域幅のサポートが用意されています。