セグメント ルーティング LSP の設定
セグメント ルーティング LSP 向けの分散型 CSPF の有効化
Junos OSリリース19.2R1S1以前は、セグメントルーティングパスのトラフィック制御のために、静的パスを明示的に設定するか、外部コントローラからの計算パスを使用することができます。セグメント ルーティング LSP の分散型制限付き最短パス ファースト(CSPF)機能を使用すると、設定した制約に従って、イングレス デバイス上でセグメント ルーティング LSP をローカルに計算できます。この機能により、LSPは設定された制約とメトリックタイプ(トラフィック制御またはIGP)に基づいて最適化されます。LSP が計算され、セグメント ルーティング ラベル スタックの圧縮が有効または無効になっている宛先への利用可能な ECMP パスを使用します。
- 分散型 CSPF 計算の制約
- 分散型 CSPF 計算アルゴリズム
- 分散型 CSPF 計算データベース
- 分散型 CSPF 計算制約の設定
- 分散型 CSPF 計算
- 分散型 CSPF 計算機能と SR-TE 機能間の相互作用
- 分散型 CSPF 計算のサンプル構成
分散型 CSPF 計算の制約
設定されたすべての制約が満たされると、セグメントルーティングLSPパスが計算されます。
分散型 CSPF 計算機能は、インターネット ドラフト draft-ietf-spring-segment-routing-policy-03.txt( トラフィック制御用セグメント ルーティング ポリシー)で指定された制約のサブセットをサポートしています。
-
管理グループの包含と除外。
-
ルーズまたはストリクト ホップ IP アドレスを含める。
注:ルーズ ホップ制約またはストリクト ホップ制約では、ルーター ID のみを指定できます。Junos OSリリース19.2R1-S1では、ラベルやその他のIPアドレスをルーズまたはストリクトホップ制約として指定することはできません。
-
セグメント リスト内のセグメント ID(SID)の最大数。
-
候補セグメント ルーティング パスあたりのセグメント リストの最大数。
セグメント ルーティング LSP の分散型 CSPF 計算機能は、以下のタイプの制約および導入シナリオをサポートしていません。
-
IPV6アドレス。
-
ドメイン間セグメント ルーティング トラフィック エンジニアリング(SR-TE)LSP。
-
番号なしインターフェイス。
-
OSPF、ISIS、BGP-LS などの複数のプロトコル ルーティング プロトコルが同時に有効になっています。
-
宛先としてのプレフィックスまたはエ anycast アドレスを使用した計算。
-
インターフェイス IP アドレスを制約として含め、除外します。
分散型 CSPF 計算アルゴリズム
セグメント ルーティング LSP の分散型 CSPF 計算機能は、CSPF でラベル スタック圧縮アルゴリズムを使用します。
ラベルスタック圧縮が有効
圧縮ラベル スタックは、ソースから宛先へのパスのセットを表します。通常、ノード SID と隣接 SID で構成されています。ラベル スタック圧縮が有効な場合、計算の結果は、制約に従いながら、スタック内の最小 SID 数で宛先への ECMP を最大化する一連のパスになります。
ラベルスタック圧縮無効
ラベル スタックの圧縮を無効にしたマルチパス CSPF 計算では、宛先へのセグメント リストまで N を検索します。
-
すべてのセグメント リストのコストは、 に等しく、宛先に到達する最短のトラフィック制御メトリックと同じです。
-
各セグメント リストは、隣接関係 SID で構成されています。
-
の N 値は、設定によって候補パスに許可されるセグメント リストの最大数です。
-
2 つのセグメント リストが同一ではありません。
-
各セグメント リストは、設定されたすべての制約を満たします。
分散型 CSPF 計算データベース
SR-TE 計算に使用されるデータベースは、トラフィック制御が広告ノードで有効になっているかどうかに関係なく、すべてのリンク、ノード、プレフィックス、および特性を持っています。つまり、コンピューティング ノードが学習したすべてのドメインのトラフィック制御データベース(TED)と IGP リンク状態データベースの和です。その結果、CSPF が機能するためには、 階層レベルで ステートメントをigp-topology[edit protocols isis traffic-engineering]含める必要があります。
分散型 CSPF 計算制約の設定
コンピューティングプロファイルを使用して、計算制約を論理的にグループ化できます。これらのコンピューティング プロファイルは、セグメント ルーティング パスによって参照され、プライマリおよびセカンダリ セグメント ルーティング LSP を計算します。
コンピューティングプロファイルを設定するには、 階層レベルで compute-profile ステートメントを [edit protocols source-packet-routing] 含めます。
サポートされている計算制約の設定には、以下が含まれます。
-
Administrative groups
階層レベル で admin-groups を
[edit protocols mpls]設定できます。Junos OS は、セグメント ルーティング トラフィックエンジニアリング(SR-TE)インターフェイスに管理グループ設定を適用します。計算制約を設定するには、一連の管理グループに 3 つのカテゴリを指定できます。計算制約設定は、すべての候補セグメント ルーティング パスに共通するか、個別の候補パスの下に配置できます。
-
include-anyリスト内の少なくとも 1 つの管理グループを持つリンクがパスを通過することを許可することを指定します。 -
include-allリスト内のすべての設定済み管理グループのリンクがパスを通過することを指定します。 -
excludeリストに設定された管理グループを持たないリンクが、パスを通過することを許容可能であることを指定します。
-
-
Explicit path
コンピューティング プロファイル内の一連のルーター ID を、SR-TE 候補パスの計算の制約として指定できます。各ホップはIPv4アドレスである必要があり、ストリクトまたはルーズタイプの場合があります。ホップのタイプが設定されていない場合は、strictが使用されます。明示的なパス制約を
compute指定する場合は、 segment-list ステートメントの下に オプションを含める必要があります。 -
Maximum number of segment lists (ECMP paths)
候補パスを多数の動的セグメントリストに関連付けることができます。パスは ECMP パスであり、各セグメントリストはアクティブな重みを持つネクスト ホップ ゲートウェイに変換されます。これらのパスは、圧縮の有無にかかわらずパスを計算した結果です。
この属性は、 コンピュートプロファイル設定ステートメントの
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 計算
SR-TE 候補パスは、設定された制約を満たすようにローカルで計算されます。ラベル スタックの圧縮が無効になっている場合、マルチパス CSPF の計算結果は、隣接 SID スタックのセットになります。ラベル スタックの圧縮が有効な場合、結果は一連の圧縮ラベル スタックになります(隣接する SID とノード SID で構成されます)。
セカンダリ パスが計算されると、プライマリ パスによって取得されたリンク、ノード、SRLGs は計算に使用されません。プライマリパスとセカンダリパスの詳細については、 プライマリおよびセカンダリLSPの設定を参照してください。
計算結果が失敗したLSPの場合、トラフィック制御データベース(TED)が変更されると、計算が再試行されます。
分散型 CSPF 計算機能と SR-TE 機能間の相互作用
SR-TE ポリシーのパスに関連付けられた重み付け
ルートのネクスト ホップに貢献する計算された静的 SR-TE パスに対して重みを設定できます。ただし、計算が有効になっている単一のパスは、複数のセグメント リストにつながる可能性があります。これらの計算されたセグメント リストは、その間で ECMP として扱われます。設定された各プライマリに割り当てられた重みを考慮して、これらのセグメントに階層型 ECMP 重み付けを割り当てることができます。
BFDライブラインス検出
計算されたプライマリパスまたはセカンダリパスに対してBFDライブライン検出を設定できます。計算されたプライマリまたはセカンダリパスはすべて、複数のセグメントリストにつながる可能性があります。その結果、セグメントリストに対して設定されたBFDパラメータが、計算されたすべてのセグメントリストに適用されます。すべてのアクティブなプライマリパスがダウンすると、事前にプログラムされたセカンダリパス(提供されている場合)がアクティブになります。
inherit-label-nexthops
計算されたプライマリパスまたはセカンダリパスは、デフォルトの inherit-label-nexthops 動作であるため、 階層の下 [edit protocols source-packet-routing segment-list segment-list-name] の設定を明示的に有効にする必要はありません。
自動変換機能
セグメント リストで自動変換機能を設定し、自動変換機能を持つプライマリ パスまたはセカンダリ パスがこれらのセグメント リストを参照するように設定できます。一方、コンピューティング機能が有効になっているプライマリまたはセカンダリは、セグメント リストを参照できません。その結果、特定のプライマリ パスまたはセカンダリ パスに対してコンピューティング機能と自動変換機能の両方を有効にすることはできません。ただし、コンピューティングタイプのプライマリパスでLSPを設定し、もう1つのLSPを自動変換タイプで設定することもできます。
分散型 CSPF 計算のサンプル構成
例1
例1では、
-
計算されていないプライマリパスは、設定されたセグメントリストを参照します。この例では、設定されたセグメント リスト static_sl1 が参照され、このプライマリ パスの名前としても機能します。
-
計算されたプライマリには名前が設定されている必要があり、この名前は設定されたセグメントリストを参照しないでください。この例では、 compute_segment1 は設定されたセグメントリストではありません。
-
compute_profile_red compute-profile は、 という名前compute_segment1のプライマリ パスに適用されます。
-
compute_profile_red compute-profileには、計算の明示的なパス制約を指定するために使用されるタイプ
computeのセグメントリストが含まれています。
[edit protocols source-packet-routing]
segment-list static_sl1{
hop1 label 80000
}
segment-list exp_path1 {
hop1 ip-address 10.1.1.1 loose
hop2 ip-address 10.2.2.2
compute
}
compute-profile compute_profile_red {
include-any red
segment-list exp_path1
maximum-segment-list-depth 5
}
計算されたパスのネクストホップと静的ネクストホップの重みは、それぞれ2と3です。計算されたパスのネクストホップが comp_nh1、 、 comp_nh2、および comp_nh3で、静的パスのネクストホップが である static_nh場合、重み付けは次のように適用されます。
|
ネクストホップ |
重量 |
|---|---|
|
comp_nh1 |
2 |
|
comp_nh2 |
2 |
|
comp_nh3 |
2 |
|
static_nh |
9 |
例2
例 2 では、プライマリ パスとセカンダリ パスの両方をコンピューティング タイプにすることができ、独自のコンピューティング プロファイルを持つことができます。
[edit protocols source-packet-routing]
compute-profile compute_profile_green{
include-any green
maximum-segment-list-depth 5
}
compute-profile compute_profile_red{
include-any red
maximum-segment-list-depth 8
}
例3
例3では、コンピューティングがプライマリまたはセカンダリパスの下で言及されると、計算のための制約やその他のパラメータを使用せずに、宛先へのパスをローカルに計算します。
[edit protocols source-packet-routing]
source-routing-path srte_colored_policy1 {
to 10.5.5.5
color 5
binding-sid 10001
primary {
compute_segment1 {
compute
}
}
}
スタティック セグメント ルーティング ラベル スイッチ パス
セグメント ルーティング アーキテクチャでは、コア ネットワークのイングレス デバイスが明示的なパスを通ってトラフィックを誘導できます。これらのパスは、セグメント リストを使用して設定し、受信トラフィックが実行する必要があるパスを定義できます。受信トラフィックには、ラベルまたは IP トラフィックがあり、イングレス デバイスでの転送操作は、ラベル スワップまたは宛先ベースのルックアップのいずれかになります。
MPLS ネットワークにおける静的セグメント ルーティング LSP について
ソースパケットルーティングまたはセグメントルーティングは、イングレスルーターが、ネットワーク内の中間ノードに頼らずに、ネットワーク内の特定のノードとリンクを介してパケットを誘導し、実際のパスを決定できるようにするコントロールプレーンアーキテクチャです。
- セグメント ルーティング LSP の概要
- セグメントルーティングLSPを使用するメリット
- 有色スタティック セグメント ルーティング LSP
- 色なし静的セグメント ルーティング LSP
- 静的セグメント ルーティング LSP プロビジョニング
- スタティック セグメント ルーティング LSP の制限
- セグメント ルーティング LSP の動的な作成
- VPN サービスのカラーベース マッピング
- PCE 開始セグメント ルーティング 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は、 階層レベルでの 次がその例です。 [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;
}
}
ここでは、各プライマリおよびセカンダリステートメントはセグメントリストを参照します。 [edit protocols]
source-packet-routing {
segment-list segment_list_name {
hop_1_name label sid_label;
...
hop_n_name label sid_label;
}
}
|
セグメントルーティングLSPを使用するメリット
-
スタティック セグメント ルーティングは、トランジット ルーターの LSP 転送状態に依存しません。したがって、コア内の LSP 転送状態ごとにプロビジョニングと維持を行う必要がなくなり、
-
MPLS ネットワークの拡張性を高めます。
有色スタティック セグメント ルーティング LSP
ステートメントで color 設定された静的セグメントルーティングLSPは、有色LSPと呼ばれます。
有色スタティック セグメント ルーティング LSP の理解
BGPセグメントルーティングポリシーと同様に、色付きLSPのイングレスルートは、IPトラフィックをマッピングするためのキーとして、 destincation-ip-address, color またはinet6color.0ルーティングテーブルにインストールされますinetcolor.0。
静的な色付きのセグメント ルーティング LSP には、ルーティング テーブルに mpls.0 ルートがインストールされているバインディング SID が含まれている場合があります。このバインディング SID ラベルは、ラベル付きトラフィックをセグメント ルーティング LSP にマッピングするために使用されます。ルートのゲートウェイは、プライマリ パスとセカンダリ パスのセグメント リスト設定から取得されます。
色付きセグメント ルーティング LSP のセグメント リスト
有色された静的セグメントルーティングLSPは、LSPを解決するためのファーストホップラベルモードのサポートをすでに証明しています。ただし、第 1 ホップ IP モードは、有色セグメント ルーティング LSP ではサポートされていません。Junos OSリリース19.1R1以降、コミットチェック機能が導入され、有色ルートに関与するすべてのセグメントリストが、すべてのホップに最小ラベルが存在することを確認します。この要件を満たしていない場合、コミットはブロックされます。
色なし静的セグメント ルーティング LSP
ステートメントなしで color 設定された静的セグメントルーティングLSPは、非カラーLSPです。PCEPセグメントルーティングトンネルと同様に、イングレスルートはまたはinet6.3ルーティングテーブルにinet.3インストールされます。
Junos OSは、イングレスルーターで色なし静的セグメントルーティングLSPをサポートしています。1つのソースルーティングパスと1つ以上のセグメントリストを設定することで、カラーなし静的セグメントルーティングLSPをプロビジョニングできます。これらのセグメント リストは、複数の非カラー セグメント ルーティング LSP で使用できます。
カラーなしセグメント ルーティング LSP を理解する
色なしセグメントルーティングLSPには、一意の名前と宛先IPアドレスがあります。宛先へのイングレスルートは、デフォルトプリファレンスが8、メトリックが1のinet.3ルーティングテーブルにインストールされます。このルートにより、非カラー サービスは宛先に関するセグメント ルーティング LSP にマッピングされます。色なしのセグメントルーティングLSPがイングレスルートを必要としない場合、イングレスルートを無効にすることができます。色なしセグメント ルーティング LSP は、バインディング SID ラベルを使用してセグメント ルーティング LSP ステッチングを実現します。このラベルは、セグメントルーティングLSPをセグメントとしてモデル化するために使用でき、階層的な方法で他のセグメントルーティングLSPを構築するためにさらに使用できます。デフォルトでは、バインディング SID ラベルのトランジットの優先度は 8、メトリックは 1 です。
Junos OSリリース18.2R1以降、イングレスデバイス上で静的に設定された非カラーセグメントルーティングLSPは、PCEP(Path Computation Element Protocol)セッションを介してパス計算要素(PCE)に報告されます。これらの色付けされていないセグメント ルーティング LSP は、それらに関連付けられた SID(バインディング サービス識別子)ラベルを持つ場合があります。この機能により、PCE はラベル スタックでこのバインディング SID ラベルを使用して、PCE が開始するセグメント ルーティング LSP パスをプロビジョニングできます。
カラーなしセグメント ルーティング LSP は、最大 8 つのプライマリ パスを持つことができます。複数の運用プライマリ パスがある場合、パケット転送エンジン(PFE)は、パスに設定された重みなどのロード バランシング要因に基づいて、パス上にトラフィックを分散します。これは、パスのいずれも重みが設定されていない場合、またはパスの少なくとも1つがパスに非ゼロ重み付け設定されている場合、ECMP(等価コストマルチパス)になります。どちらの場合も、パスの 1 つまたは一部に障害が発生した場合、PFE は、パス保護を自動的に実現する残りのパス上でトラフィックを再調整します。色なしセグメント ルーティング LSP は、専用のパス保護のためのセカンダリ パスを持つことができます。プライマリ パスに障害が発生した場合、PFE は残りの機能プライマリ パスにトラフィックを再調整します。それ以外の場合、PFE はトラフィックをバックアップ パスに切り替え、パス保護を実現します。カラーなしセグメントルーティングLSPは、イングレスおよびバインディングSIDルートに メトリックを指定 [edit protocols source-packet-routing source-routing-path lsp-name] できます。色付けされていない複数のセグメント ルーティング LSP は、イングレス ルートのネクスト ホップに貢献する同じ宛先アドレスを持ちます。
色付けされていない複数のセグメント ルーティング LSP は、イングレス ルートのネクスト ホップに貢献する同じ宛先アドレスを持ちます。各パス(プライマリまたはセカンダリ)は、各セグメント ルーティング LSP のゲートウェイ候補と見なされます。パスが機能していて、セグメント ルーティング LSP がこれらすべてのセグメント ルーティング LSP の最も優先度が高い場合です。ただし、ネクストホップが保持できるゲートウェイの最大数は、デフォルトで 128 である RPD マルチパス制限を超えることはできません。余分なパスは削除され、最初にセカンダリ パス、次にプライマリ パスが作成されます。特定のセグメント リストは、これらのセグメント ルーティング LSP によって、プライマリ パスまたはセカンダリ パスと複数回参照されることがあります。この場合、複数のゲートウェイがあり、それぞれ固有のセグメント ルーティング LSP トンネル ID を持っています。ゲートウェイは異なりますが、発信ラベル スタックとインターフェイスは同一です。色なしセグメント ルーティング LSP と色付きセグメント ルーティング LSP も同じ宛先アドレスを持つ場合があります。ただし、カラー付きセグメント ルーティング LSP の宛先アドレスは、宛先アドレスとカラーの両方で構成されるため、イングレス ルートの異なる宛先アドレスに対応します。
静的な非カラーセグメントルーティングLSPとPCEPで作成されたセグメントルーティングLSPが共存し、同じイングレスルートに貢献するアドレスが同じ場合、同じ優先度を持つ場合。それ以外の場合、ルートには、最も優先度の高いセグメント ルーティング LSP がインストールされます。
色なしセグメント ルーティング LSP のセグメント リスト
セグメントリストは、ホップのリストで構成されています。これらのホップは、SID ラベルまたは IP アドレスに基づいています。セグメント リスト内の SID ラベルの数が、最大セグメント リストの制限を超えてはなりません。LSP トンネルへの最大セグメントリスト バインディングが 8 から 128 に増加し、システムごとに最大 1,000 トンネルが使用されます。静的セグメント ルーティング LSP あたり最大 128 個のプライマリ パスがサポートされています。階層レベルで最大セグメントリスト制限を [edit protocols source-packet-routing] 設定できます。
Junos OS リリース 19.1R1 以前は、非カラーの静的セグメント ルーティング LSP を使用可能にするため、セグメント リストの最初のホップが発信インターフェイスの IP アドレスで、2 番目の nホップが SID ラベルである可能性がありました。Junos OS リリース 19.1R1 以降、カラーなし静的 LSP の最初のホップが IP アドレスに加えて SID ラベルをサポートするようになったので、この要件は適用されません。最初のホップラベルのサポートにより、有色静的LSPと同様に、静的な非カラーセグメントルーティングLSPを解決するために、MPLS高速再ルート(FRR)と重み付きイコールコストマルチパスが有効になります。
ファーストホップラベルモードを有効にするには、セグメントリストにグローバルまたは個別に ステートメントを含める 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解決のモードを説明しています。
|
ファーストホップ仕様 |
LSP 解決モード |
|---|---|
|
IP アドレスのみ 次がその例です。 segment-list path-1 {
hop-1 ip-address 172.16.12.2;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
セグメント リストは IP アドレスを使用して解決されます。 |
|
SID のみ 次がその例です。 segment-list path-2 {
hop-1 label 1000011;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
セグメント リストは SID ラベルを使用して解決されます。 |
|
IP アドレスと SID(設定なし 次がその例です。 segment-list path-3 {
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
デフォルトでは、セグメントリストはIPアドレスを使用して解決されます。 |
|
IP アドレスと SID(設定あり 次がその例です。 segment-list path-3 {
inherit-label-nexthops;
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
セグメント リストは SID ラベルを使用して解決されます。 |
コマンドを show route ip-address protocol spring-te active-path table inet.3 使用すると、inet.3ルーティングテーブルに複数のセグメントリストがインストールされた、色付けされていないセグメントルーティングトラフィック制御LSPを表示できます。
次がその例です。
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3
inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0
> to 10.11.1.2 via et-0/0/0.1, Push 801007
to 10.21.1.2 via et-0/0/2.1, Push 801007
to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top)
to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top)
to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top)
to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top)
to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top)
to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
静的セグメント ルーティング LSP のセグメント リストの最初のホップ タイプは、以下の場合にコミット失敗を引き起こす可能性があります。
-
トンネルのセグメント リストが異なると、最初のホップ解決タイプが異なります。これは、有色および非有色の静的セグメントルーティングLSPの両方に適用されます。ただし、これは PCEP ドリブン LSP には適用されません。パス計算時の最初のホップ解決タイプの不一致に対して、システムログメッセージが生成されます。
次がその例です。
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }パス-1はIPアドレス モードで、パス2はラベルモードであるため、トンネルlsp1のコミットは失敗します。
-
バインディング SID は、セグメント リスト タイプが SID ラベルである静的な非カラー LSP に対して有効になっています。
次がその例です。
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }ラベル セグメント リスト上のバインディング SID の設定は、有色静的 LSP でのみサポートされ、有色の静的 LSP ではサポートされません。
静的セグメント ルーティング LSP プロビジョニング
セグメント プロビジョニングは、ルーターごとに実行されます。ルーター上の特定のセグメントに対して、隣接 SID ラベルの動的ラベル プールから、またはプレフィックス SID またはノード SID のセグメント ルーティング グローバル ブロック(SRGB)から、必要なラベル プールから固有のサービス識別子(SID)ラベルが割り当てられます。隣接 SID ラベルは動的に割り当てることが可能です。これはデフォルトの動作であり、ローカルの静的ラベル プール(SRLB)から割り当てることもできます。次に、SID ラベルのルートが mpls.0 テーブルにインストールされます。
Junos OS では、 階層レベルで ステートメントを設定することで、 segment 静的セグメント ルーティング LSP を [edit protocols mpls static-label-switched-path static-label-switched-path] 許可します。静的セグメント LSP は、Junos OS の静的ラベル プールに該当する一意の SID ラベルによって識別されます。階層レベルで ステートメントを設定することで、Junos OS静的ラベルプールを[edit protocols mpls label-range]設定static-label-range static-label-rangeできます。
スタティック セグメント ルーティング LSP の制限
-
現在、Junos OSには、最大セグメントリストの奥行きラベルを超えてネクストホップを作成できないという制限があります。そのため、最大 SID ラベルを超えるセグメント リスト(転送ネクストホップの解決に使用される最初のホップの SID ラベルを除く)は、有色セグメント ルーティング LSP または非カラー セグメント ルーティング LSP には使用できません。また、MPLSサービスがセグメントルーティングLSP上にある場合、またはセグメントルーティングLSPがリンクまたはノード保護パス上にある場合、特定のセグメントルーティングLSPで許可される実際の数は、最大制限よりもさらに低くなる可能性があります。いずれの場合も、サービス ラベル、SID ラベル、およびリンクまたはノード保護ラベルの総数は、最大セグメント リストの奥行きを超えてはなりません。階層レベルで最大セグメントリスト制限を
[edit protocols source-packet-routing]設定できます。最大 SID ラベル以下の複数の色なしセグメント ルーティング LSP をつなぎ合わせて、より長いセグメント ルーティング LSP を構築できます。これはセグメントルーティングLSPスティッチングと呼ばれます。これは、バインディング SID ラベルを使用して実現できます。 -
セグメントルーティングLSPステッチングは、実際にはパスレベルで実行されます。カラーなしセグメント ルーティング LSP に、複数のセグメント リストである複数のパスがある場合、ステッチング ポイントで各パスを別の非カラー セグメント ルーティング LSP に個別にステッチできます。ステッチング専用の色なしセグメントルーティングLSPは、 階層レベルで
[edit protocols source-packet-routing source-routing-path lsp-name]ステートメントを設定no-ingressすることで、イングレスルートのインストールを無効にすることができます。 -
カラーなし静的セグメント ルーティング LSP ごとに、最大 128 個のプライマリ パスと 1 個のセカンダリ パスがサポートされています。設定に違反があった場合、コミットチェックは失敗し、エラーが発生します。
-
LSP トンネルへの最大セグメントリスト バインディングが 8 から 128 に増加し、システムごとに最大 1,000 トンネルが使用されます。静的セグメント ルーティング LSP あたり最大 128 個のプライマリ パスがサポートされています。制限として、LSP パスの最大センサー サポートは 32000 のみです。
-
セグメントリストが最大セグメントリストの深さよりも多くのラベルで設定されている場合、設定コミットチェックはエラーで失敗します。
セグメント ルーティング LSP の動的な作成
各 PE(プロバイダ エッジ)デバイスを他の PE デバイスに接続したセグメント ルーティング ネットワークでは、セグメント ルーティング LSP(ラベルスイッチ パス)の設定に大量の設定が必要になりますが、使用できるセグメント ルーティング トラフィック制御(SR-TE)パスはわずかです。これらのLSPのBGPトリガー化された動的作成を有効にして、このような導入における設定量を削減することができます。
- 動的セグメントルーティングLSPテンプレートの設定
- 動的セグメント ルーティング LSP の解決
- セグメント ルーティング LSP の動的作成の設定に関する考慮事項
- 動的セグメント ルーティング LSP でサポートされるサービス
- セグメントルーティングにおける複数のトンネルソースでの動作
- 動的セグメント ルーティング LSP の制限
動的セグメントルーティングLSPテンプレートの設定
セグメント ルーティング LSP の動的作成を有効にするテンプレートを設定するには、 階層に spring-te ステートメントを [edit routing-options dynamic-tunnels] 含める必要があります。
-
カラーダイナミックセグメントルーティングLSPテンプレートの設定例を以下に示します。
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } } -
以下は、非カラー動的セグメント ルーティング LSP テンプレートの設定例です。
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
動的セグメント ルーティング LSP の解決
色付き動的セグメント ルーティング LSP の解決
BGP プレフィックスにカラー コミュニティが割り当てられた場合、最初は catch-all-route-for-that-particular-color ポリシーで解決され、次に BGP プレフィックスを に解決する必要がある SR-TE テンプレートが識別されます。宛先 SID は、BGP ペイロード プレフィックスのネクストホップ属性から派生します。例えば、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 ルーティング テーブルに追加されます。色なしトンネルの宛先は、マッピングリストにテンプレート名を1つだけ持つ別 spring-te の設定で設定する必要があります。このテンプレート名は、同じ spring-te 設定で設定された宛先ネットワークのいずれかに一致するすべてのトンネル ルートに使用されます。これらのトンネルは、機能におけるRSVPトンネルと似ています。
最後のLSPテンプレート名は、プレフィックスとトンネル名の組み合わせです。例えば. <prefix>:dt-srte-<tunnel-name>
動的セグメント ルーティング LSP の設定例
動的セグメント ルーティング LSP テンプレートは、常に部分的なパスを伝送します。最終ホップ ノード SID は、プロトコルの PNH(ネクストホップ アドレス)ノード SID に応じて、トンネル作成時に自動的に派生します。同じテンプレートを、異なる宛先への複数のトンネルで使用できます。このような場合、部分パスは変わらず、PNH に応じて最後のホップのみが変化します。動的セグメント ルーティング LSP テンプレートは、単一のトンネルには共通できないため、完全なパスを伝送できません。完全なパスを使用する場合は、セグメントリストを使用できます。
色付き動的セグメント ルーティング LSP
色付き動的セグメント ルーティング LSP の設定例:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [ 123 124 125 ];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
上記のサンプル設定では、ルートエントリーは次のとおりです。
-
inetcolor.0 tunnel route:10。22.44.0-0/24 --> RT_NH_TUNNEL
-
inetcolor6.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(プレフィックス)-> 10。22.44.55-101(PNH)LSP トンネル名 = 1022.44.55:65:dt-srte-tunnel1
R1(プレフィックス)->ff::10。22.44.55-101(PNH)LSP トンネル名 = 1022.44.55:65:dt-srte-tunnel1
R1(プレフィックス)->ff::10。22.44.55-124(PNH)LSP トンネル名 = 1022.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10。22.44.55-101/64 --> <next-hop>
10。22.44.55-124/64 --> <next-hop>
-
inetcolor6.0 tunnel route:
ffff::10.22.44.55-101/160 --> <next-hop>
ffff::10.22.44.55-124/160 --> <next-hop>
色なし動的セグメント ルーティング LSP
カラーなし動的セグメント ルーティング LSP の設定例:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels {
tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [ 101 ];
}
destination-networks {
10.33.44.0/24;
}
}
}
tunnel2 {
spring-te {
source-routing-path-template {
sr_lsp1;
}
destination-networks {
10.33.44.0/24;
}
}
}
}
上記のサンプル設定では、ルートエントリーは次のとおりです。
-
inet.3 tunnel route:10.33.44.0/24 --> RT_NH_TUNNEL
-
inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(プレフィックス)-> 10.33.44.55(PNH)LSP テンプレート名 = LSP1 --- 10.33.44.55:dt-srte-tunnel2
R1(プレフィックス)->ff:::10.33.44.55(PNH)LSP テンプレート名 = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route:10.33.44.55/32 --> <next-hop>
-
inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>
未解決の動的セグメント ルーティング LSP
未解決の動的セグメント ルーティング LSP の設定例:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [120 121 122 123];
}
destination-networks {
10.33.44.0/24;
10.1.1.0/24;
}
}
}
上記のサンプル設定では、ルートエントリーは次のとおりです。
-
inetcolor.0 tunnel route:10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
inetcolor6.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(プレフィックス)-> 10.33.44.55-124(PNH)トンネルは作成されません。(色のテンプレートが見つかりません)。
セグメント ルーティング LSP の動的作成の設定に関する考慮事項
セグメントルーティングLSPの動的作成を設定する場合は、以下を考慮してください。
-
テンプレートは、カラーオブジェクトで割り当てることができます。動的トンネル
spring-te設定にカラーオブジェクトを含むテンプレートが含まれている場合は、他のすべてのテンプレートもカラーオブジェクトで設定する必要があります。すべての宛先は、その設定内で色付けされているものと見なされます。 -
テンプレートには、定義された色のリストを設定することも、 オプションで
color-any設定することもできます。両方のオプションを同じspring-te設定で共存できます。このような場合、特定の色で割り当てられたテンプレートの優先度が高くなります。 -
コンフィギュレーションでは、 オプションで
spring-tecolor-any定義できるテンプレートは1つだけです。 -
カラーとテンプレートのマッピングは、1 対 1 で行われます。1 つのカラーを複数のテンプレートにマッピングできません。
-
テンプレート名は、 階層の下の
spring-teステートメントで設定し、 オプションを有効にするprimary必要[edit protocols]があります。 -
色付き宛先と色なし宛先を同じ
spring-te設定で共存することはできません。 -
異なる
spring-te設定ステートメントでは、カラーの有無にかかわらず、同じ宛先ネットワークを設定することはできません。 -
色
spring-teなし設定では、カラー オブジェクトなしで設定できるテンプレートは 1 つだけです。
動的セグメント ルーティング LSP でサポートされるサービス
以下のサービスは、色付き動的セグメント ルーティング LSP でサポートされています。
-
レイヤー 3 VPN
-
BGP EVPN
-
エクスポート ポリシー サービス
以下のサービスは、カラーなし動的セグメント ルーティング LSP でサポートされています。
-
レイヤー 3 VPN
-
レイヤー 2 VPN
-
マルチパス構成
セグメントルーティングにおける複数のトンネルソースでの動作
2つのソースがセグメントルーティングから同じ宛先にルートをダウンロードする場合(静的および動的な送信元トンネルなど)、アクティブなルートエントリーの選択にセグメントルーティング優先度が使用されます。値が大きいほど優先度が高くなります。プリファレンスが変わらない場合は、トンネルソースを使用してルートエントリーを決定します。
動的セグメント ルーティング LSP の制限
動的 SR-TE LSP は、以下の機能をサポートしていません。
-
IPv6セグメントルーティングトンネル。
-
静的トンネル。
-
6PEはサポートされていません。
-
分散型 CSPF。
-
sBFDおよびLDPトンネリングは、動的SR-TE LSPとテンプレートではサポートされていません。
-
テンプレートにインストールし、B-SID ルートを作成する。
VPN サービスのカラーベース マッピング
静的な有色およびBGPセグメントルーティングトラフィックエンジニアリング(SR-TE)LSP上のトランスポートトンネルを解決するために、プロトコルのネクストホップ制約(IPv4またはIPv6アドレスに加えて)としてカラーを指定できます。これは、カラー IP プロトコルのネクスト ホップ解決と呼ばれ、解決マップを設定して VPN サービスに適用する必要があります。この機能により、レイヤー 2 およびレイヤー 3 VPN サービスのカラーベース トラフィック ステアリングを有効にできます。
Junos OSは、単一カラーに関連付けられた有色 SR-TE LSPをサポートしています。VPNサービス機能のカラーベースマッピングは、静的な色付きLSPとBGP SR-TE LSPでサポートされています。
- VPNサービスカラーリング
- VPN サービス マッピング モードの指定
- カラー IP プロトコルのネクスト ホップ解決
- IP プロトコルのネクスト ホップ解決にフォールバック
- SR-TE 上の BGP ラベル付きユニキャスト カラーベース マッピング
- VPN サービスのカラーベース マッピングでサポートされている機能とサポートされていない機能
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 によってアドバタイズされます。
次がその例です。
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
または
BGPグループまたはBGPネイバーのエクスポートポリシーとしてルーティングポリシーを適用する場合、ポリシーが vpn-apply-export VPN NLRIに影響を与えるために、BGP、BGPグループ、またはBGPネイバーレベルに ステートメントを含める必要があります。
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
ルーティング ポリシーは、レイヤー 3 VPN プレフィックス NLRI、レイヤー 2 VPN NRI、EVPN NLRI に適用されます。カラー拡張コミュニティーは、すべての VPN ルートによって継承され、1 つまたは複数のイングレス デバイス上のターゲット VRF にインポートされ、インストールされます。
イングレスカラーの割り当て
このモードでは、イングレスデバイス(つまりVPN NLRIの受信者)がVPNサービスを色分けします。このモードを有効にするには、ルーティングポリシーを定義し、 階層レベルでVPNサービスのルーティングインスタンス vrf-import、グループインポート、またはグループネイバーインポートに [edit protocols bgp] 適用します。ルーティング ポリシーに一致するすべての VPN ルートは、指定されたカラー拡張コミュニティにアタッチされます。
次がその例です。
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
または
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
VPN サービス マッピング モードの指定
柔軟なVPNサービスマッピングモードを指定するには、 ステートメントを使用してポリシーを resolution-map 定義し、 階層レベルでVPNサービスのルーティングインスタンス vrf-import、グループインポート、またはグループネイバーインポートでポリシーを参照する [edit protocols bgp] 必要があります。ルーティング ポリシーに一致するすべての VPN ルートは、指定された resolution-map にアタッチされます。
次がその例です。
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
VPNサービスのルーティングインスタンスにインポートポリシーを適用できます。
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
また、インポートポリシーをBGPグループまたはBGPネイバーに適用することもできます。
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
各 VPN サービス マッピング モードでは、解決マップで一意の名前を定義する必要があります。解決マップでは、IP-color の単一のエントリーのみがサポートされています。ここでは、 の形式 ip-address:colorで色付き IP プロトコルのネクスト ホップを使用して VPN ルートが解決されます。
カラー IP プロトコルのネクスト ホップ解決
プロトコルのネクスト ホップ解決プロセスは、色付き IP プロトコルのネクスト ホップ解決をサポートするように拡張されています。有色VPNサービスの場合、プロトコルのネクストホップ解決プロセスは、カラーと解決マップを取得し、 、 の形式で有色IPプロトコルの IP-address:colorネクストホップを構築し、inet6color.0ルーティングテーブルでプロトコルのネクストホップを解決します。
色付き LSP 上の色付きレイヤー 2 VPN、レイヤー 3 VPN、または EVPN サービスのマルチパス解決をサポートするポリシーを設定する必要があります。その後、リゾルバーインポートポリシーとして、関連するRIBテーブルにポリシーを適用する必要があります。
次がその例です。
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
IP プロトコルのネクスト ホップ解決にフォールバック
カラー付き VPN サービスに resolution-map が適用されていない場合、VPN サービスはそのカラーを無視し、IP プロトコルのネクスト ホップ解決にフォールバックします。反対に、非カラーVPNサービスに解決マップが適用されている場合、解決マップは無視され、VPNサービスはIPプロトコルのネクストホップ解決を使用します。
フォールバックは、色付き SR-TE LSP から LDP LSP へのシンプルなプロセスで、LDP 用の RIB グループを使用して inet{6}color.0 ルーティング テーブルにルートをインストールします。色付き IP プロトコルのネクスト ホップの最長プレフィックス一致により、有色 SR-TE LSP ルートが存在しない場合は、一致する IP アドレスを持つ LDP ルートを返す必要があります。
SR-TE 上の BGP ラベル付きユニキャスト カラーベース マッピング
Junos OSリリース20.2R1以降、BGPラベル付きユニキャスト(BGP-LU)は、IPv4とIPv6の両方のアドレスファミリーのセグメントルーティングトラフィックエンジニアリング(SR-TE)上のIPv4またはIPv6ルートを解決できます。BGP-LU は、BGP コミュニティ カラーのマッピングと SR-TE の定義を resolution map サポートします。有色プロトコルのネクスト ホップが構築され、 または inet6color.0 テーブル内の有色 SR-TE トンネルでinetcolor.0解決されます。BGPは、非カラーベースマッピングに および inet6.3 テーブルを使用inet.3します。これにより、ルーターにIPv4アドレスが設定されていないIPv6のみのネットワークで、IPv6ネクストホップアドレスを持つBGP-LU IPv6およびIPv4プレフィックスをアドバタイズできます。この機能により、現在はIS-ISアンダーレイを備えたSR-TE上のBGP IPv6 LUをサポートしています。
では 図 1、コントローラはSR-TEで設定されたIPv6コアネットワークで4つの色付きトンネルを設定します。色付きの各トンネルは、定義された解決マップに応じて、宛先ルーターDへの異なるパスを取得します。コントローラは、ルーターDの2001:db8::3701:2d05インターフェイスに色付きSR-TEトンネルを設定します。BGP は、受信したプレフィックス 2001:db8::3700:6/128 にカラーおよび解決マップを割り当てるためのポリシーをインポートします。割り当てられたコミュニティカラーに基づいて、BGP-LUは、割り当てられた解決マップポリシーに従って、BGP IPv6 LUプレフィックスの色付きネクストホップを解決します。
BGP-LU は、以下のシナリオをサポートします。
-
ISIS/OSPF IPv4 SR 拡張機能を備えた、色付き BGP IPv4 SR-TE 上の BGP IPv4 LU。
-
ISIS/OSPF IPv4 SR 拡張機能を備えた、静的な色付きおよび色以外の IPv4 SR-TE 上の BGP IPv4 LU。
-
ISIS IPv6 SR 拡張機能を備えた、色付き BGP IPv6 SR-TE 上の BGP IPv6 LU。
-
ISIS IPv6 SR 拡張を使用した、静的な色付きおよび色なし IPv6 SR-TE 上の BGP IPv6 LU。
-
IPv6 ローカル アドレスと IPv6 ネイバー アドレスを持つ IPv6 レイヤー 3 VPN サービス。
-
ISIS IPv6 SR 拡張機能を備えた BGP IPv6 SR-TE 上の IPv6 レイヤー 3 VPN サービス。
-
ISIS IPv6 SR 拡張機能を使用した、静的な色付きおよび色以外の IPv6 SR-TE 上での IPv6 レイヤー 3 VPN サービス。
VPN サービスのカラーベース マッピングでサポートされている機能とサポートされていない機能
次の機能は、VPN サービスのカラーベース マッピングでサポートされています。
-
BGP レイヤー 2 VPN(Kompella Layer 2 VPN)
-
BGP EVPN
-
単一の IP カラー オプションを使用した解決マップ。
-
色付き IPv4 および IPv6 プロトコルのネクスト ホップ解決。
-
ルーティング情報ベース(ルーティング テーブルとも呼ばれる)グループベースのフォールバック(inetcolor.0 ルーティング テーブル内の LDP LSP にフォールバック)。
-
色付き SR-TE LSP。
-
仮想プラットフォーム。
-
64 ビット Junos OS。
-
論理システム。
-
BGPラベル付きユニキャスト。
次の機能は、VPN サービスのカラーベース マッピングではサポートされていません。
-
RSVP、LDP、BGP-LU、スタティックなどの有色 MPLS LSP。
-
レイヤー 2 回線
-
FEC-129 BGP 自動検出および LDP 信号のレイヤー 2 VPN。
-
VPLS
-
MVPN
-
resolution-mapを使用したIPv4とIPv6。
PCE 開始セグメント ルーティング LSP のトンネル テンプレート
PCE が開始するセグメント ルーティング LSP のトンネル テンプレートを設定して、これらの LSP(BFD(Bidirectional Forwarding Detection)と LDP トンネリングの 2 つの追加パラメータを引き渡すことができます。
PCE開始のセグメントルーティングLSPが作成されている場合、LSPはポリシーステートメント(存在する場合)に対してチェックされ、一致する場合、ポリシーはそのLSPに設定されたテンプレートを適用します。テンプレート設定は、LSP ソース(PCEP)によって提供されていない場合にのみ継承されます。例えば、メトリックです。
テンプレートを設定するには:
-
階層レベルで ソースルーティングパステンプレート ステートメントを
[edit protocols source-packet-routing]含めます。追加のBFDおよびLDPトンネリングパラメーターは、ここで設定できます。 -
PCE 開始 LSP をチェックする必要があるポリシー ステートメントを一覧表示するには、 階層レベルに
[edit protocols source-packet-routing]ソースルーティングパステンプレートマップステートメントを含めます。 -
テンプレートを適用する必要があるLSPをリストするポリシーを定義します。
ステートメントには
from、 およびlsp-regex一致条件を使用して、LSP 名または LSP 正規表現のいずれかを含lspめることができます。これらのオプションは相互に排他的であるため、特定の時点で 1 つのオプションのみを指定できます。ステートメントには
then、アクションをsr-te-template受け入れるというオプションを含める必要があります。これは、PCE が開始する LSP にテンプレートを適用します。
PCE 開始 LSP のテンプレートを設定する場合は、以下の点に注意してください。
-
テンプレート設定は、静的に設定されたセグメントルーティングLSP、または他のクライアントのセグメントルーティングLSPには適用されません。
-
PCEP が提供する設定は、テンプレート設定よりも優先されます。
-
PCEP LSPは、テンプレートのセグメントリスト設定を継承しません。
例：静的セグメント ルーティング ラベルスイッチ パスの設定
この例では、MPLSネットワークで静的セグメントルーティングラベルスイッチパス(LSP)を設定する方法を示しています。この設定により、MPLS ネットワークの拡張性が向上します。
要件
この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。
-
7つのMXシリーズ5Gユニバーサルルーティングプラットフォーム
-
すべてのルーターでJunos OSリリース18.1以降が実行されている
開始する前に、デバイス インターフェイスを必ず設定してください。
概要
Junos OS では、 階層レベルで ステートメントを設定することで、色なし静的セグメント ルーティング トンネルのイングレス ルーターで、明示的なセグメント ルーティング パスの segment-list セットが [edit protocols source-packet-routing] 設定されます。階層レベルで [edit protocols source-packet-routing] ステートメントを設定することで、セグメントルーティングトンネルをsource-routing-path設定できます。セグメント ルーティング トンネルには、宛先アドレスと 1 つ以上のプライマリ パスがあり、オプションでセグメント リストを参照するセカンダリ パスがあります。各セグメント リストは、ホップのシーケンスで構成されています。色なし静的セグメント ルーティング トンネルの場合、セグメント リストの最初のホップは即時のネクスト ホップ IP アドレスを指定し、2 番目から N 番目のホップは、パスが通過するリンクまたはノードに対応するセグメント識別(SID)ラベルを指定します。セグメント ルーティング トンネルの宛先へのルートは、inet.3 テーブルにインストールされています。
トポロジ
この例では、プロバイダ エッジ ルーター PE1 と PE5 でレイヤー 3 VPN を設定します。すべてのルーターで MPLS プロトコルを設定します。セグメント ルーティング トンネルは、ルーター PE1 とルーター PE5 にプライマリ パスを設定して、ルーター PE1 からルーター PE5 に設定されます。また、ルーターPE1は、パス保護のためのセカンダリパスで設定されています。トランジット ルーター PE2 から PE4 への設定には、ラベル ポップと発信インターフェイスを持つ隣接 SID ラベルが設定されています。
設定
CLI クイックコンフィギュレーション
この例を迅速に設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを 階層レベルの [edit] CLI にコピー アンド ペーストして、設定モードから を入力 commit します。
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
デバイスPE1の設定
手順
次の例では、設定階層内のさまざまなレベルに移動する必要があります。CLIのナビゲーションについては、 CLIユーザーガイドの設定モードでのCLIエディターの使用を参照してください。
デバイスPE1を設定するには:
-
インターフェイスを設定します。
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
自律システム番号とオプションを設定して、パケット転送ルーティングオプションを制御します。
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
MPLSプロトコルでインターフェイスを設定し、MPLSラベル範囲を設定します。
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
アップデートにおけるNLRIのピアグループ、ローカルアドレス、プロトコルファミリーのタイプ、ピアグループのネイバーのIPアドレスを設定します。
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
プロトコルエリアインターフェイスを設定します。
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
プロトコルソースパケットルーティング(SPRING)のソースルーティングトラフィックエンジニアリング(TE)ポリシーのプライマリおよびセカンダリパスのIPv4アドレスとラベルを設定します。
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
プロトコルSPRINGの宛先IPv4アドレス、バインディングSIDラベル、プライマリ、およびセカンダリソースルーティングパスを設定します。
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
ポリシーオプションを設定します。
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
BGP コミュニティ情報を設定します。
[edit policy-options] set community VPN-A members target:65000:1
-
インスタンスタイプ、インターフェイス、ルーター区別、VRFインポート、エクスポート、テーブルラベルでルーティングインスタンスVRF1を設定します。プロトコルOSPFのエクスポートポリシーとエリアのインターフェイスを設定します。
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
結果
設定モードから、 、show routing-optionsshow policy-optionsshow protocolsおよび のコマンドをshow interfaces入力して、設定をshow routing-instances確認します。出力結果に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。
[edit]
user@PE1# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.13.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.17.1/24;
}
}
}
}
policy-options {
policy-statement VPN-A-export {
term a {
from protocol [ ospf direct ];
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from {
protocol bgp;
route-filter 10.10.0.0/16 orlonger;
}
then accept;
}
policy-statement load-balance-policy {
then {
load-balance per-packet;
}
}
community VPN-A members target:65000:1;
}
routing-instances {
VRF1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0;
}
export bgp-to-ospf;
}
}
interface ge-0/0/5.0;
route-distinguisher 192.168.147.211:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
vrf-table-label;
}
}
routing-options {
autonomous-system 65000;
forwarding-table {
export load-balance-policy;
chained-composite-next-hop {
ingress {
l3vpn;
}
}
}
}
protocols {
bgp {
group pe {
type internal;
local-address 192.168.147.211;
family inet-vpn {
unicast;
}
neighbor 192.168.146.181;
}
}
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface ge-0/0/1.0;
}
}
source-packet-routing {
segment-list sl-15-primary {
hop-1 ip-address 10.10.13.3;
hop-2 label 1000134;
hop-3 label 1000145;
}
segment-list sl-15-backup {
hop-1 ip-address 10.10.12.2;
hop-2 label 1000123;
hop-3 label 1000134;
hop-4 label 1000145;
}
source-routing-path lsp-15 {
to 192.168.146.181;
binding-sid 1000999;
primary {
sl-15-primary;
}
secondary {
sl-15-backup;
}
}
}
}
デバイスPE2の設定
手順
次の例では、設定階層内のさまざまなレベルに移動する必要があります。CLIのナビゲーションについては、 CLIユーザーガイドの設定モードでのCLIエディターの使用を参照してください。
-
インターフェイスを設定します。
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
プロトコルMPLSの静的LSPを設定します。
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
プロトコルMPLSのインターフェイスと静的ラベル範囲を設定します。
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
プロトコルOSPFのインターフェイスを設定します。
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
結果
ルーターPE2の設定モードから、 および show protocols コマンドを入力して設定をshow interfaces確認します。出力結果に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。
[edit]
user@PE2# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.23.2/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
static-label-switched-path adj-23 {
segment {
1000123;
next-hop 10.10.23.3;
pop;
}
}
static-label-switched-path adj-21 {
segment {
1000221;
next-hop 10.10.12.1;
pop;
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}検証
設定が正しく機能していることを確認します。
- ルーターPE1のルーティングテーブルinet.3のルートエントリーの検証
- ルーターPE1のルーティングテーブルmpls.0のルートテーブルエントリーの検証
- ルーターPE1のSPRINGトラフィックエンジニアリングLSPの検証
- ルーターPE1のイングレスルーターでのSPRINGトラフィックエンジニアリングLSPの検証
- ルーターPE2のルーティングテーブルmpls.0のルーティングテーブルエントリーの検証
- ルーターPE2の静的MPLS LSPセグメントのステータス検証
ルーターPE1のルーティングテーブルinet.3のルートエントリーの検証
目的
ルーターPE1のルーティングテーブルinet.3のルートエントリーを検証します。
対処
動作モードから、 コマンドを show route table inet.3 入力します。
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)意味
出力には、セグメント ルーティング トンネルのイングレス ルートが表示されます。
ルーターPE1のルーティングテーブルmpls.0のルートテーブルエントリーの検証
目的
ルーティング テーブル mpls.0 のルート エントリーを検証します。
対処
動作モードから、 コマンドを show route table mpls.0 入力します。
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
意味
出力には、セグメント ルーティング トンネルの SID ラベルが表示されます。
ルーターPE1のSPRINGトラフィックエンジニアリングLSPの検証
目的
イングレスルーターでSPRINGトラフィックエンジニアリングLSPを検証します。
対処
動作モードから、 コマンドを show spring-traffic-engineering overview 入力します。
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
意味
出力は、イングレスルーター上のSPRINGトラフィックエンジニアリングLSPの概要を表示します。
ルーターPE1のイングレスルーターでのSPRINGトラフィックエンジニアリングLSPの検証
目的
イングレスルーターでSPRINGトラフィックエンジニアリングLSPを検証します。
対処
動作モードから、 コマンドを show spring-traffic-engineering lsp detail 入力します。
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)意味
出力には、イングレスルーター上のSPRINGトラフィックエンジニアリングLSPの詳細が表示されます。
ルーターPE2のルーティングテーブルmpls.0のルーティングテーブルエントリーの検証
目的
ルーターPE2のルーティングテーブルmpls.0のルーティングテーブルエントリーを検証します。
対処
動作モードから、 コマンドを show route table mpls.0 入力します。
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, PopルーターPE2の静的MPLS LSPセグメントのステータス検証
目的
ルーターPE2のMPLS LSPセグメントのステータスを確認します。
対処
動作モードから、 コマンドを show mpls static-lsp 入力します。
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0意味
出力は、ルーターPE2の静的MPLS LSPセグメントのステータスを表示します。
ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリング向けルーティングエンジンベースS-BFD
パス障害を検出する高速メカニズムとしてS-BFDを使用し、ファーストホップラベル解決と共に、非カラーおよび有色ラベルスイッチパス(LSP)上でシームレスな双方向転送検出(S-BFD)を実行できます。
- ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリングのためのREベースS-BFDについて
- ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリング向けREベースS-BFDの設定
- 例
- LSPが静的セグメントルーティングトンネルに設定されており、S-BFDセッションステータスが表示されていることを確認する
- プライマリネクストホップとセカンダリネクストホップを使用したセグメントルーティングトンネルルートの検証
- プライマリ パスの S-BFD セッションの検証
ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリングのためのREベースS-BFDについて
ファーストホップラベル用S-BFDスタティックセグメントルーティングトンネル
セグメントルーティングアーキテクチャにより、コアネットワークのイングレスノードは、ネットワークを通過する明示的なパスを通じてトラフィックを誘導できます。セグメントルーティングトラフィックエンジニアリング(TE)ネクストホップは、セグメント識別子(SID)のリストまたはリストです。これらのセグメント リストは、受信トラフィックが必要なネットワーク内のパスを表しています。受信トラフィックには、ラベルまたはIPトラフィックがあり、イングレスノードでの転送操作は、ラベルスワップまたは宛先ベースのルックアップで、トラフィックを転送パスのセグメントルーティングTEパスに誘導することができます。
ファーストホップラベル解決により、無着色および有色の静的セグメントルーティングLSP上でシームレスBFD(S-BFD)を実行し、パス障害を検出し、グローバルコンバージェンスをトリガーする高速メカニズムとしてS-BFDを使用できます。S-BFDが必要とする状態変更はBFDに比べて少ないため、パス障害の報告にかかる時間が短縮されます。
1つまたは複数のプライマリLSPとオプションでセカンダリLSPを持つセグメントルーティングトンネルが与えられた場合、これらのLSPのいずれかでS-BFDを有効にすることができます。S-BFDセッションがダウンした場合、ソフトウェアは障害が発生したLSPのネクストホップを削除することで、セグメントルーティングトンネルのルートを更新します。LSP のファーストホップ ラベルが 1 つ以上の即時ネクストホップを指す場合、 少なくとも 1 つのネクストホップが利用可能であれば、カーネルは S-BFD パケットを送信し続けます(基盤となるネクストホップ到達可能性の障害検知は、S-BFD 検出タイマーの期間よりも高速である必要があります)。
このモデルは、自動変換派生 LSP でサポートされています。
LSP レベルの S-BFD
S-BFDセッションは、固有のラベルスタック+アドレスファミリーの組み合わせごとに作成されます。同一のセグメントリストを設定し、それらすべてに対してS-BFDを有効にすることができます。同一のラベルスタック+アドレスファミリーの組み合わせを持つセグメントリストは、同じS-BFDセッションを共有します。S-BFDセッションの送信元アドレスは、メインインスタンスの下で、最小設定のループバックアドレス(特別なアドレスを除く)に設定されます。
選択した送信元アドレスがルーティング可能であることを確認します。
LSPのアドレスファミリーは、セグメントルーティングTEトンネル内の「to」アドレスのアドレスファミリーに基づいて派生します。S-BFDが設定されたLSPの状態は、BFDが稼働しているかどうかによっても異なります。LSPにS-BFDが設定されている場合、S-BFDがパスが有効であることを報告するまでLSPルートは計算されません。
S-BFDパラメータ
セグメントルーティング TE パスでは、以下の S-BFD パラメーターがサポートされています。
-
リモート識別子
-
最小間隔
-
乗数
-
ルーターアラートオプションなし
S-BFDでは、各レスポンダは複数の識別子を持つ場合があります。識別子は、IGPによって他のルーターにアドバタイズされたり、これらのルーターで静的に設定されたりする可能性があります。イニシエーターでは、自分または中央コントローラによる決定または解決に基づいて、静的設定によってS-BFDセッションのリモート識別子として特定の識別子が選択されます。同じキーラベルスタックで複数のLSPが作成され、各パラメータでS-BFDが有効になっている場合、各パラメータのアグレッシブ値が共有S-BFDセッションで使用されます。識別子パラメータの場合、最も低い値は最もアグレッシブと見なされます。ルーターアラートオプションと同様に、ルーターアラートが設定されていない設定の1つでも、派生したS-BFDパラメータにはルーターアラートオプションはありません。
制限
-
グローバル修復のみがサポートされます。
-
設定したタイマー値に応じてS-BFDが障害を検出しても、コンバージェンス時間はグローバル修復時間(seconds)に依存します。
SBFDセッションのリモート識別子(RD)の自動導出
Junos OS リリース 22.4R1 以降、SR-TE パスの SBFD セッションに自動派生リモート 識別子を使用できるようになりました。この機能では、イングレスデバイスまたはトランジットデバイスのSFBD設定で と、対応するエンドポイントに一致するローカル識別子を設定 remote-discriminator する必要はありません。代わりに、エグレスPEデバイスは、そのローカル識別子としてIPアドレスを受け入れます。BFDでIPアドレスをローカル識別子として許可するには、 設定を使用します set protocols bfd sbfd local-discriminator-ip 。
また、複数のコントローラでプロビジョニングされた SR-TE ポリシーで SBFD 設定で共通の SBFD テンプレートを使用することもできます。これらの SBFD セッションでは、Junos OS は SR-TE ポリシーに一致するために、トンネル エンドポイントからリモート 識別子を自動的に導き出します。
-
私たちは、IPv6エンドポイントではなく、IPv4エンドポイントに対してのみRDの自動導出をサポートしています。
-
カラー専用トンネルのRDの自動導出はサポートしていません。静的に設定された SR-TE カラー専用トンネルに RD が設定されていない(RD の自動導出によって)場合、システムにコミット エラーが表示されます。SR-TE テンプレート設定を使用して、動的カラー専用トンネルに RD が設定されていない場合、Junos OS はそのトンネルの sbfd 設定をスキップします。
ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリング向けREベースS-BFDの設定
セグメントリストに対してLSPレベルS-BFDを有効にするには、 階層と 階層で [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name]設定ステートメントを [edit protocols source-packet-routing source-routing-path lsp-path-name secondary segment-list-name]設定bfd-liveness-detection します。
次の手順では、基本構成と、ファーストホップラベル解決によるS-BFDの動作を示します。
以下の手順では、基本 構成の概要を示します。
イングレスルーターでは、プライマリパスとセカンダリパスとして使用する静的セグメントルーティングトンネルのファーストホップラベルを持つ1つ以上のセグメントリストを設定します。
イングレスルーターでは、複数のプライマリパス(ロードバランシング用)、または1つのプライマリパスと1つのセカンダリパス(パス保護用)のいずれかで静的セグメントルーティングトンネルを設定します。各プライマリまたはセカンダリパス(LSP)は、すでに設定したセグメントリストの1つを指し、貢献するLSPからファーストホップラベルから派生したネクストホップを使用してルートを作成します。
イングレスルーターでは、パケット単位のロードバランシングを有効にして、イングレスルートとバインディングSIDルート(すべてがファーストホップラベルを持つ)を介して解決するルート が、パケット転送エンジン内のすべてのアクティブなパスをインストールするようにします。LSP下のS-BFDセッションは、そのLSPを使用するすべてのルートを保護します。
セグメントルーティングトンネルのエグレスルーターでは、ローカル識別子DでS-BFDレスポンダーモードを設定し、各FPC上でD用の分散型S-BFDリスナーセッションを作成します。
イングレスルーターでは、パス障害検知を確認したいすべてのLSPに対してS-BFDを設定します。エグレスルーターのローカルS-BFD識別子と一致するように、リモート識別子Dを指定します。現在のLSPキーにイニシエーターセッションがまだ存在しない場合、S-BFDイニシエーターセッションは、LSPラベルスタック+アドレスファミリーの組み合わせをキーとして使用して作成されます。一致する BFD セッションの場合の S-BFD パラメーターは、新しい共有 LSP を考慮して再評価されます。S-BFDパラメータが派生すると、各パラメータのアグレッシブ値が選択されます。
以下の手順では、基本的な操作について説明 します 。
S-BFDイニシエーターセッションは、ルーティングエンジン上の集中モードで実行されます。ソフトウェアは、S-BFDセッションのアップおよびダウン状態を追跡します。
S-BFD状態がUPに移動すると、関連するルートに対してLSPが考慮されます。
イングレスルーターでは、ソフトウェアがS-BFDセッションダウンを検出した場合、セッションダウン通知がルーティングデーモン(RPD)に送信され、RPDは障害が発生したLSPのネクストホップをセグメントルーティングトンネルのルートから削除します。
手順における総トラフィックロスは、S-BFD障害検知時間とグローバル修復時間に拘束されます。S-BFD障害検出時間は、S-BFD最小間隔および乗数パラメータによって決定されます。グローバル修復時間は、セグメントルーティングTEのプロセス時間と転送へのルートの再ダウンロードに依存します。
LSP ラベル スタックは以下のように変更されます。
特定の LSP は、既存の S-BFD セッションから切り離されています。既存のS-BFDセッションに、それを参照するLSPが少なくとも1つ存在する場合、古いBFDセッションは保持されますが、既存のLSPセッション間の積極的なパラメータ値 が選択されるように、S-BFDパラメータが再評価されます。また、S-BFDセッションの名前は、変更がある場合は最低1つに更新されます。古いS-BFDセッションにLSPがこれ以上接続されていない場合、そのS-BFDセッションは削除されます。
ソフトウェアは、new-label-stack+アドレスファミリーの組み合わせ値と一致する既存のBFDセッションを見つけようとします。このような一致が存在する場合、LSPはその既存のS-BFDセッションを指します。S-BFD セッションは、ステップ 1 の再評価と同様に、パラメーターまたはセッション名の変更について再評価されます。
システムに一致するBFDセッションがない場合、新しいBFDセッションが作成され、S-BFDパラメータがこのLSPから導き出されます。
注:S-BFDセッションの最小間隔と乗数が、セッションの障害検出時間を決定します。修理時間は、世界的な修理時間によっても異なります。
以下の出力は、プライマリLSPを持つ有色LSPに使用する設定ステートメントを示しています。
[edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
... {
bfd-liveness-detection {
sbfd {
remote-discriminator value;
}
}
}
}
}
レスポンダ側では、正しい識別子を設定する必要があります。
[edit protocols bfd]
sbfd {
local-discriminator value;
}
デフォルトでは、ルーターアラートはS-BFDパケットに対して設定されています。レスポンダー側で MPLS ヘッダーが削除されると、パケットは宛先アドレス ルックアップなしで処理のためにホストに送信されます。イングレス ルーターで no-router-alert オプションを有効にした場合、ルーターアラート オプションは IP オプションから削除されるため、エグレス側から削除されます。lo0 に宛先アドレスを明示的に設定する必要があります。それ以外の場合、パケットは破棄され、S-BFDはダウンしたままになります。
[edit interfaces lo0 unit 0 family inet] address 127.0.0.1/32;
新しいトレース フラグ 、 を使用して BFD bfdアクティビティをトレースできます。
user@host# set protocols source-packet-routing traceoptions flag bfd
例
以下の設定は、LSP保護を備えた非カラースタティックセグメントルーティングトンネルの例です。
protocols {
source-packet-routing {
source-routing-path ncsrlsp5 {
to 10.10.10.10;
primary {
ncsrpath12 {
weight 1;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath13 {
weight 2;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath14 {
weight 3;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath15 {
weight 4;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
segment-list ncsrpath12 {
hop1 label 50191;
hop2 label 801000;
}
segment-list ncsrpath13 {
hop1 label 50191;
hop2 label 801001;
hop3 label 801000;
}
segment-list ncsrpath14 {
hop1 label 801000;
}
segment-list ncsrpath15 {
hop1 label 801002;
hop2 label 801000;
}
}
}
}
}
LSPが静的セグメントルーティングトンネルに設定されており、S-BFDセッションステータスが表示されていることを確認する
目的
show spring-traffic-engineering lsp detail コマンドを使用して、S-BFDセッションステータスを持つ静的セグメントルーティングトンネルのLSPを表示します。
対処
user@host> show spring-traffic-engineering lsp detail
Name: abc
To: 77.77.77.77
State: Up
Path: sl1
Outgoing interface: NA
BFD status: Up BFD name: V4-sl1
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801007
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 22222
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 3333
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Total displayed LSPs: 1 (Up: 1, Down: 0)
多くのLSPが同じBFDセッションを共有できるため、一意のラベルスタック+アドレスファミリーの組み合わせを持つ最初のLSPが立ち上がると、S-BFDセッションの名前はアドレスファミリー+lsp-nameを使用します。後でより多くのLSPが同じセッションを共有する場合、セッションの名前がS-BFDセッションの状態に影響を与えることなく、アドレスファミリー+最小lsp-nameに変更される可能性があります。S-BFDセッションの名前は、 コマンドからの show bfd session extensive 出力にも表示されます。各 LSP の出力には、前述の例に示すように、S-BFD ステータスと、それが参照している S-BFD 名が表示 BFD status: Up BFD name: V4-sl2されます。LSP ごとに S-BFD セッションが 1 つも存在しない可能性があるため、LSP レベルの S-BFD カウンターは表示されません。
プライマリネクストホップとセカンダリネクストホップを使用したセグメントルーティングトンネルルートの検証
目的
イングレスルーターのルーティングエンジンで、プライマリネクストホップとセカンダリネクストホップを持つセグメントルーティングトンネルルートを確認します。
対処
user@host> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
128.9.146.157/32 *[SPRING-TE/8] 00:43:16, metric 1
> to 55.1.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
to 55.1.12.2 via ge-0/0/1.0, Push 1000934, Push 1000923(top)
プライマリ パスの S-BFD セッションの検証
目的
イングレスルーターのルーティングエンジンで、プライマリパスのS-BFDセッションを確認します。
対処
user@host> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 4.000 1.000 4
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Session up time 00:40:53, previous down time 00:02:08
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD (Seamless)
Min async interval 1.000, min slow interval 1.000
Adaptive async TX interval 1.000, RX interval 1.000
Local min TX interval 1.000, minimum RX interval 1.000, multiplier 4
Remote min TX interval 1.000, min RX interval 0.001, multiplier 4
Local discriminator 28, remote discriminator 32
Echo mode disabled/inactive
Remote is control-plane independent
Path-Name V4-sl-1
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
イングレスルーターのルーティングエンジンで、セカンダリパスのS-BFDセッションも同様に確認します。
シングルホップスタティックLSPを使用した集合型イーサネット・メンバー・リンクの静的隣接関係セグメント識別子の設定
アグリゲート イーサネット(AE)バンドルが使用されているネットワークでは、アグリゲート リンクを任意の数の物理リンクのバンドルにできます。これらの AE バンドル インターフェイスを介して送信されたトラフィックは、AE インターフェイスのメンバー リンクのいずれかに転送されます。トラフィックは、トラフィックの負荷分散のために定義されたハッシュに基づいて任意の物理リンクを取得できるため、どのリンクが問題になったか、トラフィックをドロップしているのかを分離することが困難になります。ネットワークで利用可能な転送パスをテストする方法の1つは、AEインターフェイスの特定のメンバーリンクを指すネクストホップを持つシングルホップの静的ラベルスイッチパス(LSP)を追加することです。
静的LSPのデフォルトラベル操作は、ポップおよびフォワードである必要があります。パケットがラベル付けされたこれらのルートに到達すると、そのパケットは特定のメンバー・リンクに転送されます。一意のラベルは、メンバー・リンクを識別するために使用されます。これらのラベルは、隣接関係セグメント識別子(SID)と呼ばれ、静的にプロビジョニングされます。
すべてのトランジット静的LSPによって割り当てられたラベルを含むラベルスタックをコントローラに構築することで、ネットワーク内のパケットのフローを制御できます。運用、管理、保守(OAM)パケットは、ラベルスタック全体で作成され、ネットワークにインジェクトされます。
パケットがこのラベルルートに到達すると、ラベルがポップされ、設定で指定されたメンバーリンク上でトラフィックが転送されます。パケットの転送中に宛先MACが選択され、宛先MacはアグリゲートインターフェイスMACアドレス(設定されたネクストホップアドレスに基づいて選択)です。
メンバー・リンクがダウンし、集約インターフェースがアップになると、そのメンバー・リンクに対応するルートが削除されます。集約インターフェイスがダウンすると、集約インターフェイスのメンバーリンクに対応するすべてのルートが削除されます。子物理インターフェイスがLACPに切り離されていても、子物理インターフェイスが稼働している場合、子リンクのラベル付きルートが削除されます。LACP切断の場合、メンバー・リンクが立ち上がっており、転送状態が無効な場合、子物理インターフェースが切り離されたときに、OAMパケットがPFEでドロップされます。
以下の例を使用して、AEメンバーリンクにシングルホップ静的LSPを設定します。
静的ラベル範囲を定義します。
user@host# set protocols mpls label-range static-label-range 1000000 1048575;注:静的LSPに1000000-1048575のデフォルトの静的ラベル範囲を設定することをお勧めします。デフォルトの静的ラベル範囲以外のラベル範囲を設定する場合は、複数の範囲を設定します。
静的ラベル範囲のセグメントルーティングローカルブロック(SRLB)プールから、AEメンバーリンクの静的LSPを作成します。
user@host# set protocols mpls static-label-switched-path statc-lsp transit 100001 pop next-hop 10.1.1.1 member-interface ge-0/0/0
この設定では、ラベル付きトランジット ルーターが mpls.0 にインストールされ、ラベルをポップして、ネクスト ホップを下にパケットを転送します。ブロードキャスト インターフェイス(ge-、xe-、ae-など)にはネクスト ホップ アドレスが必須で、P2P インターフェイスには if-name が使用されます(例:so-)。宛先MACアドレスを選択するためにネクストホップIPアドレスが使用されるため、アドレスはブロードキャストインターフェイスに必要です。パケットの送信元MACアドレスは、AEのMACアドレスです。
サンプル出力は、ネクストホップ出力のメンバー・リンク名を表示しています。
show mpls static-lsp extensive
user@host> show mpls static-lsp extensive Ingress LSPs: Total 0, displayed 0, Up 0, Down 0 Transit LSPs: LSPname: static-lsp1, Incoming-label: 1000001 Description: verify-static-lsp-behavior State: Up, Sub State: Traffic via primary but unprotected Nexthop: 10.2.1.1 Via ae0.0 -> ge-0/0/0 LabelOperation: Pop Created: Thu May 25 15:31:26 2017 Bandwidth: 0 bps Statistics: Packets 0, Bytes 0
show route label label-name extensive
user@host> show route label 1000001 extensive
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1000001 (1 entry, 1 announced)
TSI:
KRT in-kernel 1000001/52 -> {Pop }
*MPLS Preference: 6
Next hop type: Router, Next hop index: 611
Address: 0xb7a17b0
Next-hop reference count: 2
Next hop: 10.2.1.1 via ae0.0 -> ge-0/0/0 weight 0x1, selected
Label operation: Pop
Load balance label: None;
Label element ptr: 0xb7a1800
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x15d
State: <Active Int>
Age: 3:13:15 Metric: 1
Validation State: unverified
Task: MPLS
Announcement bits (1): 1-KRT
AS path: I
Label 188765184遅延の最適化されたドメイン内およびドメイン間のセグメント ルーティング パスの計算
- トラフィックエンジニアリングパスの遅延ベースメトリックの概要
- パス計算のための遅延ベースメトリックのメリット
- SR パスの遅延メトリックを使用した DCSPF ベースの計算の概要
- ドメイン間およびドメイン内の遅延メトリックの使用事例の概要
- 光ネットワークの遅延メトリックの使用事例
トラフィックエンジニアリングパスの遅延ベースメトリックの概要
動的な遅延ベースのメトリックを活用することは、最新のネットワークに望ましい属性になりつつあります。遅延ベースのメトリックは、PCE(Path Computation Element)がトラフィックエンジニアリングパスを計算するために不可欠です。遅延ベースのメトリックを使用して、最小遅延パスまたは最小遅延パスにパケットを誘導できます。これを行うには、各リンクの遅延を測定し、適切なルーティングプロトコル(IGPまたはBGP-LS)を使用してアドバタイズし、イングレスがそのTEDにリンクごとの遅延プロパティを持つ必要があります。
各リンクで遅延をアドバタイズする方法、またはリンク測定を有効にする方法については、 ISISでリンク遅延測定とアドバタイズを有効にする方法を参照してください。
以下の一連のイベントは、ネットワークの変更の検出を測定、アドバタイズ、計算し、遅延が最も短いトラフィックエンジニアリングパスを計算する場合に発生します。
- 合成プローブとルーター間の遅延を測定することで、ネットワークの変化を検出します。
- IGP拡張TEメトリック拡張により、結果をイングレスノードにフラッディングします。
- その結果を、対応する BGP-LS 拡張を持つ集中型コントローラに告知します。
- IGP ベースの最短の累積遅延メトリック パス(Flex-algo)を計算します。
- 最小の累積遅延または遅延メトリック(SR-TE)を使用して、トラフィック制御された明示的なパス(送信元から宛先へ)を計算します。
パス計算のための遅延ベースメトリックのメリット
- ネットワーク全体で最も低遅延に基づいて付加価値サービスを導入します。
- 遅延ベースのメトリックを使用して、パスごとの遅延(最小、最大、平均)を測定します。
- 遅延の影響を受けやすいサービス(VPN や 5G サービスなど)を超低遅延 SR 最適化パスに誘導します。
SR パスの遅延メトリックを使用した DCSPF ベースの計算の概要
セグメント ルーティング LSP 機能に分散型制限付き最短パス ファースト(CSPF)を使用すると、設定した制約に従って、イングレス デバイス上でセグメント ルーティング LSP をローカルに計算できます。この機能により、LSPは設定された制約とメトリックタイプ(トラフィック制御またはIGP)に基づいて最適化されます。LSP が計算され、セグメント ルーティング ラベル スタックの圧縮が有効または無効になっている宛先への利用可能な ECMP パスを使用します。
分散型CSFPを設定して、複数のヘッドエンドで実行し、各ヘッドエンドで独立してパス計算を行うことができます。ソース パス(ソース パケット ルーティング パス)にコンピューティング プロファイルを適用できます。遅延平均用に最適化されたコンピューティング プロファイルを設定している場合は、 と呼ばれる delay-variation-threshold制約を追加で適用することもできます。に値 delay-variation-thresholdを設定すると、しきい値を超えるリンクはパス計算から除外されます。
SR パスの DCSPF ベースの計算の遅延メトリックを設定するには、[edit protocols source-packet-routing compute-profile profile-name metric-type delay] 階層レベルで設定ステートメントを有効にするdelay必要があります。パス計算の最小、最大、平均、および遅延変動しきい値などの遅延メトリックを設定できます。
minimum- 累積遅延パス計算の TED からの最小遅延メトリック値。average- 累積最も遅延の少ないパス計算の TED からの平均遅延メトリック値。maximum- 累積最も遅延の少ないパス計算の TED からの最大遅延メトリック値。delay-variation-threshold-リンク遅延変動しきい値(1..16777215)。遅延変動しきい値を超えるリンクは、パス計算から除外されます。遅延変動のしきい値は、最小、最大、平均のいずれに対して最適化を行うかに依存しません。設定ステートメントは、delay-variation-threshold以下の階層レベルで表示されます。-
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay average]
-
以下の CLI 階層で遅延メトリックを設定できます。
[edit]
protocols {
source-packet-routing {
compute-profile <name> {
metric-type delay {
minimum;
maximum;
average;
delay-variation-threshold <value>;
}
}
}
}
ドメイン間およびドメイン内の遅延メトリックの使用事例の概要
ドメイン内のケース(パスが単一ドメイン内にある)では、パス計算を行う際にリンク遅延が考慮されます。セグメント ルーティング パス計算の遅延メトリックは、圧縮 SID と非圧縮 SID の両方でサポートされています。非圧縮 SID がある場合、コストが等しい場合、複数のセグメント リストを生成するためにセグメント リストの隣接関係セグメントが使用されます。[edit protocols source-packet-routing compute-profile profile-name] 階層レベルの設定ステートメントを使用して、no-label-stack-compression非圧縮 SID を設定できます。これにより、隣接関係 SID を使用して完全に拡張されたパスが提供されます。詳細については、「 compute-profile」 を参照してください。
遅延メトリックの設定例を以下に示します。
[edit protocols source-packet-routing]
user@host# show
compute-profile profile1 {
no-label-stack-compression;
metric-type {
delay {
minimum;
delay-variation-threshold 300;
}
}
}
光パスの計算では、遅延メトリックを最小限に抑えて使用することをお勧めします。最小はデフォルトの設定です。
複数の自律システムがあるドメイン間(マルチドメイン)の使用事例では、高速セグメントを使用してパス計算用のリンク遅延を設定できます。Express セグメントは、境界ノードまたは ASBR を接続するリンクです。Express セグメントの詳細については、 Express Segment LSP 設定を参照してください。遅延を設定したり、Express セグメントの基になる LSP の遅延を継承することができます。[edit protocols express-segments segment-template template-name metric] 階層レベルでを設定delayし、最小、最大、および平均遅延の値を設定できます。
以下の CLI 階層で、Express セグメントで遅延メトリックを設定できます。
[edit]
protocols {
express-segments {
segment-template <name> {
metric delay [ min <value> | avg <value> | max <value>
}
}
}
ドメイン間パス計算の場合、BGP EPEリンクに遅延メトリックを割り当てることができます。以下に示すように、[edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute]階層レベルで のdelay-metric値を設定できます。
[edit]
protocols {
bgp {
group <name> {
type external;
}
neighbor <ip_addr> {
egress-te-adj-segment <name> {
egress-te-link-attribute {
delay-metric <value>
}
}
}
}
}
光ネットワークの遅延メトリックの使用事例
以下のトポロジーは、光のユースケースの例を示しています。光保護および復旧ソリューションでは、基本的な物理属性(主にパス長)が発生し、リンク障害とそれに続く DWDM ネットワークの最適化によって変化します。
図では、A と C の間のリンクは光ノード O1 と O3 を経由し、遅延は 10 マイクロ秒です。図では、光ノード O1 と O3 の間のリンク障害と、実際の光接続が光ノード O2 を介して再ルーティングされていることがわかります。これにより、遅延が 15 マイクロ秒に増加します。AとBを接続するリンクのメトリックは、time=0とtime=1の間で動的に変更されます。
リンクごとの遅延の変化がイングレスによって検出されると、イングレスは遅延最適化パスの再計算をトリガーし、ヘッドエンドルーターは利用可能な次の最小レイテンシパス上でパスを再ルーティングします。リンク遅延が変更された場合、イングレスが遅延パスが最も少ない別のリンクセットを選択する可能性があります。図 B では、トポロジに示すように、パス A と C の間のリンクに変更があり、ヘッドエンド ルーターが再ルートし、パス A-B-C を選択していることがわかります。