Optimizability
これまでの章では、セグメントルーティングを導入するためのさまざまなユースケースを見てきました。この章では、特に SR のトラフィックエンジニアリング (TE) について見ていきます。特に以下のことを説明します。
TE プロセスモデル
明示的なパス定義の役割
SR SID タイプのルーティング制約と複数の特性を持つプロパティ
分散した一元化されたパスの計算
そして最後に、一元化されたコントローラを活用したサンプルネットワークのエンドツーエンドの SR TE ソリューションを提供します。
TE プロセスモデル
でFigure 1提供されている TE プロセスモデルでは、オペレータまたは適切なオートマトンが“、”アダプティブフィードバックコントロールシステムのコントローラとして機能します。このシステムには次のものが含まれます。
相互接続された一連のネットワーク構成要素 (IP/MPLS ネットワーク)
ネットワークの状態/トポロジーの監視要素
ネットワークパフォーマンス監視要素
ネットワーク構成管理要素
Operator/オートマトン formulates は制御ポリシーを使用して、監視システムを介してネットワークの状態を処理し、トラフィックを特徴設定し、制御アクションを適用して、ネットワークを最適な状態にします。これは、ネットワークの現在の状態に基づいて、または将来の予測に基づいて事前に、リアクティブに実行することができます。
アダプティブフィードバックループは、ネットワーク内の各ノードに実装されることがあります。つまり、分散 TE、またはパス計算の要素 (PCE) を使用する一元化された方法になります。さらに、さまざまなハイブリッドモデルが可能です。
明示的ルーティング: TE のためのツール
明示的なルーティングは、ネットワークリソースを最適化したり、非常に厳格なサービス保証を提供したりするために必要になる場合がありますが、それだけでは TE ソリューションではありません。トラフィックエンジニアリングソリューションの重要な部分である TE プロセスモデルの結果として、結果の計算をプログラムするために明示的ルートのプログラミングが必要になる可能性があります。そのため、1つまたは複数の Lsp に対して、ネットワーク全体で厳密なパスを定義できるようにすることが求められています。RSVP TE と SR はどちらも、ネットワーク全体で厳密なパス (strict ホップ、緩いホップ、抽象/エニーキャストホップ) を明示的に定義する手段を提供します。
Explicit Routing with RSVP
ネットワーク通信事業者は、通常、特定の制約条件を満たす Lsp を設定することによってリクエストを行います。たとえば、ノード R1 を発信し、ノード R6 で終了し、100メガビット/秒を予約し、blue インターフェイスのみを通過する LSP をネットワーク運用担当者が要求することが考えられます。PCE ––や受信ルーターなどの中央コントローラに配置されたパス計算モジュールは、すべての制約を満たすパスを計算します。Figure 3は、LSP を設定するための RSVP パスのセットアップおよび予約メッセージングと、その結果として得られる MPLS 転送テーブルラベル操作を示しています。
以下の構成例は、必要な構成について説明しています。’LSP にはルーティング制約が定義されていないことに注意してください。つまり、表示されている構成は、明示的なパスの定義だけです。多くの (またはほとんどの) RSVP TE の導入では、パスは明示的に定義されていませんが、受信ノードや外部 CSPF が明示的なパスを動的に計算してルーティングを満たすように、帯域幅やリンクアフィニティなどのルーティング制約が定義されています。拘束.
R1 configuration
Explicit Path Definition with SR
RSVP TE explicit Lsp と同様に、ネットワーク事業者は、特定の制約条件を満たす設定を通じて、通常は構成を通じて要求を出します。主な違いは、特定の構成構文だけではありませんが、これは非常に類似し‘てい’ますが、同じ CLI 構造を使用してルーティング制約を記述する概念に似ています。複雑な TE 制約を提供するために、受信 SR ノードは外部コントローラまたは PCE に依存している必要がある場合があります。
RSVP TE 例の場合と同じ例を使用して、ノード R1 からノード R6 までの LSP を要求したり、100メガビット/秒を確保したり、blue インターフェイスを通過したりするために、外部コントローラ/PCE がパスを計算しなければならないことがあります。外部 PCE が必要になるのは、SR’が予約を通知するために、帯域幅の制約が指定されているからです。帯域幅が不要な場合、R1 によって実行された分散パス計算は、SR パス計算には十分です。Figure 4は、その結果の SR パスと MPLS 転送テーブルラベルの操作を示しています。SPF SR LSP および以前の RSVP TE Lsp と比較した場合、SR TE LSP のラベル転送オペレーションにかなり大きな違いがあることに注意してください。
SR のナチュラル Sid は、デフォルトで動的に割り当てられます。次の例では、従来の CLI 技術を使用して、パスの各ホップをラベル/SID で指定していることを示しています。ラベルを事前に割り当て、各リンクが固有のラベル/SID を持つようにすることをお勧めします。これは、IP アドレスの処理方法と同様です。’SR TE パスは CLI を介して、従来の IP アドレスをパスで指定されたホップとして使用し、受信ルーターが SID とラベルのスタックを解決できるようにすることもできます。
R1: defining static adjacency SIDs
R1: defining explicit SR tunnels
前述したように、自動翻訳オプションを使用して、パスを RSVP TE パスなどの IP ホップとして説明し、Junos が Sid を変換します。これは、隣接する Sid も静的に構成する必要があることを排除するというメリットがあります。これにより、パスを計算したコントローラが、リンクの移行時にパスを変更する必要がなくなります。
緩やかなホップ、プレフィックス-Sid、およびエニーキャスト Sid
Segment Routing SIDs
セグメント識別子 (SID) は、各セグメントを識別します。ネットワーク事業者は、プライベート IP (RFC 1918) アドレスの割り当てに使用されるプロシージャに類似した手順を使用して Sid を割り当てます。すべての SID は、SR MPLS によって MPLS ラベルにマッピングされています。SR 対応ルーターは、IGP 経由で Sid をアドバタイズします。IGP は、前述の IGP ドメイン全体で前述した TE のリンク属性に加えて、このデータをフラッドします。そのため、IGP ドメイン内の各ノードは、リンク状態データベース (LSDB) と送信されたトラフィックエンジニアリングデータベース (TED) の同一コピーを保持しています。以下のセグメントタイプは最も一般的なものであり、この章では、関連するいくつかの使用事例を説明するために使用されています。
ナチュラル: ナチュラルセグメントは、2つのルーター間の IGP 隣接関係を表します。Junos は、隣接する Sid を動的に割り当てますが、静的に構成することもできます。前述したように、これはいくつかのシナリオでは有用です。
プレフィックス: プレフィックスセグメントは、任意のルーターと指定されたプレフィックスの間の IGP 最小コストのパスを表します。プレフィックスセグメントには、1つまたは複数のルーターホップが含まれています。ノード SID は、プレフィックス SID の一種でもあります。
エニーキャスト: エニィキャストセグメントは、任意のルーターと指定されたプレフィックスの間で IGP 最小コストのパスを表すということで、プレフィックスセグメントと同様になります。ただし、指定されたプレフィックスは、ネットワーク内の複数のポイントからアドバタイズできます。この例では、CLI は、エニーキャスト SID を発表する単一ノードのみを表示します。実際の導入では、エニーキャストグループの一部であるすべてのノードは、同じエニーキャスト SID をアドバタイズします。
バインド: バインドプレフィックスは SR ドメインのトンネルを表します。トンネルには、もう1つの SR Path、LDP シグナル LSP、RSVP TE シグナル LSP、その他のカプセル化があります。
The Critical Role of Maximum SID Depth
最大 SID 深さ (MSD) は、特定のノードに課すことが’できる sid s LSR ハードウェアおよびソフトウェアの数を定義する汎用的な概念です。この機能は、さまざまな IETF OSPF/ISIS/BGP-LS/PCEP ドラフトで定義されています。SR パスが計算される場合、コンピューティングエンティティは、特定の SR パスの各ノードまたはリンクに適用可能な MSD を学習することが重要です。これにより、計算されたパスの SID スタックの深さが、そのノードが課すことができる Sid 数を超えないようにします。
Setting, Reporting, and Advertising MSD
PCEP を使用して LSP の状態報告、制御、プロビジョニングに PCE と通信する場合は、MSD が報告されます。以下の CLI を使用して、報告される MSD 値5を増やすことができます。
このレポート Junos では、制御プレーンプロトコルによってコントローラに MSD することもできますが、ラベルを設定する受信インターフェースでは、ラベルがデフォルト値の3から増加することも要求されます。
SID Depth Reduction
MSD は SR の多くのシナリオにおいて非常に重要な問題であるため、エンドツーエンドのパスを完全に指定する必要はないという考え方が、非常に人気のあるアイデアであると考えられています。前の例では、この CLI は SR-TE LSP (および RSVP TE LSP) の個々のホップを指定しており、「 strict」と呼ばれることもあります。Strict ホップは、指定された LSR を前のホップに直接接続する必要があることを意味します。一方、緩やかなホップはパスが指定された LSR を通過する必要があることを意味しますが、LSR は、最後のホップに直接接続されることはありません。この2つの間に有効なルートを使用できます。の’Figure 5トポロジーを使用した例を見てみましょう。
LSP’を R1 から R6 へと、R3、R4、R5 のルートまで移動したいとしましょう。この目標を達成するには、パスの最初のホップとして R3 を指定してから、通常のルーティングを引き継ぐ必要があります。これは、R1 経由の R3 から R6 へのパスは、IGP メトリックが40である一方、IGP メトリックは30であるためです。SR TE LSP のラベルスタックは、前述の4つに限らず、2つのラベル (R3 の場合はノード SID、R6 の場合はノード sid) のみを表示します。
これを、これまでの例と同じように、静的ルートの MPLS バージョンにすることもできます。静的ルートと同様に、手動で構成されたパスは、明示的な制御が必要な場合に便利です。また、静的ルートと同じように、多数のパスを確立したり、ネットワークを起動または停止するリンクなどの新しいイベントに動的に反応したりする必要がある場合に、管理上の問題が発生します。
パス、RSVP、または SR に対して不要なホップを明示的に設定する場合は、特に注意する必要があります。リンクが失敗すると、予期しない転送動作が発生する可能性があります。たとえば、R1 と’R3 の間のリンクに障害が発生しているとしFigure 6ましょう。SR TE LSP は静的な命令セットであり、パスに指定されたノード SID はまだネットワークで到達可能であるため’、その結果として LSP のパスは最適ではなく、それでも有効です。
Sid のバインドは、にFigure 7示すように、明示的なパスを設定する際にラベルスタックの深さを削減するための別のオプションを表します。同じシンプルな例を使用して、SR-TE LSP を R3 から R5 に作成し、バインド SID によって通知します。これは、R1 から R6 までの入口 LSP がパスでバインドされた SID を参照し、結果のラベルスタックのみを2つの階層にしていることを示しています。
R3 to R5 SR-TE LSP with binding-SID = 2000
And then the SR-TE LSP from R1 to R6 would look like:
エニィキャスト Sid は、SR ネットワークで興味深い転送動作を作成するために使用される別の SID タイプを表しています。エニィキャストグループを構成する複数のノードは、同じプレフィックス SID をアナウンスするため、受信または送信ノードは、IGP メトリックの観点から、プレフィックス SID を発表する最も近い場所に向かって転送されます。これにより、運用担当者は、SR ネットワークに対しては、多少異なる負荷バランスと高可用性のシナリオを実現できます。繰り返しになりますが、でFigure 8示されている’シンプルなネットワークトポロジーを使用すると、R4 と R5 は同じエニーキャスト SID 405 をアナウンスすると仮定しています。R1 から R6 までの受信 LSP を作成して、r1、R2、R5、R6 のパスと R1、R3、R4、R5、R6 のパスの間でコスト負荷を均等に分散させることができるようになりました。
この場合も、エニィキャスト Sid を使用する主な目標ではありませんが、次の SR TE Lsp パスのホップとしてエニィキャスト SID を指定することで、ラベルスタックが削減されました。
受信 LSR がパスを決定するもう1つの方法は、動的に計算することです。OSPF と IS-IS 最短パス (SPF) アルゴリズムを使用してルートを計算するのと同様に、受信 LSR では、「制約された最短パス」 (cspf) と呼ばれる SPF アルゴリズムを変更して、パスを計算できます。次’に動的なパス計算を見てみましょう。
動的なパスの計算とルーティングの制約
ここまでは、SR が提供するさまざまなタイプの Sid を使用して、最短でないパスや明示的なパスを定義するさまざまな方法について見てきましたが、いくつかの特別な考慮事項があります。しかし、数十台、数百、数千、数十の静的な SR パスを定義して管理するのは、拡張性に優れていません。そのため、TE プロセスモデルに戻り、SR TE Lsp パスをどの‘よう’に計算するかを説明するシンプルなルーティング制約を定義する方法を確認する必要があります。つまり、明示的なパスは TE ではなく、TE を有効にする手段として機能します。まず、情報’の配信や状態/トポロジーの監視について見てみましょう。
Link and Node Attributes and Routing Constraints
TE に関する最も重要な要件は、リンクとノードの特性の伝達です。Sid がルーティングドメイン全体で確実にあふれているように、リンクとノードの特性とともに、TE 指向のリソースの可用性も、IGPs の拡張機能を使用して TE のドメイン全体にあふれています。リンク状態ルーティングプロトコルの使用を有効にすることで、ルーティング更新におけるリソースの可用性に関する情報を効率よく伝達できるようになります。これは、リンクステートルーティングプロトコールの拡張機能を追加することによって実現されます。リンク状態ルーティングプロトコルは、リンク状態やメトリックの変化によってネットワークの更新が殺到するだけでなく、TE の視点からの帯域幅の可用性も管理します。これらのリソース属性は、ネットワーク内のルーターのセットによってあふれ、TE トンネル LSP パス計算 (動的トンネル) で使用されるヘッドエンドルーターで利用できるようになります。
リンク状態アナウンスは、特定のルーター’の近隣にアタッチされたネットワーク、ネットワークリソース情報、実際のリソース利用可能性に関するその他の関連情報を記述する情報リストを取得します。これは、制約ベースの SPF 計算を実行するために後で必要となる場合があります。OSPF と IS-IS には、MPLS TE 環境での使用を可能にする拡張機能が用意されています。これにより、リソースの可用性およびダイナミック LSP パスの選択に関する情報を伝搬できます。これらのリンクとノード属性は、リンクカラー、共有リスクリンクグループの関連付け、利用可能帯域幅、およびメトリックタイプ (TE また IGP) を使用していくつかの形式をとります。これらの属性は、コンピューターエンティティで使用されるように TED に用意されています。ここでも、にFigure 9示すシンプルなサンプルトポロジーを使用すると、R5 に次のものが追加されました。
この結果、R5 から R2 へのリンクFigure 9がカラーになっているように見える TE トポロジーが発生します。 blueを追加して、SRLG という名前の common-254また、R5 から R4 へのリンクは色分けされています。 redを指定すると、 te-metricな 100また、同じ SRLG にも追加されています。
ここ’では、R4 への R5’s リンクの内容について説明し、TE 拡張機能を使用して R1 でリンク TE 情報があふれ、どのようにしているかを確認します。これは、パス計算に使用できます。特に、制約の包含や除外などです。
user@R1> show ted database R5.00 extensive To: R4.00(1.1.1.4), Local: 10.1.45.2, Remote: 10.1.45.1 Local interface index: 335, Remoteinterface index: 334 Color: 0x800000 red Metric: 100 IGP metric: 10 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps SRLGs: common-254 P2P Adjacency-SID: IPV4, SID: 299840, Flags: 0x30, Weight: 0 <output truncated>
Distributed SR Constraint-based SPF
通常の SPF 計算プロセスでは、ルーターは、各宛先に対して計算された最短パスを使用してツリーの先頭に配置し、最小のメトリックまたはコストのルートだけを目的として考慮に入れます。この計算において重要な概念は、動的なパスの計算の帯域幅を考慮する必要がないという点です。ルーティングは、他のパスへのリンクに制約を与えます。特定のパスに必要な属性に、リンクカラーなどの IGP コストまたはメトリック以外のパラメーターが含まれている場合、このトポロジでは、この要件を満たしていないリンクを削除することができます。これは、SPF アルゴリズムがリンクコストとリンクの包含/除外の要件の両方を含むパスを返すように制限されます。
CSPF では、リンクコスト以外のものを使用して、TE LSP パスに使用できる可能性のあるパスを特定します。TE LSP パスを設定するために選択したパスの決定は、コンピューティングエンティティで実行されます。さらに、リンクカラーなどの特定の条件に一致しないすべてのリンクを除外してから、 te-costリンクのCSPF 計算の結果は、TE LSP を形成するルーターのネクストホップアドレスにマップされる Sid セットです。そのため、複数の TE Lsp を、CSPF を使用してインスタンス化し、条件を満たすネットワーク内に存在する可能性のあるリンクを特定することができます。
制約ベースの SPF は、制約ベースの計算で管理用ウェイトまたは TE メトリックのいずれかを使用できます。同一の場合、最小帯域幅が最も高いパスが優先され、その後、パスに沿ったホップの数が最小になります。その他のものがすべて等しい場合、CSPF はパスをランダムに選択し、同じものが TE LSP の優先度のパスとして選ばれます。
前述したように、SR パスには、主に MSD および ECMP 属性といういくつかの主要属性が含まれているため、従来の RSVP TE パスとは多少異なる CSPF 結果が求められています。その結果、Junos、分散型 CSPF として実行’しています (外部について説明しています。一元管理された cspfs) は、パスに隣接する一連の sid を提供するだけでなく、特定の入口ルーター’s MSD の MSD を最小限に抑えたり満たしたりすることに加え、そのセグメントリスト内にノード sid を提供することで、候補パスのセットに沿って利用可能なすべての ecmps を活用します。
SR TE 候補パスは、設定されたルーティング制約を満たすように、ローカルに計算されます。CSPF のマルチパス計算結果は、ラベルスタック圧縮が無効になっている場合に、順序づけられた一連の Sid になります。ラベルスタック圧縮が有効になっている場合は、可能な限り、IP のような ecmp 転送動作を提供する一連の圧縮されたラベルスタック (sid およびノードと sid の組み合わせ) があります。
すべての計算結果について、イベント駆動型のアプローチを使用して、現在のネットワークの状態と一貫性のある更新結果をタイムリーに提供します。ただし、多数のネットワークイベントを持つ期間中は、計算に十分な時間がかかっていないかどうかを確認する必要があります。そのため、このアルゴリズムには次のような特性があります。
1つのイベント (リンク障害など) に対する非常に高速な反応
Temporally close の複数の IGP イベントに対する迅速な対応、計算、および結果の消費能力は容認できるものと見なされます。
計算と結果の消費能力の問題が発生した場合の遅延反力
さらに、特定のネットワークイベントへの反応は、ラベルスタック圧縮が有効かどうかによって異なります。以下のイベントについては、圧縮がオフになっている場合、SID リストの候補パスの即時 recomputation は存在しません。
リンクの TE メトリックの変更
リンクダウンイベントは、パスの候補によってリンクが走査されないことを示します。
リンクアップイベント
ラベルスタック圧縮がオンになっている場合、上記のイベントは計算結果が影響を受けるかどうかを確認するために、常に実行されます。
R1: CSPF
この構成では、SR TE の Lsp が、にFigure 11示すように作成されます。
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 2 computed segment : 1 (computed-node-segment): node segment label: 104 router-id: 1.1.1.4 computed segment : 2 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 1 computed segment : 1 (computed-node-segment): node segment label: 100 router-id: 1.1.1.6
出力を見るとわかるように、Junos は、R4 のノード SID のみから構成されるパスを計算して、red path の制約を満たします。さらに、青いパスが最短パスであると判断し、R6 のためにノード SID のみを使用することで、隣接する Sid の絶対パスを計算する必要はありません。その一方で、 no-label-stack-compressionキーワードナチュラル Sid で構成された完全修飾 SID リストの計算方法を確認できます。
Configuration example for R1
Verifying the SR-TE LSPs computed by the Distributed SR CSPF
user@R1# run show spring-traffic-engineering lsp detail Name: sr-te-lsp-to-r6 Tunnel-source: Static configuration To: 1.1.1.6 State: Up Path: 1st-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:red-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 4 computed segment : 1 (computed-adjacency-segment): label: 16 source router-id: 1.1.1.1, destination router-id: 1.1.1.3 source interface-address: 10.1.13.1, destination interface-address: 10.1.13.2 computed segment : 2 (computed-adjacency-segment): label: 18 source router-id: 1.1.1.3, destination router-id: 1.1.1.4 source interface-address: 10.1.34.1, destination interface-address: 10.1.34.2 computed segment : 3 (computed-adjacency-segment): label: 20 source router-id: 1.1.1.4, destination router-id: 1.1.1.5 source interface-address: 10.1.45.1, destination interface-address: 10.1.45.2 computed segment : 4 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2 Path: 2nd-seg-to-r6 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A Compute Status:Enabled , Compute Result:success , Compute-Profile Name:blue-lsp Total number of computed paths: 1 Computed-path-index: 1 BFD status: N/A BFD name: N/A computed segments count: 3 computed segment : 1 (computed-adjacency-segment): label: 19 source router-id: 1.1.1.1, destination router-id: 1.1.1.2 source interface-address: 10.1.12.1, destination interface-address: 10.1.12.2 computed segment : 2 (computed-adjacency-segment): label: 21 source router-id: 1.1.1.2, destination router-id: 1.1.1.5 source interface-address: 10.1.25.1, destination interface-address: 10.1.25.2 computed segment : 3 (computed-adjacency-segment): label: 24 source router-id: 1.1.1.5, destination router-id: 1.1.1.6 source interface-address: 10.1.56.1, destination interface-address: 10.1.56.2
最後に、前述したように、最大 SID の深さは、動的 CSPF で重要な役割を果たし続けています。前の PCEP の例と同様に、特定のコンピューティングプロファイルに対して、最大 SID の深さを設定できます。 maximum-segment-list-depth<value>キーワードをご検討ください。
Configuration example for R1
外部 CSPF 用の一元管理コントローラまたは PCE
SR について説明している場合、コントローラまたは集中型の PCE が存在’しているという前提があるため、Northstar の TE コントローラを SR パスの外部パス計算ソースとしてどのように活用できるかについて簡単に説明します。
BGP Link-state for Topology Discovery
コントローラ (PCE) が任意の種類のパス計算を実行するためには、ネットワーク“トポロジーと同期する必要があります。”ネットワークトポロジは、パスの計算に使用される RSVP TE、リンク状態データベース (LSDB)、またはさらには物理形式であるかのように、トラフィックエンジニアリングデータベース (TED) の形をとることができます。次の例では、BGP-LS を使用して TED を’Juniper s Northstar Controller に伝達する方法を示します。
BGP LS の設定例については、監視の章の「Observability」セクションを参照してください。
PCEP for SR-TE LSP Creation and Control
コントローラが必要としている次の情報は、学習するか、SR TE LSP 状態を作成できるようにすることです。次の設定例では、パス計算クライアント (PCC)、受信ルーター、およびコントローラ間のパス計算要素プロトコル (PCEP) セッションを示しています。Figure 13は、PCEP セッションのパラメーターを示しています。
ここで’は、SR 固有の SID タイプのいくつかにお問い合わせし‘、’コントローラについて説明し、それをどのように発表するかをご紹介します。
エニィキャスト Sid は、LSDB の際に IGP SR 拡張機能によって通知され、1組の lo 0.0 アドレスの作成と、そのためのプレフィックスとしての SID のアナウンスを行います。次の例では、ノード p1. nyc と nyc からエニィキャスト SID 123 をアナウンスしています。
Announcing anycast SIDs from p1.nyc and p2.nyc
Verifying on pe1.nyc
user@pe1.nyc> show isis database p2.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3 user@pe1.nyc> show isis database p1.nyc.00-00 extensive | match “1.1.2.3|123” IP prefix: 1.1.2.3/32 Metric: 0 Internal Up IP prefix: 1.1.2.3/32, Internal, Metric: default 0, Up IP extended prefix: 1.1.2.3/32 metric 0 up Prefix SID, Flags: 0x00(R:0,N:0,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 123 IP address: 1.1.2.3
エニィキャスト SID は、Northstar の GUI でノードプロパティとして認識され、その’後、SR-TE LSP を作成する際に、厳密なホップまたは緩んとして選択できます (多くの場合は、緩いホップになります)。バインド Sid は SR TE LSP に追加され、PCE プロトコルをFigure 14介して Northstar に通知されるようになりました。
Creating a Core SR-TE LSP with a binding SID
Verifying the core LSP on P1.NYC
user@p1.nyc# run show spring-traffic-engineering lsp detail Name: P1NYC-2-P1IAD Tunnel-source: Static configuration To: 128.49.106.9 State: Up Telemetry statistics: Sensor-name: ingress-P1NYC-2-P1IAD, Id: 3758096386 Sensor-name: transit-P1NYC-2-P1IAD, Id: 3758096387 Path: P1NYC-2-P1IAD Outgoing interface: ge-0/0/4.0 Auto-translate status: Enabled Auto-translate result: Success BFD status: N/A BFD name: N/A SR-ERO hop count: 2 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.15 SID type: 20-bit label, Value: 94 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 0.0.0.0 -> 192.0.2.26 SID type: 20-bit label, Value: 51 Total displayed LSPs: 1 (Up: 1, Down: 0)
Verifying the routing table on p1.nyc
user@p1.nyc# run show route protocol spring-te inet.0: 49 destinations, 60 routes (46 active, 0 holddown, 3 hidden) inet.3: 11 destinations, 15 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.9/32 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Push 1009 to 192.0.2.13 via ge-0/0/1.0, Push 1009, Push 1008(top) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 62 destinations, 62 routes (62 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1000001 *[SPRING-TE/8] 00:02:45, metric 1, metric2 20 > to 192.0.2.21 via ge-0/0/5.0, Swap 1009 to 192.0.2.13 via ge-0/0/1.0, Swap 1009, Push 1008(top)
Verifying binding SIDs on the Northstar TE Controller
バインド Sid を確認するには、LSP のプロパティを使用するか、[トンネル] タブにバインド SID 列を追加します。
ここまで、TE のさまざまな側面、SR 固有の SID タイプのいくつか、基本的な情報とコントローラとの同期方法について’説明したところで、これまでの章のサンプルネットワークに戻って、ソリューション全体をまとめましょう。
エンドツーエンドの TE ソリューション
サンプルネットワークをセグメントルーティングに移行する際の主要な目標の1つは、 “帯域幅最適化” (TE) をコアレベル 2 ISIS ドメインに複製することです。現在のところ、自動帯域幅 RSVP TE lsp は、パス帯域幅の最適化によって比較的きめ細かな情報を提供します。SR は LSP の状態、したがって、LSP ごとの統計を維持しないため、SR ネットワークの帯域幅最適化ソリューションでは、Observabilityの章で説明されているように、他のソースからのデータを取得するために、コントローラが RSVP TE が持つもう1つの形式のソリューションを終了する必要があります。
’最初に、pe1 lsp (を参照Table 1) のメッシュを、Nyc と iad PoP 内のすべての pe TE の間で作成します。これらの Lsp は、ephemerally の PCE プロトコルを使用して、Northstar Controller がそれぞれのパスを明示的に制御できるように作成されます。
Table 1: SR TE LSP メッシュ
LSP 名 | 受信ルーター | 送信ルーター |
|---|---|---|
pe1.nyc-pe1.iad | pe1.nyc | pe1.iad |
pe1.nyc-pe2.iad | pe1.nyc | pe2.iad |
pe1.nyc-pe3.iad | pe1.nyc | pe3.iad |
pe1.iad-pe1.nyc | pe1.iad | pe1.nyc |
pe2.iad-pe1.nyc | pe2.iad | pe1.nyc |
pe3.iad-pe1.nyc | pe3.iad | pe1.nyc |
Northstar コントローラに対して SR TE LSP を作成するには、[アプリケーション > プロビジョニング LSP] ドロップダウンオプションまたは [トンネル] タブをクリックします。にFigure 16示すように、ポップアップウィンドウが表示されます。 LSP の属性を追加します。SR TE Lsp を作成する際の重要な属性として、公称‘計画帯域’幅値を提供することが挙げられます。これは、後で説明するように、定期的な再最適化、または再最適化のトリガーによって、’Northstar s cspf でリンク渋滞の認識を考慮することができるようにするためです。
この執筆時点では、SR ポリシー受信統計 (Northstar Controller) は利用できませんでした。今後、各 SR TE LSP に割り当てられた静的な10k 帯域幅は、動的でリアルタイムのデータプレーン統計値に置き換えることができるので、よりきめ細かな帯域幅最適化を実現できます。
結果として得られる SR TE LSP Figure 17メッシュは、に示しています。メッシュによってどのリンクが走査されているかを確認できます。
受信 PCC の観点から見ると、次の3つの SR TE Lsp がコントローラ (PCE) 経由で通知されていることがわかります。
user@pe1.nyc> show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Path-Setup-Type pe1.nyc-pe1.iad Primary(Act) 10 ext-provised NS1 spring-te pe1.nyc-pe2.iad Primary(Act) 11 ext-provised NS1 spring-te pe1.nyc-pe3.iad Primary(Act) 12 ext-provised NS1 spring-te
また、それぞれが pe1 の inet にインストールされています。 nyc の3つのリブ:
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
Northstar Controller GUI を使用して各 SR TE LSP のラベルスタックを検証するには、『 Figure 18The The Record Route」および ero 列に示すように表示されます。また、トポロジのナチュラル sid を表示することもできます。
Junos 入口ルーター’の SR-TE LSP の詳細出力からわかるように、ラベルスタックは一致します。この’ことは、PCEP NAI (ノードまたはナチュラル id) フィールドの IP アドレスが出力インターフェイスの選択に使用されるため、実際 TE にはパケットには最初のラベル (17 インチ) が適用されていないことに注目しておく必要があります。これは次の出力に示されています。
Detailed SR-TE LSP output:
user@pe1.nyc> show spring-traffic-engineering lsp detail Name: pe1.nyc-pe1.iad Tunnel-source: Path computation element protocol(PCEP) To: 128.49.106.11 State: Up Telemetry statistics: Sensor-name: ingress-pe1.nyc-pe1.iad, Id: 3758096391 Outgoing interface: NA Auto-translate status: Disabled Auto-translate result: N/A BFD status: N/A BFD name: N/A SR-ERO hop count: 4 Hop 1 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.6 -> 192.0.2.7 SID type: 20-bit label, Value: 17 Hop 2 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.22 -> 192.0.2.23 SID type: 20-bit label, Value: 18 Hop 3 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.33 -> 192.0.2.32 SID type: 20-bit label, Value: 20 Hop 4 (Strict): NAI: IPv4 Adjacency ID, 192.0.2.39 -> 192.0.2.38 SID type: 20-bit label, Value: 28
JUNOS inet.3 RIB entry for the SR-TE LSPs:
user@pe1.nyc# run show route protocol spring-te table inet.3 inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:06:23, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 18, Push 22(top) 128.49.106.11/32 [SPRING-TE/8] 1d 00:38:38, metric 1, metric2 0 > to 192.0.2.7 via ge-0/0/2.0, Push 28, Push 20, Push 18(top) 128.49.106.13/32 *[SPRING-TE/8] 00:05:30, metric 1, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 20, Push 26(top)
このサンプルネットワークでは、CE ルーターの接続に複数のサービスを提供しています。Ce1 からは、pe1. nyc と pe2 の間のトランスポート SR TE Lsp のラベルスタックが表示されます。
user@ce1.nyc> traceroute 198.51.100.60 traceroute to 198.51.100.60 (198.51.100.60), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 3.008 ms 1.918 ms 1.972 ms 2 p1.nyc-ge-0-0-2.0 (192.0.2.5) 12.785 ms 9.685 ms 24.882 ms MPLS Label=22 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=1 S=1 3 p1.ewr-ge-0-0-2.0 (192.0.2.15) 8.927 ms 14.411 ms 8.648 ms MPLS Label=18 CoS=0 TTL=1 S=0 MPLS Label=18 CoS=0 TTL=2 S=1 4 p1.iad-ge-0-0-6.0 (192.0.2.26) 9.039 ms 8.564 ms 10.233 ms MPLS Label=18 CoS=0 TTL=1 S=1 5 pe2.iad-ge-0-0-1.0 (192.0.2.40) 7.857 ms 7.481 ms 17.570 ms 6 ce1.iad-ge-0-0-7.0 (198.51.100.60) 8.767 ms 13.242 ms 15.533 ms user@ce1.nyc> ping 198.51.100.54 rapid count 100000000 size 500 PING 198.51.100.54 (198.51.100.54): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
Northstar Controller’を使用して、IS-IS レベル2のドメインに帯域幅最適化サービスを提供する方法についてご紹介しましょう。元のコアネットワークは、RSVP TE の自動帯域幅 Lsp をベースに構築されています。これらは動的に適応し、トラフィック速度の増大と減少に対応します。現在、セグメントルーティングには同等の機能がありません。これは、主に、LSP の状態が不十分であるためです。Northstar Controller の属性を有効にすると、インターフェイスの輻輳に対応して、入口統計の収集だけに基づいて TE SR-最適化を開始することができます。Northstar Controller のこの機能を有効にするには、管理者 > Analytics に移動し、に示すFigure 20ように再ルーティング機能をオンにします。
トポロジーにリアルタイムインターフェイスの統計情報も表示されるようにするには、GUI の左側にあるドロップダウンボックスを使用します。にFigure 21示すように、パフォーマンスを選択し、インターフェイスの使用を有効にします。
ネットワーク上のトラフィックをシミュレートするために、コントローラ’が pe1 lsp を輻輳リンクから再 TE ルートする機能を示すために’、nyc と p1 の間に大量のパケットサイズを使用していくつかの拡張 ping を開始しましょう。 iad:
user@pe1.nyc> traceroute 192.0.2.26 traceroute to 192.0.2.26 (192.0.2.26), 30 hops max, 40 byte packets 1 p1.nyc-ge-0-0-2.0 (192.0.2.5) 3.569 ms 2.412 ms 3.261 ms 2 p1.ewr-ge-0-0-2.0 (192.0.2.15) 6.769 ms 3.793 ms 3.152 ms 3 p1.iad-ge-0-0-6.0 (192.0.2.26) 6.040 ms 5.814 ms 5.074 ms user@pe1.nyc> ping rapid 192.0.2.26 count 100000000 size 500 PING 192.0.2.26 (192.0.2.26): 500 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
他の方向にも同様…
user@p1.iad> traceroute 128.49.106.1 traceroute to 128.49.106.1 (128.49.106.1), 30 hops max, 40 byte packets 1 p1.phl-ge-0-0-3.0 (192.0.2.31) 2.637 ms 2.077 ms 2.322 ms 2 p1.nyc-ge-0-0-5.0 (192.0.2.20) 3.493 ms 5.646 ms 3.116 ms 3 pe1.nyc-lo0.0 (128.49.106.1) 7.056 ms 5.973 ms 7.435 ms user@p1.iad> ping 128.49.106.1 rapid count 10000000 size 1000 PING 128.49.106.1 (128.49.106.1): 1000 data bytes !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [output truncated]
でFigure 22は、Northstar がリンクの輻輳を検知し、パスの再最適化をトリガーして、SR TE lsp を輻輳リンクから再ルーティングしています。
左パネルで [タイムライン] を選択すると、 Figure 23インターフェイス輻輳しきい値を基にしたリンク輻輳が検出され、輻輳リンクを通過した lsp が再ルーティングの対象としてスケジュールされていることがわかります。
Northstar’s トポロジ > トンネルビューに戻ると、pe1 と pe2 の間で SR-TE LSP を見ることができます。i ad がFigure 24あります。LSP は現在、輻輳リンクを回避した新しいパスにあることがわかります。
また、入口ルーター’の SR TE LSP も更新されています。
user@pe1.nyc> show route table inet.3 protocol spring-te inet.3: 8 destinations, 12 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.10/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 18, Push 20, Push 26(top) 128.49.106.11/32 [SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 28, Push 18, Push 22(top) 128.49.106.13/32 *[SPRING-TE/8] 00:00:07, metric 5, metric2 0 > to 192.0.2.5 via ge-0/0/1.0, Push 20, Push 18, Push 22(top)
トラフィックエンジニアリングは、ほとんどのバックボーンワイドエリアネットワークに不可欠な機能です。最新の TE の主な目的は、リソースの利用を最適化することです。RSVP-TE は、長い歴史と大規模なツールボックスを利用していますが、SR は、リソースの利用率を高めるために、ストリーミングテレメトリやコントローラなどの新しいツールを活用する必要があります。この章では、明示的なパス、さまざまな形式の分散および集中型パス計算、そして最後にサンプルネットワークを SR TE にどのように移行するかについて、SR 固有のオプションをいくつか紹介しました。従来の RSVP TE の帯域幅最適化ソリューションは大きく異なりますが、インターフェイスの輻輳に対応して、リソース最適化の概算に対応する手段を提供することができます。