サマリ
- SR-MPLS 環境の障害発生時における、通信断を 50ms 以内に抑えた復旧を実現
- 障害点の隣接ノードでの Fast ReRoute（FRR）設定と、各ノードでの Microloop Avoidance、機器内のタイマ調整を実施
- SR OS + IOS XR + Junos の Multi-vendor 環境での動作検証
この記事は Multi-AS Segment Routing 検証連載の第 18 回です。過去の記事一覧は こちら
概要
イノベーションセンターの三島です。 第 9 回の記事では、IOS XR + Junos の Multi-vendor 構成での SR-MPLS 環境において障害が発生した際に、Fast ReRoute（FRR） を用いて通信断を 50ms 以内に抑える手法についてご紹介しました。 本記事では、SR OS を含めた構成において同様の手法の適用例を紹介するとともに、前回紹介できなかった Microloop Avoidance や トポロジー内のノード間での IGP のタイマー調整といったより詳しい対処ついても紹介します。
トポロジー変更時の通信断抑制と、実現のため対策すべき課題
障害などによって発生するトポロジー変更時の通信断は、あるノードにおいて経路の再計算にかかるまでの間と、それがネットワーク全体で完了するまで間、ネットワーク全体での経路の一貫性が取れていない期間に発生します。
具体的に言い換えると下記2つの課題に分割され、それらを合わせた通信断を 50ms 以内に抑える必要があります。
- 課題1. 障害発生直後に、障害点と隣接するノードにおいて経路の再計算が行われ、FIB が更新されて転送が再開されるまでの間に発生する通信断
- 課題2. 障害点の隣接ノードで経路の再計算が行われた後、他ノードの経路計算が完了するまでの間に発生する通信断
課題1. 障害発生直後に、障害点と隣接するノードにおいて経路の再計算が行われ、FIB が更新されて転送が再開されるまでの間に発生する通信断
課題1. については、連載記事第 9 回の「障害時の迂回動作について」の図にて紹介しています。 障害が発生した際に、隣接ノードでは障害の検知、IGP の再計算、再計算の結果をハードウェアに反映し転送再開、というステップで復旧に向かいます。 再計算から転送再開には100ミリ秒から秒単位の時間がかかるため、あらかじめバックアップ経路を計算しハードウェアに反映しておき使用するという手法をとります。 これが FRR です。
課題2. 障害点の隣接ノードで経路の再計算が行われた後、他ノードの経路計算が完了するまでの間に発生する通信断
課題2.の課題を図に示します。
IGP の経路計算処理は各ノードで非同期に行われるため、その実行タイミングは揃っていません。 そのため、リンク障害でトポロジーが変化した後では、変化後のトポロジーをもとに転送する経路計算が完了したノードと、変化前のトポロジーをもとに転送する経路計算が未完了なノードの混在した状況が発生します。 このような状況においては、特定のトポロジーにおいて Microloop と呼ばれるルーティングループが発生し通信断を引き起こします。 このタイミングをできるだけ揃える IGP のタイマ調整や、変化後のトポロジーの計算結果の使用を意図的に遅らせる Microloop Avoidance で対処します。
上の図は、障害発生後に rt26 でのみ経路計算が完了し、その他のノードでは未完了と仮定した場合の様子を示しています。 この状況で egress node である rt16 に向かう経路を考えます。 図中の 1. にて障害が発生した後、各ノードで経路計算が開始されます。 その後、2. では rt26 における経路の再計算が終わったため、next-hop が（もしくは outgoing interface が）rt11 に変わっています。 一方、3. の通り、rt11 は経路計算が完了していないため、next-hop が rt26 へのリンクを向いています。 そのため、rt26 は rt11 へとパケットを転送し、r11 は rt26 へとパケットを送ってしまいます。これにより、rt11 で 経路計算が完了するまでの間、4. の通り rt26 と rt11 の間で Microloop が発生します。
Microloop の発生有無は、トポロジーやタイミングによります。また、ホップ数やコストなどのトポロジー条件によっては、障害点とは離れたノードで発生する可能性もあります。 例えば先ほどの例では、コストによっては rt11 と rt23 との間で起こる可能性もありますし、また障害復旧に伴う経路計算においても Microloop は発生する可能性があります。
時系列に沿った各課題の整理
課題1・2を障害発生からの時系列で示すと下記のようになります。
この図は、ある2つのノードにおける障害発生時点からの時系列を示しています。 ノード A は障害発生箇所の隣接ノード、ノード B は障害箇所に直接接していないノードです。
障害が発生した後、隣接ノードであるノード A が障害を検知し、経路計算を開始するとともにトポロジーの変化を IGP により広告します。 また、経路広告を受け取ったノード B でも経路計算が開始されます。各ルーターにおける経路計算は、機器内部の IGP タイマーで定められた間隔毎に実施されます。
これまでに説明した通り、障害が発生した時点から、経路計算が完了するまでの期間は、課題1のループが生じます。 また、あるノードにおける経路計算が完了した時点から、全ノードでの経路計算完了までにかかる時間の期間には課題2. の Microloop が発生する可能性があります。
課題1. の対策としては FRR があります。 FRR は、ルーターがあらかじめ計算したバックアップパスを FIB に保持しておき、障害が発生した際、バックアップパスを利用することで、高速迂回を実現します。 第9回の記事でも紹介した通り、SR においては、TI-LFA と呼ばれる技術により、どのようなトポロジーであってもループフリーにバックアップパスを生成できます。
FRR による保護を、時系列の図に示しました。 図のように、FRR により通信を保護することで、障害発生地点の隣接ノードでの IGP 経路計算が完了するまでの間、バックアップパスを用いることでループを回避できます。 一方、FRR はそのノードの経路計算完了までを保護する技術であるため、経路計算が完了した後、その先のノードで発生する Microloop（課題2）は保護できません。
課題2. の対策としては、Microloop Avoidance と ルーター内の IGP 関連タイマーを調整する手法の2種が存在します。 以下の節にて、それぞれのポイントについて解説します。
Microloop Avoidance
Microloop Avoidance は、経路収束後に Microloop が発生する可能性がある場合に、タイマーに従い経路適用を遅延させることで他ノードの経路収束を待ち、Microloop を回避する技術です。
Microloop Avoidance の動作を図に示しました。 前提として、rt26 には各ノードの経路収束が現実的に完了するであろう時間分、Microloop Avoidance の遅延タイマーを設定しておきます。
障害に伴うトポロジー変更が発生した後、rt26 内で IS-IS 等での経路計算が完了した場合を想定します。 ここで、rt26 では Microloop Avoidance により、遅延タイマーの時間分だけ RIB あるいは FIB への経路更新を遅延させ、その代わりに Microloop を回避可能な経路が採用されるよう、新たなラベルを付与し送信します。
タイマーにより経路インストールを遅延させることで、rt11 がパケットを戻してしまうことを抑制できます。 この際、追加のラベルを付与して送信することで、rt23 より先のノードで経路計算が完了した場合でも、rt11 向けにパケットが戻ってくることを防止します。（rt11 より先での Microloop 防止）
rt11 での経路計算が完了すると、本来のベストパスでの転送が再開されます。
その後 rt26 で Microloop Avoidance の遅延タイマー分の時間が経過することにより、IS-IS で計算したベストパスを FIB にインストールし、Microloop Avoidance を終了します。
このように、経路収束が現実的に完了するであろう時間まで Microloop Avoidance の遅延を入れることにより、Microloop を回避できます。
Microploop Avoidance による保護を、時系列の図に示しました。 図のように、Microloop Avoidance は、あるノードでの経路計算が完了した後、事前にノード内で設定された時間分の保護を実施し、Microloop を回避します。 ただし、Microloop Avoidance はネットワーク上の全ノードの経路計算完了を検知できる技術ではないため、タイマーで設定された時間が完了するまでの間は保護が行われ続けます。
機器間のタイマー統一
ある機器における経路収束タイミングは、IGP での経路広告に加え、機器内の SPF 実行タイマーや IS-IS による LSP 生成タイマーなど、さまざまな要素が絡み決定されます。 これらのタイマーはベンダー毎に異なるため、経路計算のタイミングに差が生まれ Microloop が発生しやすくなります。
タイマーの設定による保護を、時系列の図に示しました。
図のように、IGP タイマーの値を十分短い時間に統一することにより、機器間の経路計算タイミングの差を削減できます。
これにより、ネットワーク内の全ノードで経路計算が完了するまでの時間を削減でき、課題2の発生時間を短縮可能です。
多くの機器では経路収束に関連するタイマーの値を設定できます。今回対象とするタイマーは下記の2つです。
- SPF wait : IS-IS による SPF 計算に対する遅延
- LSP wait : IS-IS の LSP 生成に対する遅延
IOS XR と Junos、そして SR OS において SPF wait / LSP wait のデフォルト値は以下の通りです。
| SR OS (config name) | IOS XR (config name) | Junos (config name) | SR OS |
|---|---|---|---|
| spf-max-wait | 5000 ms (spf-interval>maximum-wait) | 5000 ms (spf-options holddown) | 10000 ms |
| spf-initial-wait | 50 ms (spf-interval>initial-wait) | 200 ms (spf-options delay) | 1000 ms |
| spf-second-wait | 200 ms (spf-interval>secondary-wait) | 200 ms (spf-options delay) | 1000 ms |
| lsp-max-wait | 5000 ms (lsp-gen-interval>maximum-wait) | 不明 | 5000 ms |
| lsp-initial-wait | 50 ms (lsp-gen-interval>initial-wait) | 100 ms (lsp-interval) | 10 ms |
| lsp-second-wait | 200 ms (lsp-gen-interval>secondary-wait) | 100 ms (lsp-interval) | 1000 ms |
各パラメータの出典は以下の通りです。
- IOS XR
- Junos
- SR OS
特に SPF wait は IOS XR や Junos の標準設定では 100~200 ms 周期で更新されるのに対し、SR OS の標準動作では 1000 ms 周期での更新となっています。 そのため、IOS XR や Junos ルーターにおける経路収束と、SR OS ルーターにおける経路収束には最悪1秒程度の差が存在するため、Microloop の原因となります。
前節の通り、Microloop Avoidance を適切に設定することで、あるノードにおける経路収束後、Microloop Avoidance を防止できます。しかし、Microloop Avoidance 中はパケットに対する不要な追加 Encapsulation が行われるため、一般に長時間の Microloop Avoidance を設定することは好ましくありません。 一方、タイマー統一はあくまでルーター間の経路計算タイミングを近づけるアプローチであり、微小な期間の Microloop は防止できません。 しかし、タイマーを機器間で統一された短い値に設定しておくことで、機器間の経路計算タイミングの差を縮め、Microloop Avoidance の動作時間を短縮可能になります。 ただし、経路計算タイマーの短縮はルーターの負荷を向上させるため、それぞれの環境に合ったパラメータを設定する必要があります。
以降の章では、IOS XR・Junos・SR OS の混在環境において、FRR・Microloop Avoidance・タイマー調整のそれぞれの手法を検証していきます。
検証
本章では、これまでにご紹介したそれぞれの技術を適用し、障害発生時における 50ms 以内の通信断での通信を実現します。 実現にあたっては、概要章で触れた各技術を組み合わせることが必要です。ここでは、下記の順で検証します。
- 全ての技術を用いない場合の通信断の時間確認
- FRR を用いた、障害発生直後の通信断の抑制
- FRR と Microloop Avoidance を用いた、断時間 50ms の実現
- FRR と タイマー調整による、の抑制手法の紹介
上記の順で検証することで、障害発生後の通信断時間を、各種技術がどのように削減してくかを確かめます。
検証は以下のようなトポロジーを用いて行います。
本検証で用いる各ルーターの機種名と OS のバージョンは以下の通りです。
- rt11（NCS55A2: IOS XR 7.5.1）
- rt16（MX204: Junos 21.3R1.9）
- rt23（7750SR-1: SR OS 23.3.R1）
- rt24（7750SR-1: SR OS 23.3.R1）
- rt26（7750SR-1: SR OS 23.3.R1）
検証の流れ
復旧時間の計測は、 ping コマンドを用いて行います。 VM 間で ICMP パケットを一定間隔（10 ms 毎）で送信し続けておき、 rt16 と rt26 間のリンクを切断した際にどの程度パケットがロスするかを計測する事で切り替えにかかった時間を測定します。
以下の手順で確認します。
- vm01 から vm02 に対し、ping コマンドを用いて ICMP パケットを短い一定間隔（0.001秒）で送信し続けておく
- vm01 では tcpdump コマンドを用いて ICMP の request パケットをキャプチャしておく
- rt16 と rt26 間リンクの rt26 側インタフェース（xe-0/1/1）をシャットダウンする事で擬似的な障害を発生させる
- インタフェースをシャットダウンした際に、vm01 から vm02 への ICMP パケットロスがどの程度発生したかを確かめる
事前準備
rt16 と rt26 間で VRF 100 による L3VPN を実装します。 L3VPN の設定は第 4 回の記事や第 12 回の記事を参考にして以下を実施します。
- VRF 100 による L3VPN 作成
- BGP color の付与と広告
1.全ての技術を用いない場合の通信断の時間確認
まずは FRR により保護していない場合の復旧時間を計測します。
経路切り替え動作（SR OS）
状態確認
TI-LFA/FRR は未設定のためバックアップパスは作成されていません。
A:user@ar-rt26# tools dump router segment-routing tunnel | no-more
===================================================================================================
Legend: (B) - Backup Next-hop for Fast Re-Route
(D) - Duplicate
label stack is ordered from top-most to bottom-most
===================================================================================================
--------------------------------------------------------------------------------------------------+
Prefix |
Sid-Type Fwd-Type In-Label Prot-Inst(algoId) |
Next Hop(s) Out-Label(s) Interface/Tunnel-ID |
--------------------------------------------------------------------------------------------------+
10.255.2.1
Node Orig/Transit 16009 ISIS-0
10.2.17.1 16009 to_ar-rt11
10.255.2.2
Node Orig/Transit 16010 ISIS-0
10.2.17.1 16010 to_ar-rt11
10.255.2.3
Node Orig/Transit 16011 ISIS-0
10.2.17.1 3 to_ar-rt11
10.255.2.5
Node Orig/Transit 16013 ISIS-0
10.2.17.1 16013 to_ar-rt11
10.255.2.7
Node Orig/Transit 16015 ISIS-0
10.2.17.1 16015 to_ar-rt11
10.255.2.8
Node Orig/Transit 16016 ISIS-0
10.2.15.1 3 to_ar-rt16
10.255.2.23
Node Orig/Transit 16023 ISIS-0
10.2.17.1 16023 to_ar-rt11
10.255.2.24
Node Orig/Transit 16024 ISIS-0
10.2.17.1 16024 to_ar-rt11
10.255.2.25
Node Orig/Transit 16025 ISIS-0
10.2.17.1 16025 to_ar-rt11
10.255.2.26
Node Terminating 16026 IGP-Shared-0
10.2.15.1
Adjacency Transit 524282 ISIS-0
10.2.15.1 3 to_ar-rt16
10.2.17.1
Adjacency Transit 524285 ISIS-0
10.2.17.1 3 to_ar-rt11
--------------------------------------------------------------------------------------------------+
No. of Entries: 12
--------------------------------------------------------------------------------------------------+
vm01 から vm02 へ ICMP request の送信
以下のコマンドを実行します。
user@vm01:~$ sudo ping -i 0.001 192.168.40.1
リンク切断
以下の設定を追加し、rt16 と rt26 間リンクの rt16 側インターフェースである xe-0/1/1 をシャットダウンすることで擬似的に障害を発生させます。
[edit] user@rt16# show | compare [edit interfaces xe-0/1/1] + disable;
復旧に要した時間
vm02 において tcpdump コマンドを用いて、vm01 から受信した ICMP request パケットをキャプチャすると以下のような結果となりました。 rt11・rt23・rt24 を経由する経路へ切り替わると、ホップ数が 3 増加するため ttl は 3 減少します。（62 → 59） ttl に着目し障害が発生した時点でのパケットを探すと ICMP のシーケンス番号 が 4949 から 5061 の間でパケットロスが確認でき、経路が切り替わっている事が分かります。 よって、SR OS では非 FRR での通信復旧に（5061 - 4949） = 112 ms 程度要したことが確認できました。
user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v
22:12:02.360488 IP (tos 0x0, ttl 62, id 25319, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 4947, length 64
22:12:02.361488 IP (tos 0x0, ttl 62, id 25320, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 4948, length 64
22:12:02.362488 IP (tos 0x0, ttl 62, id 25321, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 4949, length 64
22:12:02.575251 IP (tos 0x0, ttl 59, id 25443, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 5061, length 64
22:12:02.576134 IP (tos 0x0, ttl 59, id 25444, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 5062, length 64
22:12:02.577131 IP (tos 0x0, ttl 59, id 25445, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 228, seq 5063, length 64
2. FRR を用いた、障害発生直後の通信断の抑制
続いて、 FRR（TI-LFA）を用いて rt26 の rt16 向けリンクを保護した場合を検証します。
第 9 回の記事では、IOS XR + Junos の 2 つのベンダー機器を用い、FRR・Topology Independent Loop-Free Alternate（TI-LFA）を用いた高速迂回を実現する方法を紹介しました。 今回は新たに Nokia SR OS（Service Router Operating System）における高速迂回手法と、各社の混在環境での検証を紹介します。
TI-LFA の設定（SR OS）
保護したいノードに対し以下の設定を追加します。
rt26（SR OS）
router isis loopfree-alternate ti-lfa node-protect
各経路に対しバックアップパスが計算されている事が確認できます。 rt16（10.255.2.8）に対しては、 16023・16016 の SID を積み増し、to_ar-rt11 のインターフェースから送出するバックアップパスが作成されました。
A:hanabi@ar-rt26# tools dump router segment-routing tunnel | no-more
===================================================================================================
Legend: (B) - Backup Next-hop for Fast Re-Route
(D) - Duplicate
label stack is ordered from top-most to bottom-most
===================================================================================================
--------------------------------------------------------------------------------------------------+
Prefix |
Sid-Type Fwd-Type In-Label Prot-Inst(algoId) |
Next Hop(s) Out-Label(s) Interface/Tunnel-ID |
--------------------------------------------------------------------------------------------------+
10.255.2.1
Node Orig/Transit 16009 ISIS-0
10.2.17.1 16009 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
16009
10.255.2.2
Node Orig/Transit 16010 ISIS-0
10.2.17.1 16010 to_ar-rt11
(B)10.2.15.1 16010 to_ar-rt16
10.255.2.3
Node Orig/Transit 16011 ISIS-0
10.2.17.1 3 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
16011
10.255.2.5
Node Orig/Transit 16013 ISIS-0
10.2.17.1 16013 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
16013
10.255.2.7
Node Orig/Transit 16015 ISIS-0
10.2.17.1 16015 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
16015
10.255.2.8
Node Orig/Transit 16016 ISIS-0
10.2.15.1 3 to_ar-rt16
(B)10.2.17.1 16023 to_ar-rt11
16016
10.255.2.23
Node Orig/Transit 16023 ISIS-0
10.2.17.1 16023 to_ar-rt11
(B)10.2.15.1 16023 to_ar-rt16
10.255.2.24
Node Orig/Transit 16024 ISIS-0
10.2.17.1 16024 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
10.255.2.25
Node Orig/Transit 16025 ISIS-0
10.2.17.1 16025 to_ar-rt11
(B)10.2.15.1 16025 to_ar-rt16
10.255.2.26
Node Terminating 16026 IGP-Shared-0
10.2.15.1
Adjacency Transit 524282 ISIS-0
10.2.15.1 3 to_ar-rt16
(B)10.2.17.1 16023 to_ar-rt11
16016
10.2.17.1
Adjacency Transit 524285 ISIS-0
10.2.17.1 3 to_ar-rt11
(B)10.2.15.1 16024 to_ar-rt16
16011
--------------------------------------------------------------------------------------------------+
No. of Entries: 12
--------------------------------------------------------------------------------------------------+
SR OS ルーターでの経路切り替え動作
vm01 から vm02 への ICMP request の送信
user@vm01:~$ sudo ping -i 0.001 192.168.40.1
リンク切断
[edit] user@rt02# show | compare [edit interfaces xe-0/1/1] + disable;
復旧に要した時間
vm02 において、vm01 から受信した ICMP の request パケット情報を確認します。 ICMP のシーケンス番号が 12637-12633 の パケットが欠けていることから、SR OS では通信復旧に 4 ms 程度要したことが確認できました。
user@vm02:~$ sudo tcpdump icmp[icmptype] == 8 -i ens192 -v
22:20:01.865557 IP (tos 0x0, ttl 62, id 60957, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12631, length 64
22:20:01.866556 IP (tos 0x0, ttl 62, id 60958, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12632, length 64
22:20:01.867560 IP (tos 0x0, ttl 62, id 60959, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12633, length 64
22:20:01.898894 IP (tos 0x0, ttl 59, id 60967, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12637, length 64
22:20:01.899881 IP (tos 0x0, ttl 59, id 60968, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12638, length 64
22:20:01.900860 IP (tos 0x0, ttl 59, id 60969, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.41.1 > vm02: ICMP echo request, id 229, seq 12639, length 64```
また、FRR 実施時は Backup Pathの通りに 16023・16016 の SID が積み増されていることも確認できました。
Nokia の SR-TE から FRR を扱う場合の注意点
SR OS にて lsp や lsp-template と FRR を併用する場合、FRR により追加される SID 数（ラベル数）の最大値を調整する必要があります。
TL-LFA の場合は 2 段の SID が積み増される可能性があるため、下記のように additional-frr-labels を設定します。
max-sr-labels {
additional-frr-labels 2
}
3. FRR と Microloop Avoidance を用いた、断時間 50ms の実現
Microloop Avoidance 未導入の場合
前節では、FRR により障害発生直後のパケットロスを防止できました。
しかし、解説の章で触れた通り、あるノードでの計算が完了した後で Microloop によるパケットロスが発生する可能性があります。 ここでは、rt26 での計算が完了した後、rt11 の経路計算が完了するまでの間に Microloop が発生することで、以下のように 95 パケットのロスが生じていることが確認できます。
64 bytes from 192.168.40.1: icmp_seq=10690 ttl=59 time=0.252 ms 64 bytes from 192.168.40.1: icmp_seq=10785 ttl=59 time=0.339 ms
Microloop Avoidance の導入
rt16 に以下の設定をし、30秒の間 Microloop Avoidance を適用させます。
user@ar-rt16# set protocols isis spf-options microloop-avoidance post-convergence-path delay 30000
[edit]
user@ar-rt16# show | compare
[edit protocols isis]
+ spf-options {
+ microloop-avoidance {
+ post-convergence-path {
+ delay 30000;
+ }
+ }
+ }
設定後、バックアップ経路から再計算後の経路に切り替わったタイミングでのパケットロスは確認できず、正しくMicroloop Avoidance が動作していることが確認できました。
4. （参考）FRR と タイマー調整による、経路計算のタイミング差抑制
rt26 のタイマーを IOS XR のものと同様の値に変更します。
[ro:/configure]
A:user@ar-rt26# /info router isis timers
spf-wait {
spf-max-wait 5000
spf-initial-wait 50
spf-second-wait 200
}
lsp-wait {
lsp-max-wait 5000
lsp-initial-wait 50
lsp-second-wait 200
}
これにより、各タイマーがベンダー間で共通化され、経路収束時間の差異を削減できます。
概要章でも述べた通り、タイマー調整はあくまで機器間の経路計算時間を統一することで、経路計算の完了タイミングを近づけるアプローチです。そのため、このアプローチでは Microloop の発生確率を下げることはできますが、回避はできません。 機器間のタイマーを統一した上で、前節の Microloop Avoidance を適切な時間分設定する上で、不要な encapsulation を最小限にしつつ、 Microloop を回避できます。
検証まとめ
それぞれの検証を通じ、IOS XR・Junos・SR OS の混在環境において、FRR と Microloop Avoidance を用いた保護により、障害が発生した際に 50 ms 以下で復旧できることを確認できました。
まとめ
本記事では、SR-MPLS 環境において、50ms 以内で通信を復旧する手法を解説しました。 その中で、障害発生直後に用いる FRR と、その後の機器毎の経路収束タイミングの差異によるループを防止する Microloop Avoidance や各種タイマーの統一手法を紹介し、IOS XR・Junos・SR OS を用いた動作検証を実施しました。
次回の記事では PCEP を用いた SR OS への SR Policy 適用方法について紹介予定です。
（2023/11/13 追記） 公開しました：[Multi-AS Segment Routing 検証連載 #19] SR OS での PCE を用いた LSP Provisioning
