相互運用性

SR と LDP の相互動作

新しいニューヨークで SR 接頭辞 Sid が推奨されていても、LDP はすべてのルーターのラベルを継続的に配布しています。SR を通じて、より高い優先度を提供するのは、LDP –経由で学習したルートが競合している場合にのみ有効です。ニューヨークのルーターが ldp によって提供されたラベルを持っている場合、その宛先へのトラフィックは非セグメントルーティングのままです。LDP を無効にすることを計画している場合は、LDP のように、すべての時点で連続したFigure 1ラベル付きパスを維持する必要があります ()。この問題は、SR から LDP まで、さらには LDP から SR までの方向性においても重要です。

Figure 1: LDP のエッジ (IS-IS L1 エリア)、および Core (IS-IS L2 サブドメイン) での RSVP TE メッシュ

SR-to-LDP

SR には、SID からすべてのルーターにアクセスできることが求められています。ネットワークのほとんどは、正面にはありません。リモートルーターは、まだ SR を実行していないため、プレフィックス Sid はありません。ニューヨークで LDP を排除し、地域外には連続した LSP が存在しないということです。明らかに、プレフィックス Sid を非 SR 対応ルーターに間接的に関連付けるメカニズムを必要としています。

SR マッピングサーバー (srms) は、単なる制御プレーン機能です。非 SR に対応するために、接頭辞の Sid をアドバタイズします。これまでに期待していたように、これにより、SR スピーカーが消費し、それ以外の場合は無視する、さらに IS-IS を追加することになります。SR ルーターは、ネイティブプレフィックス Sid を inet. 3 にインストールするのと同様に、マッピングサーバーから学習したプレフィックス Sid をインストールします。

すべてのプロキシと同様に、SRMS は高可用性でなければなりません– 。また、disseminated の情報は、srms として複数のルーターを構成することによって実現されています。マッピングの一貫性は、テンプレート設定の生成、バージョン管理された構成リポジトリ、意図しない変更を迅速にロールバックする機能など、最新の運用上のベストプラクティスに従って、aspirational の成果となります。

SRMS は、SID マッピングへのプレフィックスをアドバタイズするためにのみ存在します。そのプレフィックス自体は SRMS でアクセスできないことがあります。実際には、プレフィックスは完全には到達できない場合があります。もちろん、架空のプレフィックスのアドバタイズ SID マッピングは構成ミスと見なされるため、標準の変更レビュープロセス制御を有効にして、不正’なマッピングが有効でないことを確認する必要があります。

サーバーのアナログはクライアントです。マッピングサーバーが sway を保持するには、マッピングクライアント (SRMC) が存在している必要があります。ほとんどのプロトコルとは異なります。 SR マッピングクライアント’とサーバーは、互いに独立した制御プレーンの関係を形成しません。その代わりに、クライアントは、アドバタイズされたマッピングを使用するだけです。SRMS は、サーバーだけでなく、クライアントとも同時に使用できます。

Bordering 両方のドメインのルーターは、LDP でルーティングされたセグメントをつなぎ合わせる責任があります。境界ルーターは SR と LDP の両方を読み上げています。マッピングを受信すると、mpls の同じ FEC について LDP から学習したエントリに切り替えるための、受信ノード SID のラベルスワップエントリーが作成されます。0テーブル。

このガイド’ネットワークでは、nyc と nyc の両方がボーダールーターとして機能します。まず、SRMS を設定する方が直感的ですが、接続が中断する可能性があります。ニューヨークのルーターは SR を優先しているため、ワシントン FECs の SR マッピングエントリを学習することで、supplant の既存の LDP が’学習したラベルを PE の inet. 3 テーブルに即座に反映させることができます。SR から LDP への対応が明示的に行われていない場合、pe1 と pe2. nyc が長距離トラフィックに対して SR を使用しようとすると、p1 でトラフィックが破棄されます。 nyc と p2 によって、mpls. 0 テーブルの nyc とイン SR ラベルに対応するアクションがありません。

Enabling SR to LDP Stitching

Nyc’と nyc の両方を、SR/LDP 翻訳者として機能する、ボーダールーターとして設定しましょう。

それでも、動作を転送するように変更する必要はありません。

Connectivity verification: cross-country traffic still uses LDP labels

ここでは、nyc と nyc の両方が、SRMS からのマッピングエントリを待機しています。開始するために、nyc は最初の SRMS として設定されます。これにより、ワシントン州の PEs へのマッピングが通知されます。SR に対応したルーターはすべて SRMS –として動作することができます。トポロジーの配置は重要ではありません。厳密に真実ではない比較を BGP ルートリフレクタで行うことができます (大規模なトポロジでは、賢くルートリフレクタの配置、または最適なルートリフレクションの使用が必要になります)。

ポリシーは、プロトコルに依存しない構成セクションに作成されます。このポリシーは、プロトコル固有の階層の下で参照されるため、nyc を使用 IS-IS した SRMS として機能することができます。

Tease’では、この構成を分離してみましょう。ポリシー名は、ローカルの問題です。そこで、128.49.106.10 (pe1 の iad’s ルーター id) から始まる4つの IPv4 プレフィックスの範囲を含むマッピングエントリを広告しています。

これは、nyc’s IS-IS LSP として、1つのラベルバインドとして効率的にエンコードされます。次回の検証では、 Rangesize キーワードに対応しています。IPv4 プレフィックスは、先頭のプレフィックスとなります。次のように構成されています start-indexとして表され Value。

Control plane: verify p1.nyc is acting as an SRMS

Inet で得られたエントリ。 SRMC の3つのテーブルTable 1は、その中のものでなければなりません。

Forwarding plane: verify pe1.nyc prefers SR to LDP

ご覧のように、nyc から新たに学習した SR プレフィックス Sid を使用することで、LDP ルートは無視されました。 SRMS として機能しています。Nyc は、nyc または p2 から得られた LDP ラベルを以前にプッシュしています。 pe2 は、1000から始まる、よく知られた SR ラベルを使用しています。

Crux では、このような着信ラベルを受信した場合、nyc と p2 が実行されます。これらは境界ルーターであるため、マップサーバー派生ラベルを LDP から学習したラベルに交換する必要があります。具体的には、境界ルーターは同じ FEC に関連付けられた出力ラベルスタックのイン SR ラベルを交換する必要があります。この重要なステップがなければ、連続していないラベルスイッチパスを使用することになります。

まず’p1 をメモしておきましょう。’nyc の送信ラベルは p1 に向かっています。’iad とそれが LDP によってどのように学習されているかについて説明します。

Forwarding plane: verify p1.nyc’s outgoing label stack for p1.iad’s FEC

MPLS の Lsp は再帰的に行うことができるため、これは明らかにトンネリングの場合です。ラベル17は p1 から学習され’ています。 NYC の LDP 近隣から、この FEC に向かっている次のホップを選択しています。その近傍は p1 だということです。つまり、LDP セッションをトンネリングした RSVP LSP を介して到達できます。

Control plane: verify how p1.nyc created the label stack to reach p1.iads

この出力を基にして、nyc は、18 on on (RSVP LSP としてエクスポートされています) という、着信ラベル1011を 17 (SR から LDP ステッチ) に交換することを前提としています。

Forwarding plane: confirm p1.nyc swaps the SR label for the LDP/RSVP combination

Voilá! Inet の FEC のラベルと mpls 内の対応するラベルの両方を示しています。0は同じです。Pe1 は、pe1 に宛てられたトラフィックに対してラベル 1011 (および nyc) をプッシュしたときに、LDP ラベル (RSVP ラベルが次にプッシュされたことになります) としています。

重要なのは、従来のラベル配信プロトコル、namesake LDP、強力な RSVP といった、共存の SR の優れた機能です。

もう’1 つの長距離 traceroute を実行してみましょう。Pe1 と nyc が pe1 の SRMS アドバタイズマッピングを使用していることを確認する必要があります。もちろん、他のニューヨーク以外のルーターと同様に、pe1 は SR-oblivious を維持しています。

Connectivity verification: pe2.nyc now pushes SR label 1011, instead of the earlier LDP-learned label

Remiss は、ニューヨーク間のトラフィック’に対して予期される変更がないことを検証していない場合に有効です。

Connectivity verification: traffic within New York continues to use SR

たいへん良い。以前の traceroutes の変更はありません。

先へ進む前’に、nyc を2つ目のマッピングサーバーとして構成することにより、srms の冗長性の欠如に対処してみましょう。これは p1 と同じように設定することができます。 nyc:

Control plane: p2.nyc also originates a label-binding SID with the same mapping as p1.nyc

転送動作は変更されていません。Nyc が使用できなくなると、p2 からのマッピングが引き続き代理ノード Sid として表示されます。

SRMS エントリの設定方法を理解するために、この設定を’p2 から削除してみましょう。代わりに、個々のプレフィックスエントリを追加してから、IS-IS LSP でエンコード方法が異なることを調査しています。同じ転送動作につながります。

範囲ではなく、個々のプレフィックスに対するマッピングが作成されました。現在のネットワークの一部ではないプレフィックス’(128.49.106.12) を扱っている範囲とは異なり、このフォームは非連続のマッピングを可能にします。ご想像のとおり、p2 では個別に TLVs 使用する’必要があります。 nyc s IS-IS PDU です。

Control plane: p2.nyc now has multiple label binding TLVs

単一の TLV が登場するまで、すべてのワシントン’の pe ルーター (および無関係のエントリ) にマッピングが提供されるようになったときには、各 pe で 3 tlvs 1 を見つけられるようになりました。プレフィックスが連続していない場合は、このフォームが必要になります。どちらのアプローチにも、独自の検討事項があることに注意してください。

• この情報を最もコンパクトに配信する方法は、プレフィックス範囲です。その範囲は、SRMS サービスを必要としているかどうかについて、広範囲に対応している場合があります。

• 複数のラベルバインド TLVs、より正確なのですが、大量の IGP Pdu をリードしています。

当然、どちらのアプローチも、便宜的–にアドレス指定ができたときに、範囲を同時に使用することが可能です。

Conflict Resolution

この’ハイブリッドアプローチを、NYC から SR 対応ノード–に対するアイデアとして、さらに詳しく見てみましょう。Nyc SRMS は、ワシントンルーターの各エントリを継続的に通知し、ニューヨークルーターを対象とする範囲を追加します。その目的は、これによって混乱や害が生じているかどうかを把握することです。

Pe2 の nyc’s ルーター id (128.49.106.0) で始まる既存のエントリは、範囲によってさらに拡張されていることがわかります。Pe2 はすでにノードインデックスをアドバタイズしており、そのインデックスは SRMS purports のものと一致しているため、転送動作に変化はありません。

Control plane: p2.nyc is advertising ranges for both SR-capable and incapable routers

この練習では、個々の範囲とプレフィックスの両方を組み合わせて使用できるようにしています。損害を与えることなく、この設定は運用上のベストプラクティスではありません。Landmine の無償広告による目標を実現することは、最善で混乱があり、最悪の場合、将来のソフトウェアの行動や標準仕様の変更に対応することができません。

不要なプレフィックスセグメント範囲を削除します。

LDP-to-SR

すべてのニューヨークのルーターで LDP を必要としているのを排除しましたか? SR ノード Sid を使用して相互に到達できるようになります。ワシントンの PE ルーターのために、合成ノードの Sid をさらに学習しています。LDP は依然として必要ですか? 最後のステップの後、PEs を使用して実行します。

ワシントンのルーターは、LDP を通じてニューヨークの FECs について学習していることに注意してください。Nyc および nyc で発行された RSVP Lsp にトンネリングし、p1 で終了します。 iad と p2. iad. このよう’なルーターで LDP は、連続する LSP を壊さずにオフにすることができます。

Pe1 の nyc と pe2 で LDP を無効にすることができます。まず’、LDP 経由でワシントンルーターにラベルを伝え続ける方法を考えてみましょう。P および PE ルーター間の LDP セッションは削除されるため、P ルーターは、PEs によって LDP ラベルが発行されるように設定する必要があります。

これは SRMS と同じアイデアであり、proverbial のように感じています。SR を使用できないため、接頭辞の Sid を広告するのではなく、LDP-averse のプロキシ FEC マッピングを提供する必要があります。

変更を行う前に’、pe2 が nyc によって提供される LDP ラベルがあることを確認してみましょう。 nyc をお届けします。

Control plane: p2.nyc is advertising label 56 to its LDP neighbors

Forwarding plane: p2.nyc pops label 56 as its performing PHP to pe2.nyc

Connectivity verification: traffic from Washington to pe2.nyc uses label 56

Enabling LDP to SR Stitching

では’、LDP で SR を nyc にして、宣伝用のラベルを変更してみましょう。

Control plane: p2.nyc allocates new LDP label 59, withdrawing label 56

Control plane: LDP-to-SR stitching functionality is enabled

Forwarding plane: label 59 is swapped with 0 as pe2.nyc requests SR UHP treatment

Connectivity verification: label 59 is now in use by p2.nyc’s LDP neighbors to reach pe2.nyc

Ldp sr の–マッピングクライアント’を有効にするには、ldp からSR へのつなぎ –方と p1 にも準拠しています。 nyc は、ニューヨークに複数のパスがあることを確認しています。そして、pe1 の nyc と pe2 の両方で、LDP を無効にすることができます。今後、LDP ラベルを自分で宣伝することはなくなりますが、nyc と nyc は、にFigure 2示すようにそのまま続行します。

Figure 2: 新しい、ニューヨークのルーターで LDP を排除

この状態で、必要に応じて持続することができます。これは、ニューヨークを越えたルーターが近い将来には SR に対応していない場合の、正当な運用モードである可能性があります。ネットワークの一部で不適切なハードウェアまたはソフトウェア機能が必要になるのは、SR の導入を妨げることではありません。適切に計画され、変更が必要になった場合は、すべてのプラットフォームがセグメントルーティングに同時に変換することを必要とするビッグバンイベントである必要はありません。

SR と RSVP-TE

ここでは、ニューヨークとワシントン州の P ルーター間に LDP トンネリング用 RSVP-TE Lsp のフルメッシュが存在することについて簡単に触れました。前のセクションの最後に、pe1 の nyc と pe2 から LDP が排除されました。しかし、nyc、p2. nyc、およびそのワシントン州で LDP は使用されたままになっています。

Interworking: SR over RSVP-TE

私’たちはニューヨークで wrought が行った変更をミラーリングすることで、次のようなことを進めることができます。

1. すべてのワシントンルーターでの SR を有効にします。

2. ワシントン PEs で SR から LDP を希望しています。

受信したルーターすべてが SR に切り替わったら、最後に LDP を根絶できます。この例では、にFigure 3示すように、nyc と p2 に設定されている SRMS および LDP SR マッピングクライアントが含まれています。

Figure 3: すべてのルーターで LDP を排除

プレフィックス SID 計画の重要性を overstated することはできません。ニューヨークルーターは、SRMS のペアを通じてこれらを学習します。ネイティブノード SID の設定では、同一の値を維持する必要があります。実際、SRGB サイジング、オフセット、SID の計画は、セグメントルーティングの導入を成功させるために不可欠です。使用事例を注意深く検討することなく、ライブ導入に新旧したり、同一、一貫してサイズが設定された SRGB を使用するための、同機種の機器の能力を活用したりする必要があります。

また、ワシントン州での SR 機能を有効にする順序についても注意する必要があります。P ルーターで初めて有効にすると、接続が中断します。これは、nyc と p2. nyc は、ワシントン州の近隣が突然 SR に対応していることを確認します。Pe1 の nyc と pe2 に提供している SRMS ラベルのスワップを停止し、LDP ラベルは RSVP TE LSP で学習されます。SR から LDP への対応機能は不要と見なされます。

その代わりに、すべてのワシントン Pe で SR が最初に有効になります。

中断’が発生していないことを確認してみましょう。

Connectivity verification: traffic forwarding within New York is unchanged

Connectivity verification: traffic forwarding cross-country is unchanged

変更は適切ではありません (この場合)。ワシントン州は独立したレベル1の領域で、L1/L2 P ルーターはまだ SR が有効になっていません。Unabated は、SR から LDP へと進み続けています。この瞬間は p1 で有効になっています。 iad と p2 は、moot に必要なものになります。

これはご紹介のように思えますが、つなぎ方を決定するにはどうすればよいかを考える価値があります。近隣’が sr 機能を提供していない場合、nyc と NYC は LDP の sr ラベルとスワップ merrily ます。当社のネットワークでは、今後も RSVP TE LSP ラベルを追加しています。

その後 p1. iad (または p2. iad) がノード SID で構成されている場合は、nyc と nyc の両方が最新の IS-IS レベル 2 LSP を確認します。そのため、SR から LDP への対応については、p1 を使用していることが明らかになります。 iad (または p2 ad) は SR ネイティブラベルを転送できるようになります。

このことは、そのままではありません。’最初に SR に対応していないワシントン P ルーターが料金を削減します。これにより、すべての地域間トラフィックがセグメントルーティングされます。そのため、SR over RSVP TE を示すように、RSVP TE Lsp を引き継ぐことができます。

さらに、’P2 で SR を有効にします。 iad とオーバーロード p1. iad:

これにより、ワシントンバウンドのすべてのトラフィックが p2 から強制的に実行されます。

Connectivity verification: traffic forwarding to Washington is no longer multi-pathed

Connectivity verification: traffic forwarding within New York remains unaffected

Forwarding plane: both New York P routers swap the inbound SR label for LDP-o-RSVP

この出力は、両方のルーターが22に1011をスワップしていることを示しています。 iad ad は、、p2 によって提供される LDP ラベルですRSVP-TE LSP ラベルがプッシュされます。2つの等しくないコストパスがあり、後者は RSVP TE バイパスを表しています。

SR is then enabled on p2.iad:

NY P ルーターは、p1 を回避し続けています。 iad. そして LDP ラベルを1011スワップするのではなく、次の SR 命令と交換するだけです。これは、 continueアクションであるように動作し、1011は1011にスワップされます。

Forwarding plane: both New York P routers now swap the inbound SR label for another SR label

RSVP TE LSP プッシュラベル’が変更されないことに注意してください。SR と LDP 間でつなぎ付けなくなった一番下のラベルです。接続’が維持されるようになり、SR が RSVP TE コア間で適切に行われていることを確認しましょう。

Connectivity verification: no change within New York as expected

Connectivity verification: outside New York, SR labels are carried all the way until pe1.iad, not just the L1/L2

これは、今までにないほど SR を使用していたよりも遠くに離れています。今までは、つなぎと LDP トンネリングの複雑な相互作用により、追加の明示的な設定なしで、RSVP TE Lsp 全体で SR トラフィックを転送することが許可されていました。

すでに学んだように、インテントを明示的にすることは、noble の目標と運用上のベストプラクティスのどちらにもなります。プラットフォームのデフォルトは、それ自体よりも悪い時代になっています。運用担当者が少なくとも、orthodox –の行動によって– 、より信頼性の高いネットワークの時代遅れを実現しています。Explicating は、自己文書化のほか、プラットフォーム、ソフトウェアリリース、およびそれらの責任者間の一貫性を適用する方法の両方を備えています。

RSVP’TE lsp を明示的に実行するように SR を設定することで、これを修正してみましょう。これは即座に変更されることはありませんが、LDP が削除されると、確実に接続を維持できます。ニューヨークとワシントンの両方の P ルーターで SR を’有効にしましょう shortcuts:

Connectivity verification: no change in either traffic flow

今も残っているのは、LDP (SRMS and ステッチを含む) をニューヨークの P ルーター、ならびに、RSVP TE Lsp に対して LDP トンネリングも含めて、p1 の SR を有効にし、それを運用に導入することです。

これらの手順については、すでに dissected し、詳細に説明しています。’Belabored する必要はありません。これが完了すると、LDP を SR に置き換えることになっています。セグメントルーティングアーキテクチャが、MPLS ラベル分散プロトコルにどのように適合しているかをご覧いただいてきました。

Connectivity verification: complete reachability intra- and inter-region using SR

SR がトラフィックのエンジニアリングコアから正常に転送さ’れた場合は、その事実を書き留め、それでも永久的な運用モードになっていることを確認してみましょう。マルチパスの可能性は、SR が導入されている地域内に大きくなっています。マルチパスが領域––間などで劣化している場合、RSVP-TE が実行されます。この2つは、perennially を共存させることができます。

私たちの目的においては、L2 サブドメイン全体で SR を有効にすることについては何もありません。この設定は前の例と同様であり、繰り返し行う必要はありません。内部作業を示す目標を達成したため、ニューヨーク’とワシントンの p1 と p2 の間で RSVP TE lsp を撤去して、すべてのトラフィックが SR を使用して完全に転送されるようにしてみましょう。

Coexistence: SR-aware Bandwidth Reservation with RSVP-TE

RSVP-TE は、驚異的な機能セットを備えており、数十の実世界の運用経験を蓄積しています。特に有名で広く使用されている機能の1つは auto-bandwidth: 提供されているトラフィック負荷に合わせて、Lsp を変更したり、再ルーティングしたりすることがあります。Cleaved の自動帯域幅は、手動で入力しなくても、初期構成パラメーターを保存し、最適なパスを使用することで、ほぼわずか魔法のように表示されます。

Grossly の自動帯域幅は、次の2つの値に依存しています。LSP 予約サイズ、およびネットワーク内の特定のインターフェイスで利用可能な帯域幅。1つ目は、LSP 受信ルーターによって算出され、定期的なレート測定を使用して、間隔を滑らかにしたものです。Disseminated は、すべてのルーターが帯域幅を消費したり解放したりすることで、IGP 領域で使用されています。この2つは、分散自動帯域幅計算を推進するフィードバックループを形成しています。

このスイスでの暗黙的なクロックワーク数十年は、RSVP-TE がトラフィックを転送するためだけに使用されることを前提としています。利用可能なインターフェイス帯域幅は TED (トラフィックエンジニアリングデータベース) に格納されています。この場合、使用率スナップショットは RSVP TE によってのみ設定されます。このインターフェイスにも非 RSVP TE のトラフィックが割り当てられている場合、1つの待ち構え間に合わせは RSVP TE reservable 帯域幅を’インターフェイスの容量の割合に上限として機能します。これにより、RSVP TE Lsp は、非 MPLS トラフィックなど、帯域幅の他のユーザーとの競合を回避して、使用率のあるリンクを犠牲にすることができます。

当社のネットワークでは、SR TE とともに、帯域幅の消費者を MPLS しています。この2つを共存させるためには、完全な移行が行われるまでは、SR トラフィックの使用率’を TED s の最大 reservable インターフェイス帯域幅に反映する必要があります。そのため、RSVP TE Lsp は間接的に、帯域幅を静的に分割しなくても、容量に専用にアクセスできない可能性があることを認識しています。

ここまでは RSVP TE Lsp を購入していましたが、現在のところ、非 SR 対応デバイスとニューヨークの間にトラフィックを伝送する RSVP TE Lsp は保有しています。’わかりやすくするために、’これらのルーターや lsp –’では焦点を深くしすぎないようにしてください。その代わりに’、すべてのルーターの teds を portray して、ネットワーク’の利用可能な帯域幅を正確に表示することができます。

その他の地域では、新しいニューヨークとワシントン間で、RSVP TE Lsp を発信および終了することはありません。RSVP TE Lsp が使用するインターフェイスの中には、SR トラフィックをネイティブに切り替えるものもあります。そこで’、ニューヨークと p2 で、次に SR トラフィックを測定して、残りのインターフェイス帯域幅 (RSVP TE) からそれを差し引くようにしてみましょう。

こちらの collection-interval統計がカリングされる頻度を表します。こちらの adjustinterval は、カウンターサンプルが収集されるウィンドウの期間を示します。これらのサンプル–の平均は、リンクごとの現在の SR –トラフィック負荷を表す3つのサンプルです。この負荷が、以前に計算された平均との間のデルタである調整しきい値を超えた場合、IGP は最大 reservable 帯域幅を消費し、TED を更新します。

その結果、RSVP TE Lsp が横取りされ、再ルーティングが行われるだけでなく、TE リンクに対して reservable の最大帯域幅 IGP が氾濫してしまうことがあります。飛行中に SR トラフィックがない場合’は、p1 と nyc 間のリンクで予約に使用可能な帯域幅を確認します。 phl.

Control plane: 3Kbps in use, 97Kbps available to RSVP-TE

ここで’は、セグメント化されたトラフィックを1つ上げて、レポート可能な帯域幅を削減することを確認します。

Control plane: ~67Kbps used by SR

Control plane: 31Kbps available to RSVP-TE, reduced by ~67Kbps

Control plane: LSDB reflects updated bandwidth

この反射は逆にも機能します。で’は、SR トラフィックを staunch して、利用可能な帯域幅が増加したことを確認してみましょう。

Control plane: SR utilization drops to ~40Kbps

Control plane: RSVP-TE now indicates 54Kbps available

Control plane: The LSDB values are flooded to neighbors & match RSVP-TE’s reported values

このような SR と RSVP TE の安全な共存により、運用担当者のニーズが予測されます。過剰な導入を行う環境では、RSVP-TE はすぐに置き換えられることはほとんどありません。利用可能な帯域幅が複数のコンシューマーによって正確に予約されていることを確認します。

SR と IPv6

IPv6 についてのご意見’があれば、おそらく正しいことです。強力なドライバーが見つからない場合、おそらく、お客’様のビジネスには存在しているとは言えません。ハッピーな Eyeballsの altar に祈りを捧げると、’強制的で技術的な差別化要因というわけではありません。

既存の MPLS ラベル分散プロトコルの IPv6 サポートは以下のとおりです。LDPv6 は、基本プロトコルを拡張しています。RSVP はこの日’までは、一般的な実装を提供していません。BGP は、アドレスファミリに依存し’ないままですが、当然のことながら IGP ではありません。

重要なのは、セグメントルーティングにより、IPv6 の到達可能性はファーストクラスの市民として扱われるということです。’SR は、新たに IPv6 を導入することを納得して’いましたが、その後、参入の妨げになることはありませんでした。ノード、ナチュラル、およびエニーキャスト Sid (以前は最初’の2つを使用していました) は、IPv4 と IPv6 のどちらのフレーバーも用意されています。

とにかく、設定はほぼ同一であり’、すぐに見てみましょう。そのため、IPv6 MPLS カプセル化されたアンダーレイを作成します。Pe1 の構文については、nyc を参照してください。SID 割り当ては、ほぼ同Table 2一の構成の繰り返しを回避し、 Figure 4設定を示すために詳細に記載されています。

Figure 4: IPv6、ISO アドレッシング、さらに多くのノード SID 番号付け

この構成が有効になると、各ルーターはさらに、ipv6 ノードインデックス (IPv4 ノードインデックスとともに) と IPv6 隣接 Sid の提供を開始します。

Control plane: Additional IPv6 node index and adjacency SIDs

隣接‘関係’の SID の F フラグは、IPv6 に対応した隣接関係を示します。以前に入力し’た inet 6.3 ルーティングテーブルに新しいエントリーが表示されるようになります。

Control plane: FECs in inet6.3 use native addresses, not mapped IPv4 addresses

さらに’、これらの新しいサービスルートへの接続を、リージョンと領域の両方について検証します。次に、IPv6 サービスプレフィックスが IPv6 トランスポートによって実行されていることを確認できます。6 PE’s マッピングされた IPv4 アドレスと IPv6 明示的な null の使用は、削り残しておくことができます。

Connectivity verification: Intra-region using the new IPv6 node SIDs

Connectivity verification: inter-region using the new IPv6 node SIDs

SR とマルチキャスト

一般的な神話では、マルチキャストはセグメントルーティングネットワークで特別な処理が必要になります。ほとんどの誤解と同様に、このことは理解していないことが原因です。

マルチキャスト転送はユニキャストに直交しています。既存の–アプローチ SR が有効になっている–場合でも、IPv4 マルチキャスト、MPLS マルチキャストは使用可能です。MPLS マルチキャストに関して言えば、predate SR ––が、マルチキャスト転送のために LDP と RSVP TE 2 つのプロトコルをそのまま残していることを意味しているかもしれません。

MLDP には、ポイントツーマルチポイント (P2MP) とマルチポイント間 (MP2MP) のレプリケーションツリーが用意されるようになっています。RSVP-TE では、ポイントツーポイント (P2P) 受信レプリケーションと P2MP ネットワーク複製を提供しています。どちらも、非 VPN およびマルチキャスト VPN トラフィックの配信をサポートしています。

受信およびネットワーク複製を提供するための、スプレーやツリー SID aspire などの SR ネイティブなアプローチ。BIER は、セグメントルーティングではありませんが、通過ノードから状態を削除するのと同じような理想をたどります。これらの技術が成熟するまで、事業者は既存のマルチキャストメカニズムに頼ることができます。