Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

セグメントルーティングLSP設定

セグメントルーティングLSPの分散型CSPFの有効化

セグメントルーティングLSPの分散型CSPF(Constrained Shortest Path First)機能を使用すると、設定した制約に従って、ingressデバイス上でローカルにセグメントルーティングLSPを計算できます。この機能により、設定された制約とメトリックタイプ(トラフィックエンジニアリングまたはIGP)に基づいてLSPが最適化されます。LSP は、セグメント ルーティング ラベル スタック圧縮が有効または無効になっている状態で、宛先への利用可能な ECMP パスを利用するように計算されます。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォームに関連する注意事項については、「 プラットフォーム固有のセグメントルーティングLSP動作 」セクションを参照してください。

分散 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、IS-IS、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—リスト内に設定された管理グループを持たないリンクが、通過するパスとして許容されることを指定します。

    注:管理グループは、次のいずれかの場合にのみアドバタイズされます。
    • インターフェイスでRSVPを有効にします。

    • RSVPを有効にしない場合は、 edit protocols isis traffic-engineering advertisement always を設定します。

  • 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パスと静的SR-パスに対して重みを設定することができます。ただし、計算が有効な1つのパスでは、複数のセグメントリストになる可能性があります。これらの計算されたセグメントリストは、相互にECMPとして扱われます。これらのセグメントには、設定された各プライマリに割り当てられた重みを考慮して、階層的なECMPの重みを割り当てることができます。

BFDライブ性検出

計算されたプライマリまたはセカンダリパスに対してBFDライブ性検出を設定できます。計算されるすべてのプライマリまたはセカンダリパスは、複数のセグメントリストになる可能性があり、その結果、セグメントリストに対して設定されたBFDパラメータが計算されたすべてのセグメントリストに適用されます。すべてのアクティブなプライマリパスがダウンすると、事前にプログラムされたセカンダリパス(提供されている場合)がアクティブになります。

継承ラベルネクストホップ

計算されたプライマリパスまたはセカンダリパスに対して[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のセグメントリストが含まれています。

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

ネクストホップ

重量

comp_nh1

2

comp_nh2

2

comp_nh3

2

static_nh

9

例2

例 2 では、プライマリ パスとセカンダリ パスの両方をコンピューティング タイプにすることができ、独自のコンピューティング プロファイルを持つことができます。

例3

例 3 では、プライマリ パスまたはセカンダリ パスの下にコンピューティングが記載されている場合、計算の制約やその他のパラメーターなしに、宛先までのパスがローカルで計算されます。

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

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

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

送信元パケットルーティングまたはセグメントルーティングとは、コアネットワーク内のingressデバイスが、ネットワーク内の中間ノードに頼らずに、実際のパスを決定することなく、ネットワーク内の特定のノードやリンクを経由してトラフィックを誘導できるようにするコントロールプレーンアーキテクチャのことです。セグメントリストを使用してこれらのパスを設定し、受信トラフィックがたどるべきパスを定義できます。受信トラフィックはラベル付きトラフィックまたはIPトラフィックである可能性があり、イングレスデバイスでの転送操作はラベル交換または宛先ベースのルックアップのいずれかになります。

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

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

セグメントルーティングLSPは、本質的に動的または静的のいずれかです。

Dynamic segment routing LSPs—セグメントルーティングLSPが外部コントローラによって作成され、PCEP(Path Computation Element Protocol)拡張を介してイングレスデバイスにダウンロードされるか、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]階層レベルでのcolorステートメントの設定に基づいて、さらに色付きLSPと非色付きLSPに分類できます。

次に例を示します。

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

ここでは、各プライマリステートメントとセカンダリステートメントがセグメントリストを参照しています。

[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 ルーティングテーブルにインストールされ、IPトラフィックをマッピングするためのキーとして destination-ip-address, color されます。

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

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

色付きの静的セグメントルーティングLSPは、LSPを解決するファーストホップラベルモードのサポートをすでに提供しています。ただし、ファーストホップIPモードは、カラー付きセグメントルーティングLSPではサポートされていません。コミットチェック機能が導入され、色付きルートに寄与するすべてのセグメントリストに、すべてのホップに対して最小限のラベルが存在することを確認します。この要件が満たされない場合、コミットはブロックされます。

色なし静的セグメントルーティングLSP

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

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

非カラーセグメントルーティングLSPを理解する

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

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

色なしセグメントルーティングLSPは、最大8つのプライマリパスを持つことができます。複数の動作可能なプライマリ パスがある場合、パケット転送エンジン(PFE)は、パスに設定された重みなどのロードバランシング要因に基づいて、パス上にトラフィックを分散します。これは、どのパスにも重みが設定されていない場合は等コストマルチパス(ECMP)であり、少なくとも1つのパスにゼロ以外の重みが設定されている場合は重み付けECMPです。いずれの場合も、一方または一部のパスに障害が発生した場合、PFEは残りのパスのトラフィックのバランスを再調整し、自動的にパス保護を実現します。色なしセグメントルーティングLSPは、専用パス保護のためのセカンダリパスを持つことができます。プライマリパスに障害が発生すると、PFEは残りの機能するプライマリパスへのトラフィックのバランスを再調整します。それ以外の場合、PFEはトラフィックをバックアップパスにスイッチするため、パス保護が実現します。色なしセグメントルーティングLSPは、そのingressおよびbinding-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が共存し、同じingressルートに寄与する同じtoアドレスを持つ場合、同じ優先度を持つ場合。それ以外の場合、最適な優先度を持つセグメントルーティングLSPがルートにインストールされます。

色なしセグメントセグメントルーティングLSPのセグメントリスト

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

色なしの静的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解決のモードを示しています。

表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( inherit-label-nexthops 設定なし)

次に例を示します。

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

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

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

次に例を示します。

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

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

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

次に例を示します。

注:

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

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

    次に例を示します。

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

  • バインディングSIDは、セグメントリストタイプがSIDラベルである色なしの静的LSPに対して有効です。

    次に例を示します。

静的セグメントルーティング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ラベルによって識別されます。[edit protocols mpls label-range]階層レベルでstatic-label-range static-label-rangeステートメントを設定することで、Junos OS静的ラベルプールを設定できます。

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

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

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

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

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

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

VPNサービスのカラーリング

一般に、VPN サービスには、VPN NLRI がアドバタイズされる egressルーター、または VPN NLRI が受信および処理される ingressルーターで色が割り当てられます。

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

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

  • BGPグループごと。

  • BGPネイバーごと。

  • プレフィックスごと。

カラーを割り当てると、そのカラーはBGPカラー拡張コミュニティの形でVPNサービスに添付されます。

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

複数のカラーは、以下の順序で複数のポリシーを介して、エグレスデバイスおよび/またはイングレスデバイスによって割り当てられます。

  • エグレスデバイス上のBGPエクスポートポリシー。

  • イングレスデバイス上のBGPインポートポリシー。

  • イングレスデバイス上のVRFインポートポリシー。

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

Egressカラーの割り当て

このモードでは、エグレスデバイス(つまりVPN NLRIのアドバタイザー)がVPNサービスのカラーリングを行います。このモードを有効にするには、ルーティングポリシーを定義し、[edit protocols bgp]階層レベルでVPNサービスのルーティングインスタンスvrf-export、グループエクスポート、またはグループネイバーエクスポートに適用します。VPN NLRIは、指定されたカラーの拡張コミュニティを持つBGPによってアドバタイズされます。

次に例を示します。

または

注:

BGPグループまたはBGPネイバーのエクスポートポリシーとしてルーティングポリシーを適用する場合、ポリシーがVPN NLRIに適用されるようにするには、BGP、BGPグループ、またはBGPネイバーレベルで vpn-apply-export ステートメントを含める必要があります。

ルーティングポリシーは、レイヤー3 VPNプレフィックスNLRI、レイヤー2 VPN NRLI、およびEVPN NLRIに適用されます。カラー拡張コミュニティは、すべてのVPNルートに継承され、インポートされ、1つまたは複数のingressデバイス上のターゲットVRFにインストールされます。

イングレスカラーの割り当て

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

次に例を示します。

または

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

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

次に例を示します。

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

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

注:

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

カラーIPプロトコルネクストホップ解決

プロトコルネクストホップ解決プロセスが強化され、カラー付きIPプロトコルネクストホップ解決がサポートされます。カラー付きVPNサービスの場合、プロトコルネクストホップ解決プロセスはカラーとresolution-mapを取り、 IP-address:color形式でカラー付きIPプロトコルネクストホップを構築し、inet6color.0ルーティングテーブルでプロトコルネクストホップを解決します。

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

次に例を示します。

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

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

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

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

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のみのネットワークで、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プレフィックスの色付きネクストホップを解決します。

図1:カラー付きIPv6 SR-TEBGP IPv6 LU over colored IPv6 SR-TE上のIPv6 LU BGP

BGP-LUは、以下のシナリオをサポートします。

  • 色付き BGP IPv4 SR-TE 上の BGP IPv4 LU、IS-IS/OSPF IPv4 SR 拡張

  • 静的カラーおよび非カラーIPv4 SR-TE上のBGP IPv4 LU、IS-IS/OSPF IPv4 SR拡張

  • カラー付き BGP IPv6 SR-TE 上の BGP IPv6 LU、IS-IS IPv6 SR 拡張

  • 静的なカラーおよび非カラーのIPv6 SR-TE上のBGP IPv6 LU、IS-IS IPv6 SR拡張

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

  • IS-IS IPv6 SR拡張付き、BGP IPv6 SR-TE上でのIPv6レイヤー3VPNサービス。

  • 静的カラーおよび非カラー IPv6 SR-TE 上の IPv6 レイヤー 3 VPN サービス(IS-IS IPv6 SR 拡張)。

VPNサービスのカラーベースマッピングでサポートされている機能とサポートされていない機能

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

  • BGPレイヤー2VPN(Kompellaレイヤー2VPN)

  • 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シグナルレイヤー2VPN。

  • VPLS

  • MVPN

  • 解決マップを使用した IPv4 と IPv6

PCE開始セグメントセグメントルーティングLSP用のトンネルテンプレート

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

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

テンプレートを設定するには:

  1. [edit protocols source-packet-routing]階層レベルでsource-routing-path-templateステートメントを含めます。BFDおよびLDPトンネリングの追加パラメーターは、こちらで設定できます。

  2. [edit protocols source-packet-routing]階層レベルでsource-routing-path-template-mapステートメントを含め、PCE開始LSPをチェックすべきポリシーステートメントをリストアップします。

  3. テンプレートを適用する必要があるLSPをリストするポリシーを定義します。

    fromステートメントには、lsplsp-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 リリース 18.1 以降

開始する前に、必ずデバイスインターフェイスを設定してください。

概要

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

トポロジー

この例では、プロバイダエッジルーターPE1およびPE5でレイヤー3VPNを設定します。すべてのルーターで MPLS プロトコルを設定します。セグメント ルーティング トンネルは、PE1 ルーター から PE5 ルーターに設定され、ルーター PE1 と PE5 ルーターにプライマリ パスが設定されます。ルーターPE1には、パス保護用のセカンダリパスも設定されています。トランジットルーターPE2からPE4は、ラベルポップと発信インターフェイスを備えた隣接SIDラベルで構成されています。

図2:静的セグメントルーティングラベルスイッチパス Static Segment Routing Label Switched Path

設定

CLIクイックコンフィグレーション

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

PE1

PE2

PE3

PE4

PE5

CE1

CE2

デバイスPE1の設定
ステップバイステップの手順

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

デバイスPE1を設定するには:

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

  2. 自律システム番号とオプションを設定して、パケット転送ルーティングオプションを制御します。

  3. MPLSプロトコルでインターフェイスを設定し、MPLSラベル範囲を設定します。

  4. ピアグループのタイプ、ローカルアドレス、アップデート内のNLRIのプロトコルファミリー、ピアグループのネイバーのIPアドレスを設定します。

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

  6. プロトコル ソース パケット ルーティング(SPRING)のソース ルーティング トラフィック制御(TE)ポリシー用に、プライマリ パスとセカンダリ パスの IPv4 アドレスとラベルを設定します。

  7. プロトコルSPRINGの宛先IPv4アドレス、バインディングSIDラベル、プライマリ、セカンダリ送信元ルーティングパスを設定します。

  8. ポリシーオプションを設定します。

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

  10. インスタンスタイプ、インターフェイス、ルーター識別子、VRFインポート、エクスポート、テーブルラベルを使用して、ルーティングインスタンスVRF1を設定します。プロトコルOSPFのエリアのエクスポートポリシーとインターフェイスを設定します。

結果

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

デバイスPE2の設定
ステップバイステップの手順

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

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

  2. プロトコル MPLS の静的 LSP を設定します。

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

  4. プロトコル OSPF のインターフェイスを設定します。

結果

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

検証

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

ルーターPE1のルーティングテーブルinet.3のルートエントリーの検証
目的

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

アクション

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

意味

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

ルーターPE1のルーティングテーブルmpls.0のルートテーブルエントリーの検証
目的

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

アクション

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

意味

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

ルーターPE1のSPRINGトラフィックエンジニアリングLSPの検証
目的

イングレスルーターでSPRINGトラフィックエンジニアリングLSPを検証します。

アクション

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

意味

出力には、ingressルーター上のSPRINGトラフィックエンジニアリングLSPの概要が表示されます。

ルーターPE1のイングレスルーターでのSPRINGトラフィックエンジニアリングLSPの検証
目的

ingressルーターでSPRINGトラフィックエンジニアリングLSPを検証します。

アクション

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

意味

出力には、ingressルーター上のSPRINGトラフィックエンジニアリングLSPの詳細が表示されます

ルーターPE2のルーティングテーブルmpls.0のルーティングテーブルエントリーの検証
目的

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

アクション

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

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

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

アクション

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

意味

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

ファーストホップのラベル解決によるセグメントルーティングトラフィックエンジニアリングのための、ルーティングエンジンベースのS-BFD

S-BFDをパス障害を検出する高速メカニズムとして使用することで、ファーストホップのラベル解決で、色なしおよび色付きラベルスイッチパス(LSP)上でシームレスな双方向フォワーディング検出(S-BFD)を実行できます。

ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリングのためのREベースのS-BFDの理解

ファーストホップラベル用のS-BFD静的セグメントルーティングトンネル

セグメントルーティングアーキテクチャにより、コアネットワークのingressノードが、ネットワークを通る明示的なパスを介してトラフィックを誘導できます。セグメントルーティングトラフィック制御(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 トンネル内の「to」アドレスのアドレスファミリーに基づいて派生します。S-BFDが設定された状態でのLSPの状態は、BFDが稼働しているかどうかにも依存します。S-BFDがLSPに設定されている場合、S-BFDがパスを報告するまでLSPルートは計算されません。

S-BFDパラメータ

以下のS-BFDパラメータは、セグメントルーティングTEパスでサポートされています:

  • リモート識別器

  • 最小間隔

  • 乗数

  • ルーターアラートオプションなし

S-BFDでは、各レスポンダが複数の識別子を持つ場合があります。識別子は、IGPによって他のルーターにアドバタイズされることも、これらのルーター上で静的に設定されている場合もあります。イニシエーターでは、特定の識別子が、ユーザーまたは中央コントローラーによる決定または解決に基づいて、静的構成によってS-BFDセッションのリモート識別子として選択されます。同じキーラベルスタックで複数のLSPが作成され、それぞれで異なるパラメータでS-BFDが有効になっている場合、各パラメータのアグレッシブな値が共有S-BFDセッションで使用されます。識別子パラメーターの場合、最小値が最もアグレッシブと見なされます。同様に、ルーターアラートオプションの場合、設定のいずれかにルーターアラートが設定されていない場合、派生したS-BFDパラメーターにはルーターアラートオプションはありません。

制限事項

  • グローバルおよびローカル修復は、MXシリーズデバイスでサポートされています。

  • S-BFDは設定されたタイマー値に応じて障害を検出しますが、コンバージェンス時間はグローバル修復時間(seconds)に依存します。

SRv6 TE パス用 S-BFD

SRv6 TEパス上でS-BFDを実行し、パス障害を迅速に検出できます。SRv6 TEトンネル内でS-BFDで設定された各パスは、パスの宛先にプローブを送信できます。これらのプローブは TE パスの SID を追跡し、パス内の任意の SID の障害を報告します。障害が検出されると、対応するSRv6 TEトンネルパスがダウンし、トラフィックをバックアップパスに分散させることができます。

SRv6向けS-BFDは、イングレスルーターでは分散モード、エグレスルーターでは分散モードでサポートされています。

ingressルーター上のSRv6 TEパスにS-BFDを設定するには、[edit protocols bfd]階層レベルでsbfd local-discriminator number設定ステートメントを使用してローカル識別子を設定する必要があります。また、[edit protocols source-packet-routing source-routing-path name primary name bfd-liveness-detection]階層レベルでsbfd remote-discriminator number設定ステートメントを使用してリモート識別子を設定する必要があります。

egressルーター上のSRv6 TEパスにS-BFDを設定するには、[edit protocols bfd]階層レベルでsbfd local-discriminator number local-ipv6-address address設定ステートメントを設定する必要があります。レスポンダーのloca-discriminatorは、ingressルーターのSRv6 TEパスに設定されたremote-discriminatorと一致する必要があります

IPv6ローカルホストアドレスのみをサポートするS-BFDレスポンダーの場合、[edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name]階層レベルでbfd-liveness-detection sbfd destination-ipv6-local-host設定ステートメントを使用することで、IPv6ローカルホストアドレスの使用を強制できます。

ファーストホップラベル解決によるセグメントルーティングトラフィックエンジニアリングのための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. ingressルーターでは、静的セグメントルーティングトンネルのファーストホップラベルを持つ1つ以上のセグメントリストを設定し、プライマリおよびセカンダリパスとして使用します。

    2. ingressルーターでは、複数のプライマリパス(ロードバランシング用)、または1つのプライマリパスと1つのセカンダリパス(パス保護用)のいずれかで、静的なセグメントルーティングトンネルを設定します。各プライマリパスまたはセカンダリパス(LSP)は、すでに設定したセグメントリストの1つを参照し、寄与しているLSPからのファーストホップラベルから派生したネクストホップを使用してルートを作成します。

    3. ingressルーターでは、パケットごとのロードバランシングを有効にして、ingressルートとバインディングSIDルート(すべてファーストホップラベルを持つ)上で解決するルートが、パケット転送エンジンにすべてのアクティブなパスをインストールするようにします。LSP の下の S-BFD セッションは、その LSP を使用するすべてのルートを保護します。

    4. セグメントルーティングトンネルのegressルーターでは、ローカル識別子Dを使用してS-BFDレスポンダーモードを設定し、各FPCでD用の分散型S-BFDリスナーセッションを作成します。

    5. ingressルーターでは、パス障害検出を確認したい任意のLSPに対してS-BFDを設定します。リモート識別子 D を、egressルーターのローカル S-BFD 識別子と一致させるように指定します。S-BFDイニシエータセッションは、現在のLSPキーに対してイニシエータセッションがまだ存在しない場合、LSPラベルスタック+アドレスファミリーの組み合わせをキーとして作成されます。一致するBFDセッションの場合のS-BFDパラメーターは、新しい共有LSPを考慮して再評価されます。S-BFDパラメータが導出されると、各パラメータのアグレッシブな値が選択されます。

    すぐ以下の手順では、基本的な 操作 について説明します。

    1. S-BFDイニシエーターセッションは、ルーティングエンジン上で集中化モードで実行されます。このソフトウェアは、S-BFDセッションのアップおよびダウン状態を追跡します。

    2. S-BFDの状態がUPに移行すると、関連するルートでLSPが考慮されます。

    3. ingressルーターでは、ソフトウェアがS-BFDセッションDOWNを検出すると、セッションダウン通知がルーティングデーモン(RPD)に送信され、RPDはセグメントルーティングトンネルのルートから障害LSPのネクストホップを削除します。

    4. プロシージャーにおける総トラフィック損失は、S-BFDの障害検出時間とグローバル修復時間に結びつきます。S-BFD の障害検出時間は、S-BFD の最小間隔と乗数パラメーターによって決まります。グローバル修復時間は、セグメントルーティング TE プロセス時間と転送ルートの再ダウンロードによって異なります。

    LSPラベルスタックは以下のように変更されます。

    1. 特定のLSPが既存のS-BFDセッションから切り離されます。既存のS-BFDセッションにそれを参照するLSPが少なくとも1つある場合、古いBFDセッションは保持されますが、既存のLSPセッションの中でアグレッシブなパラメーター値が選択されるように、S-BFDパラメーターが再評価されます。また、変更があった場合、S-BFDセッションの名前は最小の1に更新されます。古いS-BFDセッションにLSPが接続されていない場合、そのS-BFDセッションは削除されます。

    2. ソフトウェアは、new-label-stack+address-familyの組み合わせ値に一致する既存のBFDセッションを見つけようとします。このような一致が存在する場合、LSPは既存のS-BFDセッションを参照します。S-BFDセッションは、ステップ1の再評価と同様に、パラメーターまたはセッション名の変更について再評価されます。

    3. システム内に一致するBFDセッションがない場合、新しいBFDセッションが作成され、このLSPからS-BFDパラメーターが導き出されます。

    注:

    S-BFDセッションの最小間隔と乗数によって、セッションの障害検出時間が決まります。修復時間は、グローバル修復時間にも依存します。

以下の出力は、プライマリLSPを持つ色付きLSPに使用する設定ステートメントを示しています。

レスポンダ側では、正しい識別子を設定する必要があります。

デフォルトでは、ルーターアラートはS-BFDパケットに対して設定されます。レスポンダー側で MPLS ヘッダーが削除されると、パケットの宛先アドレス ルックアップなしで処理のためにパケットがホストに送信されます。ingressルーターでno-ルーター-alertオプションを有効にすると、ルーターアラートオプションがIPオプションから削除されるため、egress側から削除されます。lo0 で宛先アドレスを明示的に設定する必要があります。それ以外の場合、パケットは破棄され、S-BFDはダウンしたままになります。

新しいトレースフラグ bfdを使用して、BFDアクティビティをトレースできます。

S-BFDセッション用のリモート識別子(RD)の自動導出

概要

SR-TE パスの S-BFD セッションに自動派生リモート識別子を使用できます。この機能により、イングレスデバイスまたはトランジットデバイスのS-BFD設定で remote-discriminator を設定し、対応するエンドポイントで一致するローカル識別子を設定する必要はありません。代わりに、エグレスPEデバイスは、ローカル識別子としてIPアドレスを受け入れるようになります。BFDでローカル識別子としてIPアドレスを許可するには、 set protocols bfd sbfd local-discriminator-ip 設定を使用します。

また、複数のコントローラでプロビジョニングされたSR-TEポリシーのS-BFD設定で共通のS-BFDテンプレートを使用することもできます。これらのS-BFDセッションでは、Junos OSはSR-TEポリシーに一致するために、トンネルエンドポイントからリモート識別子を自動的に導き出します。

注:
  • RDの自動導出は、IPv4エンドポイントに対してのみサポートされ、IPv6エンドポイントではサポートされません。

  • カラーのみのトンネルのRDの自動導出はサポートしていません。静的に設定されたSR-TEカラーのみのトンネルに対してRDが(RDの自動導出によって)設定されていない場合、システムはコミットエラーを表示します。SR-TEテンプレート設定を使用して、ダイナミックカラーのみのトンネル用にRDが(RDの自動導出によって)設定されていない場合、Junos OSはそのトンネルの sbfd 設定をスキップします。

例:SR-TEのシームレスな双方向フォワーディング検出(S-BFD)の設定

セグメントルーティングパスにS-BFDを設定し、転送プレーンで高速で信頼性の高い障害検出を提供し、セグメントルーティングネットワークで高速再ルート(FRR)メカニズムを有効にします。セグメントルーティングポリシーと明示的に定義されたセグメントルーティングパスを監視して、トラフィックエンジニアリングの制約が満たされ、パスが動作していることを確認できます。

ヒント:
表2:可読性スコアと時間の推定値

可読性スコア

  • フレッシュの読みやすさ:34

  • フレッシュ・キンケイドの読解学年レベル: 11.9

読書時間

所要時間は15分未満。

設定時間

1時間足らず。

前提条件の例

表3:SR-TEにS-BFDを設定するための前提条件

ハードウェア要件

PTXシリーズルーターとMXシリーズルーター

ソフトウェア要件

Junos OSリリース23.1R1以降

始める前に

表4:始める前に

利点

シンプルな設定-トンネルエンドポイントアドレスからの自動派生リモート識別子(RD)のサポートにより、S-BFD設定はユーザーフレンドリーになります。

拡張可能なオプション - 自動派生RDを使用して、複数のコントローラでプロビジョニングされたSR-TEポリシーに共通のS-BFDテンプレートを適用できます。

トラフィックの拡散を最小限に抑制-一方向のパス監視は、非対称セジメントルーティングパスに最適で、LSP障害を検出するための監視アーキテクチャを簡素化します。

オーバーヘッドが少ない-S-BFDは、各ホップに対して個別のBFDセッションを作成しないため、オーバーヘッドが削減されます。

詳細はこちら

ファーストホップのラベル解決によるセグメントルーティングトラフィックエンジニアリングのための、ルーティングエンジンベースのS-BFD

ハンズオンエクスペリエンス

vLabサンドボックス:セグメントルーティング - 基本

詳細はこちら

MPLS向けJunosセグメントルーティング

機能の概要

この表は、この例で展開された設定コンポーネントの概要を示しています。

表5:機能の概要

ポリシー

 
プレフィックスSID エグレスデバイスR3に到達するためのセグメントID(SID)を定義します。

プロトコル

 
IS-IS IS-ISはすべてのデバイスで有効になっています。
送信元パケットルーティング シームレスBFD(S-BFD)が設定されているセグメントルーティングパスには、 srpath1srpath2の2つのセグメントルーティングパスがあります。R0 と R3 の間にはセグメント ルーティング LSP(srlsp1)があります。

デバイスR3には、BFDローカル識別子が設定されています。

MPLS すべてのデバイスで MPLS が有効になっています。

一次検証タスク

  • SR-TE LSPが立ち上がっていることを確認します。

  • S-BFDセッションが自動導出されたRD(リモート識別子)値で稼働していることを確認します。

トポロジーの概要

この例では、イングレスデバイス(R0)が、エグレスデバイス(R3)へのセグメントルーティングパスを介してシームレスBFD(S-BFD)セッションを開始します。セグメント ルーティング パスは、ホップを指定するセグメント リスト(SID)を使用して定義されます。デバイスR3は、自動RDとして自動生成されるSID情報で暗号化されたプレーンIPv4パケットで応答します。

表6:トポロジーの概要

ホスト名

役割

機能

R0

イングレスデバイス(イニシエーター)

R0 は、デバイス R3 へのセグメント ルーティング パス上で BFD セッションを開始します。

R1

トランジットデバイス R0 から R3 への最初のセグメント ルーティング パス(srpath1)のセグメントの 1 つ。

R2

トランジットデバイス R0 から R3 への最初のセグメント ルーティング パス(srpath1)のセグメントの 1 つ。

R3

エグレスデバイス(レスポンダー) 自動RDとして自動生成されるSID情報で暗号化されたプレーンIPv4パケットで応答します。

R4

トランジットデバイス R0 から R3 への 2 番目のセグメント ルーティング パス(srpath2)のセグメントの 1 つ。

R5

トランジットデバイス R0 から R3 への 2 番目のセグメント ルーティング パス(srpath2)のセグメントの 1 つ。

トポロジー図

図3:SR-TEAuto-Derivation of Remote Discriminator (auto-RD) for S-BFD session in SR-TEにおけるS-BFDセッションのリモート識別子の自動導出(auto-RD)

R0でSR-TE上のS-BFDを設定します

注:

DUTの設定例については、以下を参照してください。

  1. デバイスインターフェイスを設定します。
  2. デバイスルーターIDを設定し、自律システムに割り当てます。
  3. testを設定するRIBグループを使用して、IPv4およびMPLSルートを学習し、プロトコルIS-ISに適用します。
  4. ノードセグメントIDを受け入れるようにprefix-sidポリシーを定義します。設定したポリシーをプロトコルIS-ISにエクスポートします。
  5. ループバックインターフェイスと管理インターフェイスを除くデバイスインターフェイスでIS-ISを有効にします。
  6. 他のIS-ISパラメータを設定します。
  7. IS-ISで送信元パケットルーティングパラメーターを設定します。
  8. 管理インターフェイスを除くデバイスインターフェイスでMPLSを有効にします。
  9. デバイスR3に到達するように最初のセグメントルーティングパスsrpath1を設定します。このパスのノードセグメントは、デバイスR1とデバイスR2を通過してR3に到達します。
  10. デバイスR3に到達するように、2番目のセグメントルーティングパスsrpath2を設定します。このパスのノードセグメントは、デバイスR4とデバイスR5を通過してR3に到達します。
  11. デバイスR3へのセグメントルーティングラベルスイッチパス(LSP)を設定します。
    注:

    レスポンダ側(デバイスR3)では、正しい識別子を設定する必要があります。

  12. セグメントリストからラベル情報を継承するようにsource-packet-routingを設定します。

検証

showコマンドのリストを使用して、この例の機能を検証します。

表7:検証コマンド
コマンド 検証タスク
bfdセッションを表示 BFDセッションが稼働していることを確認します。
スプリングトラフィックエンジニアリングを表示 lspコマンドオプションを使用してセグメントルーティングLSPを検証し、sbfdコマンドオプションを使用して自動導出RD値を検証します。
BFDシームレスセッションを表示 デバイスR3でS-BFDセッションを確認します。
BFDセッション検証
目的

BFDセッションのステータスを検証します。

アクション

動作モードから、 show bfd session extensive コマンドを入力して BFD セッションのステータスを表示します。

意味

BFDセッションのステータスはアップです。

セッションの名前は V4-srte_bfd_session-4V4-srte_bfd_session-3です。多くのLSPが同じBFDセッションを共有できるため、 label-stack + address-family の一意の組み合わせを持つ最初のLSPが現れると、S-BFDはセッション名に address-family + lsp-name の組み合わせを使用します。後で同じセッションを共有するLSPが増えた場合、S-BFDセッションの状態に影響を与えることなく、セッションの名前を address-family + least-lsp-nameに変更することができます。

LSPパス検証
目的

セグメントルーティングLSP(srlsp1)が設定されており、S-BFDセッションステータスが表示されていることを確認します。srlsp1がデバイスR3に到達するために通過しているパスを確認します。

アクション

動作モードから、 show spring-traffic-engineering lsp name srlsp1 detail コマンドを入力して、セグメントルーティングLSPが通過しているパスを把握します。

意味

LSP が最終ホップであるデバイス R3 に到達するために通過しているホップを確認します。

各LSPの出力には、S-BFDのステータスと、それが参照しているS-BFD名が表示されます。LSP ごとに S-BFD セッションが 1 つも存在しない場合があるため、LSP レベルの S-BFD カウンターは表示されません。

デバイスR0でのS-BFDセッション検証
目的

デバイスR0の2つのセグメントルーティングパス上でS-BFDセッションのステータスを確認します。

アクション

動作モードから、 show spring-traffic-engineering sbfd detailコマンドを入力して、S-BFD セッションのステータスを確認します。

意味

S-BFDセッションが立ち上がっており、デバイスR0はデバイスR3に到達できます。

デバイスR3でのS-BFDセッション検証
目的

BFD レスポンダーであるデバイス R3 で S-BFD セッションのステータスを確認します。

アクション

動作モードから、 show bfd seamless session extensiveコマンドを入力して、S-BFDセッションのステータスを確認します。

意味

S-BFD セッションが稼働しており、設定された BFD ローカル識別子が BFD リモート識別子の値に対応しています。

付録1:すべてのデバイスでコマンドを設定する

付録2:R0での設定出力を表示する

デバイスR0のshow configuration output。

セグメントルーティングトラフィックエンジニアリングにおける非ルーターIDエンドポイント

これまで、RSVP-TEは非ルーターIDエンドポイントをサポートしていました。セグメントルーティングトラフィックエンジニアリング(SR-TE)ポリシーに非ルーターIDエンドポイントを追加することで、SR-MPLSフレームワーク内のIPv4とIPv6の両方でネットワークの柔軟性と効率性が向上します。SR-TEの非ルーターIDエンドポイントにより、イングレスルーターは、ノードルーターIDに制約されることなく、トラフィックを論理的な宛先(例えば、エニーキャストサービスアドレス)に誘導できます。エニーキャスト、セカンダリループバック(lo0)、インターフェイスプレフィックスアドレスの仕様を宛先ポイントとして有効にすることで、堅牢なロードバランシングと冗長性を実現できます。

従来、SR-TEポリシーはルーターIDを使用していましたが、エニーキャストアドレスを指定して、SR-MPLSネットワークの冗長性とロードバランシングを強化できます。SIDスタック圧縮の有無にかかわらず、IPv4およびIPv6エニーキャストアドレスをIGPで学習した宛先として使用します。これらのエニーキャストアドレスは再配布されません(Rビット設定)。これらを、関連するコンピューティングプロファイルを持つSR-TEポリシーのtoアドレスとして使用します。

注:現在、宛先アドレスとしてエニーキャストタイプのエンドポイントをサポートしています。エンドポイントタイプ(インターフェイスプレフィックスとセカンダリループバック(lo0)アドレスを宛先としてサポートしていません。

SR-TEの非ルーターIDエンドポイントのメリット

  • 共有プレフィックスをアドバタイズする複数のノードをターゲットにすることで、ネットワークの柔軟性を高め、効果的なロードバランシングと冗長性を促進します。

  • SR-TE構成をエニーキャストアドレスで拡張し、ネットワーク設計と最適化のためのオプションが増えます。

  • トラフィックエンジニアリングの制約を受けることなくパケットイングレス制御が向上し、効率的なネットワーク管理が可能になります。

  • ルーティングパスを最適化して堅牢なネットワークパフォーマンスを実現し、シームレスなトラフィック配信と耐障害性の向上を確保します。

宛先アドレスとしてのエニーキャスト

複数のノードが、IGPドメイン全体で単一のエニーキャストIPアドレス(IPv4またはIPv6)と対応するエニーキャストSIDをアドバタイズできます。

エニーキャストSIDは、一連のノードを識別するプレフィックスSIDの一種です。ノードのセット(エニーキャストグループ)は、共有プレフィックスアドレスとプレフィックスSIDをアドバタイズするように設定されています。エニーキャストルーティングは、複数のアドバタイズノードへのトラフィックの誘導を可能にし、ロードバランシングと冗長性を提供します。エニーキャストアドレス宛てのパケットは、トポロジー的に最も近いノードに転送されます。

ingressルーターは、エニーキャストIPアドレス(IPv4またはIPv6)をエンドポイントとして使用するSR-TEポリシーで設定されます。

show spring-traffic-engineering detailコマンドを使用すると、計算されたセグメントとエニーキャストSIDの詳細を示す、非ルーター-IDエンドポイントの包括的な詳細を表示できます。これらのコマンドを使用して、SR-TEポリシーが正しく実装され、シームレスなトラフィック分散と最適化されたルーティングパスを実現します。

コンピューティング遅延最適化されたドメイン内およびドメイン間セグメントルーティングパス

トラフィックエンジニアリングパスの遅延ベースのメトリックの概要

動的な遅延ベースのメトリックを活用することは、最新のネットワークにおいて望ましい属性になりつつあります。遅延ベースのメトリックは、パス計算要素(PCE)がトラフィックエンジニアリングパスを計算するために不可欠です。遅延ベースのメトリックを使用して、パケットを最小遅延パスまたは最小遅延パスに誘導できます。そのためには、すべてのリンクで遅延を測定し、適切なルーティングプロトコル(IGPまたはBGP-LS)を使用してアドバタイズし、イングレスのTEDでリンクごとの遅延プロパティを持つようにする必要があります。

各リンクで遅延をアドバタイズする方法、またはリンク測定を有効にする方法については、「 IS-IS でリンク遅延測定とアドバタイズを有効にする方法」を参照してください。

ネットワーク内の変化の検出を測定、アドバタイズ、計算し、最短遅延でトラフィックエンジニアリングパスを計算すると、以下の一連のイベントが発生します。

  • 合成プローブを使用したルーター間ルーター間の遅延を測定することで、ネットワークの変化を検出します。
  • IGP拡張TEメトリック拡張を介して、結果をイングレスノードにフラッディングします。
  • 結果を、対応するBGP-LS拡張機能を持つ集中コントローラーにアドバタイズします。
  • IGPベースの最短累積遅延メトリックパス(フレックスアルゴ)を計算します。
  • 最短の累積遅延または遅延メトリック(SR-TE)で、トラフィック制御された明示的なパス(送信元から宛先まで)を計算します。

パス計算における遅延ベースのメトリックの利点

  • ネットワーク全体で最小限の遅延に基づいて、付加価値サービスを導入します。
  • 遅延ベースのメトリックを使用して、パスごとの遅延(最小、最大、平均)を測定します。
  • 遅延の影響を受けやすいサービス(VPNや5Gサービスなど)を、超低遅延のSR最適化パスに誘導します。

SR パスの遅延メトリックを用いた DCSPF ベースの計算の概要

セグメントルーティングLSPの分散型CSPF(Trained Shortest Path First)機能を使用すると、設定した制約に従って、ingressデバイス上でローカルにセグメントルーティング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階層で遅延メトリックを設定できます。

ドメイン間およびドメイン内ユースケースの概要の遅延メトリック

ドメイン内(パスが単一ドメイン内にある)の場合、パス計算を行う際にリンク遅延が考慮されます。セグメント ルーティング パス計算の遅延メトリックは、圧縮 SID と非圧縮 SID の両方でサポートされています。非圧縮の SID がある場合、コストが等しい場合は、セグメント リストの隣接セグメントを使用して複数のセグメント リストを生成します。非圧縮SIDは、[edit protocols source-packet-routing compute-profile profile-name ]階層レベルでno-label-stack-compression設定ステートメントを使用して設定できます。これにより、隣接SIDを使用して完全に拡張されたパスが提供されます。詳細については、「compute-profile」を参照してください。

遅延メトリックの設定例を以下に示します。

注:

光経路計算では、遅延メトリックを最小限使用することをお勧めします。最小値はデフォルトの設定です。

複数の自律システムが存在するドメイン間(マルチドメイン)のユースケースでは、エクスプレスセグメントを使用してパス計算のためのリンク遅延を設定できます。エクスプレスセグメントは、ボーダーノードまたはASBRを接続するリンクです。エクスプレスセグメントの詳細については、エクスプレスセグメントLSP設定を参照してください。エクスプレスセグメントで遅延を設定するか、基盤となるLSPの遅延を継承することができます。[edit protocols express-segments segment-template template-name metric]階層レベルでdelayを設定し、最小、最大、平均遅延の値を設定できます。

次の CLI 階層のエクスプレスセグメントで遅延メトリックを設定できます。

ドメイン間パス計算では、BGP EPEリンクに遅延メトリックを割り当てることができます。 delay-metric の値は、以下に示すように、[edit protocols bgp group group-name neighbor ip address egress-te-adj-segment segment-name egress-te-link attribute]階層レベルで設定できます。

光ネットワークのユースケースにおける遅延メトリック

以下のトポロジーは、光のユースケースの例を示しています。光保護および復元ソリューションでは、リンク障害やその後のDWDMネットワーク最適化により、主にパス長などの基盤となる物理的特性が変化します。

Segment Routing Traffic Engineering diagram with nodes A, B, C, and intermediate nodes 01, 02, 03. Green arrow from A to C indicates SR-TE path with 10 microsecond delay. Horizontal arrow shows delay variation measurement.
Network topology with green nodes labeled A, B, C, 01, 02, 03. Lines show connections, some with delay values like 15 usec. Green line indicates SR-TE Policy. Red X shows failure between 01 and 03, rerouting through 02. Analyzes min, avg, max delay-variation.

では、A と C の間のリンクは光ノード O1 と O3 を経由しており、遅延は 10 マイクロ秒です。では、光ノードO1とO3の間でリンク障害が発生し、実際の光接続が光ノードO2を介して再ルーティングされていることがわかります。これにより、15マイクロ秒の遅延が増加します。AとBを接続するリンクのメトリックは、時間=0から時間=1の間で動的に変化します。

リンクごとの遅延の変化がイングレスによって検出されると、イングレスは遅延最適化パスの再計算をトリガーし、ヘッドエンドルーターは、次に利用可能な最小遅延パスを介してパスを再ルーティングします。リンク遅延の変更により、イングレスは、最も遅延の少ないパスを持つ別のリンクセットを選択する可能性があります。図Bでは、パスAとCの間のリンクに変更があり、ヘッドエンドルーターがトポロジーに示されているようにパスA-B-Cを再ルーティングして選択していることがわかります。

SRv6 TE トンネルのローカル パス計算について

概要

従来のSIDとマイクロセグメンテーションSID(uSID)を含むSRv6 TEトンネルのローカル計算を実装することで、ネットワーク内のパス計算機能が大幅に強化されます。ローカル パス計算を有効にすることで、現在のネットワーク トポロジーと制約に基づいて、SRv6 SID を使用してトラフィック制御パスを動的かつ効率的に計算できます。設定オプションにより、SRv6 TEパス計算の有効化、コンピューティングプロファイルのアタッチ、IGPインスタンスおよびトポロジー制約の設定を行うことができます。さらに、SIDタイプのプリファレンスと、SRv6 TEコンピュートトンネル上でのシームレスな双方向フォワーディング検出(sBFD)のサポートにより、最適化されたルーティングと高いネットワーク効率が確保され、この機能は拡張可能で適応性の高いネットワーク設計に不可欠なものになります。

SRv6 TEトンネルローカル計算のメリット

  • リアルタイムのトポロジーと制約に基づいてトラフィックエンジニアリングパスを動的に計算することでネットワーク効率を最適化し、不要なオーバーヘッドを削減し、リソース使用率を向上させます。

  • 従来のSRv6 SIDとuSIDの両方をサポートすることで拡張性を強化し、セグメントリストのルーティングと管理をより効率的に行えます。

  • ローカル計算による適応型ルーティングを促進し、外部の計算ソースに依存することなく、ネットワークの変更に迅速に調整できます。

  • SRv6 TEトンネル上でのsBFDをサポートし、堅牢な障害検出と対応メカニズムを提供することで、高いネットワーク効率と信頼性を確保します。

SRv6 TEトンネルローカルパス計算の設定

SRv6 TE パス計算を設定するには、以下の CLI 設定を使用します。

  1. 計算タイプがプライマリとセカンダリの SRv6 TE トンネルを許可することで、SRv6 TE パス計算を有効にします。
  2. コンピュートプロファイルをSRv TEトンネルにアタッチします。
  3. 計算に使用するコンピューティングプロファイルを定義します。
  4. 設定で従来のSRv6 SIDを使用するかどうかを指定します。

    コミットチェックは、SRv6対応のコンピューティングプロファイルとセグメントリストを検証し、IGPにトポロジー設定が存在することを確認します。 show spring-traffic-engineering lsp detailshow spring-traffic-engineering route detailなどの診断コマンドは、パス計算操作の効果的なトラブルシューティングと監視に役立ちます。SRv6 TEアクティビティの詳細なログを提供するトレースオプションも用意されており、包括的な診断とトラブルシューティングに役立ちます。

BGP VPNオプションCの理解 SRv6上のMPLS

IPv6(SRv6)向けセグメントルーティング上のMPLSを使用したBGP VPNオプションCは、IPv4向けSR-MPLS(SR-MPLS-IPv4)とSRv6ドメイン間のシームレスな相互作用を促進することで、マルチドメインネットワークアーキテクチャを強化します。この機能は、SRv6をトランスポート層として使用し、最適なルーティングと転送のために、MPLSラベルと一緒にSRv6セグメント識別子(SID)をアドバタイズできます。

MPLS over SRv6 を使用した BGP VPN オプション C のメリット

  • MPLSドメインとSRv6ドメインのシームレスな統合を可能にすることでネットワークの拡張性を強化し、マルチドメイン環境での効率的なルーティングを促進します。

  • SRv6セグメント識別子(SID)とMPLSラベルによってルーティングの柔軟性が向上し、動的なトランスポートシナリオと最適なパケット配信が可能になります。

  • イングレス、エグレス、およびトランジットルート設定のサポートにより、ルーティングパスの正確な制御を可能にし、正確なラベル操作と効率的なデータ転送を保証します。

  • SRv6動的SIDの高可用性サポートにより、ネットワークの堅牢性と信頼性が向上し、サービスの中断が最小限に抑えられます。

  • BGP-LUアドレスファミリー内でSRv6サービスのアドバタイズと受け入れを可能にすることで、高度なネットワーク運用をサポートし、複雑なネットワーク設定における相互運用性とサービス管理を強化します。

概要

たとえば、中央ドメイン(C)とその周囲に多くのリーフドメインがあるマルチドメインネットワークがあるとします。サービスのフローは、イングレスリーフドメイン(LI)のイングレスPEから、セントラル(C)ドメインを経由して、エグレスリーフドメイン(LE)のエグレスPEに至ります。各ドメインは、独自のIGPインスタンスを実行します。リーフドメイン(LIおよびLE)はMPLSデータプレーン(SR-MPLS-IPv4)を使用し、セントラルドメイン(C)はSRv6データプレーンを使用します。

プロバイダエッジデバイスは、サービスルートリフレクタを介してMPLSベースのBGP L3(VPNなど)サービスを実行します。境界ルーターを介したサービスエンドポイントシグナリングと、対応する転送状態は、中間トランスポートドメイン上で相互作用を提供します。イングレスPEは、ペイロードをMPLSサービスラベルにカプセル化し、MPLS LSPを介してエグレスPEに送信します。トランスポートノードは、SRv6 Cドメインを介してカプセル化されたラベルスタックをegress PEに転送します。

BGPラベルユニキャスト(BGP-LU)は、マルチドメインネットワーク全体のPE IPv4ループバックのトランスポート到達可能性をアドバタイズします。境界ルーターのネクストホップセルフにより、異なるドメインにおけるドメイン内トンネル技術の独立性が得られます。MPLSベースのL3 BGPサービスは、カラー拡張コミュニティなしのサービスルートリフレクタ(RR)を介して、出口PEのIPv4ネクストホップでシグナリングされます。イングレスPEには、サービスルートでネクストホップとしてアドバタイズされたリモートPE IPv4ループバックアドレスへの到達可能性にラベルが付けられる必要があります。BGP-LUは、IPv4 PEループバックをアドバタイズします。ネクストホップ自己は、ボーダールーターで実行されます。

BGP-LU LSPはSRv6ドメイン全体でトンネリングされます

  • 各 PE IPv4 ループバック アドレスの境界ルーター上の既存の BGP-LU ラベル クロスコネクト。

  • イングレスボーダールーターでのルックアップは、BGP-LUラベルに基づいています。

  • ネクストホップへのSR-MPLS IGPラベルは、SRv6中央ドメインのDTM動作に関連付けられたDA = SRv6 SIDのIPv6トンネルに置き換えられます。

  • イングレスボーダールーターの転送は、DTM動作に関連付けられたDA = SRv6SIDを使用して、ラベルスワップとH.Encaps.Mを実行します。

BGP-LUアドレスファミリーのSRv6シグナリングを有効にする

BGP-LU アドレスファミリーの SRv6 シグナリングを有効にするには、次の方法があります。

  • BGP-LU アドレスファミリーの SRv6 サービス TLV をアドバタイズするための advertise-srv6-serviceaccept-srv6-service CLIステートメントを有効にします。

  • BGPプレフィックスSID属性のラベルルートでSRv6トンネルをサポートし、NLRIのプレフィックスにバインドされたMPLSラベルとともにSRv6SIDに信号を送ります。ラベルルートTLV用のSRv6トンネルは、prefix-SID属性のSRv6サービスTLVとまったく同じようにエンコードされます。

  • Prefix-Sid属性のラベルルートTLVのSRv6トンネルのSRv6のサブTLVのSID情報サブで、BGP-LUアドレスファミリーでend-dtm SIDをアドバタイズします。

エグレスルートの動作

end-dtm SIDが設定されている場合、end-dtm SIDルートが、エンドポイントのカプセル化解除とMPLSテーブルルックアップ動作を備えたmpls.0テーブルのネクストホップを指すinet6.0テーブルに追加されます。end-dtm-sidには、厳密なsidルートも追加されます。

イングレスルートの動作

イングレスボーダールーターは、prefix-Sid属性のラベルルートTLVに対して、SRv6トンネルで受信したSRv6 SIDとして、IPv6ヘッダー宛先アドレスを持つH.Encaps.M.redを実行します。

トランジットルートの動作

トランジットボーダールーターは、プレフィックス-Sid属性のラベルルートTLVに対して、SRv6トンネルで受信したSRv6 SIDとして、ラベルスワップとH.Encaps.M.redを実行します。

end-dtm-sidの設定

静的または動的 end-dtm-Sid を設定します。ロケーターはフレックスアルゴロケーターにすることができます。

end-dtm-sidは、カプセル化解除とMPLSテーブルルックアップ動作を持つエンドポイントです。

デフォルト以外のSIDは、ポリシーを介してのみBGP-LUプレフィックスに適用できます。

BGP-LUアドレスファミリーのadvertise-srv6-serviceの設定

advertise-srv6-service CLIステートメントが設定されている場合、ラベルルートTLVのSRv6トンネルのみがプレフィックスSID属性BGPアドバタイズされます。advertise-srv6-serviceステートメントは、オリジネーションに適用されます。このステートメントは伝播には適用されません。

BGP-LU アドレスファミリーの accept-srv6-service の設定

accept-srv6-service CLIステートメントが設定されている場合、プレフィックスSID属性に存在するラベルルートTLVのSRv6トンネルのみBGP受け入れられます。

ポリシーでend-dtm-sidを設定

SRv6 CLIステートメントは、SRv6 SIDタイプ(end-dtm-sid)を設定するように拡張されています。

プラットフォーム固有のセグメントルーティングLSPの動作

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォーム固有の動作を確認するには、以下の表を使用して下さい。

プラットフォーム固有のセグメントルーティングLSPの動作

プラットフォーム 違い

ACXシリーズ

  • set routing-options resolution preserve-nexthop-hierarchy設定ステートメントは、S-BFD機能を動作させるために、ACX7000シリーズデバイスに必須です。

  • ACX7000シリーズデバイスでは、S-BFDセッションが隣接関係を適切に形成するために、 lo0 インターフェイスをローカルホストアドレス127.0.0.1で設定する必要があります。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
19.4R1
PCE開始セグメントルーティングLSPのトンネルテンプレートを設定して、これらのLSPに2つの追加パラメーター(BFD(双方向転送検出)とLDPトンネリング)を渡すことができます。