IS-ISのリンク障害と経路切り替え
リンクステート型のルーティングプロトコルは、経路が1本使えなくなっても、別の経路があれば通信を続けられます。 IS-ISでは次の順に進みます。
- 障害に気づく
- 気づいたルータが自分のLSPを作り直して配る
- LSPを受け取った各ルータがSPFを計算し直す
- 新しい結果が転送テーブル（FIB）に入る
このうち1の「気づく」が最も時間を使います。IS-ISには気づき方が3通りあり、どれで気づくかによって 通信の止まる時間が0.14秒から28秒まで変わります。この記事では、同じ構成で障害の起こし方だけを変えて、 その差をIOS XRの実機で測ります。
| 気づき方 | きっかけ | 速さ |
|---|---|---|
| インタフェースのダウン | 自分のポートのリンクが落ちる | 最も速い |
| LSPの到着 | 障害に気づいた相手のLSPが、別の経路を回って届く | 速い |
| Holding Timeの満了 | 相手のIIHが届かなくなってから、規定の時間が過ぎる | 最も遅い（既定30秒） |
Holding Timeそのものの決まり方はIS-ISのHelloとHolding Time、 SPFやLSP生成の待ち時間はIS-ISの収束タイマーで解説しています。
実機での検証
検証環境
Cisco IOS XR（XRd 26.1.1）6台です。R1とR6の間に独立した2本の経路を用意しました。 上段（R1-R2-R3-R6）が合計30、下段（R1-R4-R5-R6）が合計60なので、通常は上段を通ります。
上段が使えなくなると中間のホップがR2・R3からR4・R5へまるごと入れ替わるので、
切り替わりがtracerouteで一目で分かります。全台が同じエリア49.0001のレベル2のみ、全リンクはpoint-to-pointです。
測定は障害を起こす前からpingを流し続けて行います。ping 6.6.6.6 source 1.1.1.1 count 600 interval 100 timeout 1
をR1とR6の両方から流し、落ちた発数で通信の止まっていた時間を求めます。応答が返らない発はtimeout 1の
1秒を待ってから次へ進むため、落ちた発数がほぼそのまま秒数になります。
検証のSTEP
| STEP | 操作 | 確かめること |
|---|---|---|
| 0 | 初期状態 | 上段を通ること |
| 1 | CMLのリンクを停止 | リンクが「切れた」ときの挙動 |
| 2 | リンクを復旧 | 戻るときの挙動 |
| 3 | 両端でshutdown | 両方のルータが自分でリンクの異常を知る場合 |
| 4 | shutdownを解除 | 復旧 |
| 5 | 片側だけshutdown | 落とされた側だけが知っている場合 |
| 6 | shutdownを解除 | 復旧 |
| 7 | R2をノードごと停止 | 装置が丸ごと落ちる場合 |
| 8 | R2を起動（最終状態） | 復旧 |
通常の経路（STEP 0）
R1からR6へは上段を通り、メトリックは30です。
RP/0/RP0/CPU0:R1#traceroute 6.6.6.6 source 1.1.1.1 timeout 1 probe 2 maxttl 6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
1 10.0.12.2 10 msec 5 msec
2 10.0.23.3 11 msec 8 msec
3 10.0.36.6 23 msec *
RP/0/RP0/CPU0:R1#show route isis
i L2 6.6.6.6/32 [115/30] via 10.0.12.2, 00:01:50, GigabitEthernet0/0/0/0気づき方①：インタフェースのダウン（STEP 3）
R1とR2の両方でshutdownすると、両方のルータが自分のポートの異常として即座に知ります。
syslogの理由はInterface state downです。
RP/0/RP0/CPU0:Sep 23 22:28:13.138 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R2 (GigabitEthernet0/0/0/0) (L2) Down, Interface state down 600発のpingのうち落ちたのは1発だけでした。キャプチャーの時刻で測ると、上段に最後のパケットが流れてから 下段に最初のパケットが流れるまで0.14秒です。
Type escape sequence to abort.
Sending 600, 100-byte ICMP Echos to 6.6.6.6 timeout is 1 seconds:
Success rate is 99 percent (599/600), round-trip min/avg/max = 8/14/174 ms経路は下段（メトリック60）に移ります。
i L2 6.6.6.6/32 [115/60] via 10.0.14.4, 00:01:24, GigabitEthernet0/0/0/1気づき方②：LSPの到着（STEP 5）
R2側だけをshutdownすると、知っているのはR2だけです。R1のインタフェースは落ちません。
それでも、落ちた発数は1発（0.14秒ではなく1.00秒）でした。R1はHolding Timeを待っていません。
理由はR2が作り直したLSPが、別の経路を回ってR1に届くからです。R2はR3へLSPを送り、それがR6・R5・R4を 経由してR1に届きます。R1はそのLSPでSPFを回し直し、上段が使えないことを知ります。
このとき、R1の隣接はまだUpのままです。隣接が落ちるのはHolding Timeが切れた後で、時刻を並べると はっきり分かります。
| 時刻（UTC） | 出来事 |
|---|---|
| 22:35:56.437 | R2がInterface state downで隣接を落とす（落とした側） |
| 22:35:57.45 | 下段に最初のパケットが流れる（＝R1の転送が切り替わった） |
| 22:36:23.728 | R1がHoldtime expiredで隣接を落とす（26.3秒後） |
RP/0/RP0/CPU0:Sep 23 22:36:23.728 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R2 (GigabitEthernet0/0/0/0) (L2) Down, Holdtime expired 隣接が落ちることと、経路が切り替わることは別です。転送はLSPが届いた時点で切り替わります。 ただしこれは迂回経路があるからで、2台を結ぶ線が1本しかない構成では、LSPを運ぶ道もないため Holding Timeを待つことになります。
気づき方③：Holding Timeの満了（STEP 1・7）
リンクが物理的に切れていなくても、フレームが流れなくなる障害があります。片側の光が出ていない、
途中のスイッチが黙って捨てている、といった場合です。このときルータのインタフェースはupのままなので、
IIHが届かなくなってHolding Timeが切れるまで気づけません。
CMLでリンクを停止すると、まさにこの状態になります。XRdのインタフェースはupのままで、
syslogの理由はHoldtime expiredです。
RP/0/RP0/CPU0:Sep 23 22:20:29.445 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R2 (GigabitEthernet0/0/0/0) (L2) Down, Holdtime expired 落ちた発数は28発、つまり約28秒の断です。既定のHolding Time（30秒）から、最後に届いたIIHからの 経過分を引いた値になります。
Type escape sequence to abort.
Sending 600, 100-byte ICMP Echos to 6.6.6.6 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!............................!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 95 percent (572/600), round-trip min/avg/max = 9/13/66 msR2を装置ごと停止したSTEP 7も同じ28発でした。装置が消えてもリンクダウンとしては伝わらないため、 両隣のR1とR3はHolding Timeで気づきます。
障害の起こし方による違い
| STEP | 障害の起こし方 | 落ちた発数 | 断の長さ | 気づいた理由 |
|---|---|---|---|---|
| 3 | 両端でshutdown | 1 / 600 | 0.14秒 | Interface state down |
| 5 | 片側だけshutdown | 1 / 600 | 1.00秒 | 相手のLSPが迂回して届いた |
| 1 | CMLのリンクを停止 | 28 / 600 | 約28秒 | Holdtime expired |
| 7 | R2をノードごと停止 | 28 / 600 | 約28秒 | Holdtime expired |
R1 → R6 と R6 → R1 で値は同じでした。復旧の操作（STEP 2・4・6）はいずれも600発すべて成功で、 上段へ戻るときにパケットは落ちていません。
数十秒の断が許されない設計では、Holding Timeに頼らない検知が要ります。Helloの間隔を詰める方法は IS-ISのHelloとHolding Timeで、ミリ秒単位で検知するBFDは IS-ISとBFDによる障害検知で扱います。
設計上の注意
- リンクが落ちない障害がある。インタフェースが
upのままフレームだけが失われる状態では、 IS-ISはHolding Timeが切れるまで気づけません。既定では30秒近く止まります - 検証環境で「ケーブルを抜いた」つもりの操作が、そうなっていないことがある。
CMLでリンクを停止してもXRdのインタフェースは
upのままで、実際にはHolding Time待ちの試験になります - 隣接がUpであることは、その経路が使われていることを意味しません。STEP 5では、隣接がUpのまま 転送だけが迂回に移りました
検証Configおよびshow結果
各STEPで6台すべてから取得しています。検証Configはこの..._run.txtです（最終状態は最後のSTEPのもの）。
| ファイル | 内容 |
|---|---|
..._show.txt | show version / show route isis / show isis interface / show isis neighbors detail / show isis topology / show isis database detail / show isis spf-log / show isis lsp-log / show isis adjacency-log ほか |
..._ping.txt | R1とR6から流した600発のping（障害の前から流し続けたもの） |
..._clear.txt | そのSTEPでクリアしたインタフェースカウンタの記録 |
..._log.txt | そのSTEPの範囲だけに絞ったshow logging |
..._run.txt | そのSTEP時点のshow running-config（＝そのSTEPの検証Config） |
..._commit.cfg | そのSTEPで実際にcommitされた設定だけ |
..._trace.txt | show isis trace。トレースバッファは起動時から累積するので、最後のSTEP 8のものが全STEPぶんを含んでいる（STEP 8の6台分だけを添付） |
STEP 0：初期状態
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | show | — | clear | — | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 1：CMLのリンクを停止
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | show | — | clear | — | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 2：リンクを復旧
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | show | — | clear | — | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 3：両端でshutdown
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | commit | log | run |
| R2 | show | — | clear | commit | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 4：shutdownを解除
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | commit | log | run |
| R2 | show | — | clear | commit | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 5：片側だけshutdown
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | show | — | clear | commit | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 6：shutdownを解除
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | show | — | clear | commit | log | run |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 7：R2をノードごと停止
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config |
|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run |
| R2 | — | — | — | — | — | — |
| R3 | show | — | clear | — | log | run |
| R4 | show | — | clear | — | log | run |
| R5 | show | — | clear | — | log | run |
| R6 | show | ping | clear | — | log | run |
STEP 8：R2を起動（最終状態）
| ルータ | show出力 | ping | clear | 投入した設定 | syslog | running-config | trace |
|---|---|---|---|---|---|---|---|
| R1 | show | ping | clear | — | log | run | trace |
| R2 | show | — | clear | — | log | run | trace |
| R3 | show | — | clear | — | log | run | trace |
| R4 | show | — | clear | — | log | run | trace |
| R5 | show | — | clear | — | log | run | trace |
| R6 | show | ping | clear | — | log | run | trace |
パケットキャプチャーはSTEPごとに取得しています（R1-R2は停止した区間なので、STEP 1・7では回収できていません）。
| STEP | R1-R2間 | R1-R4間 |
|---|---|---|
| 0 | pcap | pcap |
| 1 | — | pcap |
| 2 | — | pcap |
| 3 | pcap | pcap |
| 4 | pcap | pcap |
| 5 | pcap | pcap |
| 6 | pcap | pcap |
| 7 | — | pcap |
| 8 | — | pcap |
参考
| 標準 | タイトル | 概要 |
|---|---|---|
| ISO/IEC 10589:2002（第2版） | Intermediate System to Intermediate System intra-domain routeing information exchange protocol | 隣接の保持（holdingTimer）と、隣接が落ちたときにLSPを作り直す手順を定めている。本記事が参照したのは8.2節（隣接の維持）と7.3節（LSPの生成とフラッディング）。 |
| RFC 5303 | Three-Way Handshake for IS-IS Point-to-Point Adjacencies | ポイントツーポイントの3ウェイハンドシェイク。片側だけが落ちた状態を検出する仕組み。 |
関連記事
- IS-ISとは
- IS-ISのNSAPアドレスとNET（System ID）
- IS-ISの複数エリアアドレス（マルチホーミング）とエリアの統合・分割
- IS-ISのレベル1とレベル2（階層構造）
- IS-ISパケットの種類とヘッダーフォーマット
- IS-ISの隣接関係の確立と状態遷移
- IS-ISのDISと疑似ノード（Pseudonode）
- IS-ISのネットワークタイプ（broadcast / point-to-point）
- IS-ISのメトリック（narrow / wide）
- IS-ISの認証（hello-password / lsp-password）
- IS-ISのLSPとリンクステートデータベース
- IS-ISの主要TLV
- IS-ISのフラッディングとLSDB同期
- IS-ISのSPF計算と経路選択
- IS-ISのECMP（等コストマルチパス）
- IS-ISのATTビットとレベル1のデフォルトルート
- IS-ISのルートリークとup/downビット
- IS-ISの経路集約
- IS-ISのオーバーロードビット
- IS-ISのIPv6対応とマルチトポロジ（TLV 236 / MT ID 2）
- IS-ISのHelloとHolding Time
- IS-ISの収束タイマー（SPF / LSP生成）
- IS-ISのフラッディングのタイマー（LSP送信間隔・再送・CSNP / PSNP）
- IS-ISのリンク障害と経路切り替え
- IS-ISへの再配布（connected / static）
- IS-ISへのBGP経路の再配布