NSAP Addresses and the NET (System ID)

What Is an NSAP Address and a NET

IS-IS was not designed for IP: ISO standardized it to route CLNP, the network-layer protocol of the OSI reference model (covered in What Is IS-IS). Because of that, every router needs one ISO-style address configured on it even when IS-IS is used purely for IP routing. That address is an NSAP (Network Service Access Point), and the one configured to represent the router itself is called a NET (Network Entity Title).

The biggest difference from an IP address is what it is attached to.

What IS-IS uses to identify “which router originated this LSP” and “which node on the topology map” is the System ID inside that NSAP. It corresponds to the OSPF router ID, except that it is an identifier with no relationship to any IP address.

NSAP Address Format

The formal NSAP format is defined in Annex A (normative) of ISO/IEC 8348, in two parts (A.5.1.1). This article works from the 2002 third edition, which is technically aligned with ITU-T Recommendation X.213. ISO/IEC 10589:2002 cites the 1996 second edition normatively, and the NSAP address definition itself goes back to Addendum 2 (ISO 8348/Add.2) of an earlier edition.

The familiar breakdown of the DSP into “HO-DSP”, “ID” and “SEL” is not ISO/IEC 8348 terminology. It comes from allocation policies such as GOSIP and from vendor implementations built on them. ISO/IEC 8348 goes only as far as IDP and DSP, and says of the DSP that “the allocating authority specifies the format and semantics” (A.5.2.2).

When IS-IS is used for IP routing, however, you almost never have to think in those terms. In practice you work with the simplified NSAP format, which is just three fields.

An NSAP is at most 20 bytes long: clause A.5.4 of ISO/IEC 8348 states that the maximum length of an NSAP address in the preferred binary encoding is 20 octets. With a 6-byte System ID, the whole address is 8 bytes when the Area ID is the minimum 1 byte (the AFI alone) and 20 bytes when the Area ID is the maximum 13 bytes. For IP routing it is common to build a 10-byte address: 1 byte of AFI, 2 bytes of area information, 6 bytes of System ID and 1 byte of NSEL.

49.0001.0010.0100.1001.00
└─┬──┘ └──────┬──────┘ └┬┘
Area ID    System ID   NSEL
(3 bytes)  (6 bytes)  (1 byte)

AFI and 49

The Area ID starts with the AFI. According to clause A.5.1.1.1 of ISO/IEC 8348, the AFI specifies four things:

1. The format of the IDI
2. The authority that allocates IDI values
3. Whether leading zero digits in the IDI are significant
4. The abstract syntax of the DSP

The allocations are those of Table A.4 in the same standard.

Some rows carry two values because of point 3 above. Where the IDI format is variable-length, the preferred binary encoding has to pad the IDI out to its maximum length, and padding zeros must be distinguishable from meaningful ones. Two AFI values are therefore allocated to each such combination: the lower one when the first significant digit of the IDI is non-zero, the higher one when it is zero (A.5.2.1.2). Formats whose IDI is fixed-length or null (ISO DCC, ISO 6523 ICD, IANA ICP, ITU-T IND and Local) need no such distinction and get a single value each.

Of these, 49 is the Local IDI format with a binary DSP syntax. What makes Local distinctive is that its IDI is null, so the whole IDP is just the two digits of the AFI (A.5.2.1.2.9). The preferred binary encoding turns those two digits into one octet, which means the DSP begins immediately after the 49. That is why an area and a System ID can follow straight on in a NET written as 49.0001.0010.0100.1001.00.

The maximum DSP for Local in binary syntax is 19 octets (Table A.5), which with the one octet of AFI comes to exactly 20.

Note that “Local means private use” is not the standard’s wording. What ISO/IEC 8348 says, in the note to Table A.4, is that the Local IDI format exists “to accommodate the coexistence of OSI and non-OSI network addressing schemes, particularly in the context of a transition from non-OSI to OSI protocols”. That said, having no IDI means there is no higher authority guaranteeing uniqueness, so such addresses can indeed collide outside the organization — which is why they get described as the counterpart of a private IP address. For IS-IS running purely as an IGP for IP routing, 49 is enough: IS-IS route information never leaves the AS, and BGP handles the space between autonomous systems.

Large ISPs sometimes use 20-byte NSAPs taken from a public space (ISO 6523 ICD, for example). As far as IP routing behaviour goes, a 10-byte NET starting with 49 and a 20-byte public NSAP behave identically.

Test Environment

The test environment is four Cisco IOS XR routers (XRd 26.1.1) in a line, spanning two areas. R1 and R2 are in area 49.0001, R3 and R4 in area 49.0002, so the areas differ across the R2–R3 link in the middle.

The test runs in six stages (STEP 0 to 5). The show output, syslog and running-config collected from all four routers at every STEP are gathered in Verification config and show output at the end of the article.

Area ID

The Area ID identifies the area a router belongs to. 49.0001 is the AFI 49 followed by the area information 0001.

What matters about the Area ID is that a Level 1 adjacency cannot form unless the Area IDs match. Level 1 is the mechanism by which routers in the same area share the detailed topology of that area, so the constraint follows naturally. A Level 2 adjacency, on the other hand, forms even when the Area IDs differ, because Level 2 is the backbone that spans areas.

Seen from R2 in the initial state, the difference is right there.

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

R1, in the same area 49.0001, is L1; R3, whose Area ID differs, is L2.

What the IIH actually carries

It is tempting to assume the adjacency became Level 2 because of what R3 supports. It did not. Capturing the IIHs in both directions on the R2–R3 link narrows the cause down to the Area ID alone.

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

Both directions say Circuit type: Level 1 and 2, so both routers are willing to run Level 1. The reason no Level 1 adjacency forms is the Area address TLV (TLV 1) carried in the same IIH.

That single value is the only difference, and the result is a Level 2 adjacency only. The roles of Level 1 and Level 2 themselves are covered in Level 1 and Level 2.

What happens when you change the Area ID (STEP 1)

Changing R2’s Area ID from 49.0001 to 49.0003 stops the Level 1 adjacency with R1 from forming. R1’s syslog even states the reason.

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 says it outright. On R2 the sequence was recorded like this.

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 

Changing the NET takes the IS-IS interfaces down, so both the Level 1 and the Level 2 adjacency drop. The Level 2 one comes back about three seconds later; the Level 1 one cannot, because the Area IDs no longer match. R2 is left with a single neighbour.

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 loses every route it learned from IS-IS and is isolated (show route isis returns % No matching routes found).

The capture shows the Area address TLV in the IIH changing across the event.

    .... ..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

The Circuit type is unchanged; only the Area address moved.

In between, the capture also caught R2 withdrawing its own Level 1 LSP from the old area.

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

An LSP with Remaining lifetime: 0 and no checksum is a purge. Clause 7.3.16.4 of ISO/IEC 10589:2002 says that when an LSP’s lifetime reaches zero only its header is retained and propagated. The Purge Originator ID TLV (TLV 13) names the router that issued it; that TLV is not in ISO/IEC 10589 but was added by RFC 6232. Having changed its area, R2 is no longer a member of 49.0001, so it removes its own LSP from that area.

Choosing a System ID

The System ID is the 6-byte value that identifies a node, and clause 7.1.4 of ISO/IEC 10589:2002 imposes these constraints.

• It must be unique within an area. In the standard’s words, no two systems (IS or ES) in an area may use the same ID. An LSP’s identifier (the LSP ID) is built from the System ID, so duplicates end up being treated as the same LSP
• Level 2 routers must be unique across the whole routeing domain
• Every System ID in a domain must be the same length (automatically satisfied by Cisco’s fixed 6 bytes)

The standard allows a Level 1-only router to reuse a System ID that exists in another area, but in practice it is kept unique across the whole domain, to avoid operational confusion. This article assumes that too. What actually happens on a collision is shown in What happens when System IDs collide.

Deriving it from a loopback address

Nothing dictates the value of a System ID, but deriving it mechanically from a loopback IP address is widespread, and is the method ISPs commonly use.

Step 1. Pad each octet with zeros to three digits
        192.168.1.24  ->  192.168.001.024

Step 2. Regroup the 12 digits into three groups of four
        192168001024  ->  1921.6800.1024

Step 3. Add the Area ID and NSEL to form the NET
        49.0001.1921.6800.1024.00

The benefit is that one loopback address serves several purposes at once. The BGP router ID, the MPLS-TE router ID, the network management target and the IS-IS System ID all derive from the same value, so when LSPs are listed in show isis database you know instantly which router each came from.

The test environment follows the same rule.

Note that 6 bytes is the same length as a MAC address. That is not a coincidence but a consequence of GOSIP 2.0, and some operators use one of the router’s MAC addresses directly as the System ID. On a router with several LAN interfaces you have to decide which one to use, and replacing the hardware changes the System ID, so deriving it from a loopback is easier to operate.

NSEL

The last byte of an NSAP is the NSEL (NSAP selector). It says which higher-layer user the network layer service should be handed to, a role close to a protocol number or port number in IP.

In a NET the NSEL is always 00, because 00 means “not a particular higher-layer user, but the node’s own network entity”. What you configure on a router represents the node itself, so it cannot be anything else.

IOS XR in fact refuses a NET whose NSEL is 01 while it is still parsing the command.

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

The caret points at the NSEL position. The command never reaches the commit, so the configuration is unchanged.

Configuring and checking the NET

On IOS XR the net command under router isis does it.

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

is-type states which levels this router runs. The default is both Level 1 and Level 2 (level-1-2), and in that case no is-type line appears in show running-config. R2 and R3 in this article are left at the default, so their configuration starts at net.

What was configured is visible with 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 is also accepted, but on XRd 26.1.1 it produces exactly the same output as show isis (it is an alias).

Multiple NETs (multihoming), merging and splitting areas

A router can be given several NETs, which IS-IS calls multihoming. Clause 7.1.5 of ISO/IEC 10589:2002 lets an area have several synonymous area addresses, and the number a router can hold is governed by the management parameter maximumAreaAddresses. Its default is 3, and the standard’s wording is that every IS shall support a value of at least 3 — not “at most 3” (the PDU field can express 1 to 254). Cisco implementations fix it at 3, which is why “three at most” is the rule of thumb in practice; what XRd actually does with a fourth one is shown in A fourth NET is refused (STEP 6). Two constraints apply.

• The System ID must be identical in every NET. Only the Area ID may differ
• It does not put the router in several areas at once. Configuring several Area IDs merges those areas into one

That property is what makes merging and splitting areas possible.

Merging areas (STEP 2)

R2, whose Area ID was changed to 49.0003 in STEP 1, gets the original 49.0001 NET added back. The System ID stays 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

Both Manual area address(es) and Routing for area address(es) now have two lines. System Id is still a single value; only the Area IDs multiplied.

That brings the Level 1 adjacency with R1 back.

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 identifies R2 by its 49.0003 NET, yet a Level 1 adjacency forms. What matched was the other one, 49.0001: if even one of the configured Area IDs matches the peer, a Level 1 adjacency can form — which is exactly what “the two areas are merged” means.

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

Splitting areas (STEP 3)

Removing the NET of an area you no longer need splits them again. STEP 3 removed 49.0003 and went back to a single NET.

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

The adjacencies return to the initial state (Level 1 with R1, Level 2 with R3). Re-organizing areas in production follows the same shape: configure both Area IDs on the border router first, then remove the one you no longer want.

A fourth NET is refused (STEP 6)

To find out how many NETs XRd accepts, STEP 6 added the NETs 49.0003 and 49.0004 to R2 one at a time and then tried a fourth, 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

The second and third NETs committed without complaint, but the fourth was rejected with maximum number of area addresses is 3. XRd 26.1.1 has no command such as max-area-addresses under router isis either (% Invalid input), so the limit of 3 cannot be raised. The value that ISO/IEC 10589:2002 requires as “at least 3” is fixed at exactly 3 in this implementation.

With three NETs, R2’s show isis lists three area addresses.

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

As in STEP 2, both adjacencies (Level 1 with R1, Level 2 with R3) stayed up. STEP 7 removed the two added NETs and returned R2 to a single NET.

Dynamic hostname (TLV 137)

A System ID such as 0010.0100.1001 is a hexadecimal value and hard to read as it is. To compensate, IS-IS has a mechanism for advertising its own hostname in TLV 137 of an LSP (RFC 5301). Receiving routers remember the System-ID-to-hostname mapping and print the hostname in show output.

IOS XR enables this by default. The table is visible with 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

Note that R4 is absent from the table. R4 is a Level 1 router in area 49.0002, so its LSP circulates only inside that area and never reaches R2 in area 49.0001. The hostname table only ever covers as far as LSPs travel.

Because hostnames ride in LSPs, a router does not know its peer’s hostname at the instant the adjacency comes up. That is why boot-time syslog can show a peer as a NET (49.0001.0020.0200.2002) rather than as R2.

For environments where the dynamic hostname is unavailable, clns host <name> <NSAP> writes the table statically. It requires the same table on every router, so it is rarely used today.

What happens when System IDs collide

STEP 4 changed R3’s System ID to R2’s value, 0020.0200.2002 (making the NET 49.0002.0020.0200.2002.00). Both R2 and R3 are attached to the Level 2 backbone, so this is precisely the combination that is not allowed.

First, both R2 and R3 emit a dedicated error message.

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 names the value, the interface the offending IIH arrived on, and the peer’s SNPA (MAC address) — everything you need to track it down.

Because the duplicate IIH is not accepted, the adjacency is never refreshed and times out (Holdtime expired). The Level 2 backbone is cut in two.

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

Only R2’s own LSP is left in the Level 2 database.

The damage reaches outside the area as well. R1, a Level 1 only router, lost the default route it had been using.

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

The i*L1 0.0.0.0/0 line present in the initial state is gone. A Level 1 router does not hold individual routes to other areas; it builds a default route from the ATT (Attached) bit that Level 1/Level 2 routers set. R2 lost its Level 2 adjacency and therefore cleared the ATT bit, and R1’s default route went with it (the ATT bit is covered in The ATT bit and the Level 1 default route).

As a result R1 can no longer reach 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 means network unreachable. In the initial state the same traceroute succeeded in three hops.

One mistyped System ID on one router stops inter-area connectivity entirely. The scale of that impact is why keeping System IDs unique across the whole domain is the recommended practice. Restoring R3’s original NET in STEP 5 brought the adjacencies and routes back to the initial state.

Verification config and show output

At every STEP the following three files were collected from all four routers, separately per router. The verification config is the ..._run.txt file (the final state being the STEP 7 one).

In addition, 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 were collected from R1 in STEPs 0 to 5 as ..._trace.txt. STEPs 6 and 7 were added later (2026-09-08) to check the NET limit and have no ..._trace.txt.

STEP 0: initial state

Also collected: routes and traceroute on R1

STEP 1: change R2’s Area ID to 49.0003 — the Level 1 adjacency with R1 can no longer form

Also collected: routes and traceroute on R1

STEP 2: add a second NET to R2 (multihoming) — the areas merge and the Level 1 adjacency returns

Also collected: routes and traceroute on R1

STEP 3: remove the 49.0003 NET from R2 — splits the areas, back to a single NET

Also collected: routes and traceroute on R1

STEP 4: change R3’s System ID to the same value as R2’s — the Level 2 backbone is cut in two

Also collected: routes and traceroute on R1

STEP 5: restore R3’s original NET — same as the initial state

Also collected: routes and traceroute on R1

STEP 6: add two NETs to R2, then try a fourth — the fourth commit is refused, leaving R2 with three NETs

Also collected: R2’s response to the fourth NET

STEP 7: remove the two added NETs from R2 (final state) — same as the initial state

There are four capture files.

Download the capture of the R1-R2 link, Level 1 adjacency (isis-nsap-l1.pcap)

Download the capture of the R2-R3 link, Level 2 adjacency (isis-nsap-l2.pcap)

Download the capture of the Area ID change, STEP 1 (isis-nsap-area-change.pcap)

Download the capture of the System ID collision, STEP 4 (isis-nsap-dup-sysid.pcap)

References

Related articles

• What Is IS-IS
• NSAP Addresses and the NET (System ID)
• Level 1 and Level 2 (the IS-IS hierarchy)
• IS-IS Packet Types and Header Format
• Adjacency Formation and States
• The DIS and the Pseudonode
• Network Types (broadcast / point-to-point)