CCNP BSCI Exam: Introduction to the Intermediate System-to-Intermediate System (IS-IS) Protocol

This chapter is from the book

CCNP Self-Study: Building Scalable Cisco Internetworks (BSCI)

Learn More Buy

This chapter is from the book

This chapter is from the book 

CCNP Self-Study: Building Scalable Cisco Internetworks (BSCI)

Learn More Buy

Operation of IS-IS for CLNS/CLNP

This section describes the operation of IS-IS. As mentioned earlier, IS-IS is used for routing CLNS/CLNP data, while Integrated IS-IS is used for routing IP. Integrated IS-IS is described in the next section.

OSI Addressing

OSI network layer addressing is done through NSAP addresses that identify any system in the OSI network. These OSI addresses are often simply referred as NSAPs.

The LSPs, hello PDUs, and other routing PDUs are OSI-format PDUs; therefore, every IS-IS router requires an OSI address even if it is routing only IP. IS-IS uses the OSI address in the LSPs to identify the router, build the topology table, and build the underlying IS-IS routing tree.

The NSAPs contain the following:

• The OSI address of the device

• The link to the higher-layer process

  NOTE

  The NSAP address can be thought of as the equivalent of a combination of IP address and upper-layer protocol in an IP header.

  Dijkstra's algorithm, which is used for both IS-IS and OSPF, requires a point-to-point connection between devices. OSPF uses the router ID to represent each router for this connection, while IS-IS uses the NET (a subset of the NSAP discussed in the following section).

NSAP Address Structure

Cisco routers can route CLNS data that uses addressing conforming to the ISO 10589 standard. The NSAP structure is illustrated in Figure 5-6.

Figure 5-6 Structure of NSAP Addresses

An OSI NSAP address can be up to 20 octets long and consists of the following parts, as shown in Figure 5-6:

• The authority and format ID (AFI) specifies the format of the address and the authority that assigned that address. The AFI is 1 byte.

• The interdomain ID (IDI) identifies this domain. The IDI can be up to 10 bytes.

• The AFI and IDI together make up the interdomain part (IDP) of the NSAP address. This can loosely be equated to an IP classful major network.

• The high-order domain-specific part (DSP) (HODSP) is used for subdividing the domain into areas. This can be considered loosely as the OSI equivalent of a subnet in IP.

• The system ID identifies an individual OSI device (an ES or an IS). In OSI, a device has an address, just as it does in the DECnet protocol. This is different from IP, in which an interface has an address. OSI does not specify a fixed length for the system ID, but it does specify that it be consistent for all devices. Cisco IOS Software fixes the system ID as the 6 bytes preceding the 1-byte NSAP selector (NSEL).

  NOTE

  A Media Access Control (MAC) address is often used for the system ID.

• The NSEL (also known as the N-selector, the service identifier or the process ID) identifies a process on the device. It is a loose equivalent of a port or socket in IP. The NSEL is 1 byte long. It is not used in routing decisions. When the NSEL is set to 00, the address identifies the device itself—its network level address. In this case, the NSAP is known as a network entity title (NET).

• The HODSP, system ID, and NSEL together make up the domain-specific part (DSP) of the NSAP address.

IS-IS Versus ISO-IGRP NSAPs

IS-IS and ISO-IGRP interpret NSAPs differently, as shown in Figure 5-7.

Figure 5-7 How IS-IS and ISO-IGRP Interpret NSAP Addresses

IS-IS uses a two-layer architecture, joining the IDP and HODSP fields and treating them as its area address (Level 2), with the remaining system ID used for Level 1 routing. When used with IS-IS, therefore, the NSAP is divided into three parts, as shown in Figure 5-7: 1 octet for NSEL, 6 octets for the system ID, and from 1 to 13 octets for the area address or area ID field. An NSAP has a variable length of 8 to 20 octets. It is usually longer than 8 bytes to permit some granularity in the allocation of areas.

ISO-IGRP routes are based on a three-level architecture: domain (using the AFI and IDI fields for Level 3), area (using the HODSP field for Level 2), and system ID (for Level 1). What IS-IS treats simply as the area ID, ISO-IGRP splits into a domain and an area. ISO-IGRP sets the 2 bytes to the left of the system ID as the area ID or area address field, allowing for a theoretical 65,535 areas in an ISO-IGRP network. Everything else (a maximum of 11 bytes) is treated as a domain ID. Therefore, the minimum length for an ISO-IGRP NSAP is 10 bytes (1-byte NSEL, 6-byte system ID, 2-byte area, and minimum 1-byte domain).

ISO-IGRP sends routing information based on domain (variable length), area (length fixed by the protocol at 2 bytes), and finally system ID (fixed at 6 bytes). The NSEL is not used by ISO-IGRP.

Network Entity Title

As discussed earlier, if the NSEL field is 00, the NSAP refers to the device itself—that is, it is the equivalent of the Layer 3 OSI address of that device.

This address with the NSEL set to 00 is known as the NET. The NET is used by routers to identify themselves in the LSPs. Therefore, it forms the basis for the OSI routing calculation.

NETs and NSAPs are specified in all hexadecimal digits and must start and end on a byte boundary.

Official NSAP prefixes are required for CLNS routing. Addresses starting with the value of 49 (AFI = 49) are considered to be private addresses (analogous to RFC 1918 for IP addresses). These addresses are routed by IS-IS; however, this group of addresses should not be advertised to other CLNS networks.

Addresses starting with AFI values 39 and 47 represent the ISO data country code and ISO international code designator, respectively.

As shown in Figure 5-7 and the examples in the next section, the Cisco IOS Software IS-IS routing process interprets the NSAP address as follows (from the right, or least-significant digit, end):

• The last byte is the NSEL field and must be specified as a single byte, with two hex digits, preceded by a period (.). In a NET, this N-selector field is set to (00).

• The preceding 6 bytes (this length is fixed by Cisco IOS Software) are the system ID. It is customary to use either a MAC address from the router or (for Integrated IS-IS) an IP address (for example, the IP address of a loopback interface) as part of the system ID.

• The IS-IS routing process of Cisco IOS Software treats the rest of the address as the area ID, or area address, as follows:

  • It is 1 to 13 bytes long.

  • Using a 1-byte field for area limits the scope for area definitions. Thus, the customary area ID consists of 3 bytes, with an AFI of 1 byte and 2 additional bytes for the area ID. For example, in the address 49.0001.0000.0c12.3456.00, the AFI is 49 and the additional 2 bytes are 0001, for an effective area ID of 49.0001.

  • Cisco IOS Software attempts to summarize the area ID as much as possible. For example, if an IS-IS network is organized with major areas subdivided into minor areas, and this is reflected in the area ID assignments, then:

    Between the minor areas, Cisco IOS Software will route based on the whole area ID.

    Between the major areas, Cisco IOS Software will summarize the area ID portion up to the major area boundary.

NSAP Examples

The following examples illustrate how an NSAP address is interpreted by IS-IS and ISO-IGRP.

The NSAP 49.0001.aaaa.bbbb.cccc.00 consists of the following:

• For IS-IS:

  • Area = 49.0001

  • System ID = aaaa.bbbb.cccc

  • N-selector = 00

• For ISO-IGRP:

  • Domain = 49

  • Area = 0001

  • System ID = aaaa.bbbb.cccc

  • N-selector = ignored by ISO-IGRP

The NSAP 39.0f01.0002.0000.0c00.1111.00 consists of the following:

• For IS-IS:

  • Area = 39.0f01.0002

  • System ID = 0000.0c00.1111

  • N-selector = 00

• For ISO-IGRP:

  • Domain = 39.0f01

  • Area = 0002

  • System ID = 0000.0c00.1111

  • N-selector = ignored by ISO-IGRP

Identifying Systems in IS-IS

In IS-IS, the area ID is associated with the IS-IS routing process; a router can be a member of only one Level 2 area. Recall from earlier in the chapter that a router can belong to only one area. The area ID or area address uniquely identifies the routing area, and the system ID identifies each node.

Restrictions on Areas and System IDs

Restrictions on areas and system IDs are as follows:

• All routers in an area must use the same area address. Indeed, the shared area address actually defines the area.

• An ES might be adjacent to a Level 1 router only if they both share a common area address. In other words, ESs recognize only ISs (and ESs on the same subnetwork) that share the same area address.

• Area routing (Level 1) is based on system IDs. Therefore, each device (ES and IS) must have a unique system ID within the area, and all system IDs must be the same length. Cisco mandates a 6-byte system ID.

• All Level 2 ISs come to know about all other ISs in the Level 2 backbone. Therefore, they, too, must have unique system IDs within the area.

System IDs

The system ID must be unique inside an area. As noted earlier, it is customary to use either a MAC address from the router or (particularly for Integrated IS-IS) to code the IP address (for example, of a loopback interface) into the system ID.

It is generally recommended that the system IDs remain unique across the domain; that, way there can never be a conflict at Level 1 or Level 2 if a device is moved into a different area, for example.

All the system IDs in a domain must be of equal length. This is an OSI directive; Cisco enforces this by fixing the length of the system ID at 6 bytes in all cases.

Example of NET Addresses in IS-IS Network

Figure 5-8 shows examples of the NETs for routers in an IS-IS domain. Observe the following in Figure 5-8:

• The 6-byte system IDs are unique across the network.

• The 3-byte area IDs are common to areas and distinct between areas.

• The 1-byte N-selectors are set to 00, indicating that these are NETs.

Figure 5-8 NSAP Addresses in an IS-IS Network

IS-IS PDUs

The OSI stack defines a unit of data as a protocol data unit (PDU). A frame therefore is regarded by OSI as a data-link PDU, and a packet (or datagram, in the IP world) is regarded as a network PDU.

Three types of PDUs (with 802.2 Logical Link Control encapsulation) are shown in Figure 5-9. As the figure shows, the IS-IS and ES-IS PDUs are encapsulated directly in a data-link PDU (there is no CLNP header and no IP header), while true CLNP (data) packets contain a full CLNP header between the data-link header and any higher-layer CLNS information.

Figure 5-9 OSI Protocol Data Units

IS-IS and ES-IS PDUs contain multiple sets of variable-length fields, depending on the function of the PDU. Each field contains a type code, a length, and then the appropriate values—hence the abbreviation TLV, for Type, Length, Value fields—as shown in Figure 5-9.

Four general types of packets exist, and each type can be Level 1 or Level 2:

• LSP—Used to distribute link-state information

• Hello PDU (ESH, ISH, IS-IS Hello [IIH])—Used to establish and maintain adjacencies

• Partial sequence number PDU (PSNP)—Used to acknowledge and request link-state information

• Complete sequence number PDU (CSNP)—Used to distribute a router's complete link-state database

LSPs and hello PDUs are detailed in the following sections; the use of PSNP and CSNP is described in the section, "Link-State Database Synchronization."

Link State Packets

This section describes the IS-IS LSPs.

Network Representation

In OSI, there are two main types of physical links:

• Broadcast—Multiaccess media types that support addresses referring to groups of attached systems and are typically LANs.

• Nonbroadcast—Media types that must address ESs individually and that are typically WAN links. These include point-to-point links, multipoint links, and dynamically established links.

Consequently, IS-IS supports only two media representations for its link states:

• Broadcast for LANs

• Point-to-point for all other media

  NOTE

  IS-IS has no concept of an NBMA network. It is recommended that point-to-point links (for example, subinterfaces) be used instead of NBMA networks such as native ATM, Frame Relay, or X.25.

LSP Contents

In IS-IS, a router describes itself with an LSP. The router's LSP contains the following:

• An LSP header, describing these items:

  • The PDU type and length

  • The LSP ID and sequence number

  • The remaining lifetime for this LSP (used to age out LSPs)

• Type Length Value (TLV) variable-length fields:

  • The router's neighbor ISs (used to build the map of the network)

  • The router's neighbor ESs

  • Authentication information (used to secure routing updates)

  • Attached IP subnets (optional for Integrated IS-IS)

The LSP sequence numbers enable receiving routers to ensure that they use only the latest LSPs in their route calculations, thus avoiding duplicate LSPs being entered in the topology tables.

When a router reloads, the sequence number is set initially to 1. The router might then receive its own old LSPs back from its neighbors (which has the last good sequence number before the router reloaded). It records this number and reissues its own LSPs with the next-highest sequence number.

The Remaining Lifetime field in the LSP is used by the LSP aging process to ensure that outdated and invalid LSPs are removed from the topology table after a suitable period. The LSP remaining lifetime counts down from 1200 seconds (20 minutes) to 0.

LAN Representation

Dijkstra's algorithm, used for IS-IS, requires a virtual router (pseudonode) for broadcast media to build a weighted directed graph of the shortest paths from a single source vertex to all other vertices.

For this reason, the DIS is elected to generate an LSP representing a virtual router connecting all attached routers to a star-shape topology. The DIS is shown in Figure 5-10. The decision process for the election of the DIS is based first on the router with the highest configured priority and second on the router with the highest MAC address.

Figure 5-10 IS-IS Designated Intermediate System Is Elected to Represent the LAN

In IS-IS, all routers on the LAN establish adjacencies with all other routers and with the DIS. Thus, if the DIS fails, another router can take over immediately with little or no impact on the topology of the network.

This is different from OSPF behavior. In OSPF, once the designated router (DR) and a backup DR (BDR) are elected, the other routers on the LAN establish adjacencies only with the DR and the BDR (the BDR is elected and in the case of DR failure, is then promoted to be the DR).

LSP Variables

IS-IS LSPs include specific information about the router's attachments. This information is included in multiple TLV fields in the main body of the LSP:

• The links to neighbor routers (ISs), including the metrics of those interfaces

• The links to neighbor ESs

  NOTE

  If Integrated IS-IS is operational, the attached IP subnets are described as ESs, using a special TLV specified for IP information.

The metrics of IS-IS links are associated with the outgoing interface toward the neighbor IS (router). Up to four metrics can be specified, as follows:

• Default metric (required): cost—No automatic calculation of the metric for IS-IS takes place, compared to some routing protocols that calculate the link metric automatically based on bandwidth (OSPF) or bandwidth/delay (EIGRP). Using narrow metrics (the default), an interface cost is between 1 and 63 (a 6-bit metric value). All links use the metric of 10 by default. The total cost to a destination is the sum of the costs on all outgoing interfaces along a particular path from the source to the destination, and the least-cost paths are preferred.

• Delay, expense, and error (optional)—These metrics are intended for use in type of service (ToS) routing. These could be used to calculate alternative routes referring to the DTR (delay, throughput, and reliability) bits in the IP ToS field.

  Extended Metric

  In IS-IS, using the old-style narrow cost metric discussed previously, the total path metric is limited to 1023 (the sum of all link metrics along a path between the calculating router and any other node or prefix). This small metric value proved insufficient for large networks and provided too little granularity for new features such as traffic engineering and other applications, especially with high-bandwidth links.

  Cisco IOS Software addresses this issue with the support of a 24-bit metric field, the so-called wide metric. Using the new metric style, link metrics now have a maximum value of 16,777,215 (2²⁴–1) with a total path metric of 4,294,967,295 (2³²–1).

  Running different metric styles within one network poses a serious problem: Link-state protocols calculate loop-free routes because all routers (within one area) calculate their routing tables based on the same link-state database. This principle is violated if some routers look at old-style (narrow) and some at new-style (wider) TLVs. However, if the same interface cost is used for both the old- and new-style metrics, the SPF computes a loop-free topology.

Hello Messages

IS-IS uses hello PDUs to establish adjacencies with other routers (ISs) and ESs. Hello PDUs carry information about the system, its parameters and capabilities.

IS-IS has three types of hello PDUs, as follows:

• ESH, sent by an ES to an IS

• ISH, sent by an IS to an ES

• IIH, used between two ISs

The three types of hello PDUs are shown in Figure 5-11.

Figure 5-11 Three Types of IS-IS Hello PDUs

IS-IS Communication

ISs use IIHs to establish and maintain their neighbor relationships. When an adjacency is established, the ISs exchange link-state information using LSPs.

ISs also send out ISHs. ESs listen for these ISHs and randomly pick an IS (the one that sent the first ISH they hear) to forward all their packets to. Hence, OSI ESs require no configuration to forward packets to the rest of the network.

ISs (routers) listen to the ESHs and learn about all the ESs on a segment. ISs include this information in their LSPs.

For particular destinations, ISs might send redirect (RD) messages to ESs to provide them with an optimal route off the segment. This process is similar to IP Redirect.

Adjacencies

Separate adjacencies are established for Level 1 and Level 2. If two neighboring routers in the same area run both Level 1 and Level 2, they establish two adjacencies, one for each level. The Level 1 and Level 2 adjacencies are stored in separate Level 1 and Level 2 adjacency tables.

On LANs, the two adjacencies are established with specific Layer 1 and Layer 2 IIH PDUs. Routers on a LAN establish adjacencies with all other routers on the LAN and send LSPs to all routers on the LAN (unlike OSPF, in which routers establish adjacencies only with the designated router).

On point-to-point links, there is a common IIH format, part of which specifies whether the hello relates to Level 1, Level 2, or both.

By default, hello PDUs are sent every 10 seconds; the timeout to declare a neighbor down (that is, missing three hello packets) is 30 seconds. These timers are adjustable. (The commands to adjust the timers are not discussed in this book.)

LAN Adjacencies

IIH PDUs announce the area ID. Separate IIH packets announce the Level 1 and Level 2 neighbors. Adjacencies are established based on the area address announced in the incoming IIHs and the type of the router.

For example, in Figure 5-12, routers from two different areas are connected to the same LAN. On this LAN, the following is true:

• The routers from one area accept Level 1 IIH PDUs only from their own area and, therefore, establish adjacencies only with their own area routers.

• The routers from a second area similarly accept Level 1 IIH PDUs only from their own area.

• The Level 2 routers (or the Level 2 process within any Level 1–2 router) accept only Level 2 IIH PDUs and establish only Level 2 adjacencies.

Figure 5-12 IS-IS Adjacencies Are Based on Area Address and Type of Router

WAN Adjacencies

On point-to-point links (that is, on a WAN), the IIH PDUs are common to both Level 1 and Level 2 but announce the level type and the area ID in the hellos. This is illustrated in Figure 5-13.

Figure 5-13 On a WAN, Area Address and Router Type Are Announced in a Common IIH PDU

As shown in Figure 5-13, the following is true:

• Level 1 routers in the same area (which includes links between Level 1–only and Level 1–2 routers) exchange IIH PDUs specifying Level 1 and establish a Level 1 adjacency.

• Level 2 routers (in the same area or between areas, and including links between Level 2–only and Level 1–2 routers) exchange IIH PDUs specifying Level 2 and establish a Level 2 adjacency.

• Two Level 1–2 routers in the same area establish both Level 1 and Level 2 adjacencies, and maintain these with a common IIH PDU specifying both the Level 1 and Level 2 information.

• Two Level 1–2 routers in different areas establish only a Level 2 adjacency.

• Two Level 1 routers that might be physically connected but are not in the same area (including a Level 1–only to a Level 1–2 router in a different Level 1 area) exchange Level 1 IIH PDUs but ignore these because the area IDs do not match. Therefore, they do not establish adjacency.

Level 2 Adjacencies

Figure 5-14 shows examples of the following:

• Level 1–only routers establishing Level 1 adjacencies

• Level 2 routers establishing only Level 2 adjacencies (between areas)

• Level 1–2 routers establishing both Level 1 and Level 2 adjacencies with their Level 1–2 neighbors in the same area

Figure 5-14 Level 2 Adjacencies Must Be Continuous

Link-State Database Synchronization

IS-IS link-state database synchronization is accomplished using special PDUs: PSNPs and CSNPs. These special PDUs bear the generic name of sequence number PDUs (SNPs),

SNPs (PSNPs and CSNPs) ensure that LSPs are sent reliably. SNPs contain LSP descriptors—not the actual, detailed LSP information, but headers describing the LSPs.

PSNPs usually contain only one LSP descriptor block. They are used as follows:

• To acknowledge receipt of an LSP

• To request a complete LSP for an entry missing in the originating router's topology database

CSNPs are a list of the LSPs held by a router.

CSNPs are sent periodically on LANs. Receiving routers can compare the list of LSPs in the CSNP with their link-state database and request (with a PSNP) any missing LSPs.

CSNPs are sent on point-to-point links when the link comes active. In Cisco IOS Software, periodic CSNPs can be configured on point-to-point links.

Figure 5-15 shows an example of link-state database synchronization on a point-to-point link. In this figure, the following is true:

• A link fails.

• The R2 router notices this failure and issues a new LSP noting the change.

• The R1 router receives the LSP, stores it in its topology table, and sends a PSNP back to R2 to acknowledge receipt of the LSP.

Figure 5-15 Link-State Database Synchronization on a Point-to-Point Link

On a LAN, the DIS periodically (every 10 seconds) sends CSNPs listing the LSPs that it holds in its link-state database. This is multicast to all IS-IS routers on the LAN.

Figure 5-16 shows an example of link-state database synchronization on a LAN. In the example, the R2 router is the DIS. R2 sends a CSNP. The R1 router compares this list of LSPs with its topology table and realizes that it is missing one LSP. Therefore, it sends a PSNP to the DIS (R2) to request the missing LSP. The DIS reissues that LSP, and the R1 router acknowledges it with a PSNP (these last two steps are not shown in this figure but are similar to those in Figure 5-15).

Figure 5-16 Link-State Database Synchronization on a LAN