ルーターはどのようにして、セグメントルーティング内のパケットにプッシュするセグメントを決定するのでしょうか?

SPF最短パスとフレックスアルゴ最短パス

トラフィックがリモートルーターへの IS-IS または OSPF の計測的最短パスに従うことが唯一の要件である場合、Junos OS はその命令に関連付けられたセグメントを使用するだけです。これは自動的に発生し、通常のトポロジーとフレキシブルアルゴリズム(フレックスアルゴ)トポロジーの両方に当てはまります。

デフォルトの完全トポロジーの場合、Junos OSは、inet.3テーブル(SR-MPLSの場合)またはinet6.3テーブル(SRv6の場合)にSRトンネルのフルメッシュを持ちます。

inet.3テーブルとinet6.3テーブルには、このデバイスに入力されるすべての運用ラベルスイッチパス(LSP)が格納されていることを思い出してください。デフォルトでは、このテーブルは、BGPプロトコルのネクストホップを解決するための可能性のある方法として、BGPによって使用されます。これらのテーブル内のすべてのトンネルには、トラフィックをトンネルの宛先に転送するためにパケットにプッシュする必要がある最短パスセグメントに関する情報トンネルが含まれています。

ネットワーク内でいずれかのフレックス アルゴ トポロジーを有効にすることを選択した場合、Junos OS は、そのトポロジー内のすべてのデバイスに対して LSP の個別のフルメッシュも作成します。この機能を有効にする方法に応じて、各トポロジーは、各Junos OSルーターにinet.3テーブルに相当する独自のものを持つことができ、トポロジー内の他のすべてのルーターへの最短パストンネルのフルメッシュを持つことができます。

この概念を理解するには、以下の 図1 とCLI出力1を参照してください。まず、 図1 は、R1からR10まで番号が付けられた10台のルーターのネットワークを示しています。各ルーターには、192.168.1.x形式のループバックIPv4アドレスがあり、Xはルーター番号です。

以下のCLI出力1は、すべてのデバイスで基本的なSR-MPLS導入を有効にした後のルーターR1のinet.3ルーティングテーブルに焦点を当てています。LSP のフルメッシュをネットワーク内の他のすべてのデバイスに表示します。ネットワーク内の各ノードで最短パスセグメントを設定すると、このトンネルのフルメッシュがすべてのSR-MPLSデバイスに自動的に作成されます。

出力1: すべてのルーターで基本的なSR-MPLS導入を有効にした後、R1のinet.3テーブルは、他のすべてのルーターへのラベルスイッチパスのフルメッシュを示しています

これらの各LSPには、1つの発信トランスポートラベルが含まれています。ラベルは、そのリモートルーターへの最短パスをたどるように指示を表しています。SR-MPLSは自動的に計算するため、R1での追加設定は必要ありません。

例えば、出力には、宛先アドレスが192.168.1.5であるR5へのイングレスLSPが含まれています。R1がプロトコルネクストホップが192.168.1.5のBGPプレフィックスを学習した場合、R1はプレフィックスをこのLSPに解決します。そのため、R1 はそのトンネルに関連付けられた最短パス セグメントを自動的に使用します。この場合、R1は300405の単一のSR-MPLSトランスポートラベルをプッシュします。これは、トラフィックを R5 への最短パスを送信したときに R2 が受信するラベルです。

トポロジーに依存しないループフリーの代替バックアップパスとマイクロループ回避

TI-LFA(Topology-Independent Loop-Free Alternate)を有効にした場合や、マイクロループ回避を実行した場合にも、同様の自動結果が発生します。セグメントルーティングには、リモートデバイスへの最短パスを表すセグメントに加えて、特定のルーターからネクストホップネイバーにトラフィックを直接転送するセグメントも用意されています。最短パスセグメントと直接ネクストホップセグメントを組み合わせることで、ネットワーク内に任意のパスを作成できます。このアプローチにより、ネットワーク コンバージェンス イベント中に発生する可能性のある一時的なループを防止できます。TI-LFA は、これら 2 つのセグメント タイプを使用してバックアップ パスを計算および構築します。

SPF が宛先リンクまたはルーターへの最適パスを計算すると、TI-LFA は SPF を再実行して、ローカル リンクまたは隣接するルーターの障害から保護するバックアップ パスを決定します。TI-LFAがパスを計算すると、このパスに必要なセグメントスタックを自動的に決定します。このスタックは、単一の最短パスセグメントから、より複雑な一連のホップバイホップ命令まで多岐にわたります。いずれにせよ、これは追加のユーザー介入なしで行われます。

図2 は、R4で障害が発生した6台のルーターを示しています。

TI-LFAネットワークでは、R4を迂回するバックアップパスを計算することで、R3がこのイベントに備えます。ただし、R3は、R8とR9がどちらもループの潜在的なソースであることも特定しています。この問題を回避するために、R3 は 2 番目のセグメントをパケットに自動的にプッシュし、トラフィックを R10 に送信するようにネットワークに指示します。その後、R10からパケットをR5に安全に配信できます。これらのセグメントは自動的に計算およびプッシュされるため、TI-LFAを有効にする以外にユーザーによる追加介入は必要ありません。マイクロループ回避についても同様です。トポロジーが変更された場合、SPFは新しい最適パスを計算します。マイクロループ回避が新しいパスで短時間のマイクロループの可能性を検出した場合、Junos OS は必要なセグメントを自動的にパケットにプッシュし、パケットが確実に宛先に到達できるようにします。

手動ユーザーセグメント設定によるトラフィックエンジニアリング

Junos OS には、トラフィック制御パスのパケットに書き込まれるセグメントを決定するためのいくつかの方法が用意されています。最も単純だが、最も拡張性の低い方法は、ユーザーがリモートルーターへのトンネルを手動で作成し、そのパスに必要なMPLSラベルまたはSRv6アドレスを設定することです。この場合、ルーターはセグメントが有効で正しいかどうかを実際に確認しません。一部のセグメントはまったくアドバタイズされておらず、正確性を検証できません。この場合、Junos OS は指示に従い、指定した内容をパケットに書き込みます。

図3 は、この例を示しています。10台のルーターの同じトポロジーを使用して、セグメントリストと呼ばれるJunos OS設定構成を紹介します。名前付きセグメントリストを定義することで、パケットに書き込む正確なセグメントを定義することができます。その後、SR-TEラベルスイッチパスを作成するときにセグメントリストを参照できます。

この例では SR-MPLS を使用していますが、概念は SRv6 でも同じです。

この方法は設定は簡単ですが、すべてのスタティックパスと同様に、トポロジーの変更に反応することはできません。セグメントで表されるリンクまたはノードの 1 つに障害が発生した場合、パス全体が失敗します。このオプションのもう一つの欠点は、パスに沿った障害を本質的に特定できないことです。ただし、パスをアクティブに監視するシームレスBFD(S-BFD)と呼ばれる新しいバージョンの双方向フォワーディング検出(BFD)を有効にすることはできます。これにより、障害が検出されたときにパスがシャットダウンされ、別のバックアップパスまたはセカンダリパスに移行できます。

手動ユーザー設定とIPルックアップによるトラフィックエンジニアリング

トラフィックエンジニアリングのより拡張性の高い方法は、トラフィックエンジニアリングパスが通らなければならない必要なIPホップを設定することです。例えば、パスは、パス内のデバイスのループバックIPアドレスとネットワークインターフェイスアドレスを組み合わせることができます。Junos OSは、これらのアドレスを最短パス命令とダイレクトネクストホップ命令に変換し、そのセグメントに必要なMPLSラベルまたはSRv6アドレスを計算できます。

図4 は、この概念を示しています。

これは図 3 の例と似ていますが、今回の名前付きセグメントリストはインターフェイスIPアドレスとループバックIPアドレスを直接参照しています。このセグメントリストをSR-TE LSPで使用すると、Junos OSは自動的にIPアドレスを必要なセグメントに変換します。この方法では、パスを手動で定義する必要があることに注意してください。そのため、このパスは、このパス内のデバイスの障害には対応できません。それにもかかわらず、IPをセグメントに自動変換すると、設定でセグメント値を明示的に定義する場合と比較すると、少量の動的な動作が発生します。

動的パス計算によるトラフィック制御

さらに拡張性の高い方法は、一連のトラフィック制御制約に基づいてパスを動的に計算することです。その後、Junos OS は計算されたパスに対して正しいセグメントを計算します。このオプションは、RSVP で使用される Constrained Shortest Path First(CSPF)アルゴリズムのバージョンを使用します。このアルゴリズムは、分散型CSPF(D-CSPF)と呼ばれます。この名前は、プロトコルがネットワーク内のどのルーターでも実行できるという事実を反映しています。これは、集中コントローラーを使用するオプションとは対照的です。

D-CSPF は、管理グループや共有リスク リンク グループなど、RSVP に含まれるいくつかの TE 制約を提供します。さらに、パケットにプッシュされるセグメントの最大数を制限したり、ローカル修復をサポートするリンクのみを使用したりするなど、セグメントルーティング固有の制約も含まれています。D-CSPFでは、TEメトリックや遅延メトリックなどの代替の最短パスメトリックも考慮できます。Junos OSは、一連の制約をコンピュートプロファイルと呼ばれるオブジェクトにまとめて収集します。この制約のセットは、それらの制約を必要とする任意の TE パスに一貫して適用できます。

図5 では、この概念を簡単に紹介しています。

図5は、ネットワーク内の各リンクに、HIGH_PRIORITYとBEST_EFFORTと呼ばれる2つの管理グループのいずれかでタグ付けされていることを示しています。この図は、管理グループHIGH_PRIORITYでタグ付けされたリンクのみを考慮してパスを計算する基本的なコンピュートプロファイルの設定も示しています。この例では、1つのコンピュートプロファイルオブジェクト内に他のトラフィック制御制約を含めることができることも示しています。コンピュート・プロファイルを定義した後、このオブジェクトを2つの方法で使用できます。最初のオプションは、手動で定義した宛先エンドポイントを持つトンネル内で参照することです。この場合、エンドポイントは手動で設定されますが、パスやセグメントリストなど、他のすべてはJunos OSによって動的に計算されます。トポロジーが変更されると、Junos OS は新しいパスと新しいセグメントリストを自動的に計算します。2つ目のオプションは、オンデマンドネクストホップ(ODN)導入の一部としてコンピューティングプロファイルを参照することです。この機能では、各トンネルエンドポイントを手動で定義する必要はありません。代わりに、Junos OS は有効な BGP プロトコルのネクストホップへの新しいトンネルを動的に構築できます。

どちらの場合も、Junos OS がパケットに書き込むセグメントを決定します。

一元化されたコントローラによるトラフィック制御

中央コントローラーを使用して、セグメントリストを計算して作成できます。コントローラは、明示的なセグメントまたはIPホップを持つ手動パスの作成、TE制約に基づく動的パスの作成など、前述のすべてのTEオプションも提供します。さらに、コントローラは、トポロジーの可視化、グラフィカルパスの可視化、帯域幅の制約、ルーティングドメイン間のTEなど、さまざまな強力な機能を提供します。コントローラーがトンネルの通過すべきパスを決定すると、コントローラーはそのパスに関連するセグメントを検出し、この情報をパスのingressルーターのデータプレーンに直接書き込みます。パスはドメインの境界を簡単に越えることができます。ingressルーターは、パス内のすべてのセグメントを認識する必要はありません。ingressルーターは、パケットに書き込む必要があるMPLSラベルまたはIPv6アドレスと、トラフィックのダイレクトネクストホップのみを知っている必要があります。

参考資料

以上のセクションは、セグメントルーティングトラフィックエンジニアリングのいくつかの基本概念です。今後の改訂版におけるセグメントルーティングトラフィックエンジニアリングの詳細なドキュメントの更新にご期待ください。

セグメント ルーティングに関するこの入門シリーズの 4 つのトピックをすべて読んだ方は、SR-MPLS と SRv6 について詳しく調べる準備が整いました。