NSAPアドレスとNET（System ID）

NSAPアドレスとNETとは

IS-ISはIPのために作られたプロトコルではなく、ISOがOSI参照モデルのネットワーク層プロトコルであるCLNPの経路制御のために標準化したものです（詳しくはIS-ISとはで解説しています）。そのため、IPルーティングだけを目的にIS-ISを動かす場合でも、ISO方式のアドレスをルータに1つ設定する必要があります。このアドレスがNSAP（Network Service Access Point）であり、ルータ自身を指す用途で設定したものをNET（Network Entity Title）と呼びます。

IPアドレスとの最大の違いは、どこに付けるかです。

IS-ISが「どのルータが出したLSPか」「トポロジマップ上のどのノードか」を識別するのに使うのは、このNSAPに含まれるSystem IDです。OSPFのルータIDに相当しますが、IPアドレスとはまったく無関係の識別子である点が異なります。

NSAPアドレスのフォーマット

NSAPの正式なフォーマットは、ISO/IEC 8348の附属書A（規定）で次の2つの部分に分けて定義されています（A.5.1.1）。本記事が参照したのは2002年の第3版で、これはITU-T勧告X.213と技術的に一致する版です。ISO/IEC 10589:2002が規範として挙げているのは1996年の第2版で、NSAPアドレスの定義はさらに古い版の追補2（ISO 8348/Add.2）に由来します。

実務でよく見る「HO-DSP」「ID」「SEL」というDSPの内訳は、ISO/IEC 8348の用語ではありません。GOSIPなどのアドレス割り当て方針や、それを前提としたベンダー実装の用語です。ISO/IEC 8348が定めているのはIDPとDSPの2分割までで、DSPの中身は「IDIが識別する機関が形式と意味を決める」（A.5.2.2）とされています。

しかしIPルーティングでIS-ISを使う場合、この区分をそのまま意識する必要はほとんどありません。ISO/IEC 10589:2002自身も、図4で「IDP・DSP・AFI・IDIはISO 8348との対応を示すために描いているだけで、このプロトコルは明示的には使わない」と注記したうえで、アドレスを次の3つの部分に分けて扱っています（7.1.1）。実務でもこの簡略化NSAPフォーマットで考えます。

NSAP全体の長さは最長20バイトです。ISO/IEC 8348のA.5.4が「推奨バイナリ符号化（preferred binary encoding）におけるNSAPアドレスの最大長は20オクテット」と定めています。System IDを6バイトにすると、Area IDが最短の1バイト（AFIのみ）のとき全体は8バイト、Area IDが最長の13バイトのとき20バイトになります。IPルーティング用途では、AFI 1バイト＋エリア情報2バイト＋System ID 6バイト＋NSEL 1バイトの10バイトで構成するのが一般的です。

49.0001.0010.0100.1001.00
└─┬──┘ └──────┬──────┘ └┬┘
Area ID    System ID   NSEL
（3バイト）  （6バイト）  （1バイト）

AFIと49

Area IDの先頭がAFIです。ISO/IEC 8348のA.5.1.1.1によると、AFIは次の4つを示します。

1. IDIのフォーマット
2. IDIの値を割り当てる機関
3. IDIの先頭のゼロが有意かどうか
4. DSPの表記形式（abstract syntax）

AFIの値の割り当ては同規格の表A.4のとおりです。

値が2つ並んでいる行があるのは、上の3番目（先頭のゼロが有意かどうか）のためです。IDIが可変長のフォーマットでは、推奨バイナリ符号化のときにIDIを最大長までパディングする必要があり、パディングのゼロと意味のあるゼロを区別しなければなりません。そこで同じ組み合わせにAFIを2つ割り当て、小さいほうをIDI先頭が非ゼロのとき、大きいほうをIDI先頭がゼロのときに使う、という決め方をしています（A.5.2.1.2）。IDIが固定長またはnullのフォーマット（ISO DCC、ISO 6523 ICD、IANA ICP、ITU-T IND、Local）にこの区別は要らないため、値は1つずつです。

このうち49はLocalというIDIフォーマットで、DSPをバイナリで表記することを示す値です。Localの特徴はIDIが存在しない（null）ことで、IDP全体がAFIの2桁だけになります（A.5.2.1.2.9）。推奨バイナリ符号化ではAFIの2桁が1オクテットになるので、49の直後からがそのままDSPです。NETを49.0001.0010.0100.1001.00と書いたときに、49の後ろにエリアやSystem IDがそのまま続くのはこのためです。

Localの最大DSP長はバイナリ表記で19オクテット（表A.5）で、AFIの1オクテットを足すとちょうど20オクテットになります。

なお「Local ＝ 私用」というのは規格の言葉ではありません。ISO/IEC 8348が表A.4の注記で述べているのは「LocalというIDIフォーマットは、OSIと非OSIのアドレス体系が共存できるようにするためのもので、とくに非OSIからOSIへ移行する場面を想定している」という趣旨です。とはいえIDIが無い＝アドレスの一意性を保証する上位機関が存在しないため、結果として組織の外で重複しうるアドレスになります。IPでいうプライベートアドレスに相当する、と説明されるのはこの性質によるものです。IPルーティングのためだけにIS-ISを動かすのであれば49で十分で、IGPであるIS-ISの経路情報がAS外へ出ることはなく、AS間はBGPが担当するためです。

一方、大規模なISPでは公的なアドレス空間（ISO 6523 ICDなど）から取得した20バイトのNSAPを使うこともあります。IPルーティングの動作という観点では、49で始まる10バイトのNETと20バイトの公的NSAPに違いはありません。

検証環境

検証環境は、Cisco IOS XR（XRd 26.1.1）のルータ4台を直線に接続し、2つのエリアにまたがる構成にしています。R1・R2がエリア49.0001、R3・R4がエリア49.0002で、境界のR2–R3間はエリアが異なります。

検証は次の6段階（STEP 0〜5）で進めます。各STEPで4台すべてから取得したshow出力・syslog・running-configは、記事末尾の検証Configおよびshow結果にまとめました。

Area ID

Area IDはそのルータが所属するエリアを表します。49.0001であれば、AFI 49 にエリア情報 0001 を続けたものです。

Area IDで重要なのは、レベル1の隣接関係はArea IDが一致していないと成立しないという点です。同じエリアに属するルータ同士がエリア内の詳細なトポロジを共有する仕組みなので、当然の制約といえます。一方、レベル2の隣接関係はArea IDが違っていても成立します。レベル2はエリアをまたぐバックボーンだからです。

初期状態のR2から見ると、この違いがそのまま出ています。

RP/0/RP0/CPU0:R2#show isis neighbors
Mon Sep  7 06:43:00.213 UTC

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

Total neighbor count: 2

同じエリア49.0001のR1とはL1、Area IDが異なるR3とはL2になっています。

IIHで交換しているのはArea ID

「レベル2になったのはR3がレベル2対応だからではないか」と考えたくなりますが、そうではありません。R2–R3リンクで両方向のIIHをキャプチャして比べると、原因がArea IDひとつに絞り込めます。

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

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

両方向ともCircuit type: Level 1 and 2で、どちらもレベル1に対応しています。それでもレベル1の隣接が張られないのは、同じIIHに入っているArea address TLV（TLV 1）の値が違うためです。

違いはこの1点だけで、結果としてレベル2の隣接だけが成立します。レベル1とレベル2の役割そのものは、レベル1とレベル2を参照してください。

Area IDを変えるとどうなるか（STEP 1）

R2のArea IDを49.0001から49.0003へ変更すると、R1とのレベル1隣接が成立しなくなります。R1側のsyslogには理由まで出ます。

RP/0/RP0/CPU0:Sep  7 06:53:41.202 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to 49.0001.0020.0200.2002 (GigabitEthernet0/0/0/0) (L1) Down, Area addr/level differ 

Area addr/level differ（エリアアドレスかレベルが違う）と明示されています。R2側では次のように記録されました。

RP/0/RP0/CPU0:Sep  7 06:53:40.605 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R1 (GigabitEthernet0/0/0/0) (L1) Down, Interface state down 
RP/0/RP0/CPU0:Sep  7 06:53:40.621 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to R3 (GigabitEthernet0/0/0/1) (L2) Down, Interface state down 
RP/0/RP0/CPU0:Sep  7 06:53:43.120 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to 49.0002.0030.0300.3003 (GigabitEthernet0/0/0/1) (L2) Up, New adjacency 

NETを変更するとIS-ISのインタフェースが一度落ちるため、レベル1・レベル2の両方の隣接がいったん切れます。その後レベル2だけが3秒ほどで復帰し、レベル1はエリアが一致しないため復帰できません。結果としてR2の隣接はR3の1つだけになります。

RP/0/RP0/CPU0:R2#show isis neighbors
Mon Sep  7 06:56:22.006 UTC

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

Total neighbor count: 1

R1はIS-ISで学習した経路をすべて失い、孤立します（show route isisが% No matching routes foundになります）。

キャプチャには、変更の前後でIIHのArea address TLVが変わる様子が記録されています。

    .... ..11 = Circuit type: Level 1 and 2 (0x3)
    SystemID {Sender of PDU}: 0020.0200.2002
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0001

    .... ..11 = Circuit type: Level 1 and 2 (0x3)
    SystemID {Sender of PDU}: 0020.0200.2002
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0003

Circuit typeは同じまま、Area addressだけが変わっています。

さらにその間に、R2が元のエリアから自分のレベル1 LSPを取り下げる動作も記録されました。

ISO 10589 ISIS Link State Protocol Data Unit
    PDU length: 40
    Remaining lifetime: 0
    LSP-ID: 0020.0200.2002.00-00
    Sequence number: 0x00000008
    [Checksum: [missing]]
    [Checksum Status: Not present]
    Type block(0x0b): Partition Repair:0, Attached bits:1, Overload bit:0, IS type:3
    Purge Originator ID (t=13, l=7)
        Type: 13
        Length: 7
        Number of System IDs: 1
        System ID: 0020.0200.2002

Remaining lifetime: 0でチェックサムを持たないLSPがパージ（取り下げ）です。ISO/IEC 10589:2002の7.3.16.4は、寿命が0になったLSPはヘッダーだけを残して中身を捨て、それを伝搬すると定めています。Purge Originator ID TLV（TLV 13）に取り下げを行ったルータのSystem IDが入りますが、このTLVはISO/IEC 10589には無く、RFC 6232で追加されたものです。エリアを変えたR2は、もう49.0001のメンバーではないため、自分のLSPをそのエリアから消しているわけです。

System IDの決め方

System IDはノードを識別する6バイトの値で、ISO/IEC 10589:2002の7.1.4が次の制約を定めています。

• 同じエリア内で一意でなければならない。 規格の言い方では「エリア内の2つのシステム（ISでもESでも）が同じIDを使ってはならない」。LSPの識別子（LSP ID）がSystem IDから作られるため、重複すると同じLSPとして扱われてしまう
• レベル2のルータは、ルーティングドメイン全体で一意でなければならない
• ドメイン内のSystem IDはすべて同じ長さでなければならない（Cisco実装では6バイト固定なので自動的に満たされる）

規格上、レベル1だけのルータはエリアが違えば重複してもよいことになっていますが、実務ではドメイン全体で一意にするのが一般的です。運用時の混乱を避けるためで、本記事でもその前提で説明します。重複させた場合の実際の挙動はSystem IDが重複するとどうなるかで確認します。

ループバックアドレスから機械的に決める

System IDの値そのものに決まりはありませんが、ループバックのIPアドレスから機械的に変換する方法が広く使われています。ISPでよく使われる手順です。

Step 1. 各オクテットを3桁になるようゼロ埋めする
        192.168.1.24  →  192.168.001.024

Step 2. 12桁を4桁ずつ3つに区切る
        192168001024  →  1921.6800.1024

Step 3. Area IDとNSELを付けてNETにする
        49.0001.1921.6800.1024.00

この方法の利点は、1つのループバックアドレスを複数の用途で使い回せることです。BGPのルータID、MPLS-TEのルータID、ネットワーク管理の宛先、そしてIS-ISのSystem IDが同じ値から導かれるため、show isis databaseにLSPが並んだときにどのルータのものか即座に分かります。

本記事の検証環境でも、この規則で決めています。

なお、System IDは6バイトでMACアドレスと同じ長さです。これは偶然ではなくGOSIP 2.0の仕様によるもので、ルータのMACアドレスをそのままSystem IDに使う流儀もあります。ただしLANインタフェースを複数持つルータではどれを使うか決める必要があり、機器を交換するとSystem IDが変わってしまうため、ループバックから導く方法のほうが運用しやすいといえます。

NSEL

NSAPの最後の1バイトがNSEL（NSAPセレクタ）です。ネットワーク層のサービスをどの上位利用者に渡すかを指定するもので、IPでいえばプロトコル番号やポート番号に近い役割を持ちます。

NETではNSELが必ず00になります。00は「特定の上位利用者ではなく、そのノードのネットワークエンティティ自身」を指すためです。ルータに設定するのはノード自身を表すアドレスなので、00以外にはできません。

実際、NSELを01にしたNETを設定しようとすると、IOS XRはコマンドの解析時点で受け付けません。

RP/0/RP0/CPU0: net 49.0001.0010.0100.1001.01
                                   ^
% Invalid input detected at '^' marker.

キャレット（^）がNSELの位置を指しています。コミットまで到達しないため設定は変更されません。

NETの設定と確認

IOS XRではrouter isis配下のnetコマンドで設定します。

router isis 1
 is-type level-1
 net 49.0001.0010.0100.1001.00
 log adjacency changes
 address-family ipv4 unicast

is-typeはこのルータがどのレベルで動作するかの指定です。既定はレベル1とレベル2の両方（level-1-2）で、その場合show running-configにis-typeの行は現れません。本記事のR2・R3は既定のままなので、Configにはnetから始まります。

設定した内容はshow isisで確認できます。

RP/0/RP0/CPU0:R2#show isis
Mon Sep  7 06:42:59.454 UTC

IS-IS Router: 1
  System Id: 0020.0200.2002 
  Hostname: R2
  IS Levels: level-1-2
  Manual area address(es):
    49.0001
  Routing for area address(es):
    49.0001
  Multi-Instance Id: 0

なお、show isis protocolというコマンドも受け付けられますが、XRd 26.1.1ではshow isisとまったく同じ出力になります（別名）。

複数NET（マルチホーミング）とエリアの統合・分割

1台のルータに複数のNETを設定することができます。これをIS-ISのマルチホーミングと呼びます。ISO/IEC 10589:2002の7.1.5は、1つのエリアが複数の同義のエリアアドレスを持つことを認めており、設定できる数の上限は管理パラメータmaximumAreaAddressesで決まります。規格の既定値は3で、すべてのISは少なくとも3をサポートしなければならない、というのが規格の言い方です（「最大3つ」ではありません。PDUのフィールド上は1〜254まで表現できます）。Cisco実装がこれを3に固定しているため、実務では「3つまで」と覚えられています。XRdで実際に4つ目を入れようとした結果は4つ目のNETは入らない（STEP 6）で示します。ただし次の制約があります。

• すべてのNETでSystem IDは同一でなければならない。 違えられるのはArea IDだけ
• 複数のエリアに同時に所属できるわけではない。 複数のArea IDを設定すると、それらのエリアは1つに統合される

この性質を使うと、エリアの統合（マージ）と分割（スプリット）を行えます。

エリアの統合（STEP 2）

STEP 1でArea IDを49.0003に変えたR2に、元の49.0001のNETを追加します。System IDは0020.0200.2002のまま変えません。

router isis 1
 net 49.0001.0020.0200.2002.00
 net 49.0003.0020.0200.2002.00
 log adjacency changes

  System Id: 0020.0200.2002 
  Hostname: R2
  IS Levels: level-1-2
  Manual area address(es):
    49.0003
    49.0001
  Routing for area address(es):
    49.0003
    49.0001
  Multi-Instance Id: 0

Manual area address(es)とRouting for area address(es)がどちらも2行になりました。System Idは1つのままで、増えたのはArea IDだけです。

これでR1とのレベル1隣接が復活します。

RP/0/RP0/CPU0:Sep  7 06:58:03.322 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to 49.0003.0020.0200.2002 (GigabitEthernet0/0/0/0) (L1) Up, New adjacency 

R1はR2を49.0003のNETで識別しているのに、レベル1の隣接が成立しています。一致したのはもう一方の49.0001のほうで、「設定した複数のArea IDのうち1つでも相手と一致すればレベル1隣接が張れる」＝2つのエリアが統合されている、ということです。

RP/0/RP0/CPU0:R2#show isis neighbors
Mon Sep  7 07:00:08.605 UTC

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

Total neighbor count: 2

エリアの分割（STEP 3）

不要になったArea IDのNETを削除すると、エリアが分割されます。STEP 3では49.0003を削除して単一NETに戻しました。

  Manual area address(es):
    49.0001
  Routing for area address(es):
    49.0001

隣接関係は初期状態と同じ（R1とレベル1、R3とレベル2）に戻ります。実運用でエリアを再編する場合も、統合したい両方のArea IDをいったん境界のルータに設定してから、不要になったほうを外すという手順を踏みます。

4つ目のNETは入らない（STEP 6）

XRdが何個までNETを受け付けるかを確かめるため、STEP 6ではR2に49.0003と49.0004のNETを1つずつ追加し、続けて4つ目の49.0005を投入しました。

RP/0/RP0/CPU0:R2#configure
Tue Sep  8 14:12:48.002 UTC
RP/0/RP0/CPU0:R2(config)#router isis 1
RP/0/RP0/CPU0:R2(config-isis)#net 49.0003.0020.0200.2002.00
RP/0/RP0/CPU0:R2(config-isis)#commit
Tue Sep  8 14:12:49.691 UTC
RP/0/RP0/CPU0:R2(config-isis)#net 49.0004.0020.0200.2002.00
RP/0/RP0/CPU0:R2(config-isis)#commit
Tue Sep  8 14:12:50.497 UTC
RP/0/RP0/CPU0:R2(config-isis)#net 49.0005.0020.0200.2002.00
RP/0/RP0/CPU0:R2(config-isis)#commit
Tue Sep  8 14:12:51.195 UTC

% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RP0/CPU0:R2(config-isis)#show configuration failed
Tue Sep  8 14:12:58.911 UTC
!! SEMANTIC ERRORS: This configuration was rejected by 
!! the system due to semantic errors. The individual 
!! errors with each failed configuration command can be 
!! found below.


router isis 1
 net 49.0005.0020.0200.2002.00
!!% Maximum area address count exceeded: maximum number of area addresses is 3
!
end

2つ目・3つ目のNETはそのままcommitできましたが、4つ目はmaximum number of area addresses is 3でcommitが拒否されました。XRd 26.1.1ではrouter isis配下にmax-area-addressesのようなコマンドも無く（% Invalid input）、上限3は変更できません。ISO/IEC 10589:2002が「少なくとも3」と要求する値を、この実装はちょうど3で固定しているわけです。

3つのNETを持った状態のR2は、show isisに3つのエリアアドレスを並べます。

  Manual area address(es):
    49.0001
    49.0003
    49.0004
  Routing for area address(es):
    49.0001
    49.0003
    49.0004

隣接関係はSTEP 2と同じく、R1とのレベル1・R3とのレベル2がどちらも維持されました。STEP 7で追加した2つのNETを削除し、単一NETの状態に戻しています。

動的ホスト名（TLV 137）

System IDは0010.0100.1001のような16進の値で、そのままでは読みづらいものです。IS-ISはこれを補うために、自分のホスト名をLSPのTLV 137で広告する仕組み（RFC 5301）を持っています。受け取ったルータはSystem IDとホスト名の対応を覚え、showの出力でホスト名に置き換えて表示します。

IOS XRではこの機能が既定で有効です。対応表はshow isis hostnameで確認できます。

RP/0/RP0/CPU0:R2#show isis hostname
Mon Sep  7 06:42:59.645 UTC

IS-IS 1 hostnames
Level  System ID      Dynamic Hostname
 1     0010.0100.1001 R1
 1,2 * 0020.0200.2002 R2
 2     0030.0300.3003 R3

R4がこの表に載っていない点に注目してください。R4はエリア49.0002のレベル1ルータなので、そのLSPはエリア49.0002の中だけに流れ、エリア49.0001にいるR2までは届きません。ホスト名の対応表も、LSPが届く範囲でしか作られないということです。

ホスト名はLSPで配られるため、隣接が確立した瞬間にはまだ相手のホスト名を知りません。起動直後のsyslogで、相手がR2ではなくNET（49.0001.0020.0200.2002）のまま表示されることがあるのはこのためです。

なお、動的ホスト名が使えない環境向けに、clns host <名前> <NSAP>で静的に対応表を書く方法もあります。全ルータに同じ表を配る必要があるため、現在はほとんど使われません。

System IDが重複するとどうなるか

STEP 4で、R3のSystem IDをR2と同じ0020.0200.2002に変更しました（NETは49.0002.0020.0200.2002.00）。R2とR3はどちらもレベル2バックボーンに接続しているため、重複が許されない組み合わせです。

まず、R2とR3の両方が専用のエラーメッセージを出します。

RP/0/RP0/CPU0:Sep  7 07:05:09.321 UTC: isis[1003]: %ROUTING-ISIS-6-ERR_DUPID : ISIS (1): Duplicate System ID 0020.0200.2002 already used by Local System detected in IIH received on Gi0/0/0/1, R2 (0020.0200.2002), SNPA 5254.000a.0481 
RP/0/RP0/CPU0:Sep  7 07:05:38.742 UTC: isis[1003]: %ROUTING-ISIS-5-ADJCHANGE : ISIS (1): Adjacency to 49.0002.0030.0300.3003 (GigabitEthernet0/0/0/1) (L2) Down, Holdtime expired 

Duplicate System ID 0020.0200.2002 already used by Local System（自分がすでに使っているSystem IDを受信したIIHの中に検出した）と、受信したインタフェースおよび相手のSNPA（MACアドレス）まで示されます。切り分けに必要な情報が揃っています。

重複したIIHは受け付けられないため隣接は更新されず、ホールドタイムが満了して隣接が落ちます（Holdtime expired）。その結果、レベル2バックボーンが分断されます。

RP/0/RP0/CPU0:R2#show isis database
Mon Sep  7 07:07:27.943 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL
R1.00-00              0x00000007   0x29f0        635  /1199         0/0/0
R2.00-00            * 0x00000006   0xb4b4        1060 /*            0/0/0

 Total Level-1 LSP count: 2     Local Level-1 LSP count: 1

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime/Rcvd  ATT/P/OL
R2.00-00            * 0x0000000d   0xcab7        1090 /*            0/0/0

 Total Level-2 LSP count: 1     Local Level-2 LSP count: 1

レベル2のLSDBにR2自身のLSPしか残っていません。

影響はエリアの外にも及びます。R1（レベル1のみ）は、それまで持っていたデフォルトルートを失いました。

RP/0/RP0/CPU0:R1#show route isis
Mon Sep  7 07:07:06.306 UTC

i L1 2.2.2.2/32 [115/10] via 10.1.2.2, 00:09:01, GigabitEthernet0/0/0/0
i L1 10.2.3.0/24 [115/20] via 10.1.2.2, 00:09:01, GigabitEthernet0/0/0/0

初期状態にあったi*L1 0.0.0.0/0の行が消えています。レベル1のルータは他エリアの経路を個別に持たず、レベル1/レベル2ルータが立てるATT（Attached）ビットを見てデフォルトルートを作ります。R2はレベル2の隣接を失ってATTビットを下ろしたため、R1のデフォルトルートも消えたわけです（ATTビットの詳細はATTビットとレベル1のデフォルトルートで解説します）。

その結果、R1からR4への通信ができなくなります。

RP/0/RP0/CPU0:R1#traceroute 4.4.4.4 source 1.1.1.1
Mon Sep  7 07:08:24.589 UTC

Type escape sequence to abort.
Tracing the route to 4.4.4.4

 1  1.1.1.1 !N  *  !N 

!Nはネットワーク到達不能です。初期状態では同じtracerouteが3ホップで成功していました。

System IDを1台間違えるだけで、エリアをまたぐ疎通が丸ごと止まります。System IDをドメイン全体で一意にする運用が推奨されるのは、この影響の大きさによるものです。STEP 5でR3のNETを元に戻すと、隣接・経路とも初期状態に復帰しました。

検証Configおよびshow結果

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

これに加えて、STEP 0〜5ではR1からshow route isis / show route 0.0.0.0/0 / show route 4.4.4.4/32 / traceroute 4.4.4.4 source 1.1.1.1を..._trace.txtとして取得しています。STEP 6〜7はNETの個数の上限を確認するために後日（2026-09-08）追加したもので、..._trace.txtはありません。

STEP 0：初期状態

追加取得: R1 経路とtraceroute

STEP 1：R2のArea IDを49.0003へ変更 — R1とのレベル1隣接が成立しなくなる

追加取得: R1 経路とtraceroute

STEP 2：R2に2つ目のNETを追加（マルチホーミング） — エリアが統合され、レベル1隣接が復活

追加取得: R1 経路とtraceroute

STEP 3：R2から49.0003のNETを削除 — エリアを分割し、単一NETへ戻す

追加取得: R1 経路とtraceroute

STEP 4：R3のSystem IDをR2と同じ値へ変更 — レベル2バックボーンが分断される

追加取得: R1 経路とtraceroute

STEP 5：R3を元のNETへ戻す — 初期状態と同じ

追加取得: R1 経路とtraceroute

STEP 6：R2にNETを2つ追加し、さらに4つ目を投入 — 4つ目はcommitが拒否され、3つのNETを持つ状態になる

追加取得: R2 4つ目のNETを投入したときの応答

STEP 7：R2の追加した2つのNETを削除（最終状態） — 初期状態と同じ

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

R1–R2リンク（レベル1隣接）のキャプチャー(isis-nsap-l1.pcap) をダウンロード

R2–R3リンク（レベル2隣接）のキャプチャー(isis-nsap-l2.pcap) をダウンロード

Area ID変更時（STEP 1）のキャプチャー(isis-nsap-area-change.pcap) をダウンロード

System ID重複時（STEP 4）のキャプチャー(isis-nsap-dup-sysid.pcap) をダウンロード

参考

関連記事

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