隣接関係の確立と状態遷移

隣接関係の確立と状態遷移

IS-ISの隣接にはDown / Initializing / Upの3つの状態しかありません。OSPFの8段階と比べると拍子抜けするほど単純ですが、そのぶん、どういう条件なら隣接が成立するのかのほうに理解の重心があります。

本記事では、隣接がどのようにDown → Initializing → Upと進むのか、そしてISO/IEC 10589:2002が定める受理検査（何が一致していれば隣接が成立するのか）を、実機のログとキャプチャで確認しながら解説します。IIHそのもののフォーマットはIS-ISパケットの種類とヘッダーフォーマットで解説しています。

3つの状態

ISO/IEC 10589:2002はこの3つで隣接確立の手順を書いています。同規格の管理情報の定義にはinitializing / up / failed / downという4値の列挙型もありますが、プロトコルの動作としては上の3つです。

Initializingという状態が存在する理由は1つだけです。「相手のIIHが届いた」ことと「相手が自分のIIHを受け取れている」ことは別だからです。片方向しか通らないリンクでも前者は成立してしまうため、後者を確かめるまではUpにしません。

裏を返すと、Initializingは必ず通る段階ではありません。相手が先にこちらを認識していれば、最初に受け取ったIIHの時点で双方向が確認できるため、Downから直接Upになります。片方のルータだけを再起動した場合がこれにあたります。

「相手が自分を認識しているか」の確かめ方

その確かめ方が、リンク種別で違います。

出典の欄が示すとおり、ブロードキャストのほうは規格の時点で双方向確認の仕組みを持っていました。ISO/IEC 10589:2002の8.4.2.5.1は、LANのIIHを受け取ったら隣接を作って状態を「initialising」にし、相手が自分のSNPAアドレスを自分のIIHで報告してきたらUpにする、と明記しています。逆に自分のMACアドレスが相手のIIHから消えたら、状態をinitialisingへ戻します（8.4.2.5.3）。

ポイントツーポイントだけがこの仕組みを持っていませんでした。次節で見ます。

2ウェイと3ウェイ

ISO/IEC 10589:2002のポイントツーポイント隣接は2ウェイです。IIHが届いて受理検査を通れば、それだけで隣接がUpになります。相手が自分を見えているかを確かめる手段がないため、片方向しか通らないリンクでも隣接が成立してしまいます。

これを直したのがRFC 5303で、Point-to-Point Adjacency State（TLV 240）を追加しました。このTLVには自分から見た相手の状態と、相手のSystem IDが入ります。

Neighbor System IDが入っていないIIHを受け取ったルータは、「相手はまだ自分を認識していない」と判断してInitializingにとどまります。

なお、このTLVはISO/IEC 10589には存在しません。規格が定義するCODEは1〜10と14だけです（IS-ISパケットの種類とヘッダーフォーマットを参照してください）。

隣接が成立する条件

隣接がUpになる前に、IIHはいくつもの検査を通ります。ISO/IEC 10589:2002が定める順序は次のとおりです。

すべてのIIHに共通する受理検査

ポイントツーポイント（8.2.5.1）とブロードキャスト（8.4.2.1）でまったく同じ3つが定められています。

認証については認証で扱います。

レベル1とレベル2で非対称

共通の検査を通ったあと、レベルによって検査の中身が大きく変わります。

「エリアが違うとレベル1の隣接は張れないが、レベル2の隣接は張れる」という挙動の根拠がこの非対称性です（レベルの考え方はレベル1とレベル2で解説しています）。レベル2はエリアをまたいで経路を運ぶためのものなので、エリアが一致することを条件にしては本末転倒になります。

なおMaximum Area Addressesの検査には規格自身が例外を認めていて、「そのISが3しか実装していない場合はこの検査を省いてよい」とされています（8.4.2.2 b）。Cisco実装は3固定なので、この検査は実質的に働きません（NSAPアドレスとNETを参照してください）。

Circuit Type と is-type の組み合わせ

最後に、IIHのCircuit Typeフィールドと自分のis-typeの組み合わせが判定されます。ISO/IEC 10589:2002は表5〜表8でこれを状態遷移表として与えています。たとえばエリアが一致している場合のレベル1は表5です。

Circuit Typeは、IIHの固定部にある1バイトの下位2ビットです（IIHのフォーマットはIS-ISパケットの種類とヘッダーフォーマットで解説しています）。is-typeの設定がそのままこのビットになるため、両端のis-typeの組み合わせが隣接のレベルを決めることになります。

MTUは「検査」ではなく副作用で効く

ここまでの検査にMTUは出てきません。IS-ISにはOSPFのDBDのようなMTUフィールドがなく、代わりにIIHのパディングで間接的に検出します。

IIHはmaxsize − 1バイト以上になるまでTLV 8で埋められて送られます（8.2.3 / 8.4.2）。MTUの小さい側はこの大きなIIHを受け取れないので、そもそもIIHが届かず、隣接が成立しません。検査に落ちるのではなく、検査に到達しないわけです。

ここでmaxsizeは「リンクのブロックサイズ」と「自分が出すLSPの最大サイズ」の大きいほうと定められています。リンクのMTUだけを下げても、LSPの最大サイズ（既定1492）が変わらなければパディングの目標値は1492のままです。MTUを下げた側も、自分のMTUより大きいIIHを送り続けることになります。

MTUが片側だけ小さい場合、両端の見え方は非対称になります。

パディングそのものの仕組みはIS-ISパケットの種類とヘッダーフォーマットで解説しています。本記事のSTEP 2・3では、この動作を実機で確認します。

実機での検証

検証環境

ブロードキャストとポイントツーポイントの両方を含む構成にしました。

R1とR2は同じエリア49.0001のブロードキャストセグメント（10.1.0.0/24）で、R2とR3はpoint-to-point（10.2.3.0/24）です。R3は別エリア49.0002なので、R2–R3はレベル2の隣接になります。

IS-IS 1 Level-1 adjacencies:
System Id      Interface                SNPA           State Hold Changed  NSF IPv4 IPv6
                                                                               BFD  BFD 
R1             Gi0/0/0/0                5254.0054.6449 Up    26   00:04:12 Yes None None
  Area Address:           49.0001
  Neighbor IPv4 Address:  10.1.0.1*
  DIS Priority:           64
  Local Priority:         64 (DIS)
  Neighbor Priority:      64

IS-IS 1 Level-2 adjacencies:
System Id      Interface                SNPA           State Hold Changed  NSF IPv4 IPv6
                                                                               BFD  BFD 
R3             Gi0/0/0/1                *PtoP*         Up    27   00:04:12 Yes None None
  Area Address:           49.0002
  Neighbor IPv4 Address:  10.2.3.3*

R2から見て、LAN側のR1がレベル1、P2P側のR3がレベル2の隣接になっています。Changed欄はその状態になってからの経過時間です。R3のArea Addressが49.0002と自分とは違うエリアなのに隣接が成立しているのは、前節で見たとおりレベル2がエリアを検査しないためです。

検証のSTEP

検証にあたって、IOS XRの2つのコマンドが効きました。

show isis traceはバッファ名ではなく重大度（all / detailed / only / severe / standard）で選ぶ形式です。allは4000行近くになるので、装置側で| includeを付けて絞ります。

状態遷移を追う（STEP 1）

R2とR3でprocess restart isisを実行し、隣接が張り直される様子を見ます。

状態遷移はログにそのまま残る

  IS-IS 1  Level 1  Adjacency Log                Capacity: 100, Size: 1

When          System          Interface          State   Details
--- Wed Sep  9 2026 ---
03:52:04.514  R1              Gi0/0/0/0          d -> u  New adjacency
                                                         IPv4 Unicast Up

  IS-IS 1  Level 2  Adjacency Log                Capacity: 100, Size: 2

When          System          Interface          State   Details
--- Wed Sep  9 2026 ---
03:52:04.902  R3              Gi0/0/0/1          d -> i  
03:52:05.510  R3              Gi0/0/0/1          i -> u  New adjacency
                                                         IPv4 Unicast Up

d / i / uがそれぞれDown / Initializing / Upです。P2P側のR3とはd -> iのあと約0.6秒でi -> uへ進んでいます。

LAN側のR1とはd -> uで、Initializingを経由していません。このSTEPで再起動したのはR2とR3だけで、R1は動き続けていたためです。R1は再起動前からTLV 6にR2のMACアドレスを載せ続けているので、R2は復帰後に受け取った最初のIIHで「R1は自分を見えている」と確認でき、Initializingにとどまる必要がありません。

比較のために、ラボの初回起動時（3台が同時に立ち上がった）のログを見ると、こちらは両方とも2段階を踏んでいます。

  IS-IS 1  Level 1  Adjacency Log                Capacity: 100, Size: 2

When          System          Interface          State   Details
--- Wed Sep  9 2026 ---
03:46:26.689  R1              Gi0/0/0/0          d -> i  
03:46:29.679  R1              Gi0/0/0/0          i -> u  New adjacency
                                                         IPv4 Unicast Up

前半で述べた「Initializingは相手がまだ自分を知らないときにだけ現れる」という動作が、この2つのログの差として出ています。

3ウェイハンドシェイクをキャプチャで追う

R2–R3リンクのキャプチャに、TLV 240のAdjacency Stateが変わっていく様子がそのまま残りました。連続する4つのIIHです。

ISIS HELLO
    .... ..11 = Circuit type: Level 1 and 2 (0x3)
    0000 00.. = Reserved: 0x00
    SystemID {Sender of PDU}: 0020.0200.2002
    Holding timer: 30
    PDU length: 1497
    Local circuit ID: 0
    Point-to-point Adjacency State (t=240, l=5)
        Type: 240
        Length: 5
        Adjacency State: Down (2)
        Extended Local circuit ID: 0x00000005

再起動直後のR2が送ったIIHです。Length: 5で、Neighbor SystemIDが入っていません。RFC 5303はこの状態のときTLVを短くしてよいと定めており、「私はまだ誰も見えていない」がそのまま長さに出ています。

ISIS HELLO
    .... ..11 = Circuit type: Level 1 and 2 (0x3)
    0000 00.. = Reserved: 0x00
    SystemID {Sender of PDU}: 0030.0300.3003
    Holding timer: 30
    PDU length: 1497
    Local circuit ID: 0
    Point-to-point Adjacency State (t=240, l=15)
        Type: 240
        Length: 15
        Adjacency State: Initializing (1)
        Extended Local circuit ID: 0x00000002
        Neighbor SystemID: 0020.0200.2002
        Neighbor Extended Local circuit ID: 0x00000005

No.9を受け取ったR3の返答です。Lengthが15に伸び、Neighbor SystemID: 0020.0200.2002（R2）が入りました。これが「あなたを見えています」の表明です。

このIIHを受け取ったR2は、自分のSystem IDが載っていることを確認してUpになります。続くNo.11でR2もInitializing＋Neighbor SystemID: 0030.0300.3003を返し、それを見たR3もUpになりました。

ISIS HELLO
    .... ..11 = Circuit type: Level 1 and 2 (0x3)
    0000 00.. = Reserved: 0x00
    SystemID {Sender of PDU}: 0030.0300.3003
    Holding timer: 30
    PDU length: 1497
    Local circuit ID: 0
    Point-to-point Adjacency State (t=240, l=15)
        Type: 240
        Length: 15
        Adjacency State: Up (0)
        Extended Local circuit ID: 0x00000002
        Neighbor SystemID: 0020.0200.2002
        Neighbor Extended Local circuit ID: 0x00000005

4つのIIHをまとめると次のようになります。3ウェイという名前のとおり、Upに達するまでに3回の往復が必要です。

ルータ自身も3ウェイだと言っている

show isis traceを見ると、この判定がそのまま記録されています。

Sep  9 03:46:23.771 isis/1/hlo ... isis_osi_send_p2p_hello:1168      ADJ_SEND_P2P_DO_IETF_3WAY Gi0/0/0/1 L1L2
Sep  9 03:46:33.001 isis/1/hlo ... isis_osi_adj_p2p_3way_validate:5244  ADJ_RECV_P2P_3WAY_IETF_ACCEPT_MISSING L1L2 Gi0/0/0/1 5254.005f.3ecc P2P IIH
Sep  9 03:46:33.302 isis/1/hlo ... isis_osi_send_p2p_hello:1168      ADJ_SEND_P2P_DO_IETF_3WAY Gi0/0/0/1 L1L2
Sep  9 03:46:33.612 isis/1/hlo ... isis_osi_adj_p2p_3way_validate:5179  ADJ_RECV_P2P_3WAY_NBR_ADJ_STATE_CHANGE L1L2 Gi0/0/0/1 5254.005f.3ecc P2P IIH
Sep  9 03:46:33.612 isis/1/hlo ... isis_osi_adj_p2p_3way_validate:5337  ADJ_RECV_P2P_3WAY_IETF_ACCEPT_MATCH L1L2 Gi0/0/0/1 5254.005f.3ecc P2P IIH

MISSINGのあとにMATCHが来る流れが、上のキャプチャのNo.9→No.10にそのまま対応します。IETFという語が入っているのは、これがISO/IEC 10589ではなくIETFの拡張（RFC 5303）による動作だからです。

MTUを食い違わせる（STEP 2）

R3側のインタフェースだけMTUを小さくします。

interface GigabitEthernet0/0/0/0
 mtu 1400

IOS XRのインタフェースMTUは64から65535まで指定でき、既定は1514です。ここから14バイトのイーサネットヘッダーと3バイトのLLCヘッダーを引いた値がIS-ISから見えるMTUになります。既定の1514なら1497、1400にすると1383です。

結果は左右で違った

RP/0/RP0/CPU0:R3#show isis neighbors
Wed Sep  9 04:01:07.839 UTC

IS-IS 1 neighbors:
System Id      Interface        SNPA           State Holdtime Type IETF-NSF

RP/0/RP0/CPU0:R2#show isis neighbors
Wed Sep  9 04:00:52.063 UTC

IS-IS 1 neighbors:
System Id      Interface        SNPA           State Holdtime Type IETF-NSF
R1             Gi0/0/0/0        5254.0054.6449 Up    28       L1   Capable 
R3             Gi0/0/0/1        *PtoP*         Init  25       L2   Capable 

Total neighbor count: 2

MTUを小さくしたR3は隣接がゼロ、MTUが大きいままのR2はInitで止まりました。

理由は単純です。R2はパディングされた1497オクテットのIIHを送りますが、R3のMTUは1383しかないので受け取れません。R3から見れば相手は存在しないのと同じです。一方でR3のIIHはR2に届くため、R2はR3の存在を知ることができます。しかしR3のIIHにはNeighbor SystemIDが入っていない（R3はR2を見えていないので当然です）ため、R2は「相手はまだ自分を認識していない」と判断してInitializingにとどまります。

R3は理由まで教えてくれます。

  Media Type:               P2P
  Circuit Number:           0
  Last IIH Received:        03:56:37 (00:04:29 ago), 1497 octets
  Last PDU Rejected:        04:01:02 (5.57 sec ago), 1497 octets, P2P IIH, PDU larger than our MTU
  
  CLNS I/O
    Protocol State:         Up
    MTU:                    1383 (MTU is too small: lsp-mtu is 1492)

PDU larger than our MTU — R2の1497オクテットのIIHを、大きすぎるという理由で捨てています。Last IIH Receivedの時刻がMTUを変える前で止まっていることも、それ以降1つも受け取れていないことを示しています。

隣接を落としたのは3ウェイハンドシェイクだった

R2側のログに、この事象の記録が残りました。

03:52:04.902  R3              Gi0/0/0/1          d -> i  
03:52:05.510  R3              Gi0/0/0/1          i -> u  New adjacency
                                                         IPv4 Unicast Up
03:57:08.033  R3              Gi0/0/0/1          u -> i  3-way state down
                                                         IPv4 Unicast Down

理由の欄が3-way state downとなっています。R2はR3のIIHを受け取り続けていて、Holding Timeは満了していません。それでも隣接を落としたのは、そのIIHから自分のSystem IDが消えたからです。

ISO/IEC 10589:2002が定めるとおりの2ウェイ動作であれば、R2は「R3からIIHが届いている」という理由だけで隣接をUpのままにします。R3側は何も受け取れていないのに、R2だけがUpだと思い込む片方向の隣接が成立してしまう状態です。R2はそこへLSPを送り、R3は応答せず、経路計算だけが狂います。

2ウェイと3ウェイで述べたとおり、RFC 5303が塞いだのはこの穴です。その働きがログの1行として現れています。

なお、R3側のログでは同じ事象が別の理由で記録されています。

03:52:04.805  R2              Gi0/0/0/0          d -> i  
03:52:05.206  R2              Gi0/0/0/0          i -> u   New adjacency
03:57:07.824  R2              Gi0/0/0/0          u -> d   Holdtime expired
                                                          IPv4 Unicast Down

R3はIIHを1つも受け取れないので、Holding Timeの満了で落ちています。同じ1つのMTU不一致が、片側では3-way state down、もう片側ではHoldtime expiredとして現れるわけです。

パディングされたIIHは一方向にしか流れていない

キャプチャを見ると、この状態が定常的に続いていることが分かります。

$ tshark -r isis-adj-mtu.pcap -n -Y "isis.type == 17" \
    -T fields -e eth.src -e frame.len -e isis.hello.adjacency_state | sort | uniq -c
   2 52:54:00:5f:3e:cc	1509	0
  18 52:54:00:5f:3e:cc	1509	2
   2 52:54:00:5f:3e:cc	1514	0
   4 52:54:00:93:4c:03	1514	0
  18 52:54:00:93:4c:03	1514	1

-Y "isis.type == 17"でポイントツーポイントのIIHだけに絞り、-T fields -e ...で指定した3つのフィールドをタブ区切りで並べたものを、sort | uniq -cで同じ組み合わせごとに数えています。各列の意味は次のとおりです。

5行を時間順に読み直すと、MTUを変える前後の移り変わりがそのまま出ています。

上2つと3つ目はキャプチャ開始からの十数秒に現れるだけで、残りの36パケットはすべて下2行の状態です。R2が1514バイトでInitializing、R3が1509バイトでDownを送り続け、互いに相手を認めないまま平行線をたどっています。

3つ目の行（R3が1509バイトでまだUp）は、フレーム長が縮んでから隣接が落ちるまでの数秒間にあたります。MTUの変更はR3の送信側に即座に効きますが、隣接が落ちるのはR2のIIHが届かなくなったことに気づいてからなので、わずかな時間差が生まれます。

R3のIIHが1509バイトで、自分のMTUである1400より大きいのは、MTUは「検査」ではなく副作用で効くで述べたmaxsizeの定義によるものです。R3のリンクは1383に下がりましたが、LSPの最大サイズは既定の1492のままなので、maxsizeは1492のままです。だからR3は1492オクテット（フレームで1509バイト）まで詰め続けます。

XRのMTU: 1383 (MTU is too small: lsp-mtu is 1492)という警告は、これと同じことを別の言い方で伝えています。このリンクは、自分が出すつもりのLSPを運べない。

パディングを止めるとどうなるか（STEP 3）

MTUを食い違わせたまま、両側のIS-ISインタフェースにパディングの無効化を入れます。

router isis 1
 interface GigabitEthernet0/0/0/1      （R3では GigabitEthernet0/0/0/0）
  hello-padding disable

RP/0/RP0/CPU0:R3#show isis neighbors
Wed Sep  9 04:04:33.181 UTC

IS-IS 1 neighbors:
System Id      Interface        SNPA           State Holdtime Type IETF-NSF
R2             Gi0/0/0/0        *PtoP*         Up    24       L2   Capable 

Total neighbor count: 1

隣接が上がりました。IIHが小さくなってR3のMTUに収まるようになったためです。R3側のログにも復活が記録されています。

03:57:07.824  R2              Gi0/0/0/0          u -> d   Holdtime expired
                                                          IPv4 Unicast Down
04:01:44.110  R2              Gi0/0/0/0          d -> i  
04:01:44.718  R2              Gi0/0/0/0          i -> u   New adjacency
                                                          IPv4 Unicast Up

経路も入りました。

RP/0/RP0/CPU0:R3#show route isis
Wed Sep  9 04:04:33.732 UTC

i L2 1.1.1.1/32 [115/20] via 10.2.3.2, 00:02:49, GigabitEthernet0/0/0/0
i L2 2.2.2.2/32 [115/10] via 10.2.3.2, 00:02:49, GigabitEthernet0/0/0/0
i L2 10.1.0.0/24 [115/20] via 10.2.3.2, 00:02:49, GigabitEthernet0/0/0/0

何も壊れていない。それが問題

MTUは食い違ったままです。それでも隣接は成立し、経路も入り、showを見るかぎり異常はありません。パディングという歯止めを外したことで、IS-ISが本来拒否するはずだった構成が通ってしまったわけです。

このラボで実害が出ないのは、LSPが小さいからにすぎません。R3が受け取れるのは1383オクテットまでで、両ルータが出すつもりのLSPの上限は1492オクテットです。1384から1492オクテットのあいだのLSPが生まれた瞬間に、そのLSPだけが届かなくなります。ネットワークが育ってプレフィックスが増えたころに、隣接はUpのままLSDBだけが食い違う、という追いにくい形で表面化します。

ルータ自身はこの状態でも警告を出し続けています。

  CLNS I/O
    MTU:                    1383 (MTU is too small: lsp-mtu is 1492)

隣接がUpであることと、リンクが健全であることは別だと装置が言っているわけです。hello-padding disableを入れるときは、両端のMTUが揃っていることを別の手段で確かめておく必要があります。

STEP 4でMTUとhello-paddingを元に戻し、初期状態に復帰させました。

検証Configおよびshow結果

各STEPで3台すべてから、次の3種類をルータごとに分けて取得しています。検証Configはこの..._run.txtです（最終状態はSTEP 4のもの）。

最終状態のConfigは、R1・R2のLAN側にpoint-to-pointを書かず、R2–R3間にだけpoint-to-pointを書いたものです。STEP 2で入れたmtu 1400とSTEP 3で入れたhello-padding disableは、STEP 4でどちらも外してあります。

STEP 0：初期状態

STEP 1：R2とR3でprocess restart isis

STEP 2：R3のインタフェースMTUを1400に変更

STEP 3：MTU不一致のままhello-padding disableを投入

STEP 4：MTUとhello-paddingを元に戻す（最終状態）

キャプチャーファイルは次の4本です。

R2–R3リンク（STEP 1）のキャプチャー(isis-adj-p2p.pcap) をダウンロード

LANセグメント（STEP 1）のキャプチャー(isis-adj-lan.pcap) をダウンロード

MTU不一致時（STEP 2）のキャプチャー(isis-adj-mtu.pcap) をダウンロード

パディング無効化時（STEP 3）のキャプチャー(isis-adj-padoff.pcap) をダウンロード

参考

関連記事

• IS-ISとは
• NSAPアドレスとNET（System ID）
• レベル1とレベル2（IS-ISの階層）
• IS-ISパケットの種類とヘッダーフォーマット
• 隣接関係の確立と状態遷移
• DISと疑似ノード（Pseudonode）
• ネットワークタイプ（broadcast / point-to-point）