サマリ
- SR-MPLS L3VPN における TI-LFA を用いた障害時の高速迂回の実現
- IOS XR + Junos の Multi-vendor 環境での動作検証
この記事は Multi-AS Segment Routing 検証連載の第 9 回です。目次は こちら
概要
イノベーションセンターの岩田です。 本記事では前回までに紹介してきた SR-MPLS L2/L3 VPN をサービスとして提供する際に欠かせない障害発生時の高速迂回手法についてご紹介します。
障害時の迂回動作について
これまでの記事で紹介してきた SR-MPLS 上での L2/L3 VPN を実際にサービスとして提供する際には、機器の故障などが発生した場合でも通信が断絶する時間を少なくするための設計をすることがサービス品質の観点において欠かせません。 通常、ネットワーク上のノードやリンクに障害があった場合、障害を検知したルーターは障害により変更された新しい IGP の LinkState 情報を他ルーターと交換します。 その後、各ルーターが迂回路を計算しルーティング情報を更新することで通信が復旧します。 下図は迂回など事前準備の無い NW において障害発生から復旧までの過程を表現した図です。 図中の ② 〜 ④ の過程にあたる、各ルーター上で IGP が経路を再計算し、トポロジーを収束させる過程には数秒を要し、その間通信が断絶することになります。
図中の ② 〜 ④ の過程で通信が断絶する時間をいかに少なくするかという点はサービスの品質向上に欠かせない考慮点となります。 このような障害時の課題を解決するための技術として次節で紹介する Fast Reroute があります。
Fast Reroute
Fast Reroute(FRR)は各ノードにおいて、IGP 情報をもとに保護したいノードやリンクに対するバックアップパスをあらかじめ計算しておき、それらに障害が発生した際、即座にバックアップパスへ切り替える事で通信が断絶する時間を短縮するための技術です。 下図は、FRR を適用したネットワークにおいて障害発生から復旧までの過程を表現したものです。 図中の ③ のように、障害を検知した後、IGP により再計算された経路に切り替わるまでの間、各ノードが自律的に判断し事前に計算した経路へ切り替えるため通信が断絶する時間を 50 ミリ秒以下に短縮できます。1
FRR の実現方式としては、Loop-Free Alternate(LFA)、Remote-LFA、Topology Independent-LFA(TI-LFA)などがあります。 本記事では Segment Routing(SR)を用いたネットワークで利用できる TI-LFA を用いて検証します。
TI-LFA
TI-LFA は SR domain で用いることができる FRR の手法の 1 つで、現在 Internet-Draft 2 として議論されています。 前節でも触れましたが、LFA はその名の通りループしないバックアップパスをあらかじめ計算し用意しておき、障害が発生した際、即座にその経路へ切り替えることで通信が断絶する時間を短くするための技術です。 LFA、Remote-LFA では適用するトポロジーによってはバックアップパスを計算できない課題がありますが、TI-LFA はトポロジーに依存することなくバックアップパスを計算できます。
検証
本章では TI-LFA を用いて保護したネットワークにおいて障害が発生した場合、FRR で 50ms 以内に迂回が実現されることを検証します。 また、比較のため保護していない場合についても検証し、FRR によって復旧時間が短縮されることも確認します。 検証は以下のようなトポロジーを用いて行います。
ベンダー間の TI-LFA 機能の互換性の検証のため IOS XR と Junos のルーターを交互に配置しています。
また本検証で用いる各ルーターの機種名と OS のバージョンは以下の通りです。
- rt01(ASR 9901、 IOS XR 7.6.1)
- rt02(MX204、 Junos 21.3R1.9)
- rt05(Cisco 8201、 IOS XR 7.5.1)
- rt06(PTX10001-36MR、 Junos 21.4R1.15-EVO)
- rt07(ASR 9902、 IOS XR 7.6.1)
復旧時間の計測は、 ping コマンドを用いて行います。 VM 間で ICMP パケットを一定間隔(10ms 毎)で送信し続けておき、 rt01 と rt02 間のリンクを切断した際にどの程度パケットがロスするかを計測する事で切り替えにかかった時間を測定します。 また各ベンダーの TI-LFA の動作確認を行いたいため、IOS XR(rt01)、Junos(rt02) のルーターそれぞれに対し検証します。
IOS XR ルーターについては以下の手順で確認します。
- vm01 から vm02 に対し、ping コマンドを用いて ICMP パケットを短い一定間隔で送信し続けておく
- vm02 では tcpdump コマンドを用いて ICMP の request パケットをキャプチャしておく
- rt01 と rt02 間リンクの rt02 側インタフェース(xe-0/1/0)をシャットダウンする事で擬似的な障害を発生させる
- インタフェースをシャットダウンした際に、vm01 から vm02 への ICMP パケットがどれ位ロスされたかを確かめる
Junos ルーターについては、以下の手順で確認します。
- vm02 から vm01 に対し、ping コマンドを用いて ICMP パケットを短い一定間隔で送信し続けておく
- vm01 では tcpdump コマンドを用いて ICMP の request パケットをキャプチャしておく
- rt01 と rt02 間リンクの rt01 側インタフェース(Te0/0/0/8)をシャットダウンする事で擬似的な障害を発生させる
- インタフェースをシャットダウンした際に、vm02 から vm01 への ICMP パケットがどれ位ロスされたかを確かめる
事前準備
まず、rt01 と rt02 間で VRF 100 による L3VPN を実装します。 L3VPN の設定は第 4 回の記事を参考にして以下を実施します。
- VRF 100 による L3VPN 作成
- BGP color の付与と広告
リンク切断時の復旧動作(FRR による保護なし)
IOS XR ルーターでの経路切り替え動作
リンク切断
以下の設定を追加し、rt01 と rt02 間リンクの rt02 側インターフェースである xe-0/1/0.0 をシャットダウンすることで擬似的に障害を発生させます。
[edit] user@rt02# show | compare [edit interfaces xe-0/1/0] + disable;
vm01 から vm02 へ ICMP request の送信
以下のコマンドを実行します。
user@vm01:~$ sudo ping -i 0.01 192.168.1.1
復旧に要した時間
vm02 において tcpdump コマンドを用いて、vm01 から受信した ICMP request パケットをキャプチャすると以下のような結果となりました。 rt06 を経由する経路へ切り替わると、ホップ数が 3 増加するため ttl は 3 減少します。 ttl に着目し障害が発生した時点でのパケットを探すと ICMP のシーケンス番号 が 355 から 368 の間でパケットロスが確認でき、経路が切り替わっている事が分かります。 よって、IOS XR では通信復旧に(369 - 354)* 10ms = 150ms 程度要したことが確認できました。
user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 03:17:55.457552 IP (tos 0x0, ttl 62, id 32297, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 352, length 64 03:17:55.473551 IP (tos 0x0, ttl 62, id 32301, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 353, length 64 03:17:55.489561 IP (tos 0x0, ttl 62, id 32305, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 354, length 64 03:17:55.729656 IP (tos 0x0, ttl 59, id 32344, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 369, length 64 03:17:55.745566 IP (tos 0x0, ttl 59, id 32348, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 370, length 64 03:17:55.761589 IP (tos 0x0, ttl 59, id 32352, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 31, seq 371, length 64
Junos ルーターでの経路切り替え動作
リンク切断
RP/0/RSP0/CPU0:rt01(config)#show commit changes diff precise Tue Sep 20 17:55:55.645 JST Building configuration... !! IOS XR Configuration 7.6.1 + interface TenGigE0/0/0/8 + shutdown ! end
vm02 から vm01 への ICMP request の送信
以下のコマンドを実行します。
user@vm02:~$ sudo ping -i 0.01 192.168.0.1
復旧に要した時間
vm01 において、vm02 から受信した ICMP の request パケット情報を確認します。 ICMP のシーケンス番号が 262 から 274 までのパケットが欠けていることから、Junos では通信復旧に (275 - 261) * 10ms = 140ms 程度要したことが確認できました。
user@vm01:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 03:23:40.910480 IP (tos 0x0, ttl 62, id 43550, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 259, length 64 03:23:40.926459 IP (tos 0x0, ttl 62, id 43553, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 260, length 64 03:23:40.942443 IP (tos 0x0, ttl 62, id 43555, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 261, length 64 03:23:41.166526 IP (tos 0x0, ttl 59, id 43589, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 275, length 64 03:23:41.182452 IP (tos 0x0, ttl 59, id 43592, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 276, length 64 03:23:41.198547 IP (tos 0x0, ttl 59, id 43593, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 58, seq 277, length 64
リンク切断時の復旧動作(FRR による保護あり)
続いて FRR(TI-LFA)を用いて rt01 と rt02 リンクを保護した場合を検証します。
TI-LFA の設定(IOS XR)
保護したいノードに対し以下の設定を追加します。
rt01(IOS XR)
RP/0/RSP0/CPU0:rt01#show running-config router isis 1 interface tenGigE 0/0/0/8 Tue Sep 20 16:52:44.640 JST router isis 1 interface TenGigE0/0/0/8 point-to-point address-family ipv4 unicast fast-reroute per-prefix fast-reroute per-prefix ti-lfa ! ! !
以下のように TeGigE0/0/0/8 が利用される 10.255.1.2/32 への経路に対し、バックアップパスが計算されている事が確認できます。
RP/0/RSP0/CPU0:rt01#show isis fast-reroute sr-only Tue Sep 20 16:57:00.430 JST IS-IS 1 IPv4 Unicast FRR backups Codes: L1 - level 1, L2 - level 2, ia - interarea (leaked into level 1) df - level 1 default (closest attached router), su - summary null C - connected, S - static, R - RIP, B - BGP, O - OSPF E - EIGRP, A - access/subscriber, M - mobile, a - application i - IS-IS (redistributed from another instance) D - Downstream, LC - Line card disjoint, NP - Node protecting P - Primary path, SRLG - SRLG disjoint, TM - Total metric via backup Maximum parallel path count: 8 L2 10.255.1.2/32 [10/115] via 10.1.2.2, TenGigE0/0/0/8, rt02, SRGB Base: 16000, Weight: 0 Backup path: TI-LFA (link), via 10.1.7.2, TenGigE0/0/0/9 rt06, SRGB Base: 16000, Weight: 0, Metric: 40 P node: rt05.00 [10.255.1.5], Label: 16005 Prefix label: 16002 Backup-src: rt02.00 L2 10.255.1.3/32 [40/115] via 10.1.2.2, TenGigE0/0/0/8, rt02, SRGB Base: 16000, Weight: 0 Backup path: LFA, via 10.1.7.2, TenGigE0/0/0/9, rt06, SRGB Base: 16000, Weight: 0, Metric: 50 L2 10.255.1.4/32 [20/115] via 10.1.7.2, TenGigE0/0/0/9, rt06, SRGB Base: 16000, Weight: 0 No FRR backup L2 10.255.1.5/32 [30/115] via 10.1.2.2, TenGigE0/0/0/8, rt02, SRGB Base: 16000, Weight: 0 Backup path: LFA, via 10.1.7.2, TenGigE0/0/0/9, rt06, SRGB Base: 16000, Weight: 0, Metric: 40 L2 10.255.1.6/32 [10/115] via 10.1.7.2, TenGigE0/0/0/9, rt06, SRGB Base: 16000, Weight: 0 No FRR backup L2 10.255.1.7/32 [30/115] via 10.1.7.2, TenGigE0/0/0/9, rt06, SRGB Base: 16000, Weight: 0 No FRR backup RP/0/RSP0/CPU0:rt01#
TI-LFA の設定(Junos)
FRR を利用するための設定を追加します。
rt02 (Junos)
set policy-options policy-statement lbpf then load-balance per-packet set routing-options forwarding-table export lbpf set protocols isis backup-spf-options use-post-convergence-lfa
保護したいノードに対し以下の設定を追加します。
rt02 (Junos)
set protocols isis interface xe-0/1/0.0 level 2 post-convergence-lfa
以下のように xe-0/1/0.0 が利用される 10.255.1.1/32 への経路に対し、バックアップパスが計算されている事が確認できます。
user@rt02> show route table inet.3 inet.3: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 10.255.1.1/32 *[L-ISIS/14] 00:03:24, metric 20 > to 10.1.2.1 via xe-0/1/0.0 to 10.1.3.2 via et-0/0/1.0, Push 16001, Push 16006(top) 10.255.1.3/32 *[L-ISIS/14] 00:03:24, metric 30 > to 10.1.3.2 via et-0/0/1.0, Push 16003 10.255.1.4/32 *[L-ISIS/14] 00:03:24, metric 30 > to 10.1.2.1 via xe-0/1/0.0, Push 16004 to 10.1.3.2 via et-0/0/1.0, Push 16004 10.255.1.5/32 *[L-ISIS/14] 00:03:24, metric 20 > to 10.1.3.2 via et-0/0/1.0 10.255.1.6/32 *[L-ISIS/14] 00:03:24, metric 20 > to 10.1.2.1 via xe-0/1/0.0, Push 16006 to 10.1.3.2 via et-0/0/1.0, Push 16006 10.255.1.7/32 *[L-ISIS/14] 00:03:24, metric 30 > to 10.1.3.2 via et-0/0/1.0, Push 16007
IOS XR ルーターでの経路切り替え動作
リンク切断
[edit] user@rt02# show | compare [edit interfaces xe-0/1/0] + disable;
vm01 から vm02 への ICMP request の送信
以下のコマンドを実行します。
user@vm01:~$ sudo ping -i 0.01 192.168.1.1
復旧に要した時間
vm02 において、vm01 から受信した ICMP の request パケット情報を確認します。 ICMP のシーケンス番号が 382 の パケットが欠けていることから、IOS XR では通信復旧に(383 - 381)* 10ms = 20ms 程度要したことが確認できました。
user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 03:04:30.433895 IP (tos 0x0, ttl 62, id 57521, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 378, length 64 03:04:30.449904 IP (tos 0x0, ttl 62, id 57525, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 379, length 64 03:04:30.465836 IP (tos 0x0, ttl 62, id 57528, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 380, length 64 03:04:30.481802 IP (tos 0x0, ttl 62, id 57531, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 381, length 64 03:04:30.513843 IP (tos 0x0, ttl 59, id 57536, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 383, length 64 03:04:30.529835 IP (tos 0x0, ttl 59, id 57540, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 384, length 64 03:04:30.545934 IP (tos 0x0, ttl 59, id 57541, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.0.1 > vm02: ICMP echo request, id 30, seq 385, length 64
Junos ルーター(rt02)での経路切り替え動作
リンク切断
RP/0/RSP0/CPU0:rt01(config)#show commit changes diff precise Tue Sep 20 15:26:25.506 JST Building configuration... !! IOS XR Configuration 7.6.1 + interface TenGigE0/0/0/8 + shutdown ! end
vm02 から vm01 への ICMP request の送信
以下のコマンドを実行します。
user@vm02:~$ sudo ping -i 0.01 192.168.0.1
復旧に要した時間
vm01 において、vm02 から受信した ICMP の request パケット情報を確認します。 パケットが欠けていないことから、Junos では通信復旧に (295 - 294) * 10ms = 10ms 程度要したことが確認できました。
user@vm01:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v 03:10:58.573764 IP (tos 0x0, ttl 62, id 14664, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 292, length 64 03:10:58.589749 IP (tos 0x0, ttl 62, id 14668, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 293, length 64 03:10:58.605753 IP (tos 0x0, ttl 62, id 14670, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 294, length 64 03:10:58.621777 IP (tos 0x0, ttl 59, id 14672, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 295, length 64 03:10:58.637835 IP (tos 0x0, ttl 59, id 14674, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 296, length 64 03:10:58.653771 IP (tos 0x0, ttl 59, id 14676, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.1 > vm01: ICMP echo request, id 57, seq 297, length 64
検証まとめ
障害が発生した際に、各ルーターで復旧に要した時間は以下のようになりました。 IOS XR、Junos 共に、FRR を用いて保護することで 50ms 以下で復旧できることが確認できました。
OS | TI-LFA(FRR) 設定なし | TI-LFA(FRR) 設定有り |
---|---|---|
IOS XR | 150ms 以内 | 20ms 以内 |
Junos | 140ms 以内 | 10ms 以内 |
まとめ
本記事では、SR-MPLS L3VPN における TI-LFA を用いた障害時の高速迂回手法について紹介しました。 また、Multi-vendor で TI-LFA を利用しない場合と利用した場合の動作検証をそれぞれ行い、TI-LFA を利用する事で障害時に復旧までの時間を 50ms 以内にできる事を確認しました。
次回の記事では PCEP を用いた SR Policy の適用方法について紹介予定です。
(2022/11/14 追記) 公開しました:[Multi-AS Segment Routing 検証連載 #10] PCE を用いた SR-TE の一元管理