Understanding Intermediate System-to-Intermediate System (IS-IS)

Understanding Intermediate System-to-Intermediate System (IS-IS)

IS-IS Protocol Overview

The IS-IS routing protocol is one of three protocols specified by the International Organiza-tion for Standardization (ISO) to support connectionless network services (CLNS):

• Connectionless Network Protocol (CLNP)— ISO 84381. See also IETF RFC 994.
• End System-to-Intermediate System Routing Exchange Protocol (ES-IS)— ISO 95422. See also IETF RFC 995.
• Intermediate System-to-Intermediate System Routing Exchange Protocol (IS-IS)— ISO 105893. See also IETF RFC 1142.

ISO CLNS was meant to provide connectionless datagram services for data transmission instead of the conventional connection-oriented services. Unlike connection-oriented services that require end-to-end call establishment to precede any communication between network devices, datagram services allow data to be transmitted in independent chunks, known also as packets, without having to set a predefined path through the network between source and destination before transmission.

CLNP, which is very similar to the Internet Protocol (IP), is central to the operation of ISO CLNS. ES-IS and IS-IS are auxiliary protocols that help network nodes (end systems and routers) discover each other and gather routing information, which is used for forwarding packets. For example, the IS-IS protocol provides a dynamic mechanism that allows routers to gather information about various reachable destinations in a network. This information is then processed to determine optimal paths that routers can use for moving data from one end of the network to another.

ISO 10589 specifies IS-IS for routing CLNP packets, and RFC 11954 provides extensions to ISO 10589 to support routing of IP packets in addition to CLNP packets. Specifically, RFC 1195 defines Integrated (Dual) IS-IS, which allows IS-IS to obtain and also exchange CLNP and IP routing information simultaneously. Despite its dual capabilities, Integrated IS-IS can be used in CLNS-only or IP-only environments. This chapter and the next focuses on use of Integrated IS-IS in IP-only (pure IP) environments.

Unlike most routing protocols, which are typically encapsulated in a network layer protocol, IS-IS is itself a network layer protocol and rides over the data link alongside CLNP and IP. Actually, all three ISO protocols that support connectionless networking (CLNP, ES-IS, and IS-IS) are individually network layer protocols. This contrasts with the design of IP-specific routing protocols, such as the Open Shortest Path First (OSPF) and the Border Gateway Proto-cols, which ultimately are encapsulated in IP and operate at a higher layer of the Open System Interconnection (OSI) reference model. Protocol design requires associating a protocol or an application with an identifier for the corresponding layer of operation in the OSI model. The following is a list of network layer protocol identifiers (in binary) for the network layer proto-cols that have been mentioned so far. The hexadecimal equivalent is provided in brackets:

• CLNP: 10000001 (0x81)
• ES-IS: 10000010(0x82)
• IS-IS: 10000011 (0x83)
• IP: 11001100 (0xCC)

The ISO network layer protocol family is identified at the data link layer by 0xFEFE. IP is identified by 0x0800. CLNP by itself is not relevant to pure IP environments, and only IS-IS essentially is required to support IP routing in such environments. However, the operation of IS-IS is tied intrinsically to certain elements of the ISO CLNS environment, such as ISO addressing, network service access points (NSAP), and the ES-IS protocol. The ES-IS protocol is designed to facilitate communication between CLNS end systems and routers, and it has no relevance to the communication between IP hosts and IP routers. In an IP environment, network devices use IP-associated mechanisms, such as default gateways, the Address Resolution Proto-col (ARP) for IP address-to-data link address resolution, and the Internet Control Message Protocol (ICMP) for network-discovery and control functions. Discussions regarding details of CLNP and ES-IS are beyond the scope of this book, and further discussion is limited to issues of relevance to the operation of the IS-IS protocol.

IS-IS Routing Protocol

IS-IS is a link-state protocol designed for intradomain routing. It supports a two-level routing hierarchy:

• Routing within areas (Level 1)
• Routing between areas (Level 2)

Routers running the IS-IS protocol form adjacencies with other directly connected IS-IS routers and exchange routing information contained in link-state packets (LSPs). Each router collects LSPs into separate Level 1 and Level 2 link-state databases based on their mode of operation (Level 1 only, Level 2 only, or Level 1–2). The Level 1 link-state database provides a view of the local area’s topology, while the Level 2 link-state database provides a global view of interarea connectivity. The shortest path first (SPF) algorithm (named after Dijkstra) is run separately over Level 1 and Level 2 databases to obtain the best paths to various destinations in the network.

IS-IS is one of two popular Interior Gateway Protocols (IGP) used on the large service-provider networks that are interconnected to form the global Internet. The other popular IGP is the Open Shortest Path First (OSPF) protocol. The Border Gateway Protocol (BGP) is used for inter-domain router between network domains (or autonomous systems).

Aside from RFC 1195, which allows IS-IS to carry IP routing information, several other enhancements have been proposed for standardization in the IETF. Most prominent of these are Multiprotocol Label Switching Traffic Engineering (MPLS TE) related enhancements7. In recent times, interest in the IS-IS protocol has significantly increased, culminating in the reopening of the IS-IS working group in the IETF. Several of the new capabilities proposed in IETF already have been implemented as vendor-specific enhancements, and the effort is directed at standardization and interoperability across different vendor router products.

The successful adoption and widespread acceptance of the IS-IS protocol for IP routing is a result of its flexibility for extension, simplicity, and ease of troubleshooting. Troubleshooting of the IS-IS protocol is discussed in the next chapter. This chapter drills into key concepts behind the IS-IS protocol and lays the groundwork for Chapter 11, “Troubleshooting IS-IS.”

IS-IS Protocol Concepts

The goal of this section is to help you understand the operation, features, strengths, and limitations of the various architectural concepts underlying the IS-IS protocol. In particular, the following points are discussed:

• IS-IS nodes, links, and areas
• IS-IS adjacencies
• Level-1 and Level-2 routing
• IS-IS packets
• IS-IS metrics
• IS-IS authentication
• Addressing for the CLNP protocol

IS-IS Nodes, Links, and Areas

IS-IS inherits the following ISO classification and definition of the two basic types of net-work nodes:

• End systems
• Intermediate systems

End systems are hosts in a network that typically do not have extensive routing capabilities. Intermediate systems refer to routers whose primary function is to route packets.

Network nodes are interconnected by links. Again, in IS-IS, only two basic links types are of practical relevance:

• Point-to-point links
• Broadcast links

Point-to-point links interconnect pairs of nodes, while broadcast type links are multipoint and can interconnect more than two nodes at the same time. Transport technologies, such as serial (T1, DS-3, and so on) and Packet-over-SONET (PoS) links, are inherently point-to-point, while local-area network (LAN) media, such as Ethernet, are typical broadcast-type links. Nonbroadcast multiaccess (NBMA) transport media, such as Asynchronous Transfer Mode (ATM) and Frame Relay, can be configured to operate as simulated broadcast or point-to-point links. Because broadcast links inherently imply connected nodes are fully meshed, NBMA media should be configured as broadcast links only when the routers are fully meshed by the underlying permanent virtual circuits (PVC) .

Nonfully meshed NBMA environments should use point-to-point setups, which align with the underlying topology of PVC interconnections and are simpler to manage and troubleshoot. A network running the IS-IS routing protocol frequently is referred to as an IS-IS routing domain. A large IS-IS routing domain can be partitioned into multiple areas for the purpose of scaling routing over the entire domain. A routing area can be of any arbitrary size; the number of nodes that it contains largely is defined at the discretion of the network designer. Key factors normally taken into consideration when creating areas include memory and processing capacities of the routers involved. The larger the area is, the higher the resource (memory and CPU capacity) needs per router are for maintaining the IS-IS database and computing routes fast enough to sustain reasonable convergence times when changes occur in the network.

All IS-IS routers in the domain are assigned to at least one IS-IS area. Each IS-IS node has a unique node-based address referred to as a network service access point (NSAP). NSAPs are discussed later in this chapter, but, for now, all you need to know is that the NSAP has an area identifier component that defines the native area of each node.

Figure 10-1 shows the layout of an IS-IS domain carved into three areas with the following simple area-identifiers: 49.001, 49.002, and 49.003. As depicted, the areas are interconnected through the region known as the backbone. From this diagram, it is also apparent that each node wholly sits in a specific area and that the area boundaries cut across the links to other areas. Each IS-IS area is specified in ISO 10589 to be a stub—meaning that interarea routing inform-ation remains only within the backbone. A recent IETF-sponsored enhancement6 removes this restriction. This capability is available in Cisco IOS Software as a feature known as IS-IS route leaking.

Adjacencies

As a link-state protocol, IS-IS relies on current and complete knowledge of the network topology to compute routes accurately and optimally. Some key functions of routers partici-pating in IS-IS routing involve discovering, establishing, and maintaining routing adjacencies with neighbor routers. The type and manner in which an adjacency is formed between two routers depend on the type of link interconnecting them. This section addresses the two types of IS-IS adjacencies, which correlate with the two types of links discussed earlier. The adjac-ency types are listed here:

• Adjacencies over point-to-point links
• Adjacencies over broadcast links

Formation and maintenance of adjacencies between IS-IS routers take place through the exchange of special packets, referred to as hellos. Routers need to form both ES-IS and IS-IS adjacencies over either point-to-point or broadcast links. Even though ES-IS is not necessary for IP routing, IS-IS adjacency formation on point-to-point links is dependent on ES-IS adjac-ency detection on such links. Therefore, Cisco IOS Software enables the ES-IS protocol even if IS-IS is enabled for only IP routing. ES-IS uses end-system hellos (ESHs) and intermediate-system hellos (ISHs) for ES-IS adjacencies, while IS-IS uses intermediate system-to-intermediate system hellos (IIHs).

ES-IS Adjacencies

In ES-IS, end systems advertise ESHs to routers by addressing them to the MAC address 09-00-2B-00-00-05 (AllIntermediateSystems). On the other hand, routers advertise ISHs to 09-00-2B-00-00-04 (AllEndSystems). ES-IS essentially provides a host-discovery mech-anism in the ISO CLNS environment. Through this mechanism, end systems locate the closest router though which they can transit data to nonconnected media. Routers, in turn, learn about end systems in their area. Routers also discover each other through the ES-IS adjacency process. Figure 10-2 shows ISH and ESH transmissions between routers and a workstation on a LAN.

IS-IS Adjacencies

For routers to exchange routing information, they need to transcend ES-IS adjacencies and form IS-IS adjacencies with their neighbors. An interesting point to note is that ES-IS adjacency is required to trigger advertisement of IIHs on point-to-point links, which ultimately can lead to IS-IS adjacencies.

The IS-IS adjacencies on point-to-point links are formed and maintained a little differently than on broadcast links. Also, IIHs used on point-to-point links have a slightly different format than those used on broadcast multipoint links. The following are the three types of specified IIHs:

• Point-to-point IIH— Used over point-to-point links.
• Level 1 LAN IIH— Used over broadcast links but for Level 1 adjacencies. Advertised to 01-80-C2-00-00-14 (AllL1ISs).
• Level 2 LAN IIH— Used on broadcast links but for Level 2 adjacencies. Advertised to 01-80-C2-00-00-15 (AllL2ISs).

The point-to-point IIHs and LAN IIHs have slightly varied information in their fixed header areas. For example, the point-to-point IIHs have a local circuit ID, whereas LAN IIHs have a LAN ID. Also, point-to-point IIHs don’t have the priority information found in LAN IIHs. IS-IS packet formats are covered later in this chapter, in the section titled “IS-IS Packets.” Complete formats of hello packets are provided at the end of the chapter in the section titled “Additional IS-IS Packet Information.” IS-IS has a two-level routing hierarchy, and, as alluded to previously, the type of adjacency formed between IS-IS routers determines the type of routing relationship between them (that is, Level 1, Level 2, or both).

Routing information is exchanged through the use of link-state packets (LSPs), with control provided by sequence number packets (SNP). LSPs and SNPs will be discussed further in the section “IS-IS Link-State Database.”

On multiaccess links such as broadcast LANs or multipoint ATM and Frame Relay links in which more then two nodes are connected to the same link, forming adjacencies between all of them results in n x (n – 1)/2 adjacencies, where n is the number of connected nodes. In IS-IS, all nodes on multipoint links actually detect each other by means of the hellos multicast across the medium. Each node, therefore, forms n – 1 adjacencies on such media. A node declares a neighbor to be adjacent if that neighbor is announced in the list of detected neighbors. Reliably updating and synchronizing databases with each of these adjacent neighbors certainly is resource-demanding. Therefore, to reduce the amount of effort required for database synchronization, IS-IS models such multipoint links as virtual nodes, also referred to as a pseudonodes (PSN) (see Figure 10-3).

One of the routers on the multipoint link is elected as a designated router to play the role of the PSN. In ISO terminology, the designated router is referred to as the designated intermediate system (DIS). Election of the DIS is based on interface priorities of the routers connecting to the multiaccess link, with the highest MAC address being the tiebreaker in the case of LAN media. The default priority is 64 on Cisco routers and can be modified with the isis priority value interface-level configuration command. The priority information is carried only in LAN-type hellos, as mentioned previously. The role of the DIS is to facilitate synchronization of the IS-IS link-state databases between routers connected to the multipoint medium. It does this by periodically multicasting summaries of all known LSPs over the medium. The DIS also generates a PSN LSP that lists all known neighbors on the multipoint link. All nodes on the multipoint medium become adjacent to both the PSN and the actual router acting as the DIS. All nodes on the LAN must consistently acknowledge the same DIS for IS-IS operations to work well on the LAN. DIS election is preemptive; at any point, the most qualified router takes over the role.

Three-way reliable adjacency formation is specified in ISO 10589 for only broadcast links but not for point-to-point links. Therefore, unlike point-to-point hellos, LAN hello packets contain a list of IS neighbors on the LAN that hellos have been received from. A LAN router moves its side of the adjacency with a specific neighbor to UP state when it receives a hello from that neighbor in which it is listed. Both ISO 10589 and RFC 1195 do not specify point-to-point hellos to carry the IS neighbor list. The recent IETF draft5 proposes standardization of the three-way handshake method for adjacency formation on point-to-point links. This is supported in Cisco IOS Software Release 12.OS and later. Figure 10-4 illustrates the adjacency formation process on point-to-point links.

As shown, RTA and RTB both advertise hellos to each other in which they list only themselves in the list of known neighbors, indicating that they haven’t heard from each other yet. After they receive each other’s hello, each lists the other in the neighbor list in subsequent hello exchanges. This results in both routers moving their adjacencies to the UP state. The same process is used on multiaccess links.

Hierarchical Routing

As indicated earlier, IS-IS areas provide a means for scaling routing in the IS-IS domain. Regular IS-IS areas and the backbone interconnecting them are organized into a two-level routing hierarchy. Routing within an area is referred to as Level 1 routing. Routing between the respective areas in a domain is referred to as Level 2 routing. Figure 10-5 shows an IS-IS domain partitioned into two areas: 49.001 and 49.002. It is interesting to note that, although Level 1 routing is restricted only to the confines of each area, Level 2 routing occurs within the stretch of the backbone, which can overlap well into any area based on configuration of the routers.

IS-IS routers can be Level 1 only (L1), Level 2 only (L2), or both Level 1 and Level 2 (Level 1–2), based on their configuration. The configuration of a router determines the type of adjacency (Level 1 or Level 2) that it can form with its neighbors, regardless of the type of link. This, in turn, determines the level of routing (Level 1 or Level 2) that a router can participate in.

In the default mode of operation, Cisco routers are Level 1–2 and can form any kind of adja-cency with their neighbors. A router in one area can form only a Level 2 adjacency with a router in another area, so only Level 2 routing occurs between them. However, depending on their configuration, two routers in the same area can form a Level 1 adjacency or both Level 1 and Level 2 adjacencies with each other.

Typically, routers that are Level 2, by virtue of their connectivity to the backbone, also engage in Level 1 routing within their respective areas, making them Level 1–2 routers. Level 1–2 routers facilitate access to other areas for Level 1–only routers in the area. Level 1–2 routers flag their connectivity to the backbone in their Level 1 routing advertisements.

As specified in ISO 10589, IS-IS Level 1 areas are stubs, and the Level 1–only routers have no visibility into routes in other areas within the same domain. They depend on a default route to the nearest Level 2 router to forward packets to destinations outside the local area. Relying on a default route to the nearest Level 2 router potentially could result in suboptimal determination of the best exit to other destinations in the network. RFC 29666 standardizes domain-wide prefix advertisement (IS-IS route leaking) by allowing interarea routes to be advertised from the Level 2 backbone into Level 1 areas. This capability enables optimal path selection by Level 1 routers for destinations outside their local areas.

IS-IS Packets

Because the objective of this book is to assist with troubleshooting IP routing problems, it would not be an overstatement to point out here that familiarity with the variety of packets and their formats used by a routing protocol is key to understanding the protocol nuances required for successful troubleshooting. This section reviews the various types of IS-IS packets and studies the generic IS-IS packet format. In ISO parlance, packets are referred to as protocol data units (PDU). The complete formats of each packet type are provided at the end of the chapter in the section titled “Additional IS-IS Packet Information.” Three categories of IS-IS packets exist:

• Hello packets (IIHs)— Establish and maintain adjacencies between IS-IS neighbors.
• Link-state packets (LSPs)— Distribute routing information between IS-IS nodes.
• Sequence number packets (SNPs)— Control the distribution of LSPs. SNPs provide mechanisms for synchronizing link-state databases between routers in the same area or the backbone.

Various types of packets exist under each of the packet categories. Each type is assigned a type number, as shown in Table 10-1. All IS-IS packets are multicast on LAN media to one of the following addresses, depending on the level of routing for which it is intended:

• 01-80-C2-00-00-14 (AllL1ISs)— For Level 1 systems
• 01-80-C2-00-0-15 (AllL1ISs)— For Level 2 systems

Generic IS-IS Packet Format

Each type of IS-IS packet is made up of a packet header and a number of optional variable-length fields referred to as Type-Length-Value (TLV) fields. The fields of each packet type vary slightly from each other, consisting of the generic fields and packet type specific fields, as shown in Figure 10-6.

The generic header fields are described as follows:

• Intradomain Routing Protocol Discriminator— This is the network layer identifier assigned to IS-IS, as specified by ISO 9577. Its value is 0x83 in hexadecimal.
• Length Indicator— This specifies the length of the packet header fields in octets (bytes).
• Version/Protocol ID Extension— Currently this field has a value of 1.
• Version— The value of this field is 1.
• Reserved— These are unused bits; this field is set to 0.
• Maximum Area Addresses— This field includes values between 1 and 254 for the actual number. 0 implies a maximum of three addresses per area.

The TLV fields are so named because each is described by the following three attributes:

• Type— A 1-byte field containing a number code. ISO 10589 uses the word Code in place of Type. However, Type seems to be preferred in IETF and Cisco literature on IS-IS.
• Length— A 1-byte field that specifies the total length of TLVs of that type in the packet.
• Value— Content of the TLV. Typically, the value is made up of repeated blocks of similar information.

By specification, each IS-IS packet type includes only specific TLV types. The number of actual TLVs present in a real packet is determined by the configuration and environment of the origina-ting router. Most of the currently specified TLVs can be present in both Level 1 and Level 2 packets. A few, however, are dedicated to only Level 1 or Level 2 packets. RFC 1195 specifies additional TLVs to those specified in IS0 10589. Tables 10-2 and 10-3 list TLVs specified by ISO 10589 and RFC 1195, respectively.

Most enhancements to the original IS-IS protocol (ISO 10589) have occurred through the intro-duction of new TLVs instead of new packet types. This points largely to the flexibility and extensibility of the IS-IS protocol. For example, TLVs introduced by RFC 1195 adapted IS-IS for routing IP in addition to CLNP. Table 10-4 lists recently introduced TLVs within the IETF that provide various extensions and additional capabilities to the IS-IS protocol. TLVs 22, 134, and 135 are IS-IS extensions for MPLS-based traffic engineering.

IS-IS Metrics

The following IS0 10589 and RFC 1195 TLVs carry metric information in addition to their primary objects:

• ES Neighbor TLV (Type 2)
• IS Neighbor TLV (Type 3)
• Prefix Neighbor TLV (Type 5)
• IP Internal Reachability TLV (Type 128)
• IP External Reachability TLV (Type 130)

Obviously, each TLV would have a different overall format, but they all have the same set of metric fields. Figure 10-7 shows the format of the value field in the IP Internal Reachability TLV. Other fields of the TLV include the Type and value fields, all 1 byte each.

The following four metric types are specified by ISO 10589 and have been adopted by RFC 1195:

• Default Metric— Also known as cost. Must be supported by all routers in the IS-IS domain. Provides indication of link speed. Lower values imply relatively faster link speed or more bandwidth.
• Delay Metric— (Optional) Measures transit delay of link.
• Expense Metric— (Optional) Measures monetary cost of link.
• Error Metric— (Optional) Measures residual error probability of link.

The default metric type must be supported on all nodes in the routing domain. The other metric types—delay, expense, and error—are optional and are intended for differentiated routing of quality of service (QoS)–enabled CLNP packets. The IS-IS QoS metrics are not applicable to IP traffic differentiation, which is based on the precedence bits in the IP header. In any case, Cisco’s implementation of IS-IS supports only the required default metric type.

As depicted in Figure 10-7, each type of metric is 1 byte long. Bit 8 indicates the presence of the metric type in the TLV, and bit 7 classifies the metric as internal or external. Internal metrics refers to routes generated within the IS-IS domain, while external metrics refers to routes originating outside the IS-IS domain or from another routing protocol source, such as OSPF. Consequently, only 6 bits are available for defining the actual value of the metric. This gives a maximum cost of 63 per link, in the case of the default metric type. On Cisco routers, the cost of a link is determined by the value applied to the outgoing interface. A value of 10 is assigned by default on all interface. The cost is not derived automatically from the interface bandwidth, as in the case of OSPF. The total metric of a complete path is the sum of cost values on all outgoing interfaces from source to destination. ISO 10589 specifies 1023 as the maximum path cost. Recent IETF-driven extensions7 to IS-IS propose using the mostly unused QoS metric fields as part of the default metric type field to allow higher-cost values for the default metric type.

The following LSP TLVs, which were recently introduced to support MPLS TE, support a wider field for the default metric type:

• Extended IS Reachability TLV (Type 22)
• Extended IP Reachability TLV (Type 135)

Figure 10-8 shows the format of each prefix element contained in the Extended IP Reach-ability TLV.

The following is the list of fields in the Extended IP Reachability TLV:

• Type— (1 byte) Type 135. Indicates the Extended IP Reachability TLV.
• Length— (1 byte) Total length of the Value field.
• Value— Many prefixes can exist in each TLV, and the number is constrained only by the maximum LSP size. Each prefix element in this field consists of the following information:
  • 4 bytes of metric information
  • Control information (1 byte)—This byte is composed of
  • 1-bit sub-TLV presence bit
  • 6 bits of prefix length
  • IPv4 Prefix— Ranges from 0 to 4 bytes.
  • Optional Sub-TLVs— Ranges from 0 to 250 bytes and is composed of
    • 1 byte of length of sub-TLVs
    • 0 to 249 bytes of sub-TLVs

The 4-byte metric field (32 bits) permits large metric values, which, as specified, should not be more than the value MAX_PATH_METRIC (0xFE000000). Prefixes with metrics larger than MAX_PATH_METRIC are to be ignored in SPF computations. Consult the RFC draft7 for further details.

Cisco IOS Software releases from the 12.0S and 12.0T trains support the expanded IS-IS metric values for the default type, also known as wide metrics. The IS-IS router-level command metric-style [narrow | wide] enables and disables wide IS-IS metrics. A “hidden” option of the command metric-style transition is provided for only migration purposes. When enabled, this command allows a router to send and receive both narrow and wide metrics.

IS-IS Authentication

Both ISO 10589 and RFC 1195 specify authentication mechanisms (TLV 10 and 133, respec-tively), in an attempt to tackle protocol security concerns. Only minor differences exist between the formats of these TLVs; however, significant commonality is that they both specify only clear-text password schemes. However, both TLVs provide reserved fields for future advanced authentication options. Well, the future is already here! A new IETF draft10 proposes a protocol extension that uses an HMAC-MD5 authentication option in addition to the previously spec-ified clear-text password schemes. Most existing IS-IS implementations use TLV 10 over TLV 133, even in pure IP environments. The IS-IS HMAC-MD5 authentication extension therefore extends application of this TLV by defining a new authentication type 54 (or 0x36 in hexa-decimal) within TLV 10. The clear-text password is authentication Type 1.

ISO CLNP Addressing

An interesting paradigm concerning IS-IS is that it is deeply rooted in CLNP to the extent that, even if it is used for routing only IP, CLNP addresses still must be configured on the IP routers. Therefore, it is important for network operations staff using IS-IS in pure IP environments to become comfortable with the CLNP addressing architecture. CLNP addresses are referred to as network service access points (NSAPs). Obvious differences between IP addressing and CLNP addressing are as follows:

In IP, addresses are assigned to the router interfaces as part of subnets defined for con-necting links. In CLNP, an address is assigned to the whole node instead of the connecting links. Also, subnet masks are not required for NSAP configuration as in the case of IP addressing, even though masks can be used in CLNP static route statements.

CLNP addresses are of variable length, with a minimum length of 8 bytes and a maximum of 20 bytes. The system ID and N-selector parts of the address must have a consistent length, 6 bytes and 1 byte, respectively, on Cisco routers. In contrast, an IP version 4 address applied to a router’s interface must be 32 bits long.

NSAP Format

A simplified version of the CLNS NSAP format, specified in ISO 10589 and associated specifications, was adopted by RFC 1195 in adapting IS-IS for IP routing. This format, as shown in Figure 10-9, delineates only three key components in an NSAP address:

• Area identifier (AreaID)— This defines the IS-IS area to which a router belongs.
• System identifier (SysID)— This is a unique identifier for an IS-IS router within an area or the Level 2 backbone.
• N-selector (NSEL)— This is analogous to an application identifier. It indicates a hand-off point of IS-IS packets to the next higher layer above the network layer. IS-IS packets are forwarded to the routing layer in a router, which is designated by an all-zero (0x00) N-selector.

The maximum length of an NSAP is 160 bits (20 bytes), compared to the 32 bits (4 bytes) of an IP address. The NSEL is 1 byte long. The SysID is specified in ISO 10589 to be of variable length, ranging from 1 byte to 8 bytes long. However, Cisco follows the US GOSIP standard, which specifies 6 bytes fixed-length for the SysID. The AreaID field is a variable-length field from 1 to 13 bytes. A key component of the AreaID that RFC 1195 seems to gloss over is the Authority and Format Identifier (AFI). The AFI is the first byte of the AreaID, and it specifies a top-level ISO addressing authority as well as encoding of the NSAP.

Table 10-5 lists the AFI values for seven ISO top-level addressing domains. Each domain features two AFI values for binary and decimal encoding of the remainder of the address following the AFI field.

Various address-registration authorities oversee allocation of addresses from each of the top-level domains. For example, ICD ISO 6523 addresses are allocated through national-level registration authorities, such as the United States National Institute of Standards (NIST) or the British Standards Institute (BSI). The U.S. NIST is responsible for allocation of ISO 6523 ICD (AFI 47) addresses to organizations in the United States, including U.S. federal government institutions. Similarly, the American National Standards Institute (ANSI) is the national reg-istration authority for ISO DCC (AFI 39) addresses in the United States. AFI 49 designates a private NSAP address space similar to the private IP address space specified in RFC 191811.

NSAP Examples

Figure 10-10 shows examples of NSAP addresses. Example 1 is a complete, full-length (20 bytes) address, while Example 2 is a shorter-length address from the private space.

As mentioned earlier, the system ID (SysID) is a 6-byte field that uniquely represents a node in an IS-IS domain. Frequently, network administrators use a MAC address for the SysID. However, this is not necessary. Also, a router might have many LAN interfaces and, therefore, many MAC addresses making it unclear which is best suitable for the purpose. Most ISPs who use IS-IS as IGP have figured out a creative and decisive way to define the system ID and, therefore, the NSAP address on a router. The system ID is created from a loopback address. In many cases, an IP loopback address is defined on a router for other purposes, such as network management or specifying the router ID for BGP peering. To create the system ID, the loopback IP address, which is in dotted-decimal format is first padded with zeros to obtain the 12-digit address, as shown in Figure 10-10, Example 3. The digits then are regrouped in fours to obtain the 6-byte hexadecimal system ID, which can be used for defining a unique NSAP for the router.

Guidelines for Defining NSAP Addresses

The following provides a summary of the guidelines for selecting or defining NSAP addresses on routers in an IS-IS routing domain:

• Routers in different areas within the domain must use different area IDs. Routers within an area have the same area prefix in their NSAPs.
• Each node in an area must have a unique system ID. This also applies to nodes in the backbone relative to each other.
• All systems in an IS-IS routing domain must use the same length for their system IDs. Cisco routers use a fixed size of 6 bytes.
• Each node must have at least one NSAP. By default, you can configure Cisco routers with up to three NSAPs, each with the same system ID component but a different area ID. The router-level command max-area-area {0–254} allows up to 254 NSAPs to be configured in a similar manner.

The concept of configuring multiple NSAPs per node for a single instance of IS-IS routing allows a router to be associated with more than one Level 1 area, a concept referred to as multihoming. The effect of multihoming is that all the areas configured are merged into a single area, allowing Level 1 LSPs to be advertised across previous area boundaries. In essence, multihoming is used for transitional purposes, such as network renumbering, partitioning, or merging IS-IS areas in a domain. The technique permits nondisruptive network reconfiguration.

IS-IS Link-State Database

As a link-state protocol, IS-IS works by gathering reliable and complete information about the routing environment through the use of special packets known as Link State Protocol Data Units (LSPs). A protocol data unit (PDU) also means a packet. Each router generates an LSP, which captures local link-state information describing connected links, neighbor routers, IP subnets, related metric information, and so forth. Copies of the LSP are distributed to all routers in a specific area through a process referred to as flooding. Ultimately, all routers in an area obtain every other router’s LSP and synchronize their databases. Because the area link-state database is used for only intra-area routing (also referred to as Level 1 routing), it is called the Level 1 link-state database. The Level 2 routers interconnected into the backbone similarly maintain a Level 2 link-state database through the exchange of Level 2 LSPs. Best paths though the network are resolved by running the SPF algorithm over the information in the Level 1 and Level 2 databases separately. The sections that follow address the following subtopics:

• Overview of the IS-IS link-state database
• Flooding and database synchronization
• The SPF algorithm and route calculation

The first section provides a high-level overview of the IS-IS link-state database. The next section discusses the flooding process through which database synchronization is achieved, and the last section tops the earlier discussions with an overview of the SPF algorithm, also known as the Dijkstra algorithm.

Overview of the IS-IS Link-State Database

The operation of a link-state protocol requires each node in an area to have a complete view of the entire area and, using that knowledge, calculate the best paths to each destination in the area, starting with itself. As indicated previously, LSPs are the vehicles for propagating each router’s limited view of its immediate surroundings; therefore, the assembly of LSPs by routers to obtain the complete routing picture of the network frequently has been compared to the process of solving a jigsaw puzzle. The solved puzzle represents the entire picture of the network or its complete topology. Each of the unique Level 1 databases represents the state of adjacencies within a specific area, while the Level 2 database represents the interconnections among the various areas in the domain. On Cisco routers, the command show isis database [detail|level-1|level-2] [lspid] can be used to view the LSPs in the Level 1 or Level 2 databases. Exercising the detail option of the command displays details about elements in all known LSPs or a specific LSP. Figure 10-11 shows the format of an LSP.

The LSP header features generic fields that have already been discussed in this chapter. The following are some of the fields specific to the LSP header:

• Remaining Lifetime— This is the time interval until expiration of an LSP. An LSP ages from the time that it is generated. If it is not refreshed before its maximum age (Maxage) is reached, it expires and it is then subsequently deleted from the LSP database. The default value of Maxage is 20 minutes.
• LSP Identifier— The LSP identifier (LSPID) obviously is used for identification purposes and indicates the owner of the LSP. The LSPID format, as shown in Figure 10-12, consists of three components.

• System identifier (SysID)— This is the system ID of the originating router or the designated router (DIS), in the case of a pseudonode LSP.
  • Pseudonode identifier— This is 0 for a non-PSN LSP and nonzero for a PSN LSP.
  • LSP number— This denotes LSP fragments.
• Sequence Number— A router tags the LSP that it generates with a sequence number to differentiate newer copies from older ones. The LSP sequence number is increased by 1 whenever the router generates a new LSP to replace an outdated version. New LSPs are issued when changes occur in local surroundings of the router that need to be reported to the rest of the network. An IS-IS router periodically issues a new LSP with the same information as the previous LSP, just to refresh an LSP before it expires. The default refresh interval is 15 minutes.
• Checksum— This maintains the integrity of an LSP during storage or when the LSP is in flight during flooding. The checksum value is inserted into the LSP by the originating router and is verified by any router that receives a copy. If an LSP fails a checksum valid-ation, it is considered as corrupted and should not be used in routing calculations or flooded to other parts of the network. As a precaution, when a router determines an LSP is corrupted, it attempts to purge the LSP from the network by setting its remaining lifetime to 0 and flooding copies to all its neighbors.

Other interesting fields in the LSP header, as shown in Figure 10-11, are as follows:

• Partition Bit (P)— Bit 8. Set to indicate whether the originator of the LSP supports partition repair. This capability currently is not supported in Cisco IOS Software.
• Attached Bit (ATT)— Bits 4 to 7. Any of these bits is set to indicate that the node is attached to another area or the Level 2 backbone. These bits are set in the Level 1 LSPs generated by Level 1–2 routers. The one specific bit set indicates the type of metric used in the backbone. The bits are defined as follows:
  • Bit 4—Default metric
  • Bit 5—Delay metric
  • Bit 6—Expense metric
  • Bit 7—Error metric

Only bit 4 is set on Cisco routers because the default metric is the only supported metric type.

LSP Database Overload Bit (O)— Bit 3. This is set to indicate that the origin router is overloaded and could be experiencing resource (memory or processing) starvation prob-lems. No paths should be calculated through the origins of LSP with the overload bit set. The Cisco IOS Software command set-overload-bit can manually set the overload bit for administrative and resource-management purposes. The overload bit is also known as the hippity bit.

IS Type— Bits 1 and 2. This field indicates the type of router issuing the LSP. Bit 1 only is set for a Level 1 router, and both bits are set for a Level 2 router. The other combinations are unused. Obviously, if the IS type is set for a Level 2 router in a Level 1 LSP, the source is a Level 1–2 router.

Example 10-1 shows the output of the Cisco IOS Software command show isis database detail. As mentioned previously, the key elements of an LSP are captured in this output. This is a very useful command for troubleshooting IS-IS routing problems involving missing routes.

Example 10-1 Displaying Details of an LSP on a Cisco Router

GSR2#show isis database level-2 detail RTA.00-00
IS-IS Level-2 LSP RTA.00-0
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
GSR2.00-00 * 0x0000000E 0x08B5 986 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: RTA
IP Address: 13.1.1.2
Metric: 10 IS RTA.02
Metric: 10 IS RTB.01
Metric: 10 IS RTC.00
Metric: 10 IP 10.1.1.0 255.255.255.252
Metric: 10 IP 12.1.1.0 255.255.255.0
Metric: 10 IP 13.1.1.2 255.255.255.255

Flooding and Database Synchronization

The IS-IS functional process responsible for maintaining the link-state database (that is, generating local LSPs, receiving and advertising LSPs to neighbors) is referred to as the update process. The update process plays an important role in IS-IS routing by making sure that routers in the domain receive timely, reliable, and complete information about the routing environment. This information is necessary for determination of optimal paths to various destinations throughout the network. The process by which LSPs are advertised and distributed between routers in a domain is known as flooding. When a router receives LSPs from its neighbors, it stores copies in its local database and then forwards copies to neighbors on links other than those on which the LSPs were received. All L1 routers in the same area ultimately build identical collections of Level 1 LSPs in their Level 1 database. The same thing applies to the Level 2 routers that are connected to the backbone. Under stable conditions, the Level 2 routers in the domain have the same set of LSPs in their Level 2 link-state databases just as Level 1 routers in the same area have the same set of LSPs in their Level 1 databases. The process of ensuring that every router receives all known LSPs in the Level 1 or Level 2 databases is referred to as database synchronization. Other auxiliary functions carried out by the update process ensure database synchronization.

Various timers and control mechanisms are employed to guarantee effectiveness of the update process in carrying out flooding and database synchronization. Sequence Number PDUs (SNPs) provide control of the synchronization process. Actually, there are two types of SNPs:

• Complete sequence number PDUs (CSNP)— Contain summaries of all LSPs known by the issuing router
• Partial sequence number PDUs (PSNP)— Contain summaries of only a subset of known LSPs and solicit newer versions of a complete LSP or acknowledge receipt of LSPs

Each LSP summary in a CSNP or PSNP consists of the following attributes from the header of the original LSP:

• Remaining lifetime
• LSP ID
• LSP sequence number
• LSP checksum

Figure 10-13 elaborates how CSNPs and PSNPs are used for LS database synchronization. The complete formats of CSNP and PSNP are provided at the end of the chapter in the section titled “Additional IS-IS Packet Information.”

As noted previously, various timers play significant roles in the flooding and database-synchronization process. Table 10-6 lists some key timers employed by the update process. Also featured are their default values in Cisco IOS Software, which mostly conform to values specified by ISO 10589. The right-most column of the table lists corresponding Cisco IOS Software commands for modifying the default timer values.

shows a network with a point-to-point connection between RT1 and RT2. RT2 also is connected to RT3 and RT4 over a broadcast LAN. Also depicted is the process of LSP flooding over the point-to-point and LAN links. IS-IS uses a reliable flooding mechanism on point-to-point links in which LSPs flooded out an interface must be acknowledged with a PSNP by the node at the other end of the link. LSPs flooded over broadcast links, on the other hand, don’t need to be acknowledged by the recipients. Synchronization of databases over broadcast links is carried out with the help of the designated intermediate system (DIS), which periodi-cally multicasts a summary of all known LSPs in a CSNP. Routers that notice any LSPs in the CSNP that they do not have then request the complete copies by using PSNPs. IS-IS Level 1 and Level 2 packets are advertised to the AllL1ISs and AllL2IS multidestination addresses, respectively.

In Figure 10-13, RT1 advertises an LSP (RT1.00-00) over the point-to-point connection to RT2, which acknowledges as expected with a PSNP. RT2 then saves a copy in its database and floods another copy over the LAN to RT3 and RT4. RT3 and RT4 do not acknowledge receipt of RT1.00-00. At the expiration of the CSNP timer, however, RT2, which is also the DIS on the LAN, advertises a CSNP with summaries of all known LSPs. Because RT4 obviously didn’t receive a copy of RT1.00-00 transmitted by RT2, it notices that it is missing that LSP from the summary that it receives, and it requests a complete copy with a PSNP. The complete RT1.00-00 then is multicast again over the LAN by RT2.

Shortest Path First (SPF) Algorithm and IS-IS Route Calculation

The previous section discusses the link-state database and the various mechanisms for reliably populating it with LSPs. Even though LSPs are routing related information, they are not routes in themselves and need to be processed further to obtain the actual routes for forwarding data pac-kets. The IS-IS process responsible for converting the raw link-state information into routes is known as the decision process. The decision process uses the shortest path first (SPF) (Dijkstra) algorithm for calculating the paths to every known destination within an area or the backbone. Independent processes are run for Level 1 and Level 2 using the respective link-state databases as input.

The SPF algorithm12,13 computes a shortest-path tree to all nodes in an area or the backbone with the calculating router at the root. The calculation is done in an iterative manner by using three sets:

• Unknown
• Tentative (TENT)
• Paths (PATH)

All nodes with the exception of the root initially are placed in the unknown set and are moved to the TENT set in turn, beginning with the nodes directly connected to the root. At each iteration, the node in the TENT set that is closest to the root is moved into the PATH list. The nodes directly connected to the most recent graduate from the TENT set are then moved into the TENT set if not already present. The costs of nodes in the TENT set are then adjusted for the next iteration. This continues until all nodes are in the PATH set and the shortest-path tree is completely built. Routes then are derived from the shortest-path tree.

Configuring IS-IS for IP Routing

This section reviews the basic tasks involved in enabling IS-IS on Cisco routers. In addition to the basic configuration, numerous Cisco IOS Software commands exist for enabling various optimization and management capabilities, such as modifying hello timers, logging IS-IS adjacency changes, performing authentication, and so on. Chapter 11 covers some of these options in greater detail. For completeness, however, you should consult the “IOS Network Protocols Configuration Guide,” available at www.cisco.com.8

Enabling IS-IS on point-to-point and LAN broadcast–type links is simple and similar in both cases. Additionally, on LAN type links, you can use the interface-level command isis priority value to select a preferred router to be DIS. The default interface priority is 64. A higher value is preferred.

The following sections provide examples that elaborate on configuring IS-IS specifically:

• Configuring IS-IS on point-to-point serial links
• Configuring IS-IS on broadcast links (that is, LAN media)
• Configuring IS-IS on NBMA links, including the following:
  • ATM point-to-point
  • ATM multipoint
• IP default route advertisement
• Redistribution
• IP route summarization

Configuring IS-IS on Point-to-Point Serial Links

Figure 10-14 shows two routers, RT1 and RT2, connected back to back by a serial link. Both routers are placed in the same IS-IS area. Figure 10-15 shows a similar setup but with RT1 and RT2 in different areas. The AreaIDs of RT1 and RT2 are mismatched to put them in different areas.

The following two steps are required to enable basic IS-IS routing on Cisco routers:

Step 1. Configure the routing process.

Step 2. Apply IS-IS routing to relevant interfaces of the router to activate IS-IS routing over them.

The configuration command, router isis [tag], enables the IS-IS routing process. The tag is an optional keyword for labeling the routing process, and it is of significance only in the local router where it is used. Some service providers maintain the same tag on all routers in the domain, even though it is not required. It should be noted, however, that some old Cisco IOS Software releases require the tags to match between neighbor routers. By default, Cisco routers behave as Level 1–2 when IS-IS first is enabled on them. The com-mand clns routing also is entered automatically into the configuration when the routing process is activated. An NSAP address must be configured on the router even if it is to be used to route only IP. The router-level command net {nsap} is used for this. A NET is an NSAP with a 0-value NSEL.

The next step after configuring the routing process is to enable IS-IS routing on the interfaces where IS-IS routing is desired. The command ip router isis [tag] is sufficient for IP-only routing. The tag must be the same as the one used for the routing process. If ISO CLNP routing and packet forwarding are required, they can be enabled with the interface command clns router isis [tag].

Exclusive Level 1 or Level 2 routing can be enabled for individual interfaces with the interface-level command isis circuit type {level-1 | level-2 | level-1-2}. The level-1-2 option restores the default behavior. The router-level command is-type {level-1 | level-2-only | level-1-2} applies the preferred mode of operation to all interfaces simultaneously.

In Figure 10-14, both routers are in the same area and share a common area prefix (49.0001). Therefore, according to the default Cisco IOS Software behavior, they establish Level 1 and Level 2 adjacencies.

Example 10-2 shows the configuration for RT1 and RT2, which are depicted in Figure 10-14.

Example 10-2 Configuring Point-to-Point IS-IS Neighbors in Same Area

hostname RT1
clns routing
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip router isis
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.252
ip router isis
!
router isis
net 49.0001.0000.0000.0001.00
_____________________________________________________________________________________
hostname RT2
clns routing
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
ip router isis
!
interface Serial0/0
ip address 192.168.1.2 255.255.255.252
ip router isis
!
router isis
net 49.0001.0000.0000.0002.00

In contrast to Figure 10-14, the routers in Figure 10-15 are in different areas, so they will form only a Level 2 adjacency.

Example 10-3 shows the configuration for RT1 and RT2 depicted in Figure 10-15.

Example 10-3 Configuring Point-to-Point IS-IS Neighbors in Different Areas

hostname RT1
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip router isis
!
interface Serial2/0
ip address 192.168.1.1 255.255.255.252
ip router isis
!
router isis
net 49.0001.0000.0000.0001.00
_____________________________________________________________________________________
hostname RT2
!
interface Loopback0
ip address 10.1.1.2 255.255.255.255
ip router isis
!
interface Serial2/0
ip address 192.168.1.2 255.255.255.252
ip router isis
!
router isis
net 49.0002.0000.0000.0002.00

The following commands are useful for verifying proper configuration and operation of IS-IS on Cisco routers:

• show clns protocol
• show clns neighbors [detail]
• show clns interface
• show isis topology
• show isis database

The sections that follow provide example outputs from these show commands based on the router setup in Figure 10-15. Each example features output from each router (RT1 and RT2) to show the state of either side of the connection. Because the setup is basic, most of the output is self-explanatory. The “Integrated IS-IS Configuration Guide,” at Cisco.com,9 provides a detailed explanation of the fields in the show command output presented in these sections.

show clns protocol Command

The show clns protocol command lists the protocol-specific information for each IS-IS or ISO IGRP routing process in a router. Example 10-4 displays the show clns protocol command output for both routers depicted in Figure 10-15.

Example 10-4 show clns protocol Command Output

RT1#show clns protocol
IS-IS Router: <Null Tag>
System Id: 0000.0000.0001.00 IS-Type: level-1-2
Manual area address(es):
49.0001
Routing for area address(es):
49.0001
Interfaces supported by IS-IS:
Loopback0 - IP
Serial0/0 - IP
Redistributing:
static
Distance: 110
RRR level: none
Generate narrow metrics: level-1-2
Accept narrow metrics: level-1-2
Generate wide metrics: none
Accept wide metrics: none
_____________________________________________________________________________________
RT2#show clns protocol
IS-IS Router: <Null Tag>
System Id: 0000.0000.0002.00 IS-Type: level-1-2
Manual area address(es):
49.0002
Routing for area address(es):
49.0002
Interfaces supported by IS-IS:
Loopback0 - IP
Serial0/0 - IP
Redistributing:
static
Distance: 110
RRR level: none
Generate narrow metrics: level-1-2
Accept narrow metrics: level-1-2
Generate wide metrics: none
Accept wide metrics: none

show clns neighbors detail Command

The show clns neighbors detail command displays both end-system (ES) and intermediate-system (IS) neighbors. Example 10-5 displays the show clns neighbors detail command output for both routers depicted in Figure 10-15.

Example 10-5 show clns neighbors detail Command Output

RT1#show clns neighbors detail
System Id Interface SNPA State Holdtime Type Protoco
RT2 Se0/0 *HDLC* Up 27 L2 IS-IS
Area Address(es): 49.0002
IP Address(es): 192.168.1.2*
Uptime: 00:48:46
_____________________________________________________________________________________
RT2#show clns neighbors detail
System Id Interface SNPA State Holdtime Type Protocol
RT1 Se0/0 *HDLC* Up 26 L2 IS-IS
Area Address(es): 49.0001
IP Address(es): 192.168.1.1*
Uptime: 00:52:14

show clns interface Command

The show clns interface command lists the CLNS-specific or ES-IS information about each interface. Example 10-6 displays the show clns interface command output for both routers depicted in Figure 10-15.

Example 10-6 show clns interface Command Output

RT1#show clns interface ser 0/0
Serial0/0 is up, line protocol is up
Checksums enabled, MTU 1500, Encapsulation HDLC
ERPDUs enabled, min. interval 10 msec.
RDPDUs enabled, min. interval 100 msec., Addr Mask enabled
Congestion Experienced bit set at 4 packets
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 3 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x0, local circuit ID 0x100
Level-1 Metric: 10, Priority: 64, Circuit ID: RT1.00
Number of active level-1 adjacencies: 0
Level-2 Metric: 10, Priority: 64, Circuit ID: RT1.00
Number of active level-2 adjacencies: 1
Next IS-IS Hello in 8 seconds
_____________________________________________________________________________________
RT2#show clns interface serial0/0
Serial0/0 is up, line protocol is up
Checksums enabled, MTU 1500, Encapsulation HDLC
ERPDUs enabled, min. interval 10 msec.
RDPDUs enabled, min. interval 100 msec., Addr Mask enabled
Congestion Experienced bit set at 4 packets
CLNS fast switching enabled
CLNS SSE switching disabled
DEC compatibility mode OFF for this interface
Next ESH/ISH in 8 seconds
Routing Protocol: IS-IS
Circuit Type: level-1-2
Interface number 0x0, local circuit ID 0x100
Level-1 Metric: 10, Priority: 64, Circuit ID: RT2.00
Number of active level-1 adjacencies: 0
Level-2 Metric: 10, Priority: 64, Circuit ID: RT2.00
Number of active level-2 adjacencies: 1
Next IS-IS Hello in 2 seconds

show isis topology Command

The show isis topology command displays a list of all connected routers in all areas. Example 10-7 displays the show isis topology command output for both routers depicted in Figure 10-15.

Example 10-7 show isis topology Command Output

RT1#show isis top
IS-IS paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
RT1 --
IS-IS paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
RT1 --
RT2 10 RT2 Se0/0 *HDLC*
_____________________________________________________________________________________
RT2#show isis topology
IS-IS paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
RT2 --
IS-IS paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
RT1 10 RT1 Se0/0 *HDLC*
RT2 --

show isis database Command

The show isis database command displays the IS-IS link-state database. Example 10-8 displays the show isis database command output for both routers depicted in Figure 10-15.

Example 10-8 show isis database Command Output

RT1#show isis database
IS-IS Level-1 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 * 0x00000008 0x8B75 1126 1/0/0
RT1.01-00 * 0x00000001 0x459B 1131 0/0/0
IS-IS Level-2 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 * 0x0000008A 0x8FED 1126 0/0/0
RT2.00-00 0x0000001E 0xB82C 998 0/0/0
_____________________________________________________________________________________
RT2#show isis database
IS-IS Level-1 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT2.00-00 * 0x00000019 0x3DAB 883 1/0/0
RT2.01-00 * 0x0000000D 0x339F 980 0/0/0
IS-IS Level-2 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 0x0000008A 0x8FED 931 0/0/0
RT2.00-00 * 0x0000001E 0xB82C 808 0/0/0

Table 10-7 lists and explains the key fields in this command’s output.

ATM Configuration Examples

As an NBMA medium, ATM connectivity can be configured as multipoint on a router’s main interface or subinterfaces. Another configuration option is to use point-to-point connectivity on subinterfaces. Enabling IS-IS on ATM interfaces follows the same two steps for configuring IS-IS on point-to-point serial links:

Step 1. Configure the routing process.

Step 2. Apply IS-IS routing to relevant interfaces.

The multipoint configuration works in the same way as the simple broadcast LAN described previously. Similarly, operation of the point-to-point configuration is just like the serial point-to-point setup. The IS-IS configuration for Frame Relay is analogous to the ATM setup options shown in this section.

The large numbers of virtual circuits in NMBA clouds result in highly meshed point-to-point connections. Large meshes pose resource-related (memory and CPU) challenges to connected routers because of the high numbers of LSP required to be flooded and processed between the large number of connected neighbors (in the order of N3, where N is the number of nodes). It is strongly recommended that you use the IS-IS mesh group feature in highly meshed environ-ments to cut down on redundant flooding.

Figure 10-16 shows a network diagram illustrating a simple ATM configuration using point-to-point subinterfaces.

shows the configuration for RT5 and RT6 depicted in Figure 10-16.

Example 10-9 ATM Point-to-Point Configurations

hostname RT5
!
clns routing
!
interface ATM6/0.2 point-to-point
ip address 10.1.1.5 255.255.255.252
no ip directed-broadcast
ip router isis
atm pvc 2 0 10 aal5snap
!
router isis
net 49.0001.0000.0000.0005.00
is-type level-2-only
_____________________________________________________________________________________
hostname RT6
!
clns routing
!
interface ATM6/0.2 point-to-point
ip address 10.1.1.6 255.255.255.252
no ip directed-broadcast
ip router isis
atm pvc 2 0 10 aal5snap
!
router isis
net 49.0001.0000.0000.0006.00
is-type level-2-only
int atm 6/0.2 point
ip address . . .
ip router isis
pvc 0/10
encapsulation aal5snap

Figure 10-17 shows the network diagram for the ATM multipoint configurations presented in Example 10-10.

For multipoint configurations, the corresponding clns map statement is required, as shown in Example 10-10. In ATM, the clns map statements are placed under the ATM map list.

Example 10-10 ATM Point-to-Point Configurations

hostname RT7
!
clns routing
!
interface ATM6/0.1 multipoint
ip address 10.1.1.7 255.255.255.0
no ip directed-broadcast
ip router isis
atm pvc 1 0 8 aal5snap
map-group ISIS_CONFIG
!
router isis
net 49.0001.0000.0000.0007.00
is-type level-2-only
!
map-list ISIS_CONFIG
ip 10.1.1.8 atm-vc 1 broadcast
clns 49.0001.0000.0000.0008.00 atm-vc 1 broadcast
_____________________________________________________________________________________
hostname RT8
!
clns routing
!
interface ATM6/0.1 multipoint
ip address 10.1.1.8 255.255.255.0
no ip directed-broadcast
ip router isis
atm pvc 1 0 8 aal5snap
map-group ISIS_CONFIG
!
router isis
net 49.0001.0000.0000.0008.00
is-type level-2-only
!
map-list ISIS_CONFIG
ip 10.1.1.7 atm-vc 1 broadcast
clns 49.0001.0000.0000.0007.00 atm-vc 1 broadcast
Int atm 6/0
Pvc 0/5
Encapsulation qsaal

IP Default Route Advertisement

In IS-IS, Level 1 routers automatically install an IP default route to the nearest Level 1–2 routers in the area. The Level 1 routers detect the Level 2 routers by the attached (ATT) bit setting in the Level 1 LSPs issued by Level 1–2 routers. Level 1–2 routers generate Level 1 LSPs into their local area and set the ATT bit in these LSPs to flag their connectivity to the backbone.

On the other hand, a manual configuration is required to generate a default route into the Level 2 backbone. The router-level command default-information originate allows a Level 2 router to advertise a default route into the backbone, which will be seen by other Level 2 routers. The command causes a default route to be inserted into the Level 2 LSP of the advertising router. Unlike similar configurations in other IP routing protocols, an explicit static default route is not required to back up the default-information originate command. Figure 10-18 shows the network diagram for illustrating usage of the default information provided in Example 10-11.

Example 10-11 shows excerpts of the configuration file of a router with the default-information originate command enabled under the IS-IS routing process. Also shown is the Level 2 LSP featuring a default route entry with a metric of 0.

Example 10-11 Using the default-information originate Command

RT1#show running-config
[snip]
Hostname RT1
!
router isis
default-information originate
net 49.0001.0000.0000.0001.00
[snip]
_____________________________________________________________________________________
RT2#show isis database detail RT1.00-00 level-2
IS-IS Level-2 LSP RT1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 0x000000E1 0x7A1E 651 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: RT1
IP Address: 10.1.1.1
Metric: 10 IS RT1.01
Metric: 10 IS RT2.00
Metric: 0 IP 0.0.0.0 0.0.0.0
Metric: 10 IP 10.1.1.1 255.255.255.255
Metric: 10 IP 192.168.1.0 255.255.255.252

Route Redistribution

The IS-IS protocol considers all routes learned by a router from other sources, such as static routes, the Routing Information Protocol (RIP), and Open Shortest Path First (OSPF), as external routes. External routes can be introduced into the IS-IS environment by means of route redistribution. The procedure can also be used to advertise IS-IS routes into another routing protocol, such as OSPF. This section focuses on the former, redistributing routes into IS-IS.

RFC 1195 allows redistribution into only the Level 2 routing environment. For practical pur-poses, however, Cisco IOS Software allows redistribution into Level 1 as well. This cap-ability primarily was required by service providers who built single Level 1 IS-IS areas for their IGP infrastructures, to avoid suboptimal routing issues in hierarchical architectures in the absence of domain-wide prefix distribution. Having external IP reachability information in Level 1 LSPs should not pose any interoperability problems because IS-IS routers are not expected to parse any unknown TLVs in an IS-IS packet. They should just skip them to the next supported TLV.

The configuration and mechanisms underlying operation of route redistribution are elaborated in Example 10-12, which is based on Figure 10-19.

As in the case of other IP routing protocols, redistribution of IP static routes into IS-IS requires explicit configuration with the router-level command redistribute. The complete command for IS-IS is redistribute source ip options. Note that the ip keyword is required on the command line to specify that the operation is relevant to IP routing. You might recall that Integrated IS-IS supports both IP and CLNP routing.

Other configuration options of the redistribute command include a metric value, a metric type, a route map, and so on. The route map option provides a mechanism for filtering routes im-ported into the IS-IS environment.

By default, the metric type internal is assigned to external routes, and they are added into only the Level 2 environment if no level is specified. This is demonstrated in Example 10-12. The highlighted line in the show running-config output shows the redistribution command line in the configuration file. The highlighted line in the show isis database output shows an external route in an LSP. The last output in Example 10-12 shows a show ip route command output from Router RT2; the highlighted line is the external route that was originated from RT1.

Example 10-12 Configuring Basic Route Redistribution

RT1#show running-config
[snip]
router isis
redistribute static ip metric 0 metric-type internal level-2
default-information originate
net 49.0001.0000.0000.0001.00
_____________________________________________________________________________________
RT2#show isis database level-2 detail RT1.00-00
IS-IS Level-2 LSP RT1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 0x000000F3 0x04DF 956 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: RT1
IP Address: 10.1.1.1
Metric: 10 IS RT1.01
Metric: 10 IS RT2.00
Metric: 0 IP 0.0.0.0 0.0.0.0
Metric: 0 IP-External 10.4.4.0 255.255.255.0
Metric: 10 IP 10.1.1.1 255.255.255.255
Metric: 10 IP 192.168.1.0 255.255.255.252
RT2#show ip route
[snip]
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.2/32 is directly connected, Loopback0
i L2 10.4.4.0/24 [115/10] via 192.168.1.1, Serial0/0
i L2 10.1.1.1/32 [115/20] via 192.168.1.1, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial0/0
i*L2 0.0.0.0/0 [115/10] via 192.168.1.1, Serial0/0

In Example 10-13, the metric type explicitly is configured and specified to be external. Internal metrics are comparable to metrics used for internal routes; external metrics require the I/E bit of the metric field to be set, bumping up the value of the metric applied.

CAUTION

Cisco IOS Software sets bit 8 instead of bit 7 for the I/E bit when using narrow metrics, which results in an increase in the metric value by 128 instead of 64.

Example 10-13 Specifying External Metric Type in IS-IS Redistribution

RT1#show running-config
[snip]
router isis
redistribute static ip metric 0 metric-type external level-2
default-information originate
net 49.0001.0000.0000.0001.00
!
ip route 10.4.4.0 255.255.255.0 Null0
____________________________________________________________________________________
RT2#show isis data level-2 detail RT1.00-00
IS-IS Level-2 LSP RT1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 0x000000F1 0xA7BD 727 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: RT1
IP Address: 10.1.1.1
Metric: 10 IS RT1.01
Metric: 10 IS RT2.00
Metric: 0 IP 0.0.0.0 0.0.0.0
Metric: 128 IP-External 10.4.4.0 255.255.255.0
Metric: 10 IP 10.1.1.1 255.255.255.255
Metric: 10 IP 192.168.1.0 255.255.255.252
RT2#show ip route
[snip]
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.2/32 is directly connected, Loopback0
i L2 10.4.4.0/24 [115/138] via 192.168.1.1, Serial0/0
i L2 10.1.1.1/32 [115/20] via 192.168.1.1, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial0/0
i*L2 0.0.0.0/0 [115/10] via 192.168.1.1, Serial0/0

The highlighted line in Example 10-13 shows the redistribute command syntax with the metric type specified as external. The corresponding external entry is highlighted in the show isis database output with a metric of 128 instead of the 0 that was featured in Example 10-12. The external route advertised from RT1 is highlighted in the show ip route output of RT2 at the end of the example.

IP Route Summarization

An IS-IS router can be configured to summarize IP routes into Level 1, Level 2, or both with the following router-level configuration command:

summary-address prefix [level-1 | level-2 | level-1-2].

By default, summaries go into Level 2 if no level is specified on the command line. Example 10-14 displays a sample configuration and related show command outputs based on Figure 10-20. In the example provided, the IP subnet assigned to Ethernet0/0 of RT1, 11.1.1.0/24, is summarized as 11.0.0.0/8. The summary route 11.0.0.0/8 then is observed at RT2.

The highlighted line in the show running-config output provided in Example 10-14 shows the command line on RT1. The highlighted line in the show isis database output shows the summary entry in RT1’s LSP, and the highlighted line in the show ip route on RT2 shows evidence that the summary route has been propagated to other Level 2 routers.

Example 10-14 Route Summarization Configuration Example

RT1# show running-config
interface Ethernet0/0
ip address 11.1.1.1 255.255.255.0
ip router isis
!
interface Serial0/0
ip address 192.168.1.1 255.255.255.252
ip router isis
!
router isis
summary-address 11.0.0.0 255.0.0.0
redistribute static ip metric 0 metric-type internal level-2
default-information originate
net 49.0001.0000.0000.0001.0
_____________________________________________________________________________________
RT2#show isis data level-2 detail RT1.00-00
IS-IS Level-2 LSP RT1.00-00
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
RT1.00-00 0x000000F7 0xF8AA 518 0/0/0
Area Address: 49.0001
NLPID: 0xCC
Hostname: RT1
IP Address: 10.1.1.1
Metric: 10 IS RT1.02
Metric: 10 IS RT1.01
Metric: 10 IS RT2.00
Metric: 0 IP 0.0.0.0 0.0.0.0
Metric: 0 IP-External 10.4.4.0 255.255.255.0
Metric: 10 IP 10.1.1.1 255.255.255.255
Metric: 10 IP 192.168.1.0 255.255.255.252
Metric: 10 IP 11.0.0.0 255.0.0.0
RT2#show ip route
[snip]
Gateway of last resort is 192.168.1.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.2/32 is directly connected, Loopback0
i L2 10.4.4.0/24 [115/10] via 192.168.1.1, Serial0/0
i L2 10.1.1.1/32 [115/20] via 192.168.1.1, Serial0/0
i L2 11.0.0.0/8 [115/20] via 192.168.1.1, Serial0/0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Serial0/0
i*L2 0.0.0.0/0 [115/10] via 192.168.1.1, Serial0/0

• Troubleshooting IP Routing Protocols