はじめに 2025年8月29日、滋賀県大津市のピアザ淡海（ピアザホール）でNaniwaNOG 3ミーティングが開催されました。関西のネットワーク技術者が一堂に会するこのイベントで、前回に引き続き、学生を中心としたNOCチ […]

本記事では、ネットワークに障害が発生した際に高速迂回する技術であるTI-LFA (Topology Independent Loop-Free Alternate) の検証結果について紹介します。TI-LFAとは、Segment Routingを組み合わせて事前に計算したBackup pathを使って、任意のトポロジーで障害の高速迂回を実現する技術です。今回は、Segment RoutingとしてSRv6 uSIDを使用しました。 はじめに uSIDとTI-LFAの説明 uSID TI-LFA 使用した機種 TI-LFAの設定 Junos/Junos EVO (設定例) TI-LFA設定 uSID Locator 設定 IOS XR (設定例) TI-LFA設定 uSID Locator設定 (i) SRv6 uSIDを追加しないTI-LFA (ii) SRv6 uSIDを追加するTI-LFA PEルーターの動作 構成図 (ii-a) uNのみで迂回可能なケース (ii-b) uA利用時のみ迂回可能なケース uA利用時のみ迂回可能なケースのuSIDの付け方について 各ルーターのTI-LFAの違い Pルーターの動作 構成図 (ii-a) uNのみで迂回可能なケース (ii-b) uA利用時のみ迂回可能なケース uA利用時のみ迂回可能なケースのuSIDの付け方について PEルーターとPルーターでのカプセル化動作の違い Junos EVOでのTI-LFA Backup pathの参照テーブル まとめ はじめに こんにちは、イノベーションセンターの伊藤と藤原です。普段は全社検証網の運用や新規技術の検証に取り組んでいます。今回、Segment Routingの高速迂回技術であるTI-LFAの動作をSRv6 uSIDを用いて社内で検証しましたので、紹介します。本記事では、Junos / Junos EVO / IOS XRの3つのOSにおけるTI-LFAの動作の違いを解説します。また、VPNを終端するPEルーターと終端しないPルーターで見られた動作の違いについても整理しました。 過去にSR-MPLSを使ったTI-LFAの検証結果を公開しておりますので、Multi-AS Segment Routing検証の 第9回の記事 や 第18回の記事 も是非ご覧ください。 uSIDとTI-LFAの説明 Segment Routing、SRv6については 過去記事 や 発表資料 で説明しております。 uSID SRv6が標準化された当初は1つのIPv6 Addressを1つのSIDとして用いるFull SIDを使用していました。しかし、ヘッダサイズのオーバーヘッドが問題となり、近年は1つのIPv6 Addressを複数のSIDとして用いるuSID (Micro-SIDと読みます) を使用することが一般的となっています。 RFC9800 の記載では、uSIDはNEXT-CSID flavorと呼ばれていますが、今回のブログでは一般的に使用される通称のuSIDを用います。 uSIDは各ルーターで共通のSRv6 uSID blockとルーターのノードや動作を指定するuSID部分からなります。今回のブログではSRv6 uSID blockを32ビット、uSIDを16ビットとするF3216を用いています。 本ブログでは以下のuSIDを使用しました。 uSID 動作 Full SIDの場合の呼び方 uN 特定のノードにパケットを転送 End uA 特定のインタフェースにパケットを転送 End.X uDT4 IPv6ヘッダを外し、IPv4テーブルを見て転送 End.DT4 uNはSRv6 domain内でユニークなIDなのに対し、uA、uDT4は各ルーターのローカルなIDであり、ルーター間で重複する場合があります。そのため、SRv6 uSIDでは、uA、uDT4だけではノードへの到達性がないため、一般的にはuNとセットで用いられます。 TI-LFA TI-LFAは、Segment Routingを利用したFast Reroute (FRR) の実現手法の1つです。 今回の検証では、下図のトポロジーを使用し、経路迂回の際に付与されるuSIDによって3つに分類しました。 ( RFC9855 で定義されているTI-LFAのBackup pathの分類とは異なります。) (i) の場合、R2からR6への最短経路はR1とR3の間で発生する障害を通りません。そのため、R1がR2にパケットを転送すれば、障害を迂回できます。 (ii-a) および (ii-b) の場合、R2からR6へ向かう経路は、R2の経路計算が終わるまで障害箇所を経由します。そのため、(i) のように出力インタフェースを変更するだけでは、R1とR2の間でループが発生します。uSIDを使うことでこの状況を打開できます。 (ii-a) の場合、R4からR6へ向かう最短経路は障害を経由しないため、R4までパケットを届けることができれば障害を迂回できます。R2からR4へ向かう最短経路は障害箇所を経由しないため、R1はR4のuNをパケットに付与して、R2に転送することで障害を迂回できます。 (ii-b) の場合も同様に、R5までパケットを届けることができれば障害を迂回できますが、R4からR5の最短経路は障害箇所を経由してしまいます。よって、R4で経路を捻じ曲げるためのuAが必要となります。R2からR4にパケットを転送するにはR4のuNが必要なので、R1はR4のuNとR4→R5のuAを合成したuSIDをパケットに付与して、R2に転送することで障害を迂回できます。 そのため、R4のuNとR4からR5に向かうuAをパケットに付与することで、障害を高速迂回できます。 ケース 下図の場合に付与されるuSID (i) SRv6 uSIDを追加しないTI-LFA なし (出力インタフェースの変更だけで迂回可能) (ii-a) uNのみで迂回可能なケース R4のuN (ii-b) uA利用時のみ迂回可能なケース R4のuNとR4からR5へ転送するuA 使用した機種 今回の検証で使用した機種は下記のとおりです。 ベンダー 機種名 OS HPE (旧Juniper) MX204 Junos 24.4R1.9 HPE (旧Juniper) ACX7024 Junos 24.4R1.8-EVO HPE (旧Juniper) ACX7100-32C Junos 24.4R1-S2.9-EVO Cisco ASR 9901 IOS XR 25.4.1 Cisco 8011-4G24Y4H-I IOS XR 25.2.1 TI-LFAの設定 Junos/Junos EVO (設定例) TI-LFA設定 user@MX204-1# show | compare [edit protocols isis interface et-0/0/1.0 level 2 srv6-adjacency-segment unprotected] + locator uSID-default { + micro-adjacency-sid; + } [edit protocols isis interface et-0/0/1.0 level 2] + post-convergence-lfa; [edit protocols isis backup-spf-options] + use-source-packet-routing; uSID Locator 設定 uSID Locatorには、uSID blockとuNを合成したものを設定します。下記の設定例では、 fcbb:bb00: がuSID blockに相当します。 user@MX204-1# show | compare [edit routing-options source-packet-routing srv6 locator uSID-default] + fcbb:bb00:0101::/48; [edit routing-options source-packet-routing srv6 locator uSID-default micro-sid] + flavor { + psp; + usd; + } ※ Pルーターとして動作する場合、下記設定が追加で必要となります。なお、このままの設定だとTI-LFA対象外の経路にまで影響する可能性がありますのでご注意ください。 user@ACX7100-1# show | compare [edit policy-options] + policy-statement lbpf { + then { + load-balance per-packet; + } + } [edit routing-options forwarding-table] + export lbpf; IOS XR (設定例) TI-LFA設定 RP/0/RP0/CPU0:Cisco8011-1#show commit changes diff !! Building configuration... !! IOS XR Configuration 25.2.1 router isis core interface TenGigE0/0/0/4 address-family ipv6 unicast + fast-reroute per-prefix + fast-reroute per-prefix ti-lfa ! ! ! end uSID Locator設定 RP/0/RP0/CPU0:Cisco8011-1#show commit changes diff !! Building configuration... !! IOS XR Configuration 25.2.1 + segment-routing + srv6 + locators + locator uSID_default + micro-segment behavior unode psp-usd + prefix fcbb:bb00:10b::/48 ! ! ! ! end (i) SRv6 uSIDを追加しないTI-LFA SRv6 uSIDを追加せず、出力インタフェースの変更だけでパケットを迂回可能なケースのTI-LFAを検証しました。ASR9901の検証結果について記載しますが、他の4種のルーターでも同様の動作が確認されました。 構成図 SRv6 domainを経由してsrcからdstに通信し、SRv6 domain内ではL3VPN機能を使用しました。ACX7100-2とASR9901-1の間のリンクを障害模擬箇所としました。リンクの数字はIS-ISのメトリック値になります。 TI-LFAを設定していない場合には、Backup pathが作成されませんでした。 RP/0/RSP0/CPU0:ASR9901-1#show route ipv6 Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP A - access/subscriber, a - Application route M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path s - local SRv6 route, z - local IID route Gateway of last resort is not set i L2 fcbb:bb00:101::/48 [115/30] via fe80::8652:34ff:fe30:fe00, 00:10:35, TenGigE0/0/0/31 TI-LFAを設定すると (!) のついたFRR Backup pathが作成されました。 RP/0/RSP0/CPU0:ASR9901-1#show route ipv6 Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR, l - LISP A - access/subscriber, a - Application route M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path s - local SRv6 route, z - local IID route Gateway of last resort is not set i L2 fcbb:bb00:101::/48 [115/30] via fe80::8652:34ff:fe30:fe00, 00:04:07, TenGigE0/0/0/31 [115/40] via fe80::eebb:78ff:fe0e:8c1b, 00:04:07, TenGigE0/0/0/32 (!) TI-LFAを設定し、ASR9901-1とACX7100-2の間のリンクをダウンさせて、ASR9901-1とCisco8011-2の間のリンクでパケットキャプチャを行うと、MX204-1のuN+uDT4 (fcbb:bb00:101:e041::) をDst AddressにしたIPv6パケットが確認できました。 (ii) SRv6 uSIDを追加するTI-LFA 次にPEルーターとPルーターに分けて、我々が分類した (ii-a) uNのみで迂回可能なケースと (ii-b) uA利用時のみ迂回可能なケースの2種類のTI-LFAについて検証をしました。 PEルーターの動作 PEルーターの動作はMX204、ACX7024、ASR9901について確認しました。 構成図 リンクの数字はIS-ISのメトリック値を表し、X、Yは検証内容で変わります。 MX204 ACX7024 ASR9901 (ii-a) uNのみで迂回可能なケース MX204 Cisco8011-2のuN (fcbb:bb00:30b::) を付与するBackup pathが確認できました。 user@MX204-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Next hop: ELNH Address 0x3d5d2db81efc weight 0x1, selected Next hop type: Chain, Next hop index: 633 Address: 0x3d5d2db81efc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d2da37efc SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x3d5d2db7cd9c weight 0xf000 Next hop type: Chain, Next hop index: 634 Address: 0x3d5d2db7cd9c Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d2da540bc SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:: (snip) MX204-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、MX204-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-2のuN (fcbb:bb00:30b::) とASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 ACX7024 Cisco8011-2のuN (fcbb:bb00:30b::) を付与するBackup pathが確認できました。 user@ACX7024-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 8080 Address: 0x5565e3214d5c Next-hop reference count: 11 Kernel Table Id: 0 Next hop: ELNH Address 0x5565e596399c weight 0x1, selected Next hop type: Chain, Next hop index: 8065 Address: 0x5565e596399c Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e2c2791c SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x5565e2c25dfc weight 0xf000 Next hop type: Chain, Next hop index: 8078 Address: 0x5565e2c25dfc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e5962ffc SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:: (snip) ACX7024-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、ACX7024-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-2のuN (fcbb:bb00:30b::) をDst Addressに、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) をSegment Routing Header (SRH) に付与したIPv6パケットが確認できました。 ASR9901 Cisco8011-1のuN (fcbb:bb00:10b::) を付与するBackup pathが確認できました。 RP/0/RSP0/CPU0:ASR9901-1#show route ipv6 fcbb:bb00:101::/48 detail Routing entry for fcbb:bb00:101::/48 Known via "isis core", distance 115, metric 30, SRv6-locator, type level-2 (snip) Routing Descriptor Blocks fe80::8652:34ff:fe30:fe00, from fd00:1::1, via TenGigE0/0/0/31, Protected Route metric is 30 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:1 Path ref count:0 NHID: 0x20008 (Ref: 25) Backup path id:65 fe80::eebb:78ff:fe0e:8c1b, from fd00:1::1, via TenGigE0/0/0/32, Backup (TI-LFA) Repair Node(s): fd00:1::b Route metric is 100 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:65 Path ref count:1 NHID: 0x20007 (Ref: 27) SRv6 Headend: H.Insert.Red [f3216], SID-list {fcbb:bb00:10b::} (snip) ASR9901-1とACX7100-2の間のリンクを落としTI-LFAを動作させて、ASR9901-1とCisco8011-2の間のリンクでパケットキャプチャしました。結果、Cisco8011-1のuN (fcbb:bb00:10b::) とMX204-1のuN+uDT4 (fcbb:bb00:101:e026::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 (ii-b) uA利用時のみ迂回可能なケース MX204 Cisco8011-2のuN (fcbb:bb00:30b::)、Cisco8011-2とACX7100-2を接続するリンクのuA (fcbb:bb00:e007::) を合成したuSID (fcbb:bb00:30b:e007::) を付与するBackup pathが確認できました。 user@MX204-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 1048574 Address: 0x3d5d2ae3e19c Next-hop reference count: 12 Kernel Table Id: 0 Next hop: ELNH Address 0x3d5d32226ebc weight 0x1, selected Next hop type: Chain, Next hop index: 534 Address: 0x3d5d32226ebc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d2db8289c SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x3d5d2db80bbc weight 0xf000 Next hop type: Chain, Next hop index: 634 Address: 0x3d5d2db80bbc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d32242ebc SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:e007:: (snip) MX204-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、MX204-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-2のuN+uA (fcbb:bb00:30b:e007::) とASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 ACX7024 Cisco8011-2のuN (fcbb:bb00:30b::)、Cisco8011-2とACX7100-2を接続するリンクのuA (fcbb:bb00:e007::) を合成したuSID (fcbb:bb00:30b:e007::) を付与するBackup pathが確認できました。 user@ACX7024-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 8080 Address: 0x5565e321485c Next-hop reference count: 11 Kernel Table Id: 0 Next hop: ELNH Address 0x5565e2c2c0dc weight 0x1, selected Next hop type: Chain, Next hop index: 8065 Address: 0x5565e2c2c0dc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e596399c SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x5565e2c2b81c weight 0xf000 Next hop type: Chain, Next hop index: 8074 Address: 0x5565e2c2b81c Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e5b0bd5c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:e007:: (snip) ACX7024-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、ACX7024-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-2のuN+uA (fcbb:bb00:30b:e007::) をDst Addressに、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) をSRHに付与したIPv6パケットが確認できました。 ASR9901 Cisco8011-1のuN (fcbb:bb00:10b::)、Cisco8011-1とACX7100-1を接続するリンクのuA (fcbb:bb00:e005::) を合成したuSID (fcbb:bb00:10b:e005::) を付与するBackup pathが確認できました。 RP/0/RSP0/CPU0:ASR9901-1#show route ipv6 fcbb:bb00:101::/48 detail Routing entry for fcbb:bb00:101::/48 Known via "isis core", distance 115, metric 30, SRv6-locator, type level-2 (snip) Routing Descriptor Blocks fe80::8652:34ff:fe30:fe00, from fd00:1::1, via TenGigE0/0/0/31, Protected Route metric is 30 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:1 Path ref count:0 NHID: 0x20008 (Ref: 25) Backup path id:65 fe80::eebb:78ff:fe0e:8c1b, from fd00:1::1, via TenGigE0/0/0/32, Backup (TI-LFA) Repair Node(s): fd00:1::a Route metric is 120 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:65 Path ref count:1 NHID: 0x20007 (Ref: 27) SRv6 Headend: H.Insert.Red [f3216], SID-list {fcbb:bb00:10b:e005::} (snip) ASR9901-1とACX7100-2の間のリンクを落としTI-LFAを動作させて、ASR9901-1とCisco8011-2の間のリンクでパケットキャプチャしました。結果、Cisco8011-1のuN+uA (fcbb:bb00:10b:e005::) とMX204-1のuN+uDT4 (fcbb:bb00:101:e026::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 uA利用時のみ迂回可能なケースのuSIDの付け方について MX204/ACX7024ではuA利用時のみ迂回可能なケースにおいて、2種類のuSIDの付け方が確認できました。1つめは上記で説明したuNとuAを付与するパターンになります。TI-LFAをするルーターと付与するuAの生成元ルーターが隣接する場合 (IS-ISのメトリック値がX=50、Y=10の場合) には、uAのみを付与する動作が確認できました。ASR9901についてはこの場合にもuNとuAを付与していました。以下にその結果を示します。 MX204 Cisco8011-1とCisco8011-2を接続するリンクのuA (fcbb:bb00:e003::) を付与するBackup pathが確認できました。 user@MX204-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 1048576 Address: 0x3d5d2ae34f5c Next-hop reference count: 12 Kernel Table Id: 0 Next hop: ELNH Address 0x3d5d3224403c weight 0x1, selected Next hop type: Chain, Next hop index: 534 Address: 0x3d5d3224403c Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d2db7e7dc SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x3d5d2db841fc weight 0xf000 Next hop type: Chain, Next hop index: 634 Address: 0x3d5d2db841fc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::1 dest fcbb:bb00:301::) Next hop: ELNH Address 0x3d5d322403dc SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::1 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:e003:: (snip) MX204-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、MX204-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-1のuA (fcbb:bb00:e003::) とASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 ACX7024 Cisco8011-1とCisco8011-2を接続するリンクのuA (fcbb:bb00:e003::) を付与するBackup pathが確認できました。 user@ACX7024-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 8082 Address: 0x5565e321499c Next-hop reference count: 11 Kernel Table Id: 0 Next hop: ELNH Address 0x5565e2c2943c weight 0x1, selected Next hop type: Chain, Next hop index: 8065 Address: 0x5565e2c2943c Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e59630dc SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x5565e2c2b1fc weight 0xf000 Next hop type: Chain, Next hop index: 8080 Address: 0x5565e2c2b1fc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e595be3c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:e003:: (snip) ACX7024-1とACX7100-1の間のリンクを落としTI-LFAを動作させて、ACX7024-1とCisco8011-1の間のリンクでパケットキャプチャしました。結果、Cisco8011-1のuA (fcbb:bb00:e003::) をDst Addressに、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) をSRHに付与したIPv6パケットが確認できました。 ASR9901 Cisco8011-2のuN (fcbb:bb00:30b::)、Cisco8011-2とCisco8011-1を接続するリンクのuA (fcbb:bb00:e003::) を合成したuSID (fcbb:bb00:30b:e003::) を付与するBackup pathが確認できました。 RP/0/RSP0/CPU0:ASR9901-1#show route ipv6 fcbb:bb00:101::/48 detail Routing entry for fcbb:bb00:101::/48 Known via "isis core", distance 115, metric 30, SRv6-locator, type level-2 (snip) Routing Descriptor Blocks fe80::8652:34ff:fe30:fe00, from fd00:1::1, via TenGigE0/0/0/31, Protected Route metric is 30 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:1 Path ref count:0 NHID: 0x20008 (Ref: 25) Backup path id:65 fe80::eebb:78ff:fe0e:8c1b, from fd00:1::1, via TenGigE0/0/0/32, Backup (TI-LFA) Repair Node(s): fd00:1::b Route metric is 120 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:65 Path ref count:1 NHID: 0x20007 (Ref: 27) SRv6 Headend: H.Insert.Red [f3216], SID-list {fcbb:bb00:30b:e003::} (snip) ASR9901-1とACX7100-2の間のリンクを落としTI-LFAを動作させて、ASR9901-1とCisco8011-2の間のリンクでパケットキャプチャしました。結果、Cisco8011-2のuN+uA (fcbb:bb00:30b:e003::) とMX204-1のuN+uDT4 (fcbb:bb00:101:e026::) を合成したuSIDをDst AddressにしたIPv6パケットが確認できました。 各ルーターのTI-LFAの違い PEルーターとして動作する場合の各ルーターのTI-LFAの違いを表にまとめると以下になります。 機種 uNのみで迂回可能なケース uA利用時のみ迂回可能なケース MX204 (Junos) TI-LFA用のuSID (uN) とVPN用のuSID (uN+uDT4) を合成し、Dst IPv6 Addressにエンコードする TI-LFAを行うルーターとTI-LFA用のuSIDの生成元のルーターが隣接しない場合は TI-LFA用のuSID (uN+uA) とVPN用のuSID (uN+uDT4) を合成し、Dst IPv6 Addressにエンコードする。 隣接する場合は TI-LFA用のuSID (uA) とVPN用のuSID (uN+uDT4) を合成し、Dst IPv6 Addressにエンコードする。 ACX7024 (Junos EVO) TI-LFA用のuSID (uN) をDst IPv6 Addressに、VPN用のuSID (uN+uDT4) をSRHにエンコードする TI-LFAを行うルーターとTI-LFA用のuSIDの生成元のルーターが隣接しない場合は TI-LFA用のuSID (uN+uA) をDst IPv6 Addressに、VPN用のuSID (uN+uDT4) をSRHにエンコードする。 隣接する場合は TI-LFA用のuSID (uA) をDst IPv6 Addressに、VPN用のuSID (uN+uDT4) をSRHにエンコードする。 ASR9901 (IOS XR) TI-LFA用のuSID (uN) とVPN用のuSID (uN+uDT4) を合成し、Dst IPv6 Addressにエンコードする TI-LFA用のuSID (uN+uA) とVPN用のuSID (uN+uDT4) を合成し、Dst IPv6 Addressにエンコードする。 Pルーターの動作 続いて、PルーターのTI-LFAの動作を検証しました。 Pルーターの動作はACX7100、Cisco8011について確認しました。 構成図 ACX7100 Cisco8011 (ii-a) uNのみで迂回可能なケース ACX7100 Cisco8011-2のuN (fcbb:bb00:30b::) を付与するBackup pathが確認できました。 user@ACX7100-1> show route table inet6.0 fcbb:bb00:301::/48 extensive inet6.0: 46 destinations, 46 routes (46 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) TSI: KRT in-kernel fcbb:bb00:301::/48 -> {list:fe80::8652:34ff:fe30:fdb0, Chain 0x561d4215abdc 7165} IS-IS level 2, SRv6 Loc Sid 0x561d4376ecd0 *IS-IS Preference: 18 Level: 2 Downbit: 512 Next hop type: List, Next hop index: 7173 Address: 0x561d3fb13f1c Next-hop reference count: 2 Kernel Table Id: 0 Next hop: ELNH Address 0x561d4215dbfc weight 0x1, selected Next hop type: Router, Next hop index: 7157 Address: 0x561d4215dbfc Next-hop reference count: 13, Next-hop session id: 5 Kernel Table Id: 0 Next hop: fe80::8652:34ff:fe30:fdb0 via et-0/0/1.0 weight 0x1 Next hop: ELNH Address 0x561d4215abdc weight 0xf000 Next hop type: Chain, Next hop index: 7165 Address: 0x561d4215abdc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::a dest fcbb:bb00:301::) Next hop: ELNH Address 0x561d42158a9c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::a Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:: (snip) ACX7100-1とACX7100-2の間のリンクを落としTI-LFAを動作させて、ACX7100-1とCisco8011-1の間のリンクでパケットキャプチャをしました。結果、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) のuSIDをDst AddressにしたIPv6パケットを、Cisco8011-2のuN (fcbb:bb00:30b::) をDst AddressにしたIPv6ヘッダでさらにEncapsulationしたパケットが確認できました。 Cisco8011 ACX7100-2のuN (fcbb:bb00:30a::) を付与するBackup pathが確認できました。 RP/0/RP0/CPU0:Cisco8011-1#show route ipv6 fcbb:bb00:301::/48 detail Routing entry for fcbb:bb00:301::/48 Known via "isis core", distance 115, metric 21, SRv6-locator, type level-2 (snip) Routing Descriptor Blocks fe80::8652:34ff:fe31:da94, from fd00:3::1, via TenGigE0/0/0/11, Backup (TI-LFA) Repair Node(s): fd00:3::a Route metric is 51 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:65 Path ref count:1 NHID: 0x2003b (Ref: 20) SRv6 Headend: H.Encaps.Red [f3216], SID-list {fcbb:bb00:30a::} MPLS eid:0x1000b00000001 fe80::eebb:78ff:fe0e:8c14, from fd00:3::1, via TenGigE0/0/0/4, Protected Route metric is 21 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:1 Path ref count:0 NHID: 0x2003c (Ref: 20) MPLS eid:0x1000b00000001 Backup path id:65 (snip) Cisco8011-1とCisco8011-2の間のリンクを落としTI-LFAを動作させて、ACX7100-1とCisco8011-1の間のリンクでパケットキャプチャをしました。結果、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) のuSIDをDst AddressにしたIPv6パケットを、ACX7100-2のuN (fcbb:bb00:30a::) をDst AddressにしたIPv6ヘッダでさらにEncapsulationしたパケットが確認できました。 (ii-b) uA利用時のみ迂回可能なケース ACX7100 Cisco8011-2のuN (fcbb:bb00:30b::)、Cisco8011-2とASR9901-1を接続するリンクのuA (fcbb:bb00:e001::) を合成したuSID (fcbb:bb00:30b:e001::) を付与するBackup pathが確認できました。 user@ACX7100-1> show route table inet6.0 fcbb:bb00:301::/48 extensive inet6.0: 46 destinations, 46 routes (46 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) TSI: KRT in-kernel fcbb:bb00:301::/48 -> {list:fe80::8652:34ff:fe30:fdb0, Chain 0x561d4215cedc 7238} IS-IS level 2, SRv6 Loc Sid 0x561d4376ecd0 *IS-IS Preference: 18 Level: 2 Downbit: 512 Next hop type: List, Next hop index: 7246 Address: 0x561d3fb1c61c Next-hop reference count: 2 Kernel Table Id: 0 Next hop: ELNH Address 0x561d4215d33c weight 0x1, selected Next hop type: Router, Next hop index: 7229 Address: 0x561d4215d33c Next-hop reference count: 12, Next-hop session id: 5 Kernel Table Id: 0 Next hop: fe80::8652:34ff:fe30:fdb0 via et-0/0/1.0 weight 0x1 Next hop: ELNH Address 0x561d4215cedc weight 0xf000 Next hop type: Chain, Next hop index: 7238 Address: 0x561d4215cedc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::a dest fcbb:bb00:301::) Next hop: ELNH Address 0x561d4215997c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::a Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30b:e001:: (snip) ACX7100-1とACX7100-2の間のリンクを落としTI-LFAを動作させて、ACX7100-1とCisco8011-1の間のリンクでパケットキャプチャをしました。結果、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) のuSIDをDst AddressにしたIPv6パケットを、Cisco8011-2のuN+uA (fcbb:bb00:30b:e001::) をDst AddressにしたIPv6ヘッダでさらにEncapsulationしたパケットが確認できました。 Cisco8011 ACX7100-2のuN (fcbb:bb00:30a::)、ACX7100-2とASR9901-1を接続するリンクのuA (fcbb:bb00:e03c::) を合成したuSID (fcbb:bb00:30a:e03c::) を付与するBackup pathが確認できました。 RP/0/RP0/CPU0:Cisco8011-1#show route ipv6 fcbb:bb00:301::/48 detail Routing entry for fcbb:bb00:301::/48 Known via "isis core", distance 115, metric 21, SRv6-locator, type level-2 (snip) Routing Descriptor Blocks fe80::8652:34ff:fe31:da94, from fd00:3::1, via TenGigE0/0/0/11, Backup (TI-LFA) Repair Node(s): fd00:3::1 Route metric is 71 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:65 Path ref count:1 NHID: 0x2003b (Ref: 20) SRv6 Headend: H.Encaps.Red [f3216], SID-list {fcbb:bb00:30a:e03c::} MPLS eid:0x1000b00000001 fe80::eebb:78ff:fe0e:8c14, from fd00:3::1, via TenGigE0/0/0/4, Protected Route metric is 21 Label: None Tunnel ID: None Binding Label: None Extended communities count: 0 Path id:1 Path ref count:0 NHID: 0x20040 (Ref: 20) MPLS eid:0x1000b00000001 Backup path id:65 (snip) Cisco8011-1とCisco8011-2の間のリンクを落としTI-LFAを動作させて、ACX7100-1とCisco8011-1の間のリンクでパケットキャプチャをしました。結果、ASR9901-1のuN+uDT4 (fcbb:bb00:301:e002::) のuSIDをDst AddressにしたIPv6パケットを、ACX7100-2のuN+uA (fcbb:bb00:30a:e03c::) をDst AddressにしたIPv6ヘッダでさらにEncapsulationしたパケットが確認できました。 uA利用時のみ迂回可能なケースのuSIDの付け方について PEルーターの動作時と同様に、ACX7100ではuA利用時のみ迂回可能なケースで、2種類のuSIDの付け方が確認できました。上記で説明したケースではuNとuAを付与していましたが、TI-LFAをするルーターと付与するuAの生成元ルーターが隣接する場合(IS-ISのメトリック値がX=50、Y=10の場合)には、uAのみを付与する動作を確認できました。一方、Cisco8011についてはこの場合にもuNとuAを付与していました。 PEルーターとPルーターでのカプセル化動作の違い PEルーターでTI-LFAする場合、VPNのuSIDとTI-LFAのuSIDがPEルーターで合成されたIPv6ヘッダがEncapsulationされます。一方、PルーターでTI-LFAする場合には、PEルーターでVPNのuSIDのついたIPv6ヘッダがEncapsulationされたのち、PルーターでTI-LFAのuSIDのついたIPv6ヘッダがEncapsulationされるため、二重Encapsulationとなります。そのため、Pルーターで追加されたIPv6ヘッダを外すためのUSD (Ultimate Segment Decapsulation) Flavorに対応したuSIDが必要となります。 USD Flavorの設定の有無による動作の違いを、以下の構成で確認しました。TI-LFAのBackup pathで使用するuSIDにUSD Flavorの設定が必要となるので、ACX7024-1の検証ではACX7100-2のuSID Locator、ACX7100-2の検証ではACX7100-1のuSID Locatorの設定を変更しました。 ACX7024-1におけるTI-LFAの検証では、ACX7024-1とCisco8011-1の間のリンクを落とし、TI-LFAを動作させました。この時、ACX7100-2のuN、ACX7100-2とCisco8011-2を接続するリンクのuAを合成したuSIDを付与するBackup Pathが計算されます。 ACX7100-2のuSID LocatorにUSD Flavorを設定しないと、ACX7024-1のinet6.3にはTI-LFAのBackup Pathが登録されましたが、inet6.0には登録されませんでした。 user@ACX7024-1> show route table inet6.3 fcbb:bb00:301::/48 extensive inet6.3: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) *SRV6-ISIS Preference: 14 Level: 2 Next hop type: List, Next hop index: 8076 Address: 0x5565e3212b9c Next-hop reference count: 9 Kernel Table Id: 0 Next hop: ELNH Address 0x5565e5959ddc weight 0x1, selected Next hop type: Chain, Next hop index: 8073 Address: 0x5565e5959ddc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e595d87c SRV6-Tunnel: Reduced-SRH Encap-mode Remove-Last-Sid Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:301:: (snip) Next hop: ELNH Address 0x5565e59630dc weight 0xf000 Next hop type: Chain, Next hop index: 8075 Address: 0x5565e59630dc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e2c28d3c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30a:e05d:: (snip) user@ACX7024-1> show route table inet6.0 fcbb:bb00:301::/48 extensive inet6.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) TSI: KRT in-kernel fcbb:bb00:301::/48 -> {fe80::6608:64ff:fe98:ad0c} IS-IS level 2, SRv6 Loc Sid 0x5565ee9c9570 *IS-IS Preference: 18 Level: 2 Downbit: 512 Next hop type: Router, Next hop index: 8072 Address: 0x5565e595d87c Next-hop reference count: 25, Next-hop session id: 5 Kernel Table Id: 0 Next hop: fe80::6608:64ff:fe98:ad0c via et-0/0/1.0 weight 0x1, selected Session Id: 5 State: <Active Int> Local AS: 64900 Age: 11 Metric: 31 Validation State: unverified ORR Generation-ID: 0 Task: IS-IS Announcement bits (3): 0-KRT 2-IS-IS 8-Resolve tree 8 AS path: I Ext Data: Prefix Attribute Flags:0x0 Thread: junos-main ACX7100-2のuSID LocatorにUSD Flavorを設定すると、ACX7024-1のinet6.0にもTI-LFAのBackup Pathが登録されるようになりました。 user@ACX7100-2# show | compare [edit routing-options source-packet-routing srv6 locator uSID-default micro-sid flavor] + usd; user@ACX7024-1> show route table inet6.0 fcbb:bb00:301::/48 extensive inet6.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden) fcbb:bb00:301::/48 (1 entry, 1 announced) TSI: KRT in-kernel fcbb:bb00:301::/48 -> {fe80::6608:64ff:fe98:ad0c} IS-IS level 2, SRv6 Loc Sid 0x5565ee9c9570 *IS-IS Preference: 18 Level: 2 Downbit: 512 Next hop type: List, Next hop index: 0 Address: 0x5565e321241c Next-hop reference count: 1 Kernel Table Id: 0 Next hop: ELNH Address 0x5565e595d87c weight 0x1, selected Next hop type: Router, Next hop index: 8072 Address: 0x5565e595d87c Next-hop reference count: 25, Next-hop session id: 5 Kernel Table Id: 0 Next hop: fe80::6608:64ff:fe98:ad0c via et-0/0/1.0 weight 0x1 Next hop: ELNH Address 0x5565e5b0b8fc weight 0xf000 Next hop type: Chain, Next hop index: 0 Address: 0x5565e5b0b8fc Next-hop reference count: 1, Next-hop session id: 0 Kernel Table Id: 0 Next hop: via Chain Tunnel Composite, SRv6 (src fd00:1::3 dest fcbb:bb00:301::) Next hop: ELNH Address 0x5565e2c28d3c SRV6-Tunnel: Reduced-SRH Encap-mode Src: fd00:1::3 Dest: fcbb:bb00:301:: Segment-list[0] fcbb:bb00:30a:e05d:: (snip) ACX7100を使った検証でも同様に、uSID LocatorにUSD Flavorを設定しないと、inet6.0にTI-LFAのBackup Pathが登録されませんでした。 また、ACX7024をPEルーターとして使った際には、uSID LocatorにUSD Flavorの設定の有無に関わらずTI-LFAが動作しました。しかし、ACX7100をPルーターとして使った際には、設定がないとTI-LFAが動作しませんでした。このことから、PEルーターではinet6.3の経路を、Pルーターではinet6.0の経路を参照すると考えられます。 続いて、Cisco機器におけるTI-LFAの動作についても検証しました。 ASR9901をPEルーターとして用いた際にも、Cisco8011をPルーターとして用いた際にも、uSID LocatorにUSD Flavorを設定しないと、TI-LFAは動作しませんでした。 Junos EVOでのTI-LFA Backup pathの参照テーブル Junos EVOをPEルーターとして使う場合、TI-LFAの設定に記載した load-balance per-packet がなくても障害を迂回できていましたが、Pルーターとして使う場合には設定をしないとTI-LFAは動作しませんでした。 ACX7024を使って上記設定の有無による比較検証をしました。 設定を入れない場合、デフォルトのFIBにはTI-LFAのBackup pathが登録されませんでした。 user@ACX7024-1> show route forwarding-table destination fcbb:bb00:301::/48 extensive Routing table: default.inet6 [Index: 0] Internet6: Destination: fcbb:bb00:301::/48 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: rt nh decoupled Next-hop type: software Index: 8065 Reference: 1 Next-hop interface: et-0/0/0.0 Index: 6000 Reference: 1 Nexthop: fe80::8652:34ff:fe31:daec Next-hop type: unicast Next-hop interface: et-0/0/0.0 (snip) 設定を入れると、FIBにはTI-LFAのBackup pathが登録されました。 user@ACX7024-1> show route forwarding-table destination fcbb:bb00:301::/48 extensive Routing table: default.inet6 [Index: 0] Internet6: Destination: fcbb:bb00:301::/48 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Flags: rt nh decoupled Next-hop type: unilist Index: 8114 Reference: 1 Next-hop type: software Index: 8065 Reference: 1 Next-hop interface: et-0/0/0.0 Weight: 0x1 Index: 6000 Reference: 1 Nexthop: fe80::8652:34ff:fe31:daec Next-hop type: unicast Next-hop interface: et-0/0/0.0 Next-hop type: composite Index: 8104 Reference: 1 Weight: 0xf000 Next-hop type: software Index: 8068 Reference: 1 Next-hop interface: et-0/0/1.0 Index: 6001 Reference: 1 Nexthop: fe80::6608:64ff:fe98:ad0c Next-hop type: unicast Next-hop interface: et-0/0/1.0 一方、VPN用のFIBには設定がなくてもTI-LFAのBackup pathが登録されていました。 user@ACX7024-1> show route forwarding-table destination 10.0.30.0/24 extensive (snip) Routing table: L3-Type5.inet [Index: 54] Internet: Destination: 10.0.30.0/24 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 P2mpidx: 0 Next-hop type: composite Index: 8102 Reference: 1 Next-hop type: indirect Index: 8101 Reference: 1 Next-hop type: unilist Index: 8122 Reference: 1 Next-hop type: composite Index: 8099 Reference: 1 Weight: 0x1 Next-hop type: software Index: 8065 Reference: 1 Next-hop interface: et-0/0/0.0 Index: 6000 Reference: 1 Nexthop: fe80::8652:34ff:fe31:daec Next-hop type: unicast Next-hop interface: et-0/0/0.0 Next-hop type: composite Index: 8113 Reference: 1 Weight: 0xf000 Next-hop type: software Index: 8068 Reference: 1 Next-hop interface: et-0/0/1.0 Index: 6001 Reference: 1 Nexthop: fe80::6608:64ff:fe98:ad0c Next-hop type: unicast Next-hop interface: et-0/0/1.0 (snip) 以上より、PルーターではデフォルトのFIBを参照すると考えられるため、設定がないとTI-LFAが動作せず、PEルーターではVPN用のFIBを参照するので設定の有無に関わらず、TI-LFAが動作したと考えられます。 また、Junosについては、MX204に設定を追加しなくてもPEルーターとしてTI-LFAが動作することは確認しましたが、Pルーターとしての動作は確認しておりません。 まとめ 本記事では、SRv6 uSID環境におけるTI-LFAの動作を、Junos、Junos EVO、IOS XRのマルチベンダー構成を用いて検証しました。今回の検証では、各ベンダーにおいて必要な機能や設定を有効化することで、TI-LFAによる障害の迂回が可能であることを確認しました。一方で、迂回時に使用するuSIDの構成やパケットへのエンコード方法には実装差があることを確認しました。また、PEルーターとPルーターではパケットへのエンコード方法が異なることを確認しました。 このように、TI-LFAの基本的な動作は共通しているものの、ベンダーやルーターの役割によって生成されるパケット形式に違いがあることを、今回の検証で明らかにしました。

本ブログは 2026 年 9 月 2 日に公開された AWS Blog “ Agentic security: Detection and response at machine speed ” を翻訳したものです。 この 1 年間、エンタープライズのセキュリティリーダーと対話を重ねる中で、はっきりしたことがあります。自律型 AI エージェントの台頭は、セキュリティポスチャにとってクラウドへの移行以来最大の変化だということです。あらゆる業界の組織が、ユーザーに代わって認証を行い、複数ステップのワークフローを実行し、インフラストラクチャをまたいで意思決定を下す AI エージェントを導入しています。しかも多くの場合、人間の承認を待つことはありません。セキュリティ運用もこの流れに追随する必要があります。 Amazon Web Services (AWS) では、セキュリティは AI の導入に後れを取るのではなく、一歩先を行って進化すべきだと考えています。この考えに基づき、AWS のチームは SANS Institute と協力して、 2026 Cloud Security Exchange eBook の新しい章を執筆しました。この章では、エンタープライズ規模でエージェンティックワークロードを保護するための実践的なフレームワークを紹介しています。 課題: 脅威は今やマシンスピードで進行する 従来のセキュリティは、入力と出力が予測可能な決定論的システムを前提に構築されてきました。エージェンティックワークロードは、この前提を崩します。同じプロンプトでも、あるリクエストではポリシーに準拠した応答を返し、次のリクエストではポリシーに違反する応答を返すことがあります。エージェントは、ユーザー、データ、ツールとやり取りしながら時間とともに振る舞いを変え、真の自律性をもって動作します。つまり、API に接続し、アクションを連鎖させ、独立して意思決定を行うのです。 こうした性質があるため、一度きりの評価を想定して設計されたセキュリティコントロールでは、もはや不十分です。検出と対応は、継続的に、そしてマシンスピードで機能しなければなりません。 この課題への対応が急務となっているのは、導入のスピードとセキュリティの成熟度の間にギャップがあるからです。80% の組織が AI を導入している一方で、AI のガバナンスを実施しているのはわずか 10% にとどまります。しかもエージェントは、ローコードツールを使う開発者を含め、拡大し続ける開発者層によって構築されており、既存のセキュリティプログラムを拡張して対処すべきガバナンス上の課題が生じています。 既に機能しているものを拡張する 良い知らせもあります。エージェンティックセキュリティは、まったくの白紙から始めるものではありません。アイデンティティガバナンス、最小権限、多層防御、バックアップとリカバリといった、セキュリティチームが既に実践している原則の上に築かれます。変わるのは、ワークロードが自律的かつ確率的である場合に、これらの原則をどう実装するかという点です。eBook の章では、次の 4 つの基礎領域を取り上げています。 エージェントのアイデンティティとガバナンス: すべてのエージェントには、永続的で広範なアクセス権ではなく、一時的でスコープを限定した認証情報を伴う独自のアイデンティティが必要です。これは ゼロトラストの原則 を AI エージェントに拡張するもので、すべてのリクエストが個別に認証および認可され、すべてのアクションに追跡可能な認可のチェーンが存在します。1 つのエージェントが、機密データへのアクセス、外部と通信する能力、信頼できないコンテンツにさらされる状態を併せ持つと、リスクプロファイルは大きく変わります。単一のコンポーネントがこの 3 つすべてを兼ね備えないようにする設計パターンを採用すれば、そのリスクを大幅に低減できます。 エージェンティックワークロードに向けた検出の進化: 人間のアクティビティパターンを想定して設計された静的でルールベースの検出では、エージェントの振る舞いに追随できません。組織に必要なのは、継続的な振る舞いの監視、エージェントの進化に応じた動的ベースライン、そして異常をリアルタイムで浮かび上がらせるオブザーバビリティです。 Amazon GuardDuty は、セキュリティシグナルを継続的に分析し、脅威が出現した時点で検出することで、これを既に実現しています。 スピードと精度のバランスを取った対応: 脅威がマシンスピードで進行する場合、対応は自動化され、かつ段階的でなければなりません。エージェントの振る舞いには、直ちに封じ込めるべきものもあれば、人間の判断を必要とするものもあります。この章で示す対応フレームワークでは、安全に自動化できるアクションと、エスカレーションが必要なアクションを区別しています。 単一エージェントからマルチエージェントエコシステムへ: エージェントは既にチームを構成し、サブタスクを委任し、アクセス権を交渉し、組織の境界をまたいで連携しています。この進化の各段階は、それ以前のすべてのセキュリティ要件を引き継ぎます。つまり、今日の基本的なチャットエージェントを保護している組織は、明日のマルチエージェントエコシステムに向けた土台を既に築いているということです。 エージェンティック AI 導入を可能にするセキュリティ 日々対話しているセキュリティリーダーが問うているのは、AI エージェントを導入するかどうかではありません。ビジネスのスピードを落とさずに、責任ある形で迅速に導入する方法です。 AWS はこの課題に対し、あらゆるレイヤーにセキュリティを組み込むというアプローチで取り組んでいます。AWS 上に構築されたエージェンティック AI は、ミッションクリティカルなワークロードを保護してきた 20 年近くの経験を引き継ぎます。 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub が連携して、継続的な脅威検出、脆弱性管理、統合されたセキュリティ運用を提供し、いずれもエージェンティックワークロード固有の特性に適応します。 これは、新しいセキュリティをゼロから構築するという話ではありません。お客様のチームが既に信頼しているセキュリティの基盤を、AI がますます高い自律性をもって動作する環境へと拡張するという話です。 フレームワークの全文を読む 2026 Cloud Security Exchange eBook に収録された AWS の章では、これらの各領域をさらに掘り下げ、具体的なアーキテクチャパターン、実装のガイダンス、そして評価段階、パイロット段階、大規模運用段階のいずれにあるセキュリティチームにも役立つフレームワークを紹介しています。 2026 Cloud Security Exchange eBook を読む: Agentic Security: Detection and Response at Machine Speed AWS のセキュリティサービスの詳細は、 AWS Cloud Security でご確認いただけます。また、 AI Security Framework では、AWS が適切なコントロールを、適切なレイヤーで、適切なフェーズで適用して AI ワークロードを保護する方法を包括的に紹介しています。 Gee Rittenhouse Gee は AWS の Agentic Security 担当バイスプレジデントです。MIT で博士号を取得し、エンタープライズセキュリティとクラウドの分野で豊富なリーダーシップ経験を持っています。以前は Skyhigh Security の CEO、および Cisco の Security Business Group のシニアバイスプレジデント兼ゼネラルマネージャーを務め、Cisco の世界規模のサイバーセキュリティ事業を統括していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。