IS-IS Packet Types and Header Format

IS-IS Packet Types and Header Format

IS-IS does everything from neighbour discovery to database synchronization with its own packets (the protocol as a whole is covered in What Is IS-IS). ISO/IEC 10589 calls them PDUs (Protocol Data Units); this article says “packet” to match the IP vocabulary.

Compared with OSPF, IS-IS packets stand out in one way: the header is very short and almost everything else is a TLV (Type-Length-Value). The header shared by every packet is just 8 bytes, followed by a per-type fixed part and then a run of variable-length TLVs.

This article walks through the nine packet types, the fields of the common header and the TLV mechanism, checking each against captures taken on real equipment (Cisco IOS XR). All nine types were actually observed, so a tshark listing is included for each.

The Addresses and Encapsulation IS-IS Packets Use

IS-IS packets do not ride on IP; they are carried directly as the payload of an Ethernet frame. The encapsulation is covered in detail in What Is IS-IS; three points from it matter for this article.

All three multicast MAC addresses appear in Table 9 of ISO/IEC 10589:2002 (architectural constants for ISO 8802 subnetworks). They do not all have the same standing, though. 01:80:C2:00:00:14 (AllL1ISs) and 01:80:C2:00:00:15 (AllL2ISs) are IS-IS’s own destinations for LAN IIHs, whereas 09:00:2B:00:00:05 is described in that table as “AllIntermediateSystems — the multi-destination address ‘All Intermediate Systems’ used by ISO 9542”, making it an ES-IS (ISO 9542) address rather than an IS-IS one. Its use when IS-IS runs as point-to-point over Ethernet is an implementation convention, not something ISO/IEC 10589 prescribes.

Because this article’s test uses both a broadcast link and a point-to-point link, all three were observed.

Packet Types

IS-IS packets fall into three categories, numbered by level and link type. Clause 9.4 of ISO/IEC 10589:2002 lists exactly nine of them.

Mapped onto OSPF:

In IS-IS the PSNP does two jobs: requesting missing LSPs (OSPF’s LSR) and acknowledging received ones (OSPF’s LSAck). Both faces are shown side by side with real captures in PSNP (PDU Type 26 / 27). And where OSPF has a single Hello, IS-IS splits Hello three ways by link type and level.

There is no PDU numbered 19. ISO/IEC 10589:2002 defines only the nine in the table above (clause 9.4); nothing is assigned to 19, which sits between the Level 1 LSP at 18 and the Level 2 LSP at 20.

The Common Header Format

All nine packet types begin with the same 8-byte header. Every field is one byte.

The catch with ID Length and Maximum Area Addresses is that 0 does not mean “none” but “the default” (6 bytes / 3 addresses). Real equipment does put 0 in both.

Clause 9.1 of ISO/IEC 10589:2002 numbers octets in a PDU from 1 upwards and bits within an octet from 1 to 8, bit 1 being the least significant. The bit numbers above follow that convention.

The Length Indicator changes with the packet type, because it is the 8-byte common header plus the length of the per-type fixed part. These are the values observed here.

How TLVs Work

Behind the common header and the per-type fixed part comes a run of TLVs (Type-Length-Value).

Because Length is one byte, a single TLV carries at most 255 bytes of Value. Anything larger is carried by repeating TLVs of the same Type. ISO/IEC 10589:2002 states for every PDU that unrecognised CODEs in a received PDU are ignored, and for LSPs it adds that they are passed through unchanged (clause 9.8). That is why an unknown TLV does not break flooding.

ISO/IEC 10589:2002 calls this run VARIABLE LENGTH FIELDS and labels the first byte CODE rather than “Type” (clauses 9.5 to 9.13). Neither “TLV” nor “CLV” appears anywhere in the standard, but “TLV” is what IETF and vendor documentation settled on, so this article uses it throughout.

The payoff is that IS-IS can carry something new by adding a TLV. The header format never has to change, which is how IPv6 support (RFC 5308), MPLS traffic engineering and segment routing were all bolted on. The main TLVs are covered in IS-IS TLVs.

In fact only some of the TLVs in these captures come from the standard itself. ISO/IEC 10589:2002 defines CODEs 1 to 10 and 14; everything else was added later by the IETF.

Verification on Real Equipment

The Test Environment

To observe all nine packet types, the topology deliberately includes both a broadcast link and a point-to-point link. Some packets (PDU Types 15, 16 and 24) only ever appear on a LAN, so a topology with just one kind of link cannot produce all nine.

R1, R2 and R3 sit on one broadcast segment (10.1.0.0/24) in area 49.0001, and only the R3–R4 link is point-to-point. R4 is in a different area, 49.0002, so R3–R4 forms a Level 2 adjacency.

The LAN interfaces are not given point-to-point. That is the whole point of this setup: leaving them in the default broadcast mode is what elects a DIS and makes LAN IIHs and CSNPs flow.

RP/0/RP0/CPU0:R3#show isis neighbors
Tue Sep  8 14:42:19.720 UTC

IS-IS 1 neighbors:
System Id      Interface        SNPA           State Holdtime Type IETF-NSF
R1             Gi0/0/0/0        5254.0026.ffa1 Up    26       L1   Capable 
R2             Gi0/0/0/0        5254.004c.38a4 Up    22       L1L2 Capable 
R4             Gi0/0/0/1        *PtoP*         Up    29       L2   Capable 

Total neighbor count: 3

Two adjacencies rather than three sit on the single Gi0/0/0/0 because R1 is Level 1 only while R2 is Level 1-2. Look at the SNPA column: the two LAN adjacencies carry the neighbour’s MAC address, while the P2P one reads *PtoP*. A broadcast link needs a MAC address (the SNPA, Subnetwork Point of Attachment) to identify who it is talking to; a point-to-point link has only one possible peer and needs none.

show isis interface brief makes the difference sharper still.

RP/0/RP0/CPU0:R3#show isis interface brief
Tue Sep  8 14:42:19.560 UTC

IS-IS 1 Interfaces
    Interface      All     Adjs    Adj Topos  Adv Topos  CLNS   MTU    Prio  
                   OK    L1   L2    Run/Cfg    Run/Cfg                L1   L2
-----------------  ---  ---------  ---------  ---------  ----  ----  --------
Lo0                Yes    -    -      0/0        1/1     No       -    -    -
Gi0/0/0/0          Yes    2*   1*     1/1        1/1     Up    1497   64   64
Gi0/0/0/1          Yes    0    1      1/1        1/1     Up    1497    -    -

The LAN interface Gi0/0/0/0 has Prio 64, while the P2P interface Gi0/0/0/1 has -. Priority exists to elect a DIS, so a point-to-point link, which has no DIS, has no value for it. The * next to an adjacency count marks this router as the DIS for that level; R3 became DIS for both Level 1 and Level 2.

That default of 64 matches l1IntermediateSystemPriority / l2IntermediateSystemPriority in the management-information definitions of ISO/IEC 10589:2002. The election rule (clause 8.4.5 of the same standard) is “the highest-priority IS, ties broken by the numerically highest MAC address”, and indeed R3 has the largest of the three MACs (R1 5254.0026.ffa1, R2 5254.004c.38a4, R3 5254.0084.f661). DIS election and pseudonodes are covered in The DIS and Pseudonodes; this article goes only as far as showing that a LAN IIH has Priority and LAN ID fields.

The Test STEPs

Captures were taken at two points: the LAN segment (between R3 and the switch) and the R3–R4 link.

STEP 1 produced eight of the nine, but the L1 PSNP (26) did not appear. Restarting all four routers at once let flooding alone bring the databases into line, so no router ever had to ask for a missing LSP. STEP 2 therefore restarted only R1 while the other three kept running, forcing R1 to rebuild its database from scratch. R1 then answered the DIS’s periodic CSNP with a request, and the L1 PSNP was captured.

The set of PDU types in the captures can be checked mechanically:

$ for f in isis-packet-lan.pcap isis-packet-p2p.pcap isis-packet-lan-resync.pcap; do
>   tshark -r $f -n -V 2>/dev/null | grep -oE "PDU Type: [A-Za-z0-9 -]+ \([0-9]+\)"
> done | sort | uniq -c
  40 PDU Type: L1 CSNP (24)
 214 PDU Type: L1 HELLO (15)
  30 PDU Type: L1 LSP (18)
   1 PDU Type: L1 PSNP (26)
  41 PDU Type: L2 CSNP (25)
 161 PDU Type: L2 HELLO (16)
  36 PDU Type: L2 LSP (20)
  13 PDU Type: L2 PSNP (27)
  45 PDU Type: P2P HELLO (17)

All nine are there. The rest of this article looks at each in turn.

IIH (PDU Type 15 / 16 / 17)

The IIH (IS-IS Hello) forms and maintains adjacencies, and it splits three ways by link type and level.

The difference is that a broadcast link uses a separate packet per level, while point-to-point uses one packet that states its level inside.

LAN Level 1 IIH (PDU Type 15)

An IIH sent onto the LAN by R1 (level-1). The destination MAC is 01:80:c2:00:00:14 (AllL1ISs).

ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
    Intradomain Routing Protocol Discriminator: ISIS (0x83)
    Length Indicator: 27
    Version/Protocol ID Extension: 1
    ID Length: 0
    000. .... = Reserved: 0x0
    ...0 1111 = PDU Type: L1 HELLO (15)
    Version: 1
    Reserved: 0
    Maximum Area Addresses: 0
ISIS HELLO
    .... ..01 = Circuit type: Level 1 only (0x1)
    0000 00.. = Reserved: 0x00
    SystemID {Sender of PDU}: 0010.0100.1001
    Holding timer: 30
    PDU length: 1497
    .100 0000 = Priority: 64
    0... .... = Reserved: 0
    SystemID {Designated IS}: 0030.0300.3003.01
    Protocols Supported (t=129, l=1)
        Type: 129
        Length: 1
        NLPID: IP (0xcc)
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0001
    IP Interface address(es) (t=132, l=4)
        Type: 132
        Length: 4
        IPv4 interface address: 10.1.0.1
    IS Neighbor(s) (t=6, l=12)
        Type: 6
        Length: 12
        IS Neighbor: 52:54:00:4c:38:a4
        IS Neighbor: 52:54:00:84:f6:61
    Padding (t=8, l=255)
        Type: 8
        Length: 255

The eight bytes of the common header line up exactly with the table in The Common Header Format. ID Length: 0 and Maximum Area Addresses: 0 both mean “the default”, not zero. Note too that PDU Type is expanded as five bits, ...0 1111, with the top three shown separately as 000. .... = Reserved.

The fixed part that follows is defined in clause 9.5 of ISO/IEC 10589:2002.

R1 is configured is-type level-1, so Circuit type reads Level 1 only (0x1) — exactly what NOTE 55 of ISO/IEC 10589:2002 requires when it says a LAN Level 1 IIH must carry a Circuit Type of 1 or 3.

The LAN ID holds R3’s System ID, not R1’s (0030.0300.3003.01). Clause 9.5 defines LAN ID as the DIS’s System ID plus a low-order byte assigned by the DIS, copied from the DIS’s own IIH. R1, not being the DIS, simply echoes back what R3 sent. That trailing .01 is the number the DIS chose, and it is also what makes the pseudonode LSP appear as R3.01-00 in show isis database.

The other thing unique to a LAN IIH is TLV 6 (IS Neighbours), which lists the MAC addresses of the IS-IS routers R1 can see on this LAN (R2’s 52:54:00:4c:38:a4 and R3’s 52:54:00:84:f6:61). Confirming that the neighbour can see you is done through this TLV on a broadcast link. It never appears in a point-to-point IIH.

LAN Level 2 IIH (PDU Type 16)

A Level 2 IIH sent onto the same LAN by R2 (level-1-2). The destination MAC is 01:80:c2:00:00:15 (AllL2ISs).

ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
    Intradomain Routing Protocol Discriminator: ISIS (0x83)
    Length Indicator: 27
    Version/Protocol ID Extension: 1
    ID Length: 0
    000. .... = Reserved: 0x0
    ...1 0000 = PDU Type: L2 HELLO (16)
    Version: 1
    Reserved: 0
    Maximum Area Addresses: 0
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
    .100 0000 = Priority: 64
    0... .... = Reserved: 0
    SystemID {Designated IS}: 0030.0300.3003.01

The field layout is identical to the LAN Level 1 IIH (15); clause 9.6 of ISO/IEC 10589:2002 simply repeats the figure from 9.5. What differs is the PDU Type number, the destination MAC, and the fact that Priority and LAN ID refer to the Level 2 DIS. The Length Indicator is the same 27.

R2 is level-1-2, so its Circuit type is Level 1 and 2 (0x3). Set against R1’s 0x1, it is clear that the is-type setting lands directly in this field.

Level 1 and Level 2 elect their DIS separately, but in this test R3 won both, so LAN ID is the same 0030.0300.3003.01 as in the Level 1 IIH.

Point-to-Point IIH (PDU Type 17)

An IIH sent by R3 to R4. The destination MAC is 09:00:2b:00:00:05.

ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
    Intradomain Routing Protocol Discriminator: ISIS (0x83)
    Length Indicator: 20
    Version/Protocol ID Extension: 1
    ID Length: 0
    000. .... = Reserved: 0x0
    ...1 0001 = PDU Type: P2P HELLO (17)
    Version: 1
    Reserved: 0
    Maximum Area Addresses: 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
    Point-to-point Adjacency State (t=240, l=15)
        Type: 240
        Length: 15
        Adjacency State: Up (0)
        Extended Local circuit ID: 0x00000005
        Neighbor SystemID: 0040.0400.4004
        Neighbor Extended Local circuit ID: 0x00000004

The fixed part defined in clause 9.7 of ISO/IEC 10589:2002 differs from the LAN IIH in only its last field.

The Length Indicator is 27 for a LAN IIH and 20 for a P2P IIH, and the difference of 7 bytes is exactly Priority (1) plus LAN ID (7) minus Local Circuit ID (1). A point-to-point link needs no DIS, so the two fields that exist for the DIS disappear entirely. Whether a DIS exists is what shapes the header.

Circuit type is 0x3 (both levels), yet only a Level 2 adjacency actually forms, because R3 and R4 are in different areas. Circuit type declares the levels a router is willing to run; which level actually comes up depends on the area IDs as well (see Level 1 and Level 2).

TLV 240 (Point-to-Point Adjacency State), which appears in the capture, is not in ISO/IEC 10589. The standard’s point-to-point adjacency is a two-way handshake: an arriving IIH is enough to bring the adjacency up, and nothing checks whether the peer can see you. RFC 5303 added the three-way handshake, and TLV 240 with it. Neighbor SystemID: 0040.0400.4004 means “I am receiving your (R4’s) IIHs”, and only on seeing that does R4 bring the adjacency up.

On a broadcast link, the MAC list in TLV 6 (IS Neighbours) plays this role instead. The two link types confirm two-way visibility differently, and that is one reason IIHs come in three flavours.

LSP (PDU Type 18 / 20)

An LSP distributes a router’s own link state: 18 for Level 1, 20 for Level 2.

Level 1 LSP (PDU Type 18)

R1 sending its own Level 1 LSP.

ISO 10589 ISIS Link State Protocol Data Unit
    PDU length: 90
    Remaining lifetime: 1200
    LSP-ID: 0010.0100.1001.00-00
    Sequence number: 0x00000003
    Checksum: 0x2ad2 [correct]
    [Checksum Status: Good]
    Type block(0x01): Partition Repair:0, Attached bits:0, Overload bit:0, IS type:1
        0... .... = Partition Repair: Not supported
        .000 0... = Attachment: 0
            .0.. .... = Error metric: Not set
            ..0. .... = Expense metric: Not set
            ...0 .... = Delay metric: Not set
            0... .... = Default metric: Not set
        .... .0.. = Overload bit: Not set
        .... ..01 = Type of Intermediate System: Level 1 (1)
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0001
    Originating neighbor buffer size (t=14, l=2)
        Type: 14
        Length: 2
        Neighbor originating buffer size: 1492
    Protocols supported (t=129, l=1)
        Type: 129
        Length: 1
        NLPID: IP (0xcc)
    IP Interface address(es) (t=132, l=4)
        Type: 132
        Length: 4
        IPv4 interface address: 1.1.1.1
    Hostname (t=137, l=2)
        Type: 137
        Length: 2
        Hostname: R1
    IP Internal reachability (t=128, l=24)
        Type: 128
        Length: 24
        IPv4 prefix: 1.1.1.1/32
            ..00 0000 = Default Metric: 0

Clause 9.8 of ISO/IEC 10589:2002 defines what follows the common header.

The three parts of the LSP ID are exactly what the LSPID column of show isis database prints. In 0010.0100.1001.00-00, the .00 is the Pseudonode ID and the -00 is the LSP Number. An LSP with a non-zero Pseudonode ID belongs to a pseudonode; here that is 0030.0300.3003.01-00, issued by the DIS R3.

The last byte is the value behind the ATT/P/OL column of show isis database.

That ATT is four bits wide is not something the ATT/P/OL display or the phrase “the ATT bit” reveals. The tshark output above shows the definition directly: under Attachment: 0 it expands Error metric, Expense metric, Delay metric and Default metric. Only the Default metric is used in modern IP networks, so in practice it behaves as one bit, and the ATT that show prints is that bit 4.

R1 is level-1, so IS type is Level 1 (1), and since it has no way out to another area every ATT bit is 0. The Level 1 LSPs of the Level 1-2 routers R2 and R3 do set ATT (see Level 1 and Level 2).

Among the TLVs is Originating neighbor buffer size (t=14). That is CODE 14 (originatingLSPBufferSize) from ISO/IEC 10589:2002, and its value of 1492 matches the architectural constant RecieveLSPBufferSize = 1492 in Table 2 of the same standard.

Level 2 LSP (PDU Type 20)

A Level 2 LSP from R3.

ISO 10589 ISIS Link State Protocol Data Unit
    PDU length: 137
    Remaining lifetime: 1200
    LSP-ID: 0030.0300.3003.00-00
    Sequence number: 0x00000006
    Checksum: 0xb0ed [correct]
    [Checksum Status: Good]
    Type block(0x03): Partition Repair:0, Attached bits:0, Overload bit:0, IS type:3
        0... .... = Partition Repair: Not supported
        .000 0... = Attachment: 0
            .0.. .... = Error metric: Not set
            ..0. .... = Expense metric: Not set
            ...0 .... = Delay metric: Not set
            0... .... = Default metric: Not set
        .... .0.. = Overload bit: Not set
        .... ..11 = Type of Intermediate System: Level 2 (3)
    Area address(es) (t=1, l=4)
        Type: 1
        Length: 4
        Area address (3): 49.0001
    Hostname (t=137, l=2)
        Type: 137
        Length: 2
        Hostname: R3
    IP Internal reachability (t=128, l=60)
        Type: 128
        Length: 60
        IPv4 prefix: 1.1.1.1/32
            ..00 1010 = Default Metric: 10

The header format is the same as a Level 1 LSP (clause 9.9 of ISO/IEC 10589:2002). What differs is the PDU Type of 20 and the IS type of Level 2 (3). R3 is level-1-2, so the same router issues a Level 1 LSP (IS type 1) and a Level 2 LSP (IS type 3) separately.

Every ATT bit is 0 because Level 2 LSPs do not use ATT. ATT tells a Level 1 area that this router is a way out to other areas, so it only means anything in a Level 1 LSP.

CSNP (PDU Type 24 / 25)

A CSNP shows the peer the list of LSPs held in the sender’s database.

Level 1 CSNP (PDU Type 24)

R3, the DIS, sending its periodic Level 1 CSNP onto the LAN.

ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
    Intradomain Routing Protocol Discriminator: ISIS (0x83)
    Length Indicator: 33
    Version/Protocol ID Extension: 1
    ID Length: 0
    000. .... = Reserved: 0x0
    ...1 1000 = PDU Type: L1 CSNP (24)
    Version: 1
    Reserved: 0
    Maximum Area Addresses: 0
ISO 10589 ISIS Complete Sequence Numbers Protocol Data Unit
    PDU length: 99
    Source-ID: 0030.0300.3003
    Source-ID-Circuit: 00
    Start LSP-ID: 0000.0000.0000.00-00
    End LSP-ID: ffff.ffff.ffff.ff-ff
    LSP entries (t=9, l=64)
        Type: 9
        Length: 64
        LSP Entry
            LSP Sequence Number: 0x00000005
            Remaining Lifetime: 1159
            LSP checksum: 0x26d4
        LSP-ID: 0010.0100.1001.00-00
        LSP Entry
            LSP Sequence Number: 0x00000006
            Remaining Lifetime: 1197
            LSP checksum: 0xae16
        LSP-ID: 0020.0200.2002.00-00
        LSP Entry
            LSP Sequence Number: 0x00000007
            Remaining Lifetime: 1197
            LSP checksum: 0xf7f7
        LSP-ID: 0030.0300.3003.00-00
        LSP Entry
            LSP Sequence Number: 0x00000005
            Remaining Lifetime: 1158
            LSP checksum: 0x0417
        LSP-ID: 0030.0300.3003.01-00

Clause 9.10 of ISO/IEC 10589:2002 defines the CSNP’s fixed part.

Start LSP-ID is 0000... and End LSP-ID is ffff..., covering the entire space of possible LSP IDs. That is what “Complete” means. Clause 7.3.15 of ISO/IEC 10589:2002 allows the set to be split across several CSNPs when it does not fit in one, but requires their ranges to be contiguous and to cover the whole range of possible LSP IDs. On that basis it states that the absence of an LSP ID from a CSNP whose range includes it means total lack of information about that LSP — which is exactly how the receiver detects what the sender is missing.

The list itself travels in TLV 9 (LSP Entries). Each entry is 16 bytes: Remaining Lifetime (2), LSP ID (8), LSP Sequence Number (4) and Checksum (2). Four entries at 16 bytes gives the 64 that Length: 64 reports.

The ordering matters too: 0010.0100.1001.00-00, 0020.0200.2002.00-00, 0030.0300.3003.00-00, 0030.0300.3003.01-00 — ascending LSP ID order, as ISO/IEC 10589:2002 requires, so that the receiver can diff the two lists efficiently.

The fourth entry, 0030.0300.3003.01-00, is the pseudonode LSP. Its Pseudonode ID is 01, and the DIS R3 issues it to represent the LAN itself as a single node. A broadcast link adds LSPs of this kind to the database (covered in The DIS and Pseudonodes).

Level 2 CSNP (PDU Type 25)

A Level 2 CSNP, this time seen on the point-to-point link.

ISO 10589 ISIS Complete Sequence Numbers Protocol Data Unit
    PDU length: 51
    Source-ID: 0030.0300.3003
    Source-ID-Circuit: 00
    Start LSP-ID: 0000.0000.0000.00-00
    End LSP-ID: ffff.ffff.ffff.ff-ff
    LSP entries (t=9, l=16)
        Type: 9
        Length: 16
        LSP Entry
            LSP Sequence Number: 0x00000002
            Remaining Lifetime: 1200

The format matches the Level 1 CSNP. What differed was how often they were sent.

Clause 7.3.15 of ISO/IEC 10589:2002 says the LAN Level 1 DIS periodically multicasts complete sets of Level 1 CSNPs to AllL1ISs, and the Level 2 DIS does the same for Level 2 to AllL2ISs. The default interval is the management parameter completeSNPInterval = 10 seconds, matching the roughly 10-second spacing observed.

On a broadcast link the DIS keeps announcing “this is the whole database” to hold everyone in sync; on a point-to-point link there is only one peer, so the exchange happens only when needed.

PSNP (PDU Type 26 / 27)

A PSNP is used both to request missing LSPs and to acknowledge received ones. Here are both faces, side by side, from real captures.

Level 1 PSNP (PDU Type 26): the request

Captured in STEP 2, when only R1 was restarted. Coming up with an empty database, R1 sees the DIS’s CSNP and asks for the LSPs it does not have.

ISO 10589 ISIS InTRA Domain Routeing Information Exchange Protocol
    Intradomain Routing Protocol Discriminator: ISIS (0x83)
    Length Indicator: 17
    Version/Protocol ID Extension: 1
    ID Length: 0
    000. .... = Reserved: 0x0
    ...1 1010 = PDU Type: L1 PSNP (26)
    Version: 1
    Reserved: 0
    Maximum Area Addresses: 0
ISO 10589 ISIS Partial Sequence Numbers Protocol Data Unit
    PDU length: 51
    Source-ID: 0010.0100.1001
    Source-ID-Circuit: 00
    LSP entries (t=9, l=32)
        Type: 9
        Length: 32
        LSP Entry
            LSP Sequence Number: 0x00000000
            Remaining Lifetime: 925
            LSP checksum: 0x0000
        LSP-ID: 0020.0200.2002.00-00
        LSP Entry
            LSP Sequence Number: 0x00000000
            Remaining Lifetime: 926
            LSP checksum: 0x0000
        LSP-ID: 0030.0300.3003.00-00

The giveaway is that LSP Sequence Number and LSP checksum are both 0. That means “I hold nothing at all for this LSP ID”, and R2 and R3 respond by sending their LSPs. This is the PSNP as a request.

Level 2 PSNP (PDU Type 27): the acknowledgement

The same packet type, but here R3 is telling R4 on the point-to-point link that it received R4’s LSP.

ISO 10589 ISIS Partial Sequence Numbers Protocol Data Unit
    PDU length: 35
    Source-ID: 0030.0300.3003
    Source-ID-Circuit: 00
    LSP entries (t=9, l=16)
        Type: 9
        Length: 16
        LSP Entry
            LSP Sequence Number: 0x00000001
            Remaining Lifetime: 1200
            LSP checksum: 0x6e56
        LSP-ID: 0040.0400.4004.00-00

This time LSP Sequence Number: 0x00000001 and LSP checksum: 0x6e56 carry real values: “I have indeed received the LSP with this sequence number and this checksum.”

The same PDU Type and the same TLV 9 mean different things depending on whether the values are zero. That is why IS-IS is described as folding OSPF’s LSR and LSAck into one packet.

CSNP and PSNP header differences

The PSNP’s fixed part (clause 9.12 of ISO/IEC 10589:2002) is the CSNP’s with the two range fields removed.

The 16-byte difference is Start LSP ID and End LSP ID (8 bytes each). Having no range field is precisely what “Partial” means. A CSNP declares “for this range, this is everything I hold”, so an LSP ID missing from it means the sender does not have it. A PSNP declares no range, so it speaks only about the LSPs listed in it. That single difference is why the same TLV 9 carries different meaning in the two packets.

IIH Padding

An IIH comes with padding that fills the frame out (TLV 8). It stops an adjacency from forming when the two ends of a link disagree on the MTU — the same job OSPF does with the MTU field in its DBD packets.

ISO/IEC 10589:2002 is specific about it: clauses 8.2.3 (point-to-point) and 8.4.2 (broadcast) require the IIH to be padded to at least maxsize − 1 bytes, where maxsize is the largest of:

It is “at least maxsize − 1” rather than exactly maxsize because, as the standard notes, the PDU should be padded to maxsize where possible, but if the PDU is already maxsize − 1 bytes no padding is possible or required (a TLV needs at least two bytes for CODE and LENGTH, so a single spare byte cannot hold one).

Disabling it at every end at once does not bring the adjacency down. Padding exists to verify that the MTUs agree; it is not itself a condition for forming an adjacency. What breaks an adjacency is disabling it on only one side while the MTUs differ, and that behaviour is covered in Adjacency Formation and States.

STEP 3 applied hello-padding disable to all three LAN routers so the two states could be compared.

router isis 1
 interface GigabitEthernet0/0/0/0
  hello-padding disable

IOS XR offers four choices for hello-padding:

RP/0/RP0/CPU0:R1(config-isis-if)#hello-padding ?
  adaptive   Enable hello-padding till neighbor confirms adjacency up
  always     Always enable hello-padding
  disable    Disable hello-padding
  sometimes  Enable hello-padding during adjacency formation only

Before the change, an IIH was 1514 bytes on the wire (PDU length 1497).

Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
    PDU length: 1497
    Padding (t=8, l=255)
        Type: 8
        Length: 255

That packet held six Padding (t=8) TLVs: five with l=255 and one with l=149. Adding two bytes of TLV header each gives (255+2)x5 + (149+2) = 1436 bytes.

Afterwards the same IIH shrinks to 78 bytes.

Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)
ISIS HELLO
    .... ..01 = Circuit type: Level 1 only (0x1)
    SystemID {Sender of PDU}: 0010.0100.1001
    Holding timer: 30
    PDU length: 61
    .100 0000 = Priority: 64
    SystemID {Designated IS}: 0030.0300.3003.01
    Protocols Supported (t=129, l=1)
    Restart Signaling (t=211, l=3)
    Area address(es) (t=1, l=4)
    IP Interface address(es) (t=132, l=4)
    IS Neighbor(s) (t=6, l=12)

The PDU length went from 1497 bytes to 61. The 1436-byte difference is exactly the amount of padding counted above. Only Padding (t=8) disappeared; the remaining TLVs are unchanged.

Counting IIH frame lengths across the whole capture shows the two states separating cleanly.

The Level 1 IIH is six bytes longer because TLV 6 (IS Neighbours) carries the MAC addresses of the neighbours on the LAN. This test had two Level 1 adjacencies and one Level 2 adjacency, and the extra entry accounts for exactly those six bytes.

All three routers were changed at once, so as described above no adjacency dropped. Turning padding off does save bandwidth (1514 bytes from each of three routers becomes 72 to 78), but the trade-off is that an adjacency will now form even when the two ends disagree on the MTU. That leads to the hard-to-find failure where IIHs get through but LSPs do not, so disabling it on only one side is best avoided.

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 4 one).

The final configuration leaves point-to-point off Gi0/0/0/0 on the three LAN routers (R1, R2, R3) and applies it only to the R3–R4 pair. The hello-padding disable lines were removed again in STEP 4.

STEP 0: initial state

STEP 1: process restart isis on all four routers at once

STEP 2: process restart isis on R1 only

STEP 3: apply hello-padding disable to the three LAN routers

STEP 4: put hello-padding back (final state)

There are four capture files.

Download the LAN segment capture (isis-packet-lan.pcap)

Download the R3-R4 link capture (isis-packet-p2p.pcap)

Download the capture from restarting R1 only, STEP 2 (isis-packet-lan-resync.pcap)

Download the capture from disabling padding, STEP 3 (isis-packet-padding.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)