IS-IS Link-State Packets

Level 1 and Level 2 LSPs are similar in format even though each type of packet carries information for different levels of the IS-IS routing hierarchy. This section reviews the generic LSP packet format and identifies differences between Level 1 and Level 2 LSPs. It also looks at the TLVs associated with each type of LSP.

Link-State Packet Format

As noted in Chapter 3, all IS-IS packets have a header to which TLV fields are appended (refer to Figure 3-2). A complete layout of the LSP format, including the header and the TLV sections, is shown in Figure 5-4.

Figure 5-4. LSP format.

The PDU types for Level 1 and Level 2 LSPs are numbered 18 and 20, respectively. The interpretation of the header fields from the top of the packet up to and including the PDU Length field is the same for all IS-IS packets. The header fields following the PDU Length field are specific to the LSP format and have the following meanings:

• Remaining Lifetime ” Remaining time for the LSP to expire.

• LSP Identifier (LSP ID) ” Associates an LSP with its source for identification.

• Sequence Number ” The sequence number of the LSP.

• Checksum ” Checksum of the LSP calculated over fields starting from the LSP ID field to the end.

• Partition ” Bit 8. Set if source of LSP supports partition repair.

• Attached ” Bits 4 “7. Set to indicate attachment to another area with applicable metrics as follows : bit 4 “ default, bit 5 “ delay, bit 6 “ expense, bit 7 “ error.

• Overload ” Bit 3. Set to indicate that the Link-State database of the source is overloaded and that processing and memory resources are limited.

• IS Type ” Bits 1 and 2. Indicates the type of router; Level 1 (only bit 1 set) or Level 2 (both bits 1 and 2 set). Other combinations are not defined.

Various types of TLV fields can be included in LSPs to propagate different kinds of routing information. Each TLV follows a generic format, which includes fields for the type of TLV, the length of the specific TLV, and the value or contents of the TLV. The section in this chapter titled "Link-State Packet TLVs" provides in-depth coverage of the type of TLVs that might be contained in LSPs.

The LSPs in the Link-State database of a Cisco router can be viewed with the command show isis database (see Example 5-1). This command displays two separate Link-State databases: Level 1 and Level 2. A variation of the command can be entered to display only one database by using the Level-1 or Level-2 command options.

Example 5-1 Output of show isis database Command

 RTB#  sh isis database  IS-IS Level-1 Link State Database LSPID                 LSP Seq Num   LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0005.00-00  0x000007EF    0xDD14       667          0/0/0 0000.0000.0006.00-00  0x000007E7    0x2ECA       1126         0/0/0 0000.0000.0007.00-00* 0x000007FB    0x6FCB       960          1/0/0 0000.0000.0007.01-00* 0x000007E3    0xA91D       782          0/0/0 IS-IS Level-2 Link State Database LSPID                 LSP Seq Num   LSP Checksum LSP Holdtime ATT/P/OL 0000.0000.0001.00-00  0x000007EB    0x27F        858          0/0/0 0000.0000.0007.00-00* 0x000007EF    0x1637       851          0/0/0 0000.0000.0007.01-00* 0x000007CB    0x2C5F       630          0/0/0 

Each database contains LSPs for a specific routing level. In Example 5-1, the following information is provided for each LSP: LSP ID, LSP sequence number, LSP checksum, LSP holdtime, remaining lifetime (LSP holdtime), status of attachment (ATT), overload status (OL), and partition support (P).

Depending on the setup of a router, the system ID component in the LSP IDs can be resolved into the corresponding host names of the source routers (see Example 5-2). As you can see, all these elements that describe the LSP in the show isis database output are excerpts from the LSP header. The following sections discuss them further.

LSP Remaining Lifetime

The Remaining Lifetime field in an LSP features a timer that tracks the age of an LSP. The ultimate goal for tracking the age of an LSP is to purge the Link-State database of stale information. The two important threshold values associated with the remaining lifetime are LSP maxage and LSP refresh interval.

LSP maxage is the upper bound of the remaining lifetime of an LSP and specifies the maximum life span of an LSP. ISO 10589 specifies a value of 20 minutes (1200 seconds). Recent changes in Cisco IOS Software allow larger values of the LSP lifetime to be configured (up to 653,350 seconds) using the lsp-max-lifetime command. When an LSP is created at the originating router, the Remaining Lifetime field is set to the value of LSP maxage and flooded throughout the area through adjacent neighbors. The remaining lifetime of an LSP decreases with time. When an LSP ages up to the refresh interval (that is, the remaining lifetime has decreased by the refresh interval), it is regenerated by the source. Otherwise, the LSP would continue to age until the remaining lifetime reaches zero value; at which point, it would be purged out of the network.

The refresh interval is the periodic interval at which LSPs are regenerated or refreshed by the originating routers even if no network changes necessitate that. When the LSP is regenerated, the remaining lifetime is reset to maxage and reflooded into the network. At the refresh time, the value of the Remaining Lifetime is the difference between maxage and the refresh interval. ISO 10589 specifies an LSP refresh interval of 15 minutes, which is 900 seconds. Recent Cisco IOS releases allow higher values of the refresh intervals to be configured using the command lsp-refresh-interval . Up to 635,530 seconds of refresh time can be configured in place of the 900-second default. If a router does not refresh its LSP after the refresh interval and the LSP ages on to zero remaining lifetime, all routers that have a copy of this LSP eventually purge it from their databases after a grace period of60 seconds. The grace period, which is referred to as ZeroAgeLifetime is not a configurable parameter in Cisco IOS Software.

Increasing the refresh interval reduces the frequency of periodic refreshing of LSPs. This in turn , reduces the toll on network resources, such as bandwidth and processing costs. Larger refresh intervals than the default are recommended only in stable network environments. If there is a need to adjust the LSP refresh interval, the LSP maxage also must be adjusted accordingly , with maxage being a little higher than the refresh interval.

Link-State Packet Identifier

The Link-State Packet Identifier (LSP ID), as the name implies, is used to distinguish LSPs from each other and to identify the originating routers. The LSP ID consists of the following three components :

• System Identifier (SysID)

• Pseudonode Identifier (PSN ID)

• LSP number

Figure 5-5 shows the LSP structure. The size of the SysID is 6 bytes, with a 1-byte Pseudonode ID and a 1-byte LSP number appended.

Figure 5-5. Structure of the LSP ID.

The SysID component of the LSP ID refers to the originating router. The non-zero Pseudonode ID identifies special LSPs that are referred to as pseudonode LSPs . A pseudonode LSP is associated with a multiaccess link, and it is generated by the designated intermediate system on that link. A router's regular LSP has a Pseudonode ID value of zero. The LSP number refers to fragments of an LSP (regular or pseudonode). The first fragment of an LSP is number zero. When any fragment of a large LSP is lost in transmission, the receiver drops all the other fragments and the whole set must be retransmitted, wasting precious bandwidth.

In contrast to the Open Shortest Path First (OSPF) Protocol, IS-IS does not use many types of LSPs to distribute routing information. All routing information, as for Level 1 routing, is bundled into a single LSP, which can be fragmented as necessary. Because fragmentationon-the-fly has undesirable consequences on processing resources of routers, however, IS-IS mitigates the negative consequences by constraining the maximum size of an LSP unit and proactively fragmenting a large LSP into smaller units, which are independently flooded through the network. The maximum size of an LSP is 1492 bytes. The IS-IS specification, ISO 10589, requires hellos to be padded to the maximum LSP buffer size or the MTU of the outgoing interfaces (MTU usually used), meaning both sides of an adjacency must normally have the same MTU to form an adjacency . Figure 5-6 shows examples of LSP IDs. The third example shows the LSP ID of an LSP fragment.

Figure 5-6. Figure 5-6 LSP ID examples.

As indicated previously, the numeric SysID in the LSP ID (refer to Example 5-1) is replaced by the host name of the originating router if static host names are in place or dynamic name resolution is in effect. Example 5-2 shows a show isis database output in which the LSP IDs feature the host names of the corresponding source routers.

Example 5-2 Name-Based System IDs

 RTB#  show isis database  IS-IS Level-1 Link State Database: LSPID                 LSP Seq Num   LSP Checksum LSP Holdtime ATT/P/OL  RTA.00-00  0x00000065     0x1EDF       989          0/0/0  RTA.01-00  0x0000005A     0x370E       744          0/0/0  RTB.00-00  *0x00000067     0x8475       1128         1/0/0 IS-IS Level-2 Link State Database: LSPID                 LSP Seq Num   LSP Checksum LSP Holdtime ATT/P/OL  RTB.00-00  *0x00000070     0x6289       1176         0/0/0  RTC.00-00  0x00000063     0x657A       965          0/0/0  RTC.02-00  0x0000005D     0xB1BE       1088         0/0/0 

This show isis database output contains two LSPs from RTA in the Level 1 database, represented by RTA.00-00 and RTA.01-00, respectively. Even though generated by the same router, each LSP has a different pseudonode number in its LSP ID. RTA.00-00, which has a zero pseudonode number and is RTA's own regular LSP. RTA.01-00 has a non-zero Pseudonode ID, and therefore represents a pseudonode LSP generated for a LAN on which RTA is the DIS. The pseudonode LSP lists all known routers connected to the LAN, whereas a router's own LSP carries information such as adjacent neighbors on all interfaces, IP prefix information, and so on.

Link-State Packet Sequence Number

In the LSP header, 4 bytes are dedicated to the Sequence Number field for numbering LSPs by the update process. The LSP sequence number is specified as a 32-bit unsigned integer and increases in 1 increments from 0 to an upper threshold of 1 less than the number 2 to the power of 32 (2^32 “ 1). The value 2^32 is referred to as SequenceModulus . The first LSP generated by a router, when it first connects to a network, has a sequence number of 1. The sequence number is increased by 1 whenever a newer version of the LSP is generated as a result of changes in a router's environment. The sequence number plays a key role in the database synchronization process by helping routers in the same area identify older LSPs from newer versions. Also, when a router crashes and reconnects to the network, it generates a new LSP with a sequence number of 1. If the router's older LSP at the time of crash has a higher sequence number and hasn't been purged from the network, however, one of the other routers in the same area sends a copy of the older LSP to the recovered router. The router then adjusts its sequence number to be close to the value before it crashed, by generating yet another LSP with current information but with a sequence number that is larger than that of the older LSP by 1.

The size of the Sequence Number field (4 bytes) allows a router to generate new LSPs with incrementing sequence numbers for a long time without running over. The following calculation elaborates on the reasoning behind this claim. First, consider the maximum possible sequence number, account for inherent protocol delays in regenerating LSPs, and then convert the time it takes to attain the maximum sequence number into years .

Step 1. The total number of possible sequence number adjustments, counting from 1, is 2^32 “ 1 = 4,294,967,295.

Step 2. Using the specified minimum LSP regeneration interval of 30 seconds, the time required to deplete the sequence number space is (4,294,967,295 x 30) seconds.

Step 3. The resulting value from Step 2 is converted into years, as follows:

(4,294,967,295 x 30 seconds)/(60 seconds x 60 minutes x 24 hours x 365 days) = 4085.77 years

Even accounting for leap years, it will take more than 4000 years for a router that is continuously generating its LSP (unrealistically) to overrun the Sequence Number field.

Still wondering what might happen if by some magic a router's LSP sequence number were to reach the maximum possible sequence number? Well, ISO 10589 instructs that an event referred to as AttemptToExceedMaximumSequenceNumber should be logged and the IS-IS process disabled for the period of maxage + ZeroAgeLifetime to allow the most recent LSP to expire and be purged from the network. The router can then be restarted, enabling it to kick off with a new LSP with a sequence number value of 1.

Link-State Packet Checksum

To guarantee the integrity of the information in an LSP, the originating router computes a checksum on the LSP and enters it into the LSP Checksum field. The checksum value is verified by any router that receives a copy of the LSP. The Checksum field is the third column in the output of the show isis database command (refer to Example 5-2). The LSP checksum is calculated over fields starting after the Remaining Lifetime field up to the end of the LSP. The checksum is unmodified as copies of the LSP are propagated through the network from one router to the other. It makes sense to exclude the Remaining Lifetime field because it contains a continuously changing timer value. The checksum helps detect corrupted LSPs or stale LSP duplicates that have not yet been purged from the network.

When a router receives what looks like a copy of its LSP but with corrupted information, it tries to purge it from the network by flooding a newer LSP with current link-state information and a higher sequence number than that of the corrupted LSPs. All other routers in the area then receive and install the newer LSP, thus purging the older LSP from their databases. In general, any router that detects a corrupted LSP initiates a purge by flooding a copy with the remaining lifetime reset to 0. This action effectively causes other routers in the area also to purge the LSP. Corrupted LSPs are not used in routing calculations or reflooded as is. If the originator is still connected to the area, it originates and refloods a valid copy of the LSP.

If an LSP is continuously being corrupted in transmission, purged from thenetwork by other routers, and then reissued by the source, this results in a situation described as an LSP corruption storm . This phenomenon is covered in detail later in this chapter in the section "IS-IS Link-State Database Integrity Issues." An LSP corruption storm is a resource- intensive activity that can potentially result in more complicated network problems and even a network meltdown if pervasive.

Cisco IOS Software allows routers to be configured to ignore corrupted LSPs and to log errors only locally. The router-level IOS command lsp-ignore-errors can be used to enable this capability.

Other LSP Header Information: Partition, Attached, Overload, and IS Type Fields

This section looks at the bit fields in the last byte of the LSP header. These fields include the 1-bit Partition field, the 4-bit Attached field, the 1-bit Overload field, and the 2-bitIS Type field.

Partition ” The original IS-IS specification, ISO 10589, describes how to repair a partitioned Level 1 area by creating an alternate Level 1 path through the Level 2 backbone. This arrangement takes advantage of the existence of connections from each of the Level 1 partitions to the backbone and the latter's contiguity to establish a repair path by reconnecting the partitions over the backbone. This works by electing a Level 2-capable router in each partition as the partition-designated Level 2 IS and establishing a special adjacency, known as virtual adjacency or virtual link between them.

The virtual link provides the Level 1 repair path through the backbone. The partition-designated routers advertise the virtual adjacencies by setting the partition bit in their Level 1 LSPs, thus signaling the existence of the virtual link to Level 1 routers for forwarding data between the partitions. Figure 5-7 illustrates area partition repair. Details regarding detection of an area partition, election of partition-designated routers, and establishment of virtual links are beyond the scope of this book. (For more complete coverage, refer to ISO 10589.) Partition repair is an optional capability in IS-IS and is currently not supported in Cisco IOS Software. Cisco routers enabled for IS-IS routing, therefore, always set the partition bit in their LSPs to zero and also ignore the partition bit if it is set in any received LSPs. Consequently, the partition bit has no relevance to the operation of Integrated IS-IS on Cisco routers.

Figure 5-7. Area partition repair.

Attached ” The 4-bit Attached field is set by Level 2 routers in their Level 1 LSPs to indicate to same-area Level 1 routers that they are connected in other areas. Connectivity to another area in the domain essentially implies attachment to the backbone. IS-IS areas, as specified in ISO 10589, are stubs, and Level 1 routers forward packets to other areas in the domain through the closest Level 2 router. Level 2 routers in an area advertise themselves to the Level 1 routers by setting the attach bits in their Level 1 LSPs. Even though the attached bits are specified in both Level 1 and Level 2 LSPs, they are relevant only in the Level 1 routing framework. The 4 bits also allow an IS-IS router to indicate which of the 4 metric types are supported for attaching to the backbone. Each bit is dedicated to a specific type of metric (see Table 5-1). The four types of metrics supported by the IS-IS protocol (default, delay, expense, and error) is discussed in detail in Chapter 3. These metrics are designed for quality-of-service application. Only the default metric is supported in Cisco IOS Software.

Table 5-1. Attached Bits Field Settings

Bit position in Octet	Attached Field Bits	Metric Type
4 (00001000)	0001	Default
5 (00010000)	0010	Delay
6 (00100000)	0100	Expense
7 (01000000)	1000	Error

Overload ” Bit 3 in the last byte of the LSP header signals the resource availability stateof a router. If this bit is set, it indicates an overload condition at the router. An overload condition indicates the router's performance is inhibited by low memory and processing resources. LSPs with the overload bit set are not reflooded and also are not used in calculating paths through the overloaded router. This means that the overloaded router is circumvented for transit traffic; however, paths in which the overloaded router is the last hop are calculated. The Cisco IOS command set-overload-bit allows manual setting of the overload bit. The overload bit can be leveraged to deliberately prevent transit traffic from flowing through a specific router. This is discussed further in Chapter 7.

IS Type ” The IS Type bits in the LSP indicate whether the LSP is from a Level 1 or Level 2 router. This essentially indicates the target Link-State database for storing the LSP. The possible bit settings for the IS Type field are shown in Table 5-2.

Table 5-2. IS Type Field Settings

Bits Values	Bits in Octet	IS Type
00	00000000	Unused
01	00000001	Level-1
10	00000010	Unused
11	00000011	Level-2

Example 5-3 is a decode of an LSP from a packet analyzer showing the fields in the LSP header section. All the LSP-specific header fields discussed earlier are featured, presenting an interesting view of the structure and format of the LSP header.

Example 5-3 LSP Header Decode

 IS-IS: Protocol ID = 83 (Intermediate System Routing Exchange Protocol) IS-IS: Header length = 27 IS-IS: Version / Protocol ID Extension = 1 IS-IS: ID Length = 0, Indicate 6 Octets IS-IS: PDU type = 18  (Link State, Level 1) IS-IS: Version = 1 IS-IS: Reserved = 0 IS-IS: Maximum Area Addresses = 0 IS-IS: Frame length is 100 byte(s) IS-IS: Remaining life is 1199 second(s) IS-IS: Link State Frame ID: IS-IS:   Source ID      = 000000000001 IS-IS:   Pseudo-node    =     (Not a pseudo-node) IS-IS:   Link frame no. = 0 IS-IS: Frame Sequence = 6203 IS-IS: Checksum = E6CF IS-IS: Attributes = 0B IS-IS: O...  .... = Partition repair not supported IS-IS: .0..  .... = Not attached using error metric IS-IS: ..0.  .... = Not attached using expense metric IS-IS: ...0  .... = Not attached using delay metric IS-IS: ....1  ... = Attached using default metric IS-IS: .... .0..  = No LSP Database Overload IS-IS: .... ..11    = Level 2 intermediate system