Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

 

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

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

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

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

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

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

Dynamic segment routing LSPs—セグメントルーティング LSP が外部コントローラによって作成され、パス計算要素プロトコル (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 ラベルの数は、セグメントリストの最大制限値を超えてはなりません。[edit protocols source-packet-routing]階層レベルで最大セグメントリスト制限を構成できます。

Junos OS Release 19.1 R1 より前は、色の付いていない静的セグメントルーティング LSP を使用できるようにするには、セグメントリストの最初のホップがアウトゴーイングインターフェイスの IP アドレスであり、2つ目は wireless-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の設定が適用されていないため、このステートメントをグローバルに有効にする必要があります。

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

表 1: 第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 ルーティングテーブルに複数のセグメントリストがインストールされている、色が付いていないセグメントルーティングトラフィックを表示することができます。

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

user@host> show route 7.7.7.7 protocol spring-te active-path table inet.3

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

  • トンネルのセグメントリストが異なると、最初のホップの解決タイプも異なります。これは、色が付いた静的な静的セグメントルーティング Lsp にも適用できます。ただし、これは PCEP 駆動型 Lsp には適用されません。パスを計算する時点での最初のホップの解決タイプの不一致について、システムログメッセージが生成されます。

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

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

  • セグメントリストタイプが 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] 文を設定することで、受信ルートのインストールを無効にすることができます。

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

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

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

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

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

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

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

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

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

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

BGP プレフィックスがカラーコミュニティーに割り当てられている場合は、まず、その–特定のカラーに設定されたすべての色のポリシーで解決が行われます。さらに、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 の構成例:

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

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

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

  • BGP prefix to tunnel mapping:

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

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

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

  • inetcolor.0 tunnel route:

    22.33.44.55-101/64--> < 次ホップ >

    22.33.44.55/64--> < 次ホップ >

  • inetcolor6.0 tunnel route:

    ffff:: 22.33.44.55-101/160--> < 次ホップ >

    ffff:: 22.33.44.55-124/160--> < 次ホップ >

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

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

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

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

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

  • BGP prefix to tunnel mapping:

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

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

  • inet.3 tunnel route: 22.33.44.55/32--> < 次ホップ >

  • inet6.3 tunnel route: ffff:: 22.33.44.55/128--> < 次ホップ >

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

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

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

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

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

  • 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 サービス’のルーティングインスタンス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 サービス’のルーティングインスタンスvrf-import、グループインポート、またはグループの近傍インポートに[edit protocols bgp]階層レベルで適用します。ルーティングポリシーに一致するすべての VPN ルートが、指定されたカラーの拡張コミュニティーにアタッチされます。

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





および

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

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

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

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

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

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

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

プロトコルのネクストホップ解決プロセスが拡張され、カラー IP プロトコルのネクストホップの解決が可能になります。色付き VPN サービスの場合、プロトコルのネクストホップ解決プロセスは、カラーと解像度マップを使用して、色分けされた IP プロトコルを次ホップで構築します。 IP アドレス: 色inet6color のルーティングテーブルでプロトコルのネクストホップを解決します。

色付きの 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 ルートが返されます。

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

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

  • BGP レイヤー 3 VPN

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

  • BGP EVPN

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

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

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

  • カラーの SRTE LSP。

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

  • 64ビット Junos OS

  • 論理システム

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

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

  • レイヤー2回路

  • FEC-129 BGP 自動検出され、LDP 信号を備えたレイヤー 2 VPN です。

  • VPLS

  • MVPN

  • 高解像度マップを使用して IPv4 と IPv6 を実現します。

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

PCE が開始するセグメントルーティング Lsp のためのトンネルテンプレート

PCE が開始するセグメントルーティング Lsp のトンネルテンプレートを設定して、これらの Lsp 双方向転送検知 (BFD) および LDP トンネリング用の2つの追加パラメーターを渡すことができます。

PCE 開始セグメントルーティング LSP が作成されている場合、LSP はポリシーステートメント (存在する場合) に照らし合わせてチェックされ、一致している場合は、その LSP に対して設定されているテンプレートを適用します。LSP ソース (PCEP) によって提供されていない場合にのみ、テンプレート構成が継承されます。たとえば、メトリックなどです。

テンプレートを設定するには、次のようにします。

  1. source-routing-path-templateステートメントを[edit protocols source-packet-routing]階層レベルに含めます。ここで、追加の BFD と LDP のトンネリングパラメーターを設定できます。
  2. PCE が開始した LSP のチェック対象となるポリシーステートメントの[edit protocols source-packet-routing]リストを表示するには、source-routing-path-template-mapステートメントを階層レベルに含めます。
  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 ラベルを使用して構成されています。

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

構成

CLI 簡単構成

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

デバイス PE1 の構成

ステップごとの手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。Cli のナビゲートの詳細については、『 Using the CLI Editor in Configuration Modeの「 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 interfacesshow policy-optionsshow protocolsshow routing-optionsshow routing-instancesコマンド. 出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイス PE2 の構成

ステップごとの手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。Cli のナビゲートの詳細については、『 Using the CLI Editor in Configuration Modeの「 CLI ユーザーガイド」を参照してください。

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

結果

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

検証

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

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

目的

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

アクション

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

user@PE1> show route table inet.3

意味

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

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

目的

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

アクション

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

user@PE1> show route table mpls.0

意味

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

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

目的

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

アクション

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

user@PE1> show spring-traffic-engineering overview

意味

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

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

目的

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

アクション

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

user@PE1# show spring-traffic-engineering lsp detail

意味

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

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

目的

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

アクション

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

user@PE2> show route table mpls.0

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

目的

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

アクション

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

user@PE2> show mpls static-lsp

意味

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

Release History Table
リリース
説明
PCE が開始するセグメントルーティング Lsp のトンネルテンプレートを設定して、これらの Lsp 双方向転送検知 (BFD) および LDP トンネリング用の2つの追加パラメーターを渡すことができます。
Junos OS リリース 19.1 R1 から開始すると、カラールートに関与するすべてのセグメントリストがすべてのホップに対して最小ラベルを持つように、コミットチェック機能が導入されます。
Junos OS リリース 19.1 R1 では、この要件は適用されず、非カラーの静的 Lsp の最初のホップが SID ラベルと IP アドレスのサポートを提供できるようになったため、該当するものではありません。第1ホップラベルをサポートしている場合は、MPLS 高速ルート転送 (FRR) および重み付けされた同等コストのマルチパスが有効になり、カラーの静的 Lsp と同様に、色の付いていないセグメントルーティング Lsp を解決できます。
Junos OS のリリース18.2 で始まって、受信デバイスで静的に設定された非カラーセグメントルーティング Lsp が、Path Computation Element Protocol (PCEP) セッションを介して Path Computation 要素 (PCE) に報告しています。