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

IS-ISの隣接にはDown / Initializing / Upの3つの状態しかありません。単純なぶん、どういう条件なら隣接が成立するのかが理解の中心になります。

この記事では状態遷移と、ISO/IEC 10589:2002が定める受理検査を実機のログとキャプチャで確認します。IIHのフォーマットはIS-ISパケットの種類とヘッダーフォーマットで解説しています。

3つの状態

状態	意味
Down	隣接が無い。相手からIIHが届いていないか、届いても受理できていない
Initializing	相手のIIHは届いたが、相手が自分を認識しているかがまだ分からない
Up	双方向であることが確認できた。LSPの交換が始まる

ISO/IEC 10589:2002の隣接確立手順はこの3つで書かれています（管理情報の列挙型にはfailedもあります）。

Initializingがあるのは、「相手のIIHが届いた」と「相手が自分のIIHを受け取れている」が別だからです。後者を確かめるまでUpにしません。

Initializingは必ず通る段階ではありません。相手が先にこちらを認識していれば、Downから直接Upになります。片方だけを再起動した場合がこれです。

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

確かめ方はリンク種別で違います。

リンク種別	確かめ方	出典
ブロードキャスト	相手のIIHのTLV 6（IS Neighbours）に自分のMACアドレスが載っているか	ISO/IEC 10589:2002 8.4.2.5.1
ポイントツーポイント	相手のIIHのTLV 240の`Neighbor System ID`に自分のSystem IDが載っているか	RFC 5303

ブロードキャストは規格の時点で双方向確認を持っていました。8.4.2.5.1はLANのIIHを受け取ったら「initialising」にし、相手が自分のSNPAを報告してきたらUpにすると定め、消えたらinitialisingへ戻します（8.4.2.5.3）。

ポイントツーポイントにはこの仕組みがありませんでした。

2ウェイと3ウェイ

ISO/IEC 10589:2002のポイントツーポイント隣接は2ウェイで、IIHが受理検査を通ればUpになります。片方向しか通らないリンクでも隣接が成立してしまいます。

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

フィールド	内容
Adjacency State	自分から見た隣接の状態（`0` = Up、`1` = Initializing、`2` = Down）
Extended Local Circuit ID	自分の回線識別子（4バイトに拡張されたもの）
Neighbor System ID	相手のSystem ID。これが入っていることが「あなたを見えている」の証
Neighbor Extended Local Circuit ID	相手の回線識別子

Neighbor System IDが入っていないIIHを受け取ったルータはInitializingにとどまります。

このTLVはISO/IEC 10589には存在しません（規格のCODEは1〜10と14だけです）。

隣接が成立する条件

IIHはUpになる前にいくつもの検査を通ります。順序は次のとおりです。

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

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

検査	通らなかったときの動作
受信した回線の`externalDomain`属性が`True`でないこと	PDUを破棄
`ID Length`が自分のドメインの値と一致すること	PDUを破棄し`iDFieldLengthMismatch`イベントを生成
認証（パスワード）が通ること	PDUを破棄し`authenticationFailure`イベントを生成

認証についてはIS-ISの認証（hello-password / lsp-password）で解説しています。

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

共通の検査のあとはレベルで検査の中身が変わります。

レベル	エリアアドレスの検査
レベル1	少なくとも1つ一致しなければ拒否し、`areaMismatch`イベントを生成（8.4.2.2 a）。加えて`Maximum Area Addresses`の一致も確認する（8.4.2.2 b）
レベル2	エリアの検査をしない。規格は「レベル2 LAN IIHを受け取ったら隣接を受け入れ、`neighbourSystemType`を『L2 Intermediate System』にする」とだけ書いている（8.4.2.3）

「エリアが違うとレベル1は張れないがレベル2は張れる」の根拠がこの非対称性です（IS-ISのレベル1とレベル2）。

Maximum Area Addressesの検査は「3しか実装していないISは省いてよい」とされ（8.4.2.2 b）、Cisco実装は3固定なので実質的に働きません。

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

最後にIIHのCircuit Typeと自分のis-typeの組み合わせを判定します。ISO/IEC 10589:2002はポイントツーポイントについて表5〜表8に状態遷移表を与えています。エリアが一致する場合のレベル1が表5です。

受信したIIHの`Circuit Type`	隣接が無いとき	すでにレベル1の隣接があるとき
Level 1 only	Up（レベル1として成立）	そのまま維持
Level 2 only	拒否（`wrongSystemType`）	Downにして隣接を削除
Level 1 and 2	Up（レベル1として成立）	そのまま維持

Circuit TypeはIIH固定部の1バイトの下位2ビットで、is-typeの設定がそのままこのビットになります。両端のis-typeの組み合わせが隣接のレベルを決めます。

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

検査にMTUは出てきません。IS-ISはMTUフィールドを持たず、IIHのパディングで間接的に検出します。

IIHはmaxsize − 1バイト以上までTLV 8で埋められます（8.2.4 / 8.4.2）。MTUの小さい側は受け取れないので、IIHが届かず隣接が成立しません。

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

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

側	見え方
MTUが小さい側	相手の大きなIIHを受け取れないので、隣接がまったく見えない
MTUが大きい側	相手の小さなIIHは届くので存在は分かるが、そのIIHに自分のSystem IDが載らないためInitializingで止まる

パディングの仕組みはIS-ISパケットの種類とヘッダーフォーマットで解説しています。STEP 2・3で確認します。

実機での検証

検証環境

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

ルータ	NET	`is-type`	接続
R1	`49.0001.0010.0100.1001.00`	`level-1`	LANのみ
R2	`49.0001.0020.0200.2002.00`	（既定＝level-1-2）	LAN ＋ R3へのP2P
R3	`49.0002.0030.0300.3003.00`	（既定＝level-1-2）	R2へのP2Pのみ

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

STEP 0：R2の show isis adjacency detail（抜粋）
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    21   00:04:16 Yes None None
  Area Address:           49.0001
  Neighbor IPv4 Address:  10.1.0.1*
  DIS Priority:           64
  Local Priority:         64 (DIS)
  Neighbor Priority:      64
  Topology:               IPv4 Unicast
  BFD Status:             Neighbor Useable (BFD Not Configured)

Total adjacency count: 1

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*
  Topology:               IPv4 Unicast
  BFD Status:             Neighbor Useable (BFD Not Configured)
  Adjacency Flaps:        0

Total adjacency count: 1

R2から見てR1がレベル1、R3がレベル2です。R3はエリアが違うのに隣接が成立しているのは、レベル2がエリアを検査しないためです。

検証のSTEP

STEP	操作	狙い
0	初期状態	定常状態の隣接。`Changed`欄の経過時間
1	R2とR3で`process restart isis`	Down → Initializing → Upの遷移をsyslogとキャプチャで追う
2	R3側のインタフェースMTUだけを変更	隣接が成立しないことを確認。パディングによる検出の実証
3	MTU不一致のまま、片側に`hello-padding disable`	MTUが食い違ったまま隣接が上がってしまうことを確認
4	MTUとパディングを元に戻す（最終状態）	初期状態と同じ

IOS XRの次の2つのコマンドを使います。

コマンド	見えるもの
`show isis adjacency-log`	状態遷移そのもの。`d -> i`、`i -> u`のように、いつ・どのインタフェースで・どのレベルの隣接がどう変わったかがレベル別に並ぶ
`show isis trace all \| include 3WAY`	3ウェイハンドシェイクの検証過程。受け取ったIIHに自分のSystem IDが入っていたかどうかまで出る

show isis traceは重大度（all / detailed / only / severe / standard）で選びます。allは4000行近いので装置側で| includeで絞ります。

状態遷移を追う（STEP 1）

R2とR3でprocess restart isisを実行します。

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

STEP 1：R2の show isis adjacency-log
  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です。R3とはd -> iの約0.6秒後にi -> uです。

R1とはd -> uで、Initializingを経由していません。R1は動き続けていたので、R2は復帰後の最初のIIH（TLV 6にR2のMACが載っている）で双方向を確認できるためです。

ラボの初回起動時（3台同時）のログでは両方とも2段階を踏んでいます。

STEP 0：R2の show isis adjacency-log（初回起動時）
  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は相手がまだ自分を知らないときだけ現れる」という動作が、この差です。

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

R2–R3リンクのキャプチャで、TLV 240のAdjacency Stateが変わる連続する4つのIIHを見ます。

No.9 R2 → R3（Adjacency State: Down）tshark -V
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

上のtshark出力のパケット（No.9 Adjacency State: Down）のpcapをダウンロード

再起動直後のR2のIIHです。Length: 5でNeighbor SystemIDがありません。RFC 5303はこの状態でTLVを短くしてよいと定めています。

No.10 R3 → R2（Adjacency State: Initializing）tshark -V
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

上のtshark出力のパケット（No.10 Adjacency State: Initializing）のpcapをダウンロード

R3の返答です。Lengthが15になり、Neighbor SystemID: 0020.0200.2002（R2）が入りました。「あなたを見えています」の表明です。

これを受け取ったR2はUpになり、No.11でNeighbor SystemID: 0030.0300.3003を返し、それを見たR3もUpになります。

No.12 R3 → R2（Adjacency State: Up）tshark -V
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

上のtshark出力のパケット（No.12 Adjacency State: Up）のpcapをダウンロード

まとめると次のとおりで、Upに達するまでに3回の往復が必要です。

No.	送信元	`Adjacency State`	`Neighbor SystemID`
9	R2	Down (2)	なし（`Length: 5`）
10	R3	Initializing (1)	`0020.0200.2002`（R2）
11	R2	Initializing (1)	`0030.0300.3003`（R3）
12	R3	Up (0)	`0020.0200.2002`（R2）

traceに残る3ウェイの判定

show isis traceにこの判定が記録されています。

STEP 1：R2の show isis trace all | include 3WAY（抜粋）
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

キーワード	意味
`ADJ_SEND_P2P_DO_IETF_3WAY`	送信するP2P IIHにRFC 5303の3ウェイ情報を載せた
`ADJ_RECV_P2P_3WAY_IETF_ACCEPT_MISSING`	受け取ったIIHに自分のSystem IDが入っていなかった
`ADJ_RECV_P2P_3WAY_IETF_ACCEPT_MATCH`	受け取ったIIHの`Neighbor System ID`が自分と一致した

MISSINGのあとのMATCHがNo.9→No.10に対応します。IETFとあるのは、これがRFC 5303による動作だからです。

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

R3側だけMTUを小さくします。

STEP 2：R3に投入した設定
interface GigabitEthernet0/0/0/0
 mtu 1400

IOS XRのインタフェースMTUの既定は1514で、イーサネットヘッダー14バイトとLLC 3バイトを引いた値がIS-ISのMTUです。1514なら1497、1400なら1383です。

両端の見え方は非対称になる

STEP 2：R3の show isis neighbors
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

STEP 2：R2の show isis neighbors
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は隣接がゼロ、R2はInitで止まります。

R2の1497オクテットのIIHはR3のMTU 1383に収まらず届きません。R3のIIHはR2に届きますが、Neighbor SystemIDが入っていないため、R2はInitializingにとどまります。

R3には理由が出ます。

STEP 2：R3の show isis interface GigabitEthernet0/0/0/0（抜粋）
  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と、大きすぎるという理由で捨てています。Last IIH Receivedの時刻もMTUを変える前で止まっています。

隣接を落とすのは3ウェイハンドシェイク

R2側のログです。

STEP 2：R2の show isis adjacency-log（Level 2、末尾）
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を受け取り続けているのに落としたのは、そのIIHから自分のSystem IDが消えたからです。

規格どおりの2ウェイなら、R2はIIHが届いているだけでUpのままにし、片方向の隣接が成立してしまいます。

RFC 5303が塞いだのはこの穴で、その働きがログの1行として現れています。

R3側では同じ事象が別の理由で記録されます。

STEP 2：R3の show isis adjacency-log（Level 2、抜粋）
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を受け取れないのでHolding Timeの満了です。同じMTU不一致が、片側では3-way state down、もう片側ではHoldtime expiredとして現れます。

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

キャプチャではこの状態が続いています。

STEP 2：MTU不一致中のP2P 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"でP2P IIHに絞り、3つのフィールドの組み合わせをsort | uniq -cで数えています。

列	由来	内容
1列目	`uniq -c`	その組み合わせが現れたパケット数
2列目	`-e eth.src`	送信元MACアドレス。`52:54:00:93:4c:03`がR2、`52:54:00:5f:3e:cc`がR3
3列目	`-e frame.len`	フレーム長（バイト）
4列目	`-e isis.hello.adjacency_state`	TLV 240の`Adjacency State`。`0`＝Up、`1`＝Initializing、`2`＝Down

時間順に読むと前後の移り変わりが出ています。

件数	送信元	フレーム長	状態	いつの分か
2	R3	1514	Up (0)	MTUを変える前。両端とも1514バイトで隣接はUp
4	R2	1514	Up (0)	同上（R2はキャプチャ中ずっと1514バイトのまま）
2	R3	1509	Up (0)	MTU変更の直後。R3のフレームだけ1509バイトに縮んだが、隣接はまだUpのまま
18	R2	1514	Initializing (1)	不一致が効いたあとの定常状態。R3は見えているが、自分を認識してもらえていない
18	R3	1509	Down (2)	同じく定常状態。R2のIIHが1つも届かないので、誰も見えていない

上3つはキャプチャ開始からの十数秒だけで、残りの36パケットは下2行の状態です。

3つ目（R3が1509バイトでまだUp）は、フレーム長が縮んでから隣接が落ちるまでの数秒間です。

上の集計のうちR2側のパケット（No.10 Adjacency State: Initializing）のpcapをダウンロード

同じくR3側のパケット（No.9 Adjacency State: Down）のpcapをダウンロード

R3のIIHが自分のMTUより大きい1509バイトなのは、maxsizeがLSPの最大サイズ1492のままだからです（MTUは「検査」ではなく副作用で効く）。

XRのMTU: 1383 (MTU is too small: lsp-mtu is 1492)という警告も同じことを伝えています。

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

MTUを食い違わせたまま、両側にパディングの無効化を入れます。

STEP 3：R2とR3に投入した設定
router isis 1
 interface GigabitEthernet0/0/0/1      （R3では GigabitEthernet0/0/0/0）
  hello-padding disable

STEP 3：R3の show isis neighbors
RP/0/RP0/CPU0:R3#show isis neighbors
Wed Sep  9 04:05:36.746 UTC

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

Total neighbor count: 1

隣接が上がります。IIHがR3のMTUに収まるためです。

STEP 3：R3の show isis adjacency-log（Level 2、末尾）
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

経路も入りました。

STEP 3：R3の show route isis
RP/0/RP0/CPU0:R3#show route isis
Wed Sep  9 04:05:35.890 UTC

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

隣接がUpでもMTUは食い違ったまま

MTUは食い違ったままですが隣接は成立し、showに異常はありません。IS-ISが本来拒否するはずの構成が通っています。

実害が出ないのはLSPが小さいからです。1384〜1492オクテットのLSPが生まれた瞬間に、そのLSPだけが届かなくなります。隣接はUpのままLSDBだけが食い違う形で表面化します。

ルータは警告を出し続けています。

STEP 3：R3の show isis interface（隣接がUpの状態でも）
  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）。

ファイル	内容
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route isis` / `show isis` / `show isis hostname` / `show isis interface` / `show isis interface brief` / `show isis neighbors` / `show isis neighbors detail` / `show isis database` / `show isis database detail` / `show isis topology` / `show isis adjacency` / `show isis adjacency detail` / `show isis adjacency-log` / `show isis trace standard \| include ADJ` / `show isis trace all \| include 3WAY` / `show isis spf-log` / `show isis lsp-log` / `show isis statistics` / `show cef`
`..._log.txt`	そのSTEPの範囲だけに絞った`show logging`（STEP 0のみ起動時からの全履歴）
`..._run.txt`	そのSTEP時点の`show running-config`（＝そのSTEPの検証Config）

最終状態はR2–R3間にだけpoint-to-pointを書き、mtu 1400とhello-padding disableを外したものです。

STEP 0：初期状態

ルータ	show出力	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run

STEP 1：R2とR3でprocess restart isis

ルータ	show出力	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run

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

ルータ	show出力	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run

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

ルータ	show出力	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run

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

ルータ	show出力	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run

キャプチャーファイルは次の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) をダウンロード

参考

標準	タイトル	概要
ISO/IEC 10589:2002（第2版）	Intermediate System to Intermediate System intra-domain routeing information exchange protocol	IS-IS本体の仕様。本記事が参照したのは、ポイントツーポイントの隣接手順を定める8.2.4〜8.2.6、ブロードキャストの隣接手順を定める8.4.2（とくに受理検査の8.4.2.1、レベル1の8.4.2.2、レベル2の8.4.2.3、新規隣接の8.4.2.5）、`Circuit Type`との組み合わせを与える表5〜表8、IIHのパディングを規定する8.2.4 / 8.4.2。
RFC 1142	OSI IS-IS Intra-domain Routing Protocol	ISO 10589のDraft Proposal（1990年）を再公開したもの。現在はHistoric。ISO/IEC 10589の代わりに参照してはいけません（RFC 7142）。
RFC 7142	Reclassification of RFC 1142 to Historic	参照すべきはISO/IEC 10589:2002 第2版であることを述べている。
RFC 5303	Three-Way Handshake for IS-IS Point-to-Point Adjacencies	TLV 240を定義。ISO/IEC 10589のポイントツーポイント隣接が2ウェイであることの問題と、その解決策を述べている。
RFC 1195	Use of OSI IS-IS for Routing in TCP/IP and Dual Environments	IPの経路を運ぶための拡張。