セグメントルーティングLSPの設定
セグメントルーティングLSPに対する分散型CSPFの有効化
Junos OS リリース 19.2R1S1 以前では、セグメントルーティングパスのトラフィックエンジニアリングに、静的パスを明示的に設定するか、外部コントローラからの計算されたパスを使用することができました。セグメントルーティングLSPの分散型CSPF(制限付き最短パスファースト)機能を使用すると、設定した制約に従って、イングレスデバイス上でローカルにセグメントルーティングLSPを計算できます。この機能により、設定された制約条件とメトリックタイプ(トラフィックエンジニアリングまたはIGP)に基づいてLSPが最適化されます。LSPは、セグメントルーティングラベルスタック圧縮を有効または無効にした宛先への利用可能なECMPパスを利用するように計算されます。
- 分散 CSPF 計算の制約
- 分散型CSPF計算アルゴリズム
- 分散CSPF計算データベース
- 分散 CSPF 計算制約の設定
- 分散型CSPF計算
- 分散CSPF計算と SR-TE 機能の相互作用
- 分散 CSPF 計算の構成例
分散 CSPF 計算の制約
セグメント ルーティング LSP パスは、設定されたすべての制約が満たされた場合に計算されます。
分散型CSPF計算機能は、インターネットドラフト、draft-ietf-spring-segment-routing-policy-03.txt、 トラフィックエンジニアリングのセグメントルーティングポリシーで指定されている以下の制約のサブセットをサポートします。
-
管理グループの包含と除外。
-
ルーズまたはストリクト ホップの IP アドレスを含める。
注:緩いホップ制約または厳密なホップ制約では、ルーター ID のみを指定できます。ラベルおよびその他の IP アドレスは、Junos OS リリース 19.2R1-S1 でルーズ ホップ制約またはストリクト ホップ制約として指定できません。
-
セグメント リスト内のセグメント ID (SID) の最大数。
-
候補セグメント ルーティング パスあたりのセグメント リストの最大数。
セグメントルーティングLSP向けの分散型CSPF計算機能では、以下のタイプの制約や導入シナリオをサポートしていません。
-
IPV6 アドレス
-
ドメイン間セグメントルーティングトラフィック制御(SR-TE)LSP
-
番号なしインターフェイス。
-
OSPF、ISIS、BGP-LSなど、複数のプロトコルルーティングプロトコルを同時に有効化します。
-
プレフィックスまたはエニーキャストアドレスを宛先とする計算。
-
インターフェイス IP アドレスを制約に含める、または除外する。
分散型CSPF計算アルゴリズム
セグメントルーティングLSPの分散型CSPF計算機能では、CSPFでラベルスタック圧縮アルゴリズムを使用します。
ラベルスタック圧縮の有効化
圧縮されたラベルスタックは、送信元から送信先へのパスのセットを表します。通常は、ノード SID と隣接 SID で構成されます。ラベルスタックの圧縮が有効になっている場合、計算の結果は、制約に準拠しながら、スタック内のSIDの最小数で、宛先へのECMPを最大化する一連のパスになります。
ラベルスタック圧縮が無効
ラベルスタック圧縮を無効にしたマルチパスCSPF計算では、宛先へのセグメントリストが最大 N 検出されます。
-
すべてのセグメント リストのコストは、宛先に到達するための最短トラフィック エンジニアリング メトリックと同じであり、同じです。
-
各セグメント リストは、隣接 SID で構成されます。
-
値 N は、設定によって候補パスに許可されるセグメント リストの最大数です。
-
同一のセグメント リストは 2 つとありません。
-
各セグメント リストは、設定されたすべての制約を満たします。
分散CSPF計算データベース
SR-TE計算に使用されるデータベースには、アドバタイズノードでトラフィック制御が有効になっているかどうかに関係なく、すべてのリンク、ノード、プレフィックス、およびそれらの特性が含まれます。つまり、コンピューティングノードが学習したすべてのドメインのトラフィック制御データベース(TED)とIGPリンク状態データベースの和集合です。したがって、CSPF を機能させるには、[edit protocols isis traffic-engineering]階層レベルで igp-topology ステートメントを含める必要があります。
分散 CSPF 計算制約の設定
コンピューティング プロファイルを使用して、計算制約を論理的にグループ化できます。これらのコンピューティング プロファイルは、プライマリおよびセカンダリ セグメント ルーティング LSP を計算するためのセグメント ルーティング パスによって参照されます。
コンピューティング プロファイルを設定するには、[edit protocols source-packet-routing]階層レベルで compute-profile ステートメントを含めます。
サポートされている計算制約の構成は次のとおりです。
-
Administrative groups
[edit protocols mpls]階層レベルで管理者グループを設定できます。Junos OSは、管理グループ設定をセグメントルーティングトラフィック制御(SR-TE)インターフェイスに適用します。計算制約を設定するには、管理グループのセットに 3 つのカテゴリを指定します。計算制約の構成は、すべての候補セグメントルーティングパスに共通とすることも、個々の候補パスの下に設定することもできます。
-
include-any- リスト内の設定された管理グループの少なくとも 1 つを持つリンクが、パスの通過に許容されることを指定します。 -
include-all- リスト内のすべての設定済み管理グループを含むすべてのリンクが、パスの通過に許容されることを指定します。 -
exclude- リスト内に設定された管理グループがないリンクが、パスの通過に許容されることを指定します。
-
-
Explicit path
SR-TE候補パスを計算するための制約として、コンピューティング プロファイルで一連のルーター ID を指定できます。各ホップは IPv4 アドレスである必要があり、ストリクトまたはルーズのタイプにすることができます。ホップのタイプが設定されていない場合は、strictが使用されます。明示的なパス制約を指定する場合、segment-list ステートメントの下に
computeオプションを含める必要があります。 -
Maximum number of segment lists (ECMP paths)
候補パスは、多数の動的セグメントリストに関連付けることができます。パスは ECMP パスであり、各セグメント リストはアクティブな重みを持つネクスト ホップ ゲートウェイに変換されます。これらのパスは、圧縮の有無にかかわらずパス計算の結果です。
この属性は、compute-profile 設定ステートメントの下にある
maximum-computed-segment-lists maximum-computed-segment-listsオプションを使用して設定できます。この設定は、特定のプライマリおよびセカンダリLSPに対して計算されるそのようなセグメントリストの最大数を決定します。 -
Maximum segment list depth
最大セグメント リスト深度計算パラメータは、管理グループなどの他のすべての制約を満たす ECMP パスのうち、セグメント リストの最大深度以下のセグメント リストを持つパスのみが使用されるようにします。このパラメーターをコンピューティング プロファイルの制約として構成すると、
[edit protocols source-packet-routing]階層レベルのmaximum-segment-list-depth構成が上書きされます (存在する場合)。この属性は、compute-profile 設定ステートメントの下にある
maximum-segment-list-depth maximum-segment-list-depthオプションを使用して設定できます。 -
Protected or unprotected adjacency SIDs
コンピューティング プロファイルの下の制約として保護または非保護隣接 SID を構成して、指定した SID タイプとのリンクを回避できます。
-
Metric type
計算に使用するリンク上のメトリックのタイプを指定できます。デフォルトでは、SR-TE LSP は、計算にリンクのトラフィック制御メトリックを使用します。リンクのトラフィック制御メトリックは、IGPプロトコルのトラフィック制御拡張によってアドバタイズされます。ただし、コンピューティング プロファイルでメトリック タイプの設定を使用して、計算に IGP メトリックを使用することもできます。
この属性は、compute-profile 設定ステートメントの下にある
metric-type (igp | te)オプションを使用して設定できます。
分散型CSPF計算
SR-TE候補パスは、設定された制約を満たすようにローカルで計算されます。ラベルスタックの圧縮が無効になっている場合、マルチパスCSPFの計算結果は、隣接SIDスタックのセットになります。ラベル スタックの圧縮が有効になっている場合、結果は一連の圧縮されたラベル スタック (隣接する SID とノード SID で構成される) になります。
セカンダリパスが計算されるとき、プライマリパスによって取られるリンク、ノード、およびSRLGは計算のために回避されません。プライマリ パスとセカンダリ パスの詳細については、 プライマリおよびセカンダリ LSP の設定を参照してください。
計算結果に失敗した LSP については、TED(トラフィック制御データベース)の変更に伴い、計算が再試行されます。
分散CSPF計算と SR-TE 機能の相互作用
SR-TEポリシーのパスに関連付けられた重み
ルートのネクストホップに寄与する計算済みおよび静的 SR-TE パスに対して重みを設定できます。ただし、計算が有効になっている単一のパスは、複数のセグメント リストになる可能性があります。これらの計算されたセグメント リストは、それ自体が ECMP として扱われます。設定された各プライマリに割り当てられた重みを考慮して、これらのセグメントに階層ECMP重みを割り当てることができます。
BFDライブ性検出
計算されたプライマリまたはセカンダリ パスに対して BFD ライブ性検出を設定できます。計算されたすべてのプライマリまたはセカンダリ パスは、複数のセグメント リストになる可能性があり、その結果、セグメント リストに対して設定された BFD パラメータが、計算されたすべてのセグメント リストに適用されます。すべてのアクティブなプライマリパスがダウンすると、事前にプログラムされたセカンダリパス(提供されている場合)がアクティブになります。
inherit-label-nexthops
計算されたプライマリまたはセカンダリパスの[edit protocols source-packet-routing segment-list segment-list-name]階層下でのinherit-label-nexthops設定は、デフォルトの動作であるため、明示的に有効にする必要はありません。
自動翻訳機能
セグメントリストで自動翻訳機能を設定することができ、自動翻訳機能を持つプライマリパスまたはセカンダリパスはこれらのセグメントリストを参照します。一方、コンピューティング機能が有効になっているプライマリまたはセカンダリは、セグメント リストを参照できません。そのため、特定のプライマリパスまたはセカンダリパスに対して、コンピューティング機能と自動翻訳機能の両方を有効にすることはできません。ただし、コンピューティングタイプのプライマリパスと自動翻訳タイプのプライマリパスでLSPを設定することは可能です。
分散 CSPF 計算の構成例
例1
実施例1において、
-
非計算プライマリパスは、設定されたセグメントリストを参照しています。この例では、設定されたセグメントリスト static_sl1 が参照され、このプライマリパスの名前としても機能します。
-
計算されたプライマリには名前が設定されている必要があり、この名前は設定されたセグメントリストを参照しないでください。この例では、 compute_segment1 は設定されたセグメントリストではありません。
-
compute_profile_redコンピューティング プロファイルは、名前が compute_segment1 のプライマリ パスに適用されます。
-
compute_profile_redコンピューティング プロファイルには、計算の明示的なパス制約を指定するために使用されるタイプ
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が外部コントローラによって作成され、パス計算要素プロトコル(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のイングレスルートは、 inetcolor.0 または inet6color.0 ルーティングテーブルにインストールされ、 destination-ip-address, color をマッピングIPトラフィックのキーとします。
静的なカラー付きセグメントルーティングLSPは、バインディングSIDを持つことができ、そのバインディングSIDは、 mpls.0 ルーティングテーブルにルートがインストールされます。このバインディングSIDラベルは、ラベル付けされたトラフィックをセグメントルーティングLSPにマッピングするために使用されます。ルートのゲートウェイは、プライマリパスとセカンダリパスの下のセグメントリスト設定から導き出されます。
色付きセグメントルーティングLSPのセグメントリスト
色付き静的セグメントルーティングLSPは、LSPを解決するファーストホップラベルモードをすでにサポートしています。ただし、ファーストホップIPモードは、色付きセグメントルーティングLSPには対応していません。Junos OS リリース 19.1R1 以降、コミットチェック機能が導入され、色付きルートに寄与するすべてのセグメントリストに、すべてのホップの最小ラベルが存在することを確認します。この要件が満たされない場合、コミットはブロックされます。
ノンカラースタティックセグメントルーティングLSP
color ステートメントなしで設定された静的セグメントルーティングLSPは、カラーなしLSPです。PCEPセグメントルーティングトンネルと同様に、イングレスルートは inet.3 または inet6.3 ルーティングテーブルにインストールされます。
Junos OS は、イングレスルーターで非カラーリング静的セグメントルーティング LSP をサポートします。1 つのソース ルーティング パスと 1 つ以上のセグメント リストを設定することで、色なしスタティック セグメント ルーティング LSP をプロビジョニングできます。これらのセグメントリストは、複数の非カラーセグメントルーティングLSPで使用できます。
非カラーリングセグメントルーティングLSPについて
色なしセグメントルーティングLSPには、固有の名称と宛先IPアドレスがあります。宛先へのイングレスルートが、inet.3ルーティングテーブルにインストールされ、デフォルトプリファレンスは8、メトリックは1となります。このルートでは、宛先に関連するセグメント ルーティング LSP に色付けされていないサービスをマッピングできます。色なしセグメントルーティングLSPがイングレスルートを必要としない場合、イングレスルートを無効にすることができます。色なしセグメントルーティングLSPは、バインディングSIDラベルを使用してセグメントルーティングLSPステッチを実現します。セグメントルーティングLSPを、他のセグメントルーティングLSPを階層的に構築するためにさらに使用することができるセグメントとしてモデル化するために使用できるこのラベル。バインディングSIDラベルのトランジットは、デフォルトでは、プリファレンスは8、メトリックは1です。
Junos OS Release 18.2R1以降、イングレスデバイス上で静的に設定された色なしセグメントルーティングLSPは、パス計算要素プロトコル(PCEP)セッションを通じてパス計算要素(PCE)に報告されます。これらの色付けされていないセグメントルーティングLSPには、バインディングサービス識別子(SID)ラベルが関連付けられている場合があります。この機能により、PCE はラベルスタック内のこのバインディング SID ラベルを使用して、PCE によって開始されるセグメントルーティング LSP パスをプロビジョニングできます。
カラーリングされていないセグメントルーティングLSPは、最大8つのプライマリパスを持つことができます。複数の運用プライマリパスがある場合、パケット転送エンジン(PFE)は、パスに設定された重みなどのロードバランシング係数に基づいて、パス全体にトラフィックを分散します。これは、どのパスにも重みが設定されていない場合は等コストマルチパス(ECMP)、少なくとも1つのパスにゼロ以外の重みが設定されている場合は重み付けECMP(等コストマルチパス)です。いずれの場合も、1 つまたは一部のパスに障害が発生すると、PFE は残りのパス上でトラフィックのバランスを再調整し、自動的にパス保護の達成につながります。色なしセグメント ルーティング LSP は、専用パス保護用のセカンダリ パスを持つことができます。プライマリパスに障害が発生すると、PFE は残りの機能しているプライマリパスにトラフィックのバランスを取り直します。それ以外の場合、PFE はトラフィックをバックアップ パスに切り替え、パス保護を実現します。色なしセグメントルーティングLSPは、そのイングレスおよびバインディングSIDルートの [edit protocols source-packet-routing source-routing-path lsp-name] 時のメトリックを指定できます。複数の非カラーリングセグメントルーティングLSPは、イングレスルートのネクストホップに寄与する同じ宛先アドレスを持っています。
複数の非カラーリングセグメントルーティングLSPは、イングレスルートのネクストホップに寄与する同じ宛先アドレスを持っています。各セグメントルーティングLSPのプライマリまたはセカンダリの各パスは、パスが機能しており、セグメントルーティングLSPがこれらすべてのセグメントルーティングLSPの中で最良の優先度を持っている場合、ゲートウェイ候補と見なされます。ただし、ネクストホップが保持できるゲートウェイの最大数は、RPD マルチパスの制限(デフォルトでは 128)を超えることはできません。余分なパスは、最初にセカンダリパス、次にプライマリパスで除外されます。特定のセグメント リストは、これらのセグメント ルーティング LSP によってプライマリ パスまたはセカンダリ パスとして複数回参照される場合があります。この場合、複数のゲートウェイがあり、それぞれに固有のセグメントルーティングLSPトンネルIDがあります。これらのゲートウェイは、発信ラベルスタックとインターフェイスが同じですが、異なります。また、色なしセグメントルーティングLSPと色付きセグメントルーティングLSPは、同じ宛先アドレスを持つことができます。ただし、色付きセグメントルーティングLSPの宛先アドレスは、宛先アドレスとカラーの両方で構築されるため、入力ルートでは異なる宛先アドレスに対応します。
静的な非カラーセグメントルーティングLSPとPCEPで作成されたセグメントルーティングLSPが共存し、同じイングレスルートに寄与する同じ宛先アドレスを持つ場合、それらも同じプリファレンスを持っている場合。そうでない場合は、最も優先度の高いセグメントルーティングLSPがルートにインストールされます。
非カラーセグメントルーティングLSPのセグメントリスト
セグメント リストは、ホップのリストで構成されます。これらのホップは、SID ラベルまたは IP アドレスに基づいています。セグメントリスト内のSIDラベルの数は、セグメントリストの最大制限を超えてはなりません。LSP トンネルへの最大セグメントリスト バインディングが 8 から 128 に増加し、システムあたり最大 1000 トンネルになります。スタティックセグメントルーティングLSPごとに最大128のプライマリパスがサポートされています。セグメント リストの最大制限は、 [edit protocols source-packet-routing] 階層レベルで設定できます。
Junos OS リリース 19.1R1 以前では、色付けされていない静的セグメントルーティング LSP を使用できるためには、セグメントリストの最初のホップは発信インターフェイスの IP アドレスで、2 番目から n番目のホップは SID ラベルである必要がありました。Junos OS Release 19.1R1以降は、カラーリングされていない静的LSPの最初のホップが、IPアドレスに加えてSIDラベルもサポートするようになったため、この要件は適用されません。ファーストホップラベルのサポートにより、MPLS高速リルート(FRR)と重み付き等価コストマルチパスが有効になり、色付きスタティックLSPと同様に、静的な非カラー付きセグメントルーティングLSPを解決できます。
ファーストホップラベルモードを有効にするには、セグメントリストにグローバルに、または個別に inherit-label-nexthops ステートメントを含め、セグメントリストの最初のホップにIPアドレスとラベルの両方を含める必要があります。最初のホップにIPアドレスのみが含まれている場合、 inherit-label-nexthops ステートメントは無効です。
次のいずれかの階層で inherit-label-nexthops を設定できます。inherit-label-nexthops ステートメントは、セグメント リストの最初のホップに IP アドレスとラベルの両方が含まれている場合にのみ有効になります。
-
Segment list level-
[edit protocols source-packet-routing segment-list segment-list-name]階層レベル。 -
Globally-
[edit protocols source-packet-routing]階層レベル。
inherit-label-nexthops ステートメントがグローバルに設定されている場合、セグメントリストレベルの設定よりも優先され、inherit-label-nexthops設定がすべてのセグメントリストに適用されます。inherit-label-nexthops ステートメントがグローバルに設定されていない場合、最初のホップにラベルと IP アドレスの両方が存在し、inherit-label-nexthops ステートメントで設定されたセグメントリストのみが SID ラベルを使用して解決されます。
動的非カラー静的LSP、つまりPCEPドリブンセグメントルーティング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; } }トンネル lsp1 のコミットは、パス 1 が IP アドレス モードで、パス 2 がラベル モードであるため失敗します。
-
バインディング 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またはノードSIDのセグメントルーティンググローバルブロック(SRGB)からのものです。隣接 SID ラベルは、動的に割り当てることも(デフォルトの動作)、ローカル静的ラベルプール(SRLB)から割り当てることもできます。次に、SID ラベルのルートが mpls.0 テーブルにインストールされます。
Junos OS では、[edit protocols mpls static-label-switched-path static-label-switched-path] 階層レベルで segment ステートメントを設定することにより、スタティックセグメントルーティングLSPを可能にします。静的セグメントLSPは、Junos OS静的ラベルプールに該当する一意のSIDラベルによって識別されます。Junos OSの静的ラベルプールを設定するには、[edit protocols mpls label-range]階層レベルでstatic-label-range static-label-rangeステートメントを設定します。
静的セグメントルーティングLSPの制限
-
現在の Junos OS には、セグメント リストの最大深度ラベルを超えてプッシュするようにネクスト ホップを構築できないという制限があります。そのため、最大SIDラベル(転送ネクストホップの解決に使用される最初のホップのSIDラベルを除く)を超えるセグメントリストは、色付きまたは非色付きのセグメントルーティングLSPには使用できません。また、MPLS サービスがセグメント ルーティング LSP 上にある場合、またはセグメント ルーティング LSP がリンクまたはノード保護パス上にある場合は、特定のセグメント ルーティング LSP に許可される実際の数が、上限よりもさらに少なくなることがあります。いずれの場合も、サービス ラベル、SID ラベル、リンクまたはノード保護ラベルの合計数が、セグメント リストの最大深度を超えてはなりません。階層レベルでセグメント リストの最大制限を設定できます
[edit protocols source-packet-routing]。最大SIDラベル以下の複数の非カラーセグメントルーティングLSPをつなぎ合わせて、より長いセグメントルーティングLSPを構築することができます。これはセグメントルーティングLSPスティッチングと呼ばれます。これは、バインディングSIDラベルを使用して実現できます。 -
セグメントルーティングLSPスティッチングは、実際にはパスレベルで実行されます。色なしセグメントルーティングLSPに複数のセグメントリストという複数のパスがある場合、各パスは、ステッチングポイントで別の色付きなしセグメントルーティングLSPに独立してステッチングできます。ステッチ専用の色なしセグメントルーティングLSPは、階層レベルで ステートメントを設定することにより
no-ingressイングレスルートのインストール[edit protocols source-packet-routing source-routing-path lsp-name]無効にすることができます。 -
カラーリングされていない静的セグメントルーティングLSPごとに、最大128のプライマリパスと1つのセカンダリパスがサポートされています。設定に違反がある場合、コミットチェックは失敗し、エラーになります。
-
LSP トンネルへの最大セグメントリスト バインディングが 8 から 128 に増加し、システムあたり最大 1000 トンネルになります。スタティックセグメントルーティングLSPごとに最大128のプライマリパスがサポートされています。制限として、LSP パスの最大センサー サポートは 32000 のみです。
-
いずれかのセグメントリストに、セグメントリストの最大深さよりも多くのラベルが設定されている場合、設定コミットチェックは失敗し、エラーが発生します。
セグメントルーティングLSPの動的作成
各PE(プロバイダ エッジ)デバイスが他のすべての PE デバイスに接続されているセグメント ルーティング ネットワークでは、少数のセグメント ルーティング トラフィックエンジニアリング(SR-TE)パスしか使用できませんが、セグメント ルーティングの LSP(ラベルスイッチ パス)の設定に大量の設定が必要になります。これらのLSPのBGPトリガーによる動的作成を有効にして、このような導入における設定の量を減らすことができます。
- 動的セグメントルーティングLSPテンプレートの設定
- 動的セグメントルーティングLSPの解決
- セグメントルーティングLSPの動的作成の設定に関する考慮事項
- 動的セグメントルーティングLSPでサポートされるサービス
- セグメントルーティングにおける複数のトンネルソースの動作
- 動的セグメントルーティングLSPの制限
動的セグメントルーティングLSPテンプレートの設定
セグメントルーティングLSPの動的作成を可能にするテンプレートを設定するには、[edit routing-options dynamic-tunnels]階層にspring-teステートメントを含める必要があります。
-
以下は、カラーダイナミックセグメントルーティング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 プレフィックスにカラーコミュニティが割り当てられると、最初にキャッチオールルートフォーザット特定のカラーポリシーで解決され、次に 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 [101 124];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
BGPサービスPNHが10.22.44.0/24で、カラーコミュニティが123/124/125の場合、SR-TEテンプレートsr_lsp1を使用してトンネルを作成します。同じPNHプレフィックスの他の色はsr_lsp2 color-any 構成によりテンプレートを使用します。
上記の構成例では、ルート エントリは次のようになります。
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
inet6color.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 トンネル名 = 10.22.44.55:65:dt-srte-tunnel1
R1(プレフィックス) -> ffff::10.22.44.55-101(PNH) LSP トンネル名 = 10.22.44.55:65:dt-srte-tunnel1
R1(プレフィックス) -> ffff::10.22.44.55-124(PNH) LSP トンネル名 = 10.22.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <ネクストホップ>
10.22.44.55-124/64 --> <ネクストホップ>
-
inet6color.0 tunnel route:
ffff::10.22.44.55-101/160 --> <ネクストホップ>
ffff::10.22.44.55-124/160 --> <ネクストホップ>
カラー101トンネル(10.22.44.55:65:dt-srte-tunnel1)は、 color-any 設定により作成されます。
inet6color.0 の IPv6 ルートは、 mpls ipv6-tunneling 設定によるものです。inetcolor.0ルーティングテーブルに格納されているSR-TEルートをIPv4にマッピングされたIPv6アドレスに変換し、それをinet6color.0ルーティングテーブルにコピーすることで、カラーコミュニティを持つIPv6ルートをinet6color.0テーブル上で解決することができます。
非カラーダイナミックセグメントルーティング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(プレフィックス) -> ffff::10.33.44.55(PNH) LSP テンプレート名 = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <ネクストホップ>
-
inet6.3 tunnel route: ffff::10.33.44.55/128 --> <ネクストホップ>
色なしトンネル(10.33.44.55:dt-srte-tunnel2)は、色が設定されていないため、動的トンネルトンネル2を使用して作成されます。inet6.3 の IPv6 ルートは、 mpls ipv6-tunneling 設定によるものです。inet.3ルーティングテーブルに保存されているSR-TEルートをIPv4にマッピングされたIPv6アドレスに変換し、inet6.3ルーティングテーブルにコピーすることで、IPv6ルートをMPLSネットワーク上で解決することができます。
未解決の動的セグメントルーティング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
-
inet6color.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(プレフィックス)-> 10.33.44.55-124(PNH) トンネル is は 作成されません。(色のテンプレートが見つかりません)。
セグメントルーティングLSPの動的作成の設定に関する考慮事項
セグメントルーティングLSPの動的作成を設定する場合、以下の点を考慮してください。
-
テンプレートは、カラーオブジェクトで割り当てることができます。動的トンネル
spring-te設定にカラーオブジェクトを持つテンプレートが含まれている場合、他のすべてのテンプレートにもカラーオブジェクトを設定する必要があります。すべての宛先は、その設定内で色付けされていると見なされます。 -
テンプレートには、色のリストを定義することも、
color-anyオプションで構成することもできます。これらのオプションは両方とも、同じspring-te構成に共存できます。このような場合、特定の色で割り当てられたテンプレートの方が優先度が高くなります。 -
spring-te設定では、color-anyオプションで定義できるテンプレートは 1 つだけです。 -
色からテンプレートへのマッピングは、1 対 1 で行われます。1 つの色を複数のテンプレートにマップすることはできません。
-
テンプレート名は、
[edit protocols]階層の下のspring-teステートメントで設定し、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サービスのカラーベースマッピング
静的なカラー付きおよびBGPセグメントルーティングトラフィックエンジニアリング(SR-TE)LSP上のトランスポートトンネルを解決するために、(IPv4またはIPv6アドレスに加えて)プロトコルネクストホップ制約として色を指定することができます。これは color-IP プロトコル ネクスト ホップ解決と呼ばれ、解決マップを構成して VPN サービスに適用する必要があります。この機能により、レイヤー2およびレイヤー3VPNサービスのカラーベースのトラフィックステアリングを有効にすることができます。
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 サービスの色付けを行います。このモードを有効にするには、ルーティング ポリシーを定義し、[edit protocols bgp]階層レベルで VPN サービスのルーティング インスタンス vrf-export、グループ エクスポート、またはグループ ネイバー エクスポートで適用します。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 NLRI に反映されるようにするには、BGP、BGP グループ、または BGP ネイバー レベルで vpn-apply-export ステートメントを含める必要があります。
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
ルーティング ポリシーは、レイヤー 3 VPN プレフィックス NLRI、レイヤー 2 VPN NRLI、EVPN NLRI に適用されます。カラー拡張コミュニティは、すべての VPN ルートに継承され、インポートされ、1 つまたは複数のイングレス デバイスのターゲット VRF にインストールされます。
イングレスカラーの割り当て
このモードでは、イングレス デバイス(つまり、VPN NLRI の受信者)が VPN サービスの色付けを行います。このモードを有効にするには、ルーティングポリシーを定義し、[edit protocols bgp]階層レベルでVPNサービスのルーティングインスタンスvrf-import、グループインポート、またはグループネイバーインポートに適用します。ルーティングポリシーに一致するすべての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 ステートメントを使用してポリシーを定義し、[edit protocols bgp]階層レベルで VPN サービスのルーティング インスタンス vrf-import、グループ インポート、またはグループ ネイバー インポートでポリシーを参照する必要があります。ルーティング ポリシーに一致するすべての VPN ルートが、指定された解決マップにアタッチされます。
たとえば、以下のように表示されます。
[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 カラーのエントリは 1 つだけサポートされ、VPN ルートは ip-address:color 形式のカラー付き IP プロトコル ネクストホップを使用して解決されます。
カラー IP プロトコル ネクストホップ解決
プロトコルネクストホップ解決プロセスが拡張され、カラー付きIPプロトコルネクストホップ解決がサポートされるようになりました。カラー付きVPNサービスの場合、プロトコルネクストホップ解決プロセスは、カラーと解像度マップを受け取り、 IP-address:color形式でカラー付きIPプロトコルネクストホップを構築し、inet6color.0ルーティングテーブルでプロトコルネクストホップを解決します。
カラー付きLSP上で、カラー付きレイヤー2VPN、レイヤー3VPN、または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 サービスに解像度マップが適用されていない場合、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 の定義をサポートしています。色付きプロトコルネクストホップが作成され、 inetcolor.0 テーブルまたは inet6color.0 テーブルの色付きSR-TEトンネルで解決されます。BGPは、非カラーベースのマッピングに inet.3 テーブルと inet6.3 テーブルを使用します。これにより、ルーターにIPv4アドレスが設定されていないIPv6専用ネットワークにおいて、BGP-LU IPv6およびIPv4プレフィックスをIPv6ネクストホップアドレスでアドバタイズすることができます。この機能により、現在、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 は、以下のシナリオをサポートします。
-
SIS/OSPF IPv4 SR 拡張を備えた、色付きの BGP IPv4 SR-TE 上の BGP IPv4 LU。
-
静的なカラー付きおよび非カラー付きIPv4 SR-TEを介したBGP IPv4 LU、ISIS/OSPF IPv4 SR拡張付き。
-
ISIS IPv6 SR 拡張を使用した、色付きの BGP IPv6 SR-TE 上の BGP IPv6 LU。
-
静的なカラー付きおよび非カラー付きIPv6 SR-TEを介したBGP IPv6 LU、ISIS IPv6 SR拡張付き。
-
IPv6ローカルアドレスとIPv6ネイバーアドレスを使用したIPv6レイヤー3VPNサービス。
-
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 レイヤー 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
-
解像度マップを使用したIPv4およびIPv6。
PCE開始セグメントルーティングLSPのトンネルテンプレート
PCE開始セグメントルーティングLSPのトンネルテンプレートを設定して、これらのLSPの2つの追加パラメータ(双方向転送検出(BFD)とLDPトンネリング)を渡すことができます。
PCE開始セグメントルーティングLSPが作成されると、LSPがポリシーステートメント(存在する場合)と照合され、一致するものがあれば、ポリシーはそのLSPに設定されたテンプレートを適用します。テンプレートの設定は、LSP ソース(PCEP)によって提供されていない場合にのみ継承されます。たとえば、メトリックです。
テンプレートを設定するには:
-
[edit protocols source-packet-routing]階層レベルにsource-routing-path-templateステートメントを含めます。追加の BFD および LDP トンネリング パラメータは、ここで設定できます。 -
PCE開始LSPをチェックするポリシーステートメントをリストするには、
[edit protocols source-packet-routing]階層レベルにsource-routing-path-template-mapステートメントを含めます。 -
テンプレートが適用される LSP をリストするポリシーを定義します。
fromステートメントには、lspおよびlsp-regex一致条件を使用した LSP 名または LSP 正規表現のいずれかを含めることができます。これらのオプションは相互に排他的であるため、特定の時点で指定できるオプションは 1 つだけです。thenステートメントには、accept アクションを持つsr-te-templateオプションを含める必要があります。これにより、PCE開始LSPにテンプレートが適用されます。
PCE開始LSPのテンプレートを設定する際には,以下の点を考慮してください。
-
テンプレート設定は、静的に設定されたセグメントルーティングLSP、または他のクライアントのセグメントルーティングLSPには適用されません。
-
PCEP で提供される設定は、テンプレートの設定よりも優先されます。
-
PCEP LSPはテンプレートセグメントリストの設定を継承しません。
例：スタティックセグメントルーティングラベルスイッチパスの設定
この例は、MPLS ネットワークでスタティック セグメント ルーティング ラベル スイッチド パス(LSP)を設定する方法を示しています。この設定は、MPLS ネットワークのスケーラビリティの向上に役立ちます。
要件
この例では、以下のハードウェアとソフトウェアのコンポーネントを使用しています。
-
7つのMXシリーズ5Gユニバーサルルーティングプラットフォーム
-
すべてのルーターで Junos OS Release 18.1 またはそれ以降のものが作動
開始する前に、必ずデバイスインターフェイスを設定してください。
概要
Junos OS 明示的なセグメントルーティングパスのセットは、[edit protocols source-packet-routing]階層レベルで segment-list ステートメントを設定することにより、色なし静的セグメントルーティングトンネルのイングレスルーターで設定されます。階層レベルで source-routing-path ステートメントを設定することで [edit protocols source-packet-routing] セグメントルーティングトンネルを設定できます。セグメントルーティングトンネルには、宛先アドレスと、セグメントリストを参照する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
-
ルーティングインスタンスVRF1に、インスタンスタイプ、インターフェイス、ルーター識別、VRFインポート、エクスポート、テーブルラベルを設定します。プロトコル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-options、show interfaces 、show policy-optionsおよびshow protocolsと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 interfaces および show protocols コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
[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 つのネクストホップが利用可能であれば、カーネルは S-BFD パケットを送信し続けます(基盤となるネクストホップ到達可能性障害検出は、S-BFD 検出タイマーの期間よりも速くなければなりません)。
このモデルは、自動翻訳から派生したLSPでサポートされています。
LSPレベルのS-BFD
S-BFDセッションは、一意のラベルスタック+アドレスファミリーの組み合わせごとに作成されます。同一のセグメントリストを設定し、それらすべてに対してS-BFDを有効にすることができます。同一のラベルスタック+アドレスファミリーの組み合わせを持つセグメントリストは、同じS-BFDセッションを共有します。S-BFDセッションの送信元アドレスは、メインインスタンスで最小設定されたループバックアドレス(特殊アドレスを除く)に設定されます。
選択した送信元アドレスがルーティング可能であることを確認します。
LSP のアドレスファミリーは、セグメントルーティング TE トンネルの「宛先」アドレスのアドレスファミリーに基づいて導き出されます。S-BFD が設定された LSP の状態は、BFD が稼働しているかどうかによっても異なります。LSP に S-BFD が設定されている場合、S-BFD がパスが有効なことを報告するまで LSP ルートは計算されません。
S-BFDパラメータ
以下のS-BFDパラメータは、セグメントルーティングTEパスでサポートされています。
-
リモート識別器
-
最小間隔
-
乗数
-
ルーターアラートオプションなし
S-BFDでは、各レスポンダが複数の識別器を持つ場合があります。識別器は、IGPによって他のルーターにアドバタイズされることも、これらのルーター上で静的に設定されることもあります。イニシエーターでは、特定の識別器が、ユーザーまたは中央コントローラーが行った決定または解決に基づいて、静的構成によってS-BFDセッションのリモート識別器として選択されます。同じ鍵ラベルスタックで複数のLSPが作成され、それぞれで異なるパラメータでS-BFDが有効になっている場合、共有S-BFDセッションでは各パラメータのアグレッシブ値が使用されます。識別子パラメーターの場合、最小値が最も積極的であると見なされます。同様に、ルータ アラート オプションの場合、ルータ アラートが設定されていない設定の 1 つがある場合、派生 S-BFD パラメータにはルータ アラート オプションがありません。
限界
-
グローバル修復のみがサポートされています。
-
S-BFDは設定したタイマー値によっては障害を検出しますが、コンバージェンス時間はグローバルリペア時間(seconds)に依存します。
SBFDセッションにおけるリモート識別器(RD)の自動導出
Junos OS Release 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ポリシーのリモート識別子をトンネルエンドポイントから自動的に導き出します。
-
RD の自動派生は IPv4 エンドポイントに対してのみサポートされ、IPv6 エンドポイントに対してはサポートされていません。
-
カラーのみのトンネルに対するRDの自動導出はサポートされていません。静的に設定されたSR-TEカラーのみのトンネルにRDが(RDの自動導出によって)設定されていない場合、システムはコミットエラーを表示します。SR-TE テンプレート設定を使用して、動的カラーのみのトンネルに RD が(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 セッションは保持されますが、S-BFD パラメータが再評価され、 既存の LSP セッションの中から)アグレッシブなパラメータ値が選択されます。また、変更があった場合は、S-BFD セッションの名前が少なくとも 1 つに更新されます。古い S-BFD セッションにこれ以上 LSP が接続されていない場合、その S-BFD セッションは削除されます。
ソフトウェアは、新しいラベルスタック+アドレスファミリーの組み合わせ値に一致する既存のBFDセッションを見つけようとします。そのような一致が存在する場合、LSP はその既存の S-BFD セッションを参照します。S-BFDセッションは、ステップ1の再評価と同様に、パラメータまたはセッション名の変更について再評価されます。
一致する BFD セッションがシステム内に存在しない場合、新しい BFD セッションが作成され、この LSP から S-BFD パラメータが導出されます。
注: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 コマンドを使用して、静的セグメントルーティングトンネルの LSP を S-BFD セッションステータスとともに表示します。
アクション
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セッションの状態に影響を与えることなく、セッションの名前をaddress-family+least-lsp-nameに変更することができます。S-BFDセッションの名前は、 show bfd session extensive コマンドからの出力にも表示されます。各LSPの出力には、S-BFDステータスとそれが参照しているS-BFD名が表示されます(前の例で示すとおり BFD status: Up BFD name: V4-sl2。1つのLSPにつき1つのS-BFDセッションが存在しない場合があるため、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 デタッチの場合、メンバーリンクがアップで無効な転送状態になると、子物理インターフェイスがデタッチされると PFE で OAM パケットがドロップされます。
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-など)には必須で、if-nameはP2Pインターフェイス(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
ルートラベルラベル名拡張を表示
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)に不可欠です。遅延ベースのメトリックを使用して、パケットを最小遅延パスまたは最小遅延パスに誘導できます。そのためには、すべてのリンクで遅延を測定し、適切なルーティングプロトコル(IGPまたはBGP-LS)を使用してそれをアドバタイズし、イングレスのTEDにリンクごとの遅延プロパティが含まれるようにする必要があります。
各リンクで遅延をアドバタイズする方法、またはリンク測定をオンにする方法については、「 ISIS でリンク遅延測定とアドバタイズを有効にする方法」を参照してください。
ネットワークの変化の検出を測定、アドバタイズ、および計算し、最短の遅延でトラフィックエンジニアリングパスを計算すると、次の一連のイベントが発生します。
- ルーター間の合成プローブを使用して遅延を測定し、ネットワークの変化を検出します。
- IGP拡張TEメトリック拡張を介して、結果をイングレスノードにフラッディングします。
- 対応するBGP-LS拡張を使用して、集中コントローラーに結果をアドバタイズします。
- IGP ベースの最短累積レイテンシメトリックパス (Flex-algo) を計算します。
- SR-TE(累積レイテンシまたは遅延メトリック)を最短にして、トラフィック制御された明示的パス(送信元から送信先)を計算します。
パス計算における遅延ベースのメトリックの利点
- ネットワーク全体で最小の遅延に基づいて付加価値サービスを展開します。
- 遅延ベースのメトリックを使用して、パスあたりのレイテンシー(最小、最大、平均)を測定します。
- 遅延の影響を受けやすいサービス(VPNや5Gサービスなど)を、超低遅延のSR最適化パスで誘導します。
SRパスの遅延メトリックを使用したDCSPFベースの計算の概要
セグメントルーティングLSPの分散型CSPF(制限付き最短パスファースト)機能を使用すると、設定した制約に従って、イングレスデバイス上でローカルにセグメントルーティングLSPを計算できます。この機能により、設定された制約条件とメトリックタイプ(トラフィックエンジニアリングまたはIGP)に基づいてLSPが最適化されます。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 がある場合、セグメント リストの隣接セグメントを使用して、コストが等しい場合は複数のセグメント リストが生成されます。非圧縮 SID は、[edit protocols source-packet-routing compute-profile profile-name] 階層レベルで no-label-stack-compression 構成ステートメントを使用して構成できます。これにより、隣接 SID を使用して完全に拡張されたパスが提供されます。詳細については、「 コンピューティング プロファイル 」を参照してください。
遅延メトリックの構成例を次に示します。
[edit protocols source-packet-routing]
user@host# show
compute-profile profile1 {
no-label-stack-compression;
metric-type {
delay {
minimum;
delay-variation-threshold 300;
}
}
}
光パスの計算では、最低限遅延メトリックを使用することをお勧めします。[最小] が既定の構成です。
複数の自律システムが存在するドメイン間(マルチドメイン)のユースケースでは、エクスプレスセグメントを使用して、パス計算のためのリンク遅延を設定できます。エクスプレスセグメントは、ボーダーノードまたはASBRを接続するリンクです。エクスプレスセグメントについては、 エクスプレスセグメント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 を再ルーティングして選択することがわかります。
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。