ON THIS PAGE
接続性
この章では、エッジで LDP を使用し、RSVP TE のみのコアをトンネリングする、参照nfield network (レガシーシステムを含む) について説明します。この章’の最初の作業は、SR をインテリジェントに導入し、故意に行うことです。次に、SR がすべてのラベル配信責任を subsume できる範囲を確認します。
ここで説明した機能の一部は、このガイドが公開された時点ではまだ利用可能になっていない場合があります。タイムラインについては、Juniper アカウントマネージャーにお問い合わせください。
到達可能性
SR の基本的な接続は、広告の接頭辞と隣接関係のセグメントによって実現されます。これらは、セグメント識別子(SID) によって示されます。その他にも多くのタイプの Sid が存在し、それぞれ異なる目的に対応していますが、この2つは基本的な接続性の確立に十分です。プレフィックスとその専用ノード SID フォームは、特定のパス検出アルゴリズムを通して、所定のトポロジ内のルーターを一意に識別します。ナチュラル SID は、IGP の近隣へのルーティングされたリンクを識別します。
セグメントの種類が増えていますが、それについて話していく余地はありません。エニィキャストセグメントは、シンプルでステートレスの負荷分散と冗長性を実現するために使用できる、ノード間の共有プレフィックスを表します。レベル2隣接型 SID は、LAG バンドルの個々のメンバーリンクを表し、メンバーリンクの OAM の検証に使用される予定です。そのようなナチュラルは、隣接関係を1つのセグメントにまとめた隣接関係セットです。バインド Sid はトンネルを表します。これらの Sid のいくつかについては、Optimizability のObservabilityの章で詳しく解説されています。
一部のセグメントは、隣接する Sid の場合のように、ラベルとして直接アドバタイズされます。プレフィックスとノードの Sid は間接的にインデックスとして SR グローバルブロック (SRGB) にアドバタイズされます。SRGB は、ノードがグローバルセグメントを参照するために使用するラベル領域を表します。SR が IGP 学習した各プレフィックスにラベルを提供する必要がない理由の1つです。SRGB は設定可能で、理想的には SR ドメイン全体で一貫しています。
IPv4 プレフィックスに関連付けられているセグメントが少なくとも1つ、IPv6 の場合は別のものがあります。ノードセグメントは、ルーター’のループバックアドレスと関連付けられています。実際、IPv4 および IPv6 ノードインデックスは、ループバックアドレスとして扱われている–ことが期待されています。これは、運用担当者が SR ドメイン内で固有のノード単位で管理しているのと同じです。
ナチュラルセグメントでは、pop によって動的にラベルが割り当てられ、対応する IGP 隣接関係アクションを通して転送されるようになっています。これらは、トラフィック保護を含む、厳重なステアリングに使用されます。ノードの Sid とは異なり、ナチュラル Sid はローカルまたはグローバルに重要です (グローバルに重要な隣接性を持つ Sid は珍しいものではありません)。
厳密に言えば、ノード Sid は、すべてのルーターが共通の SRGB を共有する場合にのみ、グローバルに一貫したものになります。これは推奨される導入モードです。グローバルに一貫したノード SID は、トラブルシューティングなどの運用を大幅に簡素化します。特定のルーターは、同じ SR ドメイン内の他のすべてのルーターのラベル転送情報ベース (LFIB) の同一エントリによって表されます。
マイフィールド
この例のネットワークは、 Figure 1に示されています。これは、多くの通信事業者にとって一般的な設計です。インターネットと VPN のオーバーレイサービスは、ラベル配信プロトコルとして LDP/RSVP TE を組み合わせて配信されるほか、選択肢の IGP としてマルチエリア IS-IS にも対応します。
焦点がアンダーレイであるため、インターネットと L3VPN の接続において、it の証拠として十分に活用できます。もちろん、MPLS サービス– 6PE、6PE、L2VPN、evpn、et などがあります。al は、 –これと同じネットワークを介して配信される可能性があります。
自分たちを回転さ’せるには、ニューヨークの CE (ce1) からワシントン州 (ce1) までの traceroute を実行してみましょう。
簡潔にするために、ワシントン州 DC は今からワシントンと呼ばれています。
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 2.427 ms 1.646 ms 3.676 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 70.034 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 7.387 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 52.897 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 55.576 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 6.849 ms p1.phl-ge-0-0-2.0 (192.0.2.21) 80.628 ms MPLS Label=313824 CoS=0 TTL=1 S=0 MPLS Label=352896 CoS=0 TTL=1 S=1 4 p2.iad-ge-0-0-6.0 (192.0.2.28) 7.129 ms p1.iad-ge-0-0-5.0 (192.0.2.30) 80.143 ms 73.898 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.994 ms 8.681 ms 5.971 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 8.125 ms 7.631 ms 10.807 ms
SR が使用されると、使用中のラベルが変更されることに注意してください。
ここでは、’pe1 on nyc を有効にして、コントロールと転送プレーンに加えられた変更を注意深くトレースしてみましょう。
Enabling SR on pe1.nyc
SRGB は、1000から1127の範囲内に設定されています。その範囲内では、このルーターは IPv4 ループバックアドレスを 1001 (1000 + 1、IPv4 インデックス) として表します。この’ことを確認してみてください。
Control plane: node SID verification
user@pe1.nyc> show isis overview Instance: master Router ID: 128.49.106.1 Hostname: pe1.nyc Sysid: 0128.0049.1061 Areaid: 49.0001 Adjacency holddown: enabled Maximum Areas: 3 LSP life time: 1200 Attached bit evaluation: enabled SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3 Overload bit at startup is set Overload high metrics: disabled Allow route leaking: disabled Allow internal prefix overloading: disabled Allow external prefix overloading: disabled IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled Traffic engineering: enabled Restart: Disabled Helper mode: Enabled Layer2-map: Disabled Source Packet Routing (SPRING): Enabled SRGB Config Range: SRGB Start-Label : 1000, SRGB Index-Range : 128 SRGB Block Allocation: Success SRGB Start Index : 1000, SRGB Size : 128, Label-Range: [ 1000, 1127 ] Node Segments: Enabled Ipv4 Index : 1, Ipv6 Index : 61 Post Convergence Backup: Disabled Level 1 Internal route preference: 15 External route preference: 160 Prefix export count: 0 Wide metrics are enabled Source Packet Routing is enabled Level 2 Internal route preference: 18 External route preference: 165 Prefix export count: 0 Wide metrics are enabled, Narrow metrics are enabled Source Packet Routing is enabled
手動で構成されたノード SID 以外に’、隣接する sid も動的に割り当てられていることを確認してみましょう。
Control plane: adjacency SID verification
user@pe1.nyc> show isis database pe1.nyc level 1 extensive IS-IS level 1 link-state database: pe1.nyc.00-00 Sequence: 0x496, Checksum: 0x981e, Lifetime: 771 secs IPV4 Index: 1 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 26, Weight: 0, Flags: --VL-- IS neighbor: p1.nyc.00 Metric: 10 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 27, Weight: 0, Flags: --VL-- IP prefix: 128.49.106.1/32 Metric: 0 Internal Up Header: LSP ID: pe1.nyc.00-00, Length: 191 bytes Allocated length: 1492 bytes, Router ID: 128.49.106.1 Remaining lifetime: 771 secs, Level: 1, Interface: 0 Estimated free bytes: 1257, Actual free bytes: 1301 Aging timer expires in: 771 secs Protocols: IP, IPv6 Packet: LSP ID: pe1.nyc.00-00, Length: 191 bytes, Lifetime : 1198 secs Checksum: 0x981e, Sequence: 0x496, Attributes: 0x5 <L1 Overload=> NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes Packet type: 18, Packet version: 1, Max area: 0 TLVs: Area address: 49.0001 (3) LSP Buffer Size: 1492 Speaks: IP Speaks: IPV6 IP router id: 128.49.106.1 IP address: 128.49.106.1 Hostname: pe1.nyc Router Capability: Router ID 128.49.106.1, Flags: 0x00 SPRING Capability - Flags: 0xc0(I:1,V:1), Range: 128, SID-Label: 1000 SPRING Algorithm - Algo: 0 Extended IS Reachability TLV, Type: 22, Length: 80 IS extended neighbor: p2.nyc.00, Metric: default 10 SubTLV len: 29 IP address: 192.0.2.6 Neighbor’s IP address: 192.0.2.7 Local interface index: 336, Remote interface index: 334 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 26 P2P IPv4 Adj-SID: 26, Weight: 0, Flags: --VL-- IS extended neighbor: p1.nyc.00, Metric: default 10 SubTLV len: 29 IP address: 192.0.2.4 Neighbor’s IP address: 192.0.2.5 Local interface index: 335, Remote interface index: 334 P2P IPV4 Adj-SID - Flags:0x30(F:0,B:0,V:1,L:1,S:0,P:0), Weight:0, Label: 27 P2P IPv4 Adj-SID: 27, Weight: 0, Flags: --VL-- IP extended prefix: 128.49.106.1/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 1 No queued transmissions </L1
Pe1 の nyc’s IS-IS の各ノードには、1つの隣接した SID があります。さらに、ノード SID は、IP 拡張プレフィックス TLV のサブ TLV として強調表示されています。このフラグは、2つの SID タイプの違いについても明確にしています。‘V’は、subTLV が値 (ナチュラル SID の場合) またはインデックス (ノード SID と同様) を含むかどうかを示します。‘L’は、ローカルとグローバルの重要度を表します。最後に、 ‘N’フラグは、特定のプレフィックス SID が、ルーター’のループバックアドレスにアタッチされているノード SID よりも具体的であることを示しています。
Forwarding plane: PE1’s FIB
user@pe1.nyc> show route table mpls.0 protocol isis mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 26 *[L-ISIS/14] 00:44:02, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 26(S=0) *[L-ISIS/14] 00:02:40, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 27 *[L-ISIS/14] 00:44:02, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 27(S=0) *[L-ISIS/14] 00:02:40, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop
L-ISISはラベル付き IS-IS を表しています。ナチュラル Sid は FIB にインストールされていますが、ノード SID が欠落しているように見えます。これは正常なことです。‘P’フラグ (php.ini) が設定されていないため、このルーターは上位ラベル1001を持つパケットを受信することを想定していません。代わりに、1001は、その近隣によってポップされます (SR で有効になると)。これは、従来のラベル分散プロトコルによって使用される暗黙の null 動作に似ています。
Inter-area
現在、他のルーターが SR で有効になっていないため’、pe1 の’nyc s sid は、エリア外部ルーターによってまだ学習されていません。Pe2 などのエリア内ルーターは、nyc などを学習しますが、そのようなものは無視されます。
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 6.659 ms 2.265 ms 2.116 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 8.626 ms 8.556 ms 13.895 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p2.ewr-ge-0-0-2.0 (192.0.2.17) 20.193 ms p1.phl-ge-0-0-2.0 (192.0.2.21) 18.045 ms 11.514 ms MPLS Label=313824 CoS=0 TTL=1 S=0 MPLS Label=352896 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 10.881 ms 9.305 ms 8.683 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 8.032 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.232 ms pe1.iad-ge-0-0-1.0 (192.0.2.36) 7.529 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 15.007 ms 10.747 ms 12.320 ms
変更されたものはありません。IS-IS には、LDP または RSVP TE よりも低いプロトコルの優先度が設定されており、使用を開始するには、オペレータの介入が必要です。Sr ドメインは、にFigure 2示す1つの島であるため、sr 転送は行われません。次のセクション’では、ニューヨークのすべてのルーターでノード sid を構成します。 (これも共通 IS-IS エリアを共有しています)、L1-L2 のアタッチされた p1. nyc を開始します。
Enabling SR on p1.nyc
Control plane
何’が変化していないのかを、今から短時間で確認してみましょう。Abridged の出力は、楕円 (…) に示されている興味深いポイントを示しています。
user@p1.nyc> show isis database extensive p1.nyc IS-IS level 1 link-state database: p1.nyc.00-00 Sequence: 0x4b8, Checksum: 0x6c1a, Lifetime: 546 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 30, Weight: 0, Flags: --VL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 31, Weight: 0, Flags: --VL-- IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 32, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.3/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 3 IS-IS level 2 link-state database: p1.nyc.00-00 Sequence: 0x758, Checksum: 0xc13, Lifetime: 967 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p2.nyc.00 Metric: 999999 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 33, Weight: 0, Flags: --VL-- IS neighbor: p1.ewr.00 Metric: 10 Two-way fragment: p1.ewr.00-00, Two-way first fragment: p1.ewr.00-00 P2P IPv4 Adj-SID: 29, Weight: 0, Flags: --VL-- IS neighbor: p1.phl.00 Metric: 10 Two-way fragment: p1.phl.00-00, Two-way first fragment: p1.phl.00-00 P2P IPv4 Adj-SID: 28, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.3/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 3 IP extended prefix: 128.49.106.1/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 1
Pe1 と比較した場合、2つの違いが明らかになります。 nyc 領域境界ルーター (ABR)、p1. nyc は、独自のノード SID を L1 領域と L2 エリアの両方にアドバタイズするだけでなく、pe1 の nyc’s ノード sid 広告をエリア全体に発信しています。これにより、IGP 領域全体でグローバルセグメントを学習できます。R ‘’フラグは、このノード SID がエリア/レベルで再アドバタイズされていることを示します。
Crucially は、 ‘まったく’を p1 と比較して、再提供されたノード sid に P フラグを’設定します。 nyc s 独自のノード sid。このことは、nyc によって、「continue (スワップ)」アクションを使用し、転送命令として解釈される上位ラベルを pe1 に保持していると想定されている、SR に対応した近隣に通知されます。
Forwarding plane: P1’s FIB
Nyc が pe1 の nyc’s ノード SID を表すラベル1001のエントリーをインストール済みであることを確認できます。
user@p1.nyc> show route table mpls.0 protocol isis mpls.0: 31 destinations, 31 routes (31 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 28 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.21 via ge-0/0/5.0, Pop 28(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.21 via ge-0/0/5.0, Pop 29 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.15 via ge-0/0/4.0, Pop 29(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.15 via ge-0/0/4.0, Pop 30 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.8 via ge-0/0/3.0, Pop 30(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.8 via ge-0/0/3.0, Pop 31 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.4 via ge-0/0/2.0, Pop 31(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.4 via ge-0/0/2.0, Pop 32 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 32(S=0) *[L-ISIS/14] 00:07:10, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 33 *[L-ISIS/14] 00:34:55, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 33(S=0) *[L-ISIS/14] 00:09:21, metric 0 > to 192.0.2.13 via ge-0/0/1.0, Pop 1001 *[L-ISIS/14] 00:34:55, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop 1001(S=0) *[L-ISIS/14] 00:07:10, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop
Pop (MPLS 転送プレーン’s バージョンのcontinue) アクションが表示されるだけではないので、着信ラベル1001に対して、ナチュラル SID ラベル28-33 の pop アクションを見ることができます。
Forwarding plane: PE1’s FIB
user@pe1.nyc> show route protocol isis table mpls.0 mpls.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 26 *[L-ISIS/14] 02:06:55, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 26(S=0) *[L-ISIS/14] 00:10:50, metric 0 > to 192.0.2.7 via ge-0/0/2.0, Pop 27 *[L-ISIS/14] 00:48:12, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 27(S=0) *[L-ISIS/14] 00:10:50, metric 0 > to 192.0.2.5 via ge-0/0/1.0, Pop 1003 *[L-ISIS/14] 00:35:14, metric 10 > to 192.0.2.5 via ge-0/0/1.0, Pop 1003(S=0) *[L-ISIS/14] 00:10:50, metric 10 > to 192.0.2.5 via ge-0/0/1.0, Pop
Pe1 の nyc では、p1. nyc’s ノード SID を表す転送エントリーがラベル1003に対して送信されました。
Inter-area
Pe1 以外の nyc は、nyc’s のその他のすべての隣接ノードが SR 対応になっています。すべての L2 隣接部門が、そのセグメントを学習しますが、無視します。
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 3.118 ms 2.042 ms 1.803 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 7.747 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 101.823 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 23.312 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 7.152 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 69.566 ms 67.497 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 11.528 ms 9.755 ms p2.iad-ge-0-0-6.0 (192.0.2.28) 6.276 ms MPLS Label=355776 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 5.667 ms 8.056 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 10.915 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 169.285 ms 11.048 ms 9.896 ms
転送動作の変化が存在しないため、これは reassuring です。SR を有効にすることで、既存のサービスを不注意で変更してしまうことがなくなります。結局のところ、制御された導入を推奨しています。
Enabling SR on the remaining New York routers
Control plane
この時点で、期待することを理解しておく必要があります。2つの新しいノード Sid が L1 領域に提供されます。pe2 の nyc’s node SID は、nyc と p2 の両方によって再アドバタイズされます。 nyc は、L2 サブドメインに登録します。Pe1 のようなものです。nyc’s が登場する以前は、現時点では非 SR 対応 L2 ルーターによって無視されます。見’てみましょう。
user@p2.nyc> show isis database p2.nyc extensive IS-IS level 1 link-state database: p2.nyc.00-00 Sequence: 0x4a3, Checksum: 0x28ab, Lifetime: 851 secs IPV4 Index: 2 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 265, Weight: 0, Flags: --VL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 266, Weight: 0, Flags: --VL-- IS neighbor: p1.nyc.00 Metric: 10 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 267, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.2/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 2 IS-IS level 2 link-state database: p2.nyc.00-00 Sequence: 0x4a0, Checksum: 0x8f75, Lifetime: 851 secs IPV4 Index: 2 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: p1.nyc.00 Metric: 999999 Two-way fragment: p1.nyc.00-00, Two-way first fragment: p1.nyc.00-00 P2P IPv4 Adj-SID: 268, Weight: 0, Flags: --VL-- IS neighbor: p2.ewr.00 Metric: 10 Two-way fragment: p2.ewr.00-00, Two-way first fragment: p2.ewr.00-00 P2P IPv4 Adj-SID: 264, Weight: 0, Flags: --VL-- IS neighbor: p2.phl.00 Metric: 10 Two-way fragment: p2.phl.00-00, Two-way first fragment: p2.phl.00-00 P2P IPv4 Adj-SID: 263, Weight: 0, Flags: --VL-- ... TLVs: ... IP extended prefix: 128.49.106.2/32 metric 0 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x40(R:0,N:1,P:0,E:0,V:0,L:0), Algo: SPF(0), Value: 2 IP extended prefix: 128.49.106.0/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 0 IP extended prefix: 128.49.106.1/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 1 IP extended prefix: 128.49.106.3/32 metric 10 up 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0xe0(R:1,N:1,P:1,E:0,V:0,L:0), Algo: SPF(0), Value: 3
ここでは、すべての SR 対応ルーターに対して、各 IS-IS (SR に対応可能またはない)、ノード Sid (すべての場合に再提供されます) に対応する、隣接する Sid があることに慣れています。
Connectivity verification
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe1.nyc-ge-0-0-10.1 (198.51.100.1) 27.852 ms 38.214 ms 2.399 ms 2 p2.nyc-ge-0-0-2.0 (192.0.2.7) 8.883 ms p1.nyc-ge-0-0-2.0 (192.0.2.5) 7.776 ms p2.nyc-ge-0-0-2.0 (192.0.2.7) 6.584 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 6.929 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 7.092 ms 8.230 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p1.iad-ge-0-0-5.0 (192.0.2.30) 7.097 ms 6.988 ms p2.iad-ge-0-0-6.0 (192.0.2.28) 7.142 ms MPLS Label=355776 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.132 ms pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.677 ms 5.444 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 11.672 ms 9.005 ms 7.873 ms
最後に、トラフィック転送に変更を行わないことを確認できます。
この作業はすべて終わりですか? ほとんど。SR 制御プレーンを有効にしても、運用担当者がすぐに転送プレーンを使用することはありません。実際、これは、SR –制御プレーンの検証への移行における最初のステップであり、継続的なサービス保証との連携になります。
SR へのスイッチング
現在、ニューヨークを通じて SR が有効になっています。そのために必要なのは、受信ルーターのプロトコル設定を調整することです。ここまでは、ニューヨークとワシントンの CEs 間の転送をテストしてきました。SR ドメインは前者に制約されているため’、地域内の CEs 間の接続を迅速に検証してみましょう。
Connectivity verification
user@ce1.nyc> traceroute routing-instance svc-inet 198.51.100.0 traceroute to 198.51.100.0 (198.51.100.0), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 235.860 ms 226.521 ms 69.491 ms 2 p1.nyc-ge-0-0-3.0 (192.0.2.9) 11.960 ms 4.510 ms p2.nyc-ge-0-0-3.0 (192.0.2.11) 4.477 ms MPLS Label=257 CoS=0 TTL=1 S=1 3 pe1.nyc-ge-0-0-1.0 (192.0.2.4) 3.625 ms 4.503 ms pe1.nyc-ge-0-0-2.0 (192.0.2.6) 5.833 ms 4 ce1.nyc-ge-0-0-1.1 (198.51.100.0) 6.088 ms 6.480 ms 7.580 ms
どの SR ラベルも使用されていない。これは、pe2 サービスルート解決を BGP 行う際に、nyc (入口ルーター) が LDP から学習した次のホップを引き続き採用しているため、理にかなっています。
Control plane
’受信 PE でサービスルートとその次ホップを検証します。
user@pe2.nyc> show route 198.51.100.0 active-path extensive inet.0: 30 destinations, 37 routes (30 active, 0 holddown, 0 hidden) 198.51.100.0/31 (2 entries, 1 announced) ... Indirect next hops: 1 Protocol next hop: 128.49.106.1 Metric: 1 Indirect next hop: 0xba57f80 1048577 INH Session ID: 0x165 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 192.0.2.9 via ge-0/0/1.0 weight 0x1 Session Id: 0x0 Next hop: 192.0.2.11 via ge-0/0/2.0 weight 0x1 Session Id: 0x0 user@pe2.nyc> show route 128.49.106.1 table inet.3 inet.3: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.1/32 *[LDP/9] 00:54:50, metric 1 to 192.0.2.9 via ge-0/0/1.0, Push 18 > to 192.0.2.11 via ge-0/0/2.0, Push 257 [L-ISIS/14] 00:54:29, metric 20 to 192.0.2.9 via ge-0/0/1.0, Push 1001 > to 192.0.2.11 via ge-0/0/2.0, Push 1001 user@pe2.nyc> show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/1.0 p1.nyc 1 Up 26 ge-0/0/2.0 p2.nyc 1 Up 26 user@pe2.nyc> show ldp database | match “put|128.49.106.1/32” Input label database, 128.49.106.0:0--128.49.106.2:0 257 128.49.106.1/32 ...
トレースを’再開する BGP ルートは、128.49.106.1 –のプロトコル next-hop を使用して学習されます’。これは pe1 の nyc s ループバックアドレスです。この転送同等クラス (FEC) と LDP と SR (L-ISIS はラベル付き IS-IS) の両方に関連付けられています。前者は、より優れたプロトコル設定を備えているため、pe2 は nyc が、選択した近傍 (p2) から LDP から学習したラベル257を採用しています。
ECMP が有効になっているので、nyc は同じようにプッシュされたラベル18にも対応しています。これは、同じ FEC の nyc が提供しています。これは、転送プレーンの決定です。その結果、受信パケットヘッダーをハッシュし、その結果を使用して、フローごとに単一の送信パスを選択することができます。
変更を行うには、’pe2 の nyc における L-ISIS のプロトコルの優先度を上げてみましょう。
Prefer SR for intra-region traffic originating at pe2.nyc
Control plane: confirm pe2.nyc performs route resolution using SR instead of LDP
user@pe2.nyc> show route 128.49.106.1 table inet.3 inet.3: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 128.49.106.1/32 *[L-ISIS/8] 00:00:41, metric 20 to 192.0.2.9 via ge-0/0/1.0, Push 1001 > to 192.0.2.11 via ge-0/0/2.0, Push 1001 [LDP/9] 01:10:36, metric 1 to 192.0.2.9 via ge-0/0/1.0, Push 18 > to 192.0.2.11 via ge-0/0/2.0, Push 257
プロトコルの次ホップでは、SR divined ラベル (1001、pe1、nyc’s ノード SID) が優先されるようになりました。このことは、転送プレーンに影響を与えることになります (finally!)。
Connectivity verification: intra-NY traffic is SR-switched
user@ce1.nyc> traceroute routing-instance svc-inet 198.51.100.0 traceroute to 198.51.100.0 (198.51.100.0), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 2.903 ms 3.001 ms 1.934 ms 2 p2.nyc-ge-0-0-3.0 (192.0.2.11) 5.263 ms p1.nyc-ge-0-0-3.0 (192.0.2.9) 35.811 ms 87.604 ms MPLS Label=1001 CoS=0 TTL=1 S=1 3 pe1.nyc-ge-0-0-1.0 (192.0.2.4) 188.617 ms 47.428 ms 8.965 ms 4 ce1.nyc-ge-0-0-1.1 (198.51.100.0) 10.858 ms 5.580 ms 5.275 ms
Pe2 によって nyc によって変更されたラベルは、257から1001に変わります。これにより、SR ドメイン内のトラフィックをセグメント単位でプレイしていることが確認できます。Pe2 でのプロトコルの優先度の変更によって、すべての地域別のトラフィックが影響を受けないようにする必要があります。 nyc では、ワシントン州のクロスカントリーの宛先に対するトレースは、従来のラベルスイッチとして維持されます。
Connectivity verification: extra-NY traffic still uses LDP
user@ce1.nyc> traceroute 198.51.100.54 routing-instance svc-inet traceroute to 198.51.100.54 (198.51.100.54), 30 hops max, 40 byte packets 1 pe2.nyc-ge-0-0-10.1 (198.51.100.3) 49.540 ms 78.154 ms 68.680 ms 2 p1.nyc-ge-0-0-3.0 (192.0.2.9) 62.733 ms 64.765 ms p2.nyc-ge-0-0-3.0 (192.0.2.11) 64.562 ms MPLS Label=119 CoS=0 TTL=1 S=1 3 p1.phl-ge-0-0-2.0 (192.0.2.21) 60.903 ms 6.794 ms p2.ewr-ge-0-0-2.0 (192.0.2.17) 33.531 ms MPLS Label=314 CoS=0 TTL=1 S=0 MPLS Label=355776 CoS=0 TTL=1 S=1 4 p2.iad-ge-0-0-6.0 (192.0.2.28) 6.553 ms p1.iad-ge-0-0-5.0 (192.0.2.30) 96.063 ms 67.346 ms MPLS Label=352896 CoS=0 TTL=1 S=1 5 pe1.iad-ge-0-0-2.0 (192.0.2.38) 8.891 ms pe1.iad-ge-0-0-1.0 (192.0.2.36) 6.837 ms 6.421 ms 6 ce1.iad-ge-0-0-4.0 (198.51.100.54) 30.158 ms 108.181 ms 84.979 ms
当社のアクションの結果としてサービスの不連続性が存在しないと確信し’たので、pe2 のミラー化をお勧めします。すべて’のニューヨークルーターで NYC s SR の環境設定を行います。この設定は同一です。
この時点で、ニューヨーク本社は LDP から、その他のニューヨークルーターに対する次ホップの解決を希望しています。その領域外のルーターは依然として SR とトラフィックを中断することなく、引き続き転送されます。
サービスの保存クラス
島が機能するようになった’ところで、SR がアップタイムとサービスクラス (CoS) の厳格な sla を満たすネットワークをどのようにサポートしているかについて、簡単に見ていきましょう。広く導入されている手法として、penultimate のホップ型 (UHP) のような動作を可能にすることで、(PHP) を無効にすることができます。SR はノードの Sid をラベルとして直接アドバタイズしていないため、フラグを使用して上流のルーターからの UHP の動作を要求します。Pe1’で uhp を有効にして、nyc の’ FIB への変更を確認してみましょう。
Enable explicit-null UHP behavior on egress router pe1.nyc
Control plane: verify the change in pe1.nyc’s IS-IS LSP
user@pe1.nyc> show isis database pe1.nyc extensive IS-IS level 1 link-state database: pe1.nyc.00-00 Sequence: 0x4d4, Checksum: 0x4f97, Lifetime: 1195 secs IPV4 Index: 1 ... IP extended prefix: 128.49.106.1/32 metric 0 up \ 14 bytes of subtlvs Administrative tag 1: 1111 Node SID, Flags: 0x70(R:0,N:1,P:1,E:1,V:0,L:0), Algo: SPF(0), Value: 1
これまでの出力とは対照的に、pe1 は nyc のノード SID をアドバタイズするようになりました。‘P’(PHP が終了するか、PHP を無効にします)‘E’(明示的な null を有効にするか、予約ラベル0を使用してください) フラグセット。
これにより、近隣、nyc、nyc をリードし、ラベル 1001 (pe1) の次 (pop) アクションではなく、continue (swap) を使用し’ます。 nyc s node index は1、ネットワークは前述したように、共通の SRGB を1k として使用しています。Pe2 が nyc’s FIB に変更されることはありません。Pe1 に直接接続されているわけではありません。 nyc PHP および UHP の動作は、即座に上流側のルーターにのみ関連しています。
Forwarding plane: verify pe1.nyc neighbors’ FIB
user@p1.nyc> show route label 1001 mpls.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 00:04:03, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Swap 0 1001(S=0) *[L-ISIS/8] 00:04:03, metric 10 > to 192.0.2.4 via ge-0/0/2.0, Pop user@p2.nyc> show route label 1001 mpls.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 00:04:05, metric 10 > to 192.0.2.6 via ge-0/0/2.0, Swap 0 1001(S=0) *[L-ISIS/8] 00:04:05, metric 10 > to 192.0.2.6 via ge-0/0/2.0, Pop user@pe2.nyc> show route label 1001 mpls.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1001 *[L-ISIS/8] 09:14:56, metric 20 to 192.0.2.9 via ge-0/0/1.0, Swap 1001 > to 192.0.2.11 via ge-0/0/2.0, Swap 1001
P1 と p2 は、ラベル1001をラベル0にスワップしています。これは、IPv4 explicit null ラベルであることを示しています。このラベルにより、MPLS トラフィッククラス (以前は試験用ビットと呼ばれていたもの) が最終ホップルーターに一貫してコピーされるようになります。この最後ホップでは、ラベル0がポップされ、IPv4 ルックアップが行われます。ラベル0が存在することで、CoS の透明性と維持が可能になります。
先へ進む前に、UHP が pe2 でも有効になっていることに注意してください。
トラフィックの保護と復元
パケットネットワークは、50ミリ秒以内に、SONET/SDH ネットワークによって設定されたバーを通過する、非常に長い時間内に保護を提供できるようになりました。IP ベースの高速再ルーティング (FRR) は、LDP でループフリーの代替 (LFA) およびリモート LFA (rLFA) として利用できます。さらに、RSVP-TE は、共有リスクリンクグループ(SRLG) として識別された、リンク、ノード、または運命共有リソースの損失から保護するために、さまざまなメカニズムを導入しています。
どちらのアプローチでも、その点については注意が必要です。LFA は、トポロジーに依存し、保護機能を提供します。rLFA は、対象化された LDP セッションの状態と複雑さを追加してコストを削減し、これを改善しています。RSVP-TE は最も完全な機能セットを備えています。これは、バイパスおよび detour Lsp の追加のシグナリングおよび状態保守に依存します。
SR’s ソースルート、明示的にステアリング、および輸送制御プレーンの状態がないため、コストのかからないローカル保護パスを確立することができます。トポロジーに物理的な冗長性がある限り、トポロジーに依存しないループなしの代替ルート (TI) を見つけることができます。保護されたリンク、ノード、またはローカルに定義された運命共有グループの周囲をルート変更できます。さらに、保護技術の向上というもう1つの改善点は、TI の保護パスが、さらには ECMP にも対応していることです。
TI は、ローカル修理 (PLR) の点ではローカルに保護されています。バックアップパスは事前に計算されていますが、事前通知はありません。各リリースポイントはプレフィックス単位で最適化されているため、単数のマージポイント (MP) はありません。事前計算されたパスは、IGP コンバージェンスパスを計算するために、トポロジから保護リソースを排除または大幅に削減します。保護されたリソースの障害が発生すると、データプレーンの1つの更新が行われ、ローカルとグローバルの両方の修復が1つのステップにまとめられることになります。
Nyc’でリンク保護を有効にして、その SR 近隣における変更の結果を確認してみましょう。
Enable TI-LFA link protection for all level 1 links on p1.nyc
Control plane: verify p1.nyc is announcing its adjacency SIDs as protection-eligible
user@p1.nyc> show isis database extensive p1.nyc level 1 IS-IS level 1 link-state database: p1.nyc.00-00 Sequence: 0x510, Checksum: 0x192f, Lifetime: 1078 secs IPV4 Index: 3 Node Segment Blocks Advertised: Start Index : 0, Size : 128, Label-Range: [ 1000, 1127 ] IS neighbor: pe2.nyc.00 Metric: 10 Two-way fragment: pe2.nyc.00-00, Two-way first fragment: pe2.nyc.00-00 P2P IPv4 Adj-SID: 47, Weight: 0, Flags: -BVL-- IS neighbor: pe1.nyc.00 Metric: 10 Two-way fragment: pe1.nyc.00-00, Two-way first fragment: pe1.nyc.00-00 P2P IPv4 Adj-SID: 48, Weight: 0, Flags: -BVL-- IS neighbor: p2.nyc.00 Metric: 10 Two-way fragment: p2.nyc.00-00, Two-way first fragment: p2.nyc.00-00 P2P IPv4 Adj-SID: 35, Weight: 0, Flags: -BVL—
B ‘’フラグは、nyc が保護のためにこれらの隣接する sid の候補を考慮していることを示しています。Pe2’へのリンクを表す SID 47 の–詳細については、そのうちの1つを見てみましょう。
Forwarding plane: verify p1.nyc has installed backup paths for protection-eligible SIDs
user@p1.nyc> show route label 47 extensive mpls.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden) … Next hop: 192.0.2.8 via ge-0/0/3.0 weight 0x1, selected Label operation: Pop … Next hop: 192.0.2.13 via ge-0/0/1.0 weight 0xf000 Label operation: Swap 1000 user@p1.nyc> show isis adjacency Interface System L State Hold (secs) SNPA ge-0/0/1.0 p2.nyc 3 Up 23 ... ge-0/0/3.0 pe2.nyc 1 Up 20
2つの等しくないネクストホップがあり、後者は新たにバックアップとして追加されています。Nyc’s は、pe2 に到達するためにバックアップを計算し、保護された ge 0/0/3 リンクを回避していることに注意してください。 nyc を使用します。着信ラベル47の主なアクションは、pe2 に直接 pop を送信することをお勧めします。バックアップアクションは、pe2 の nyc’s ノード SID (ラベル 1000) に対してスワップを行い、nyc に送信します (をFigure 3参照してください)。このルーターでは、pe2 が明示的な null を介して到達可能性を通知する nyc の結果として、ラベルが0に対して交換されます。
Forwarding plane: verify p2.nyc acts as a transit router on this stateless protection path
user@p2.nyc> show route label 1000 mpls.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 1000 *[L-ISIS/8] 12:18:02, metric 10 > to 192.0.2.10 via ge-0/0/3.0, Swap 0 1000(S=0) *[L-ISIS/8] 00:03:43, metric 10 > to 192.0.2.10 via ge-0/0/3.0, Pop
これで最初の区間は終わりです。ネットワークの一部でありながら、SR が有効で、アクティブな使用になっています。到達可能性と、CoS マーキングを維持し、ステートレストラフィックの保護と復元を提供する機能が用意されています。
次のステップは、SR をネットワークの他の部分に broach することです。