Integrated IS-IS Routing Protocol Concepts

A span of interconnected routers operated and managed by the same administrative group is referred to as an autonomous system of routers or a routing domain. Such a system of routers allows forwarding of data traffic from one location to the other. The current IS-IS specification, ISO 10589, refers to network nodes as intermediate systems, but this book uses the equivalent terminology of routers more frequently because it is more popular in current networking literature.

Individual routing domains are interconnected to form larger networks, such as the Internet, allowing transfer of data from one routing domain to the other over a large geographic span. Routers use routing protocols to learn about various locations within local or remote network domains. The two basic types of routing protocols follow:

• Interior Gateway Protocols (IGPs)—Optimized only for operation within a single network domain. IGPs are also known as intradomain routing protocols.

• Exterior Gateway Protocols (EGPs)—Optimized for exchange of routing information between domains. EGPs are also referred to as interdomain routing protocols.

IS-IS is designed and optimized to provide IGP functionality. The Border Gateway Protocol (BGP) is a well-known routing protocol with extensive capabilities for interdomain routing.

Typically, routing protocols support only one network layer protocol (Layer 3 in the OSI reference model). Therefore, when you use routers to provide connectivity for multiple Layer 3 protocols concurrently, they are usually configured with different routing protocols for each type of Layer 3 protocol supported. This approach is referred to as ships in the night.

As mentioned in the preceding chapter, Integrated IS-IS supports two network layer protocols: ISO CLNP and IP. Another routing protocol, which supports multiple Layer 3 protocols, is the Cisco proprietary Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP can be used to route IP, the Internet Packet Exchange Protocol (IPX), and AppleTalk all at the same time. Popular routing protocols that support only one network layer protocol include the NetWare Link Services Protocol (NLSP), which is based on the IS-IS protocol and supports only IPX; the Open Shortest Path First (OSPF) Protocol supports only IP. Versions 1 and 2 of the Routing Information Protocol (RIP) are also IP-only routing protocols. IS-IS and OSPF are similar in many regards and are the two most popular IGPs that are widely deployed in Internet service provider, IP-based enterprise networks.

IS-IS Routing Domain

An IS-IS routing domain is a network in which all the routers run the Integrated IS-IS routing protocol to support intradomain exchange of routing information. The network environment can be IP-only, ISO CLNP-only, or both. The IS-IS protocol was originally intended to support only CLNP. RFC 1195 adapts the original IS-IS specification (ISO 10589) to support IP, in what is referred to as Integrated IS-IS. The following implementation requirements are specified by RFC 1195:

• Pure IP domains route only IP traffic but support forwarding and processing of OSI packets required for IS-IS operation.

• Pure ISO domains carry only ISO traffic including those required for IS-IS operation.

• A dual domain routes both IP and OSI CLNP traffic simultaneously.

It is also possible to design a dual domain so that some areas route IP only, whereas others route CLNP only, and yet others route both IP and CLNP. RFC 1195 imposes restrictions on the manner in which IP and CLNP can be mixed within an area. The underlying goal is to achieve consistent routing information within an area by having identical Level 1 link-state databases on all routers in that area. Hence, all routers in an area are required to be configured in the same way, either for IP-only or CLNP-only or both. To clarify further, a router is not allowed to have a set of links dedicated to IP only and another set to CLNP and yet another set to both protocols. At the domain level, there is no restriction on mixing areas that are uniformly IP-only with other areas that are uniformly CLNP-only or uniformly configured for both IP and CLNP. In order words, all links in an area must be configured the same way, but links in the backbone can have the attached routers configured differently.

IS-IS Areas and Routing Hierarchies

As specified in ISO 10589 and RFC 1195, the IS-IS protocol supports a two-level hierarchy for managing and scaling routing in large networks. A network domain can be carved out in a planned way or arbitrarily by the network designer or architect into small segments known as areas. This allows hierarchical routing to be leveraged for efficient routing within the domain. Integrated IS-IS uses the legacy CLNP node-based addresses to identify routers even in pure IP environments. The CLNP addresses, which are known as Network Service Access Points (NSAPs), are made up of three components: an area identifier (area ID) prefix, followed by a system identifier (SysID), and an N-selector. The N-selector refers to the network service user, such as a transport protocol or the routing layer. It has similar interpretation as the application port number used in the IP Transmission Control Protocol (TCP). The CLNP addressing scheme is introduced later in this chapter (see the section "Addressing Concepts in Integrated IS-IS") and discussed further in detail in Chapter 4, "Addressing in Integrated IS-IS."

For now, just remember that each IS-IS router has a unique SysID, which together with the area ID and an N-selector value of 0x00 forms a special NSAP known as the node's network entity title (NET).

A group of routers belong to the same area if they share a common area ID. Note that all routers in an IS- IS domain must be associated with a single physical area, which is determined by the area ID in the NSAP. In practice, an IS-IS router can be configured with multiple NSAPs all with different area IDs and same SysID in situations where the router is "homed" to multiple areas. As discussed later, however, multihoming merges all the areas involved into a single physical area. Routers belonging to a common area and engaged in Level 1 routing are referred to as Level 1 routers. In CLNP routing, Level 1 routing involves collecting SysID and adjacency information through all routers and hosts in the local area. Routers in different areas exchange routing information through Level 2 routing and are referred to as Level 2 or backbone routers. In CLNP Level 2 routing, routers exchange area prefix information with their peers. For IP routing, however, intra-area IP prefixes are exchanged within the area in Level 1 routing. The IP prefixes originated in the various areas are then exchanged between areas in Level 2 routing by routers connected to the backbone.

In most designs with routing hierarchy, the Level 2 routers are also Level 1 routers by virtue of their identification with a certain area. Therefore, in IS-IS, a router can function as Level 1-only or Level 2-only and possibly as both Level 1 and Level 2 (Level 1-2). Level 1-2 routers act as border routers to their respective areas, providing connectivity to other areas. The Level 2 backbone is essentially a virtual IS-IS area consisting of routers engaged in Level 2 routing (see Figure 3-1). The Level 2 stretch in a network must be contiguous, requiring all routers to be interconnected. Because partition repair is not supported in Cisco IOS and most other implementations, the contiguity requirement also applies to Level 1 areas. In a hierarchical network, some Level 2-only routers could be embedded in the backbone without impacting traffic flow between the respective areas supported by Level 1-2 routers. Existing IS-IS specfications require only Level 2 routers to provide connectivity to external domains; however, Cisco IOS allows redistribution of external routes into Level 1 for historical and practical reasons.

Figure 3-1 IS-IS areas.

Level 1-only routers are aware of the local area topology only, which involves all the nodes in the area and the next-hop routers to reach them. Level 1 routers depend on Level 2 routers for access to other areas and forward all traffic to destinations outside the area to the closest Level 2 router.

Cisco routers running IS-IS can be configured to be either Level 1-only, Level 2-only, or both. By default, they are both Level 1 and Level 2, and special configuration is required to disable Level 1 or Level 2 capability. Caution must be exercised when disabling either capability because this might introduce disruptive inconsistencies into the routing environment. In Figure 3-1, routers RTA-1, RTA-2, RTA-3, and RTX must be Level 2-capable to participate in routing between the areas. RTX can be in its own dedicated area and because it doesn't connect to any Level 1 routers, it can be configured to be Level 2-only. However, the others must be Level 1-2 and each identified with a specific area for which it provides interarea connectivity. RTB-n, RTC-n (n = 1,2,3) can be configured to be Level 1-only if they don't need to connect to the backbone.

IS-IS Packets

Before delving into other concepts behind the IS-IS protocol, you need to understand the fundamentals of IS-IS packets and packet formats. This knowledge aids in the understanding of the capabilities of the protocol and how it works. Connectionless protocols, such as CLNP and IP, transmit data in little chunks known as packets. In ISO 10589, packets are referred to as protocol data units (PDU). This book refers to them as packets in conformity with IP terminology. Multiple packet types are used in connectionless environments, with data and routing information packets being predominant.

This section briefly reviews the types of packets used in the IS-IS protocol and their general format. IS-IS packets have three categories: hello packets, link-state packets, and sequence number packets. Hello packets are used to establish and maintain adjacencies between IS-IS neighbors. Link-state packets are used to distribute routing information between IS-IS nodes. Sequence number packets are used to control distribution of link-state packets, essentially providing mechanisms for synchronization of the distributed Link-State databases on the routers in an IS-IS routing area.

Hello packets have the following subcategories:

• LAN Level 1 hello packets (PDU Type 15)

• LAN Level 2 hello packets (PDU Type 16)

• Point-to-point hello packets (PDU Type 17)

Link-state packets have the following subcategories:

• Level 1 link-state packets (PDU Type 18)

• Level-2 link-state packets (PDU Type 20)

Finally, sequence number packets have the following subcategories:

• Level 1 complete sequence number packets (PDU Type 24)

• Level 2 complete sequence number packets (PDU Type 25)

• Level 1 partial sequence number packets (PDU Type 26)

• Level 2 partial sequence number packets (PDU Type 27)

IS-IS Packet Formats

Each type of IS-IS packet is made up of a header and a number of optional variable-length fields containing specific routing-related information. Each variable-length field has a 1-byte type label that describes the information it contains. The value of the variable-length field is the specific information it contains. Typically, the value is composed of repeated blocks of similar information, the length of which is specified in a 1-byte length field. Type, length, and value form a tuple (TLV), which has become a synonym for variable-length fields. The types of variable-length fields are actually specified as numeric code values. Both current IS-IS specifications, ISO 10589 and RFC 1195, use code in rather than type, but TLV has gained more popularity than CLV in current networking literature because it is used in other protocol specifications.

The different types of IS-IS packets have a slightly different composition of the header fields but the first eight fields, each 1-byte long, are repeated in all packets (see Figure 3-2). Each type of packet then has its own set of additional header fields, which are then followed by TLVs. The additional header fields vary in composition, length, and order of the information. Figure 3-2 shows the generic packet format and the common fields shared by all IS-IS packets.

Figure 3-2 IS-IS header fields.

• Intradomain Routing Protocol Discriminator—This is the network layer identifier assigned to IS-IS, as specified by ISO 9577. Its value is 10000011 (binary), 0x83 (hexadecimal), or 131 (decimal).

• Length Indicator—Length of the packet header fields in octets.

• Version/Protocol ID Extension—Currently has a value of 1.

• ID Length—Indicates length of the source ID (SysID) field. A value of 0 implies a length of 6 bytes; a value of 255 implies 0 length. Other possible values are 1 to 8 for actual length in bytes.

• PDU Type—Specifies the type of IS-IS packet. The three types of IS-IS packets are hello packets, link-state packets (LSPs), and sequence number packets (SNPs).

• Version—The value is 1.

• Reserved—Unused bits. Set to 0s.

• Maximum Area Addresses—Values between 1 and 254 for actual number. A value of 0 implies a maximum of three addresses per area.

The Type, Length, and Value attributes of TLV fields have the following meaning:

• Type—A number code for a specific TLV. ISO10589 uses the word code in place of type. However, type seems to be preferred in IETF and Cisco literature on IS-IS.

• Length—Length specifies the total length of the TLV.

• Value—Value indicates the content of the TLV.

All packets in each category of packet type have similar information in the header. The TLV fields are appended to the header to make up the entire packet. Each type of packet supports only specific TLV fields, which might optionally be present in a real packet. This topic is explored further later in this chapter.

Table 3-1 lists TLVs specified in ISO 10589.

Table 3-1 ISO 10589 TLVs

Enhancements to the original IS-IS protocol as specified in IS0 10589 are normally achieved through the introduction of new TLV fields. Enhancements, attained in this manner include TLVs introduced by RF1195 for Integrated IS-IS and recent modifications to support Multiprotocol Label Switching (MPLS) Traffic Engineering. Table 3-2 lists the TLVs introduced by RFC 1195. Note that a key strength of the IS-IS protocol design lies in the ease of extension through the introduction of new TLVs rather than new packet types.

Table 3-2 RFC 1195 TLVs

IS-IS Protocol Functions

The routing layer functions provided by the IS-IS protocol can be grouped into two main categories: subnetwork-dependent functions and subnetwork-independent functions. In IS-IS, subnetwork refers to the data-link layer. This notion fundamentally differs from IP terminology, in which a subnetwork refers to an IP address subnet. Only two types of IS-IS subnetworks are of practical significance in current applications of the IS-IS protocol: point-to-point and broadcast links.

The subnetwork-dependent functions relate to capabilities for interfacing with the data-link layer and primarily involve operations for detecting, forming, and maintaining routing adjacencies with neighboring routers over various types of interconnecting network media or links. The ES-IS protocol and certain elements of CLNP are key to the operation of the subnetwork-dependent functions.

Subsequent sections explore the subnetwork-dependent functions. In those sections, you will learn about IS-IS links, IS-IS adjacencies, and types of IS-IS systems (nodes).

The subnetwork-independent functions provide the capabilities for exchange and processing of routing information and related control information between adjacent routers as validated by the subnetwork-dependent functions.

The IS-IS routing engine, discussed later in this section, elaborates on the relationship between subsystems (processes and databases) that provide the subnetwork-independent functions within the framework of a conventional router.

Subnetwork-Dependent Functions

The role of the subnetwork-dependent functions of the IS-IS protocol was described in the previous section. Critical component functions are further described within this section. The IS-IS routing protocol distinguishes two main types of subnetworks or links in a network: general topology subnetworks and broadcast subnetworks.

General Topology Subnetworks

General topology subnetworks are permanent or dynamically established point-to-point links. An example of the former is Packet over SONET/SDH. Asynchronous Transfer Mode (ATM) point-to-point switched virtual circuit (SVC) is an example of the latter.

Broadcast Subnetworks

Broadcast subnetworks are multipoint or local-area network (LAN) media with broadcast capabilities, such as Ethernet, Fiber Distributed Data Interface (FDDI), or the Cisco-invented Dynamic Packet Transport Technology (DPT).

IS-IS Network Nodes

The ISO Connectionless Network Protocol is specified for transfer of data between two main categories of network devices:

• End systems—The analogy for an end system is a workstation or network host with limited routing capability.

• Intermediate systems—These are network devices such as routers with extensive packet-forwarding capabilities. The word intermediate refers to the capabilities of routers as intermediate forwarding or relay devices. Routers are referred to as gateways in some older networking literature.

The IS-IS routing protocol is designed to provide routing intelligence for intermediate systems, whose role in the network is to relay data between user applications running on distantly located end systems. IS-IS allows the gathering and processing of routing information by routers within the same domain. Routers can locate end systems on directly connected segments using ES-IS for CLNP or ARP for IP. Therefore, the combination of ES-IS and IS-IS or ARP allows routers to perform their primary function of helping move data packets from one end system to another within the network domain.

Adjacencies

The subnetwork-dependent functions of the routing layer provided by IS-IS are responsible for discovering, establishing, and maintaining adjacencies between the routers in an IS-IS domain. As stated previously, IS-IS works in conjunction with ES-IS and certain elements of the CLNP protocol to achieve this. No special configuration is required on Cisco routers to enable ES-IS. The ES-IS operation is enabled automatically when IS-IS is configured on Cisco routers, and it runs as a background process to support the operation of IS-IS. The subnetwork-dependent functions of IS-IS work with ES-IS to determine network layer addresses of all adjacent neighbors (both end systems and routers). On multiaccess links, data-link addresses (for example, MAC addresses; also referred to as subnetwork points of attachment [SNPAs]) are obtained for all adjacent neighbors and stored in the adjacency database.

ES-IS Adjacencies

ES-IS is designed for host-to-router communication in a pure ISO environment, such as implemented in Digital's DECnet Phase V networking architecture. In an IP environment, ES-IS is relevant only to the extent that it facilitates router-to-router adjacency formation. IP hosts do not participate in the ES-IS protocol and instead rely on ARP for Layer 3-to-Layer 2 address resolution in determining the Layer 2 addresses of LAN-connected hosts and the IP default gateway. In CLNP environments, end systems and routers use the ES-IS protocol to discover each other by sending ESHs and ISHs to well-known LAN broadcast addresses. End systems send ESHs targeted at the routers to 09-00-2B-00-00-05 (AllIntermediateSystems), and routers send the ISHs to 09-00-2B-00-00-04 (AllEndSystems). ES-IS allows end systems to locate the closest router for access to other nondirectly connected media. Routers, in turn, learn about the location of end systems through the ES-IS adjacency information. Routers also distribute the SysID of known end systems to other routers within the same area by means of Level 1 IS-IS routing. Other ES-IS events, such as redirection, are beyond the scope of this book.

Figure 3-3 End System Hello (ESH) and Intermediate System Hello (ISH).

IS-IS Adjacencies

Directly connected routers enabled for IS-IS routing go beyond the ES-IS adjacencies described in the preceding section to form IS-IS adjacencies. The IS-IS adjacencies on point-to-point links are formed and maintained a little differently than on broadcast links. Consequently, different types of IS-IS hellos (IIHs) are used. The three types of IIHs follow:

• Point-to-point IIH—Used over point-to-point links

• Level 1 LAN IIH—Used over broadcast links, but for Leve1 1 adjacencies

• Level 2 LAN IIH—Used on broadcast links, but for Level 2 adjacencies

Like all IS-IS packets, the IS-IS hello packets are made up of headers and variable-length fields. The point-to-point IIHs and LAN IIHs have slightly varied information in their header area. Mostly, however, similar information is contained in the header area of both packet types except that point-to-point IIHs have a local circuit ID in place of the LAN ID in LAN IIHs. Also, point-to-point IIHs do not have the priority information found in LAN IIHs. As specified in ISO 10589, TLV types used in point-to-point IIHs are limited to the following:

• Area Addresses (Type 1)

• Padding (Type 8)

• Authentication Type (Type 10)

LAN IIHs support the following TLVs fields:

• Area Addresses (Type 1)

• Intermediate System Neighbors (Type 6)

• Padding (Type 8)

• Authentication Information (Type 10)

  NOTE

  The absence of information on intermediate system neighbors in point-to-point IIHs as specified in the original hello format caused reliability issues in forming point-to-point adjacencies. A recent IEFT draft proposes TLV Type 240 to address this problem. This draft is discussed later in this chapter.

Successful formation of an IS-IS adjacency between two nodes paves the way for the exchange of IS-IS routing information by using special routing information and control packets known as link-state packets (LSP) and sequence number packets (SNP), respectively. LSP and SNP exchange between IS-IS routers is discussed in-depth in Chapter 5, "IS-IS Link-State Database." The type of adjacency formed between neighbor routers determines the type of routing information that is exchanged between them. As mentioned previously, IS-IS routing has a two-level hierarchy, Level 1 and Level 2, and the types of adjacencies that can be formed are consistent with this hierarchy. As specified, routers in the same area must be able to form at least a Level 1 adjacency, regardless of the type of interconnecting links (point-to-point or broadcast). On Cisco routers, the default mode of operation for routers in the same area, is to form both Level 1 and Level 2 adjacencies. Routers that belong to different areas can form only Level 2 adjacencies. Point-to-point and broadcast adjacencies are further covered in detail in later sections of this chapter.

Hello Interval, Hello Multiplier, and Hello Holdtime

Routers periodically send hello packets to adjacent peers, every hello interval. The hello interval is jittered, up to about 25 percent, to reduce the likeliness of synchronized IIH transmission over the network. On Cisco routers, the default value of the hello interval is 10 seconds for ordinary routers and 3.3 seconds for the designated intermediate system (DIS) on a multiaccess link. IS-IS uses the concept of hello multiplier to determine how many hello packets can be missed from an adjacent neighbor before declaring it "dead." The maximum time lapse allowed between receipt of two consecutive hello packets received is referred to as the holdtime. The holdtime is defined as the product of the hello interval and the hello multiplier. On Cisco routers, the default value of the hello multiplier is 3; therefore, the default hold time is 30 seconds. If a router does not receive a hello from a neighbor before the holdtime expires, the adjacency is torn down. The holdtime is reset anytime a hello is received. Hellos are transmitted periodically by routers to neighbors at the expiration of the hello interval. However, the following conditions will also trigger immediate transmission:

IS-IS Point-to-Point Adjacencies

IS-IS adjacencies on point-to-point links are initialized by receipt of ISHs through the ES-IS protocol. This is followed by the exchange of point-to-point IIHs. The type of adjacency formed will depend on the parameters exchanged in the IIHs. The IIHs also are sent periodically over the link to every hello interval to maintain the adjacency. On Cisco routers, the default hello interval for point-to-point links is 10 seconds. The format of the point-to-point hello packet is shown in Figure 3-4.

Figure 3-4 Point-to-Point Hello Packet (PDU Type 17).

A router performs checks on a received IIH to confirm various parameters in the hello header, such as SysID length, Maximum Area Addresses, and so on. System capabilities are advertised in the appended TLVs. The TLV fields that might be appended to the point-to-point hello packet are Area Addresses (Type 1), Padding (Type 8), and Authentication (Type 10) information. Padding is applied in increments of 2 bytes up to at least 1 byte short of the physical MTU of the outgoing interface.

The following is a list of packet type-specific fields in the header of a point-to-point hello:

• Circuit Type—Level 1, Level 1-2, or Level 2 only

• Source ID—System ID of the router that generated the hello packet

• Holding Time—Maximum interval between two consecutive hello packets before the router is considered no longer available

• PDU Length—Length of the entire PDU, including header

• Local Circuit ID—Unique link identifier

• TLV Fields—Variable-length fields

When an ISH is received on a newly enabled point-to-point link, the router verifies whether an adjacency already exists with the sender by checking the source SysID in the ISH against its adjacency database. The ISH is ignored if an adjacency exists. If not, the receiving router creates a new adjacency and sets its state to "initializing" and the system type to "unknown." The router then sends the new neighbor an IIH in response. Upon receiving a subsequent IIH from the new neighbor, the router then moves the adjacency to an up state and changes the neighbor's system type to IS. In this process, the local router is unable to determine whether its hellos are reaching the remote end.

As specified in ISO 10589, point-to-point hellos do not include the IS Neighbors TLVs (Type 6); therefore, it is impossible to use a three-way process to confirm whether hellos generated locally are reaching neighbors. This might lead to situations where one end of an adjacency is up but the other end is not. An Internet draft submitted to the IETF proposes a more reliable way to form point-to-point IS-IS adjacencies—by using a three-way handshake process, which is backward-compatible to the ISO 10589 procedure.

In the default mode of operation, IIHs are padded to the MTU size of the outgoing interface. Routers match the size of IIHs received to their local MTUs to ensure that they can handle the largest possible packets from their neighbors before completing an adjacency.

When a router sends out a hello packet, it sets the Circuit Type field in the header to Level 1 only, Level 2 only, or Level 1-2, depending on its configuration, either globally by IS type or on an interface level by circuit type. The default IS type on a Cisco router is to be both a Level 1 and Level 2, but this can be modified to be Level 1 only or Level 2 only. Cisco routers also allow the circuit type of a link to be modified individually and independent of the global IS type. A router assigns a locally unique link identifier to each point-to-point link by using the 8-bit Local Circuit ID field in the hello header. The 8-bit field allows up to 256 unique point-to-point links only to be defined in an IS-IS router. Efforts in the IETF's IS-IS Working Group to remove this limitation is discussed in a later section.

One of the key requirements of IS-IS is that the length of the SysID must be consistent on all routers across the domain. Consequently, if the ID Length field of the hello packet (which indicates the length of the SysID) is set to a different value from what is expected, the receiving router discards the IIH. On Cisco routers, the length of the SysID is fixed at 6 bytes. A value of 0 in the ID field of an IIH indicates support for a 6-byte SysID. This means that all nodes interoperating with Cisco routers in an IS-IS network need to set the value of the ID field to 0, to indicate they also support 6-byte SysIDs. Details of the CLNS addressing scheme used in IS-IS is covered in Chapter 4, "Addressing in Integrated IS-IS."

The maximum number of area addresses supported in a single router configuration must match between adjacent neighbors as well, unless the verifying router supports only a maximum value of 3. By default, Cisco routers support a maximum of three area addresses. This can be changed to 255 in recent IOS releases. Any disagreement in the maximum number of supported areas causes the IIH to be discarded; otherwise, it is accepted for further processing. As previously noted, adjacency information such as SNPAs and corresponding SysIDs are obtained from the ISHs that are exchanged through the ES-IS protocol. A key role of IIHs, however, is to help establish the type of the adjacency to be formed. The receiving router determines the type of adjacency to be formed with the remote router from the IS type and the Area ID advertised in the received hello. Thus, in determining the type of adjacency, a router considers all the addresses defined in the Area Address TLVs present in the IIH received. Because they belong to different areas, two routers with nonmatching Area IDs can form only a Level 2 adjacency. If two connected Cisco routers match in Area IDs, they'll form both Level 1 and Level 2 adjacencies according to default behavior.

If authentication is configured, the router appends an Authentication TLV field (Type 10) to the hello packet, which is then checked by the receiving node. ISO 10589 and RFC 1195 specify use of clear-text, simple passwords only. Currently, Cisco routers do not support any other more sophisticated authentication methods. More sophisticated authentication using MD5 message digest might be supported in the future.

If any of the adjacency checks previously described fails, a router will not bring up the new adjacency or will tear down an existing adjacency. When a router tears down an adjacency, it generates a notification message and removes the corresponding entry from its adjacency database. In case of a link failure, the IS-IS process reacts as soon as it obtains appropriate notification from the interface subsystem, by removing any adjacencies associated with the affected interface. The router then generates and floods an updated LSP reflecting the change to other neighbors.

Forming a Reliable Point-to-Point Adjacency

The three-way handshake process for reliably forming point-to-point adjacencies introduces a new type length value field (Type 240), known as Point-to-Point Adjacency State TLV. For backward compatibility, older systems running IS-IS implementations that do not support TLV Type 240 can ignore it, if encountered in an IIH, and follow conventional procedures for forming the adjacency. This is necessary so that newer and older systems can coexist in the same network. The three-way handshake requires a conforming system to move the state of the point-to-point adjacency to up only after confirming that there is bidirectional communication with the remote router and that its hellos are reaching the remote end. Compliant routers include the SysIDs of neighbors from which they have received hellos in TLV 240. A router knows its hellos are reaching a point-to-point neighbor when it receives a hello from that neighbor in which it is listed in this TLV. The TLV Type 240 consists of the following information:

This TLV enhances the IS-IS point-to-point adjacency formation process in two ways. First, a node can confirm three-way communication with its neighbor by confirming the presence of its SysID in a TLV 240 attached to hellos received from the neighbor. The local adjacency state can then be adjusted based on the existing state and the state featured in the Value field of TLV 240 from the hello received. Second, the Extended Local Circuit ID field in TLV 240 can be leveraged to provide unique link IDs for point-to-point links beyond the 256 limit specified in ISO 10589.

IS-IS Adjacencies over Multiaccess Media

The method specified in ISO 10589 for building adjacencies over broadcast media, such as LANs, differs slightly from that used on point-to-point links. Some of the significant differences are as follows:

• The process is not triggered by receipt of ISHs. A router sends IIHs on broadcast interfaces as soon as the interface is enabled.

• The broadcast medium is modeled as a node, called the pseudonode. The pseudonode role is played by an elected DIS.

• Depending on the configuration, nodes on the LAN broadcast their hellos to well-known Level 1 and Level 2 broadcast MAC addresses.

• Two-way communication is confirmed between adjacent nodes by using a three-way handshake procedure made possible by the presence of an IS Neighbors field in the LAN (Level 1 or Level 2) hello packets. The reliable point-to-point adjacency formation introduced by TLV Type 240 is similar to this process.

Details of the process for forming LAN adjacencies is discussed later in this chapter. For now, however, take a look at the format of the LAN hello packets, which is the same for both Level 1 and Level 2.

Figure 3-5 IS-IS LAN Hello (PDU Types 15, 16).

The packet type–specific fields for IS-IS LAN hellos are as follows:

• Circuit Type—Tells whether this circuit is Level 1-only, Level 2-only, or both.

• Source ID—The SysID of the originator.

• Holding Time—Tells how long to wait for hellos from this router before declaring it dead and removing its adjacency.

• PDU Length—Length of the entire PDU, fixed header, and TLVs.

• Priority—This 7-bit value designates the priority to be the DIS (Level 1 or Level 2) on the LAN.

• LAN ID—SysID of the DIS plus an octet-long unique ID for this router assigned by the DIS.

The differences between LAN Level 1 and LAN Level 2 hellos is only in the interpretation of the values in the fields and the broadcast addresses to which they are transmitted. The MAC-level broadcast addresses are as follows:

• 01-80-C2-00-00-15 for Level 2 adjacencies (AllL2ISs)

• 01-80-C2-00-00-14 for Level 1 adjacencies (AllL1ISs)

The IS-IS PDU types for LAN Level 1 and Level 2 packets are 15 and 16, respectively. Example 3-1 shows a sample trace capture of a LAN Level 1 hello frame. The example displays a source address of 0x00D058F78941 and a destination or destination address of 0x0180C2000014. The target address is the AllL1IS address.

Example 3-1 Trace of IS-IS LAN Level 1 Hello

DLC: ----- DLC Header -----
   DLC: 
   DLC: Frame 1 arrived at 19:03:01.2025; frame size is 1514 (05EA hex) bytes.
   DLC: Destination = Multicast 0180C2000014
   DLC: Source   = Station 00D058F78941
   DLC: 802.3 length = 1500
   DLC: 
LLC: ----- LLC Header -----
   LLC: 
   LLC: DSAP Address = FE, DSAP IG Bit = 00 (Individual Address)
   LLC: SSAP Address = FE, SSAP CR Bit = 00 (Command)
   LLC: Unnumbered frame: UI

The following TLVs fields can be found in LAN hello packets:

• Area Addresses (Type 1)—Contains area addresses configured on the router

• IS Neighbors (Type 6)—MAC addresses (SNPAs) of Level 1 (Level 2) neighbors that IIHs received from over the LAN interface in an initializing or up state

• Padding (Type 8)—Used to make hello as large as MTU (or at least MTU - 1 octets)

• Authentication (Type 10)—Password information

Forming LAN Adjacencies

When a LAN interface is enabled for IS-IS routing, the router immediately sends out IIH packets with a locally defined LAN ID, consisting of its own SysID and a unique local circuit ID. It also begins to listen to ESHs, ISHs, and IIHs to discover any connected adjacencies. It subsequently runs the DIS election process, depending on its configuration, to determine whether it is eligible to be a Level 1 or Level 2 DIS on the LAN.

The manner in which a router processes received IIHs depends on its configuration (IS type and circuit type). As in the case of point-to-point links, all IIHs received are checked for configuration conformity and authentication. The ID Length and Maximum Area Addresses fields in the received IIHs must match local values, and authentication passwords must be confirmed before the adjacency is further processed. Examples of additional information contained in hello packets are the neighbor's SysID, holding timer (holdtime), Level 1 or Level 2 priority, and configured area addresses.

A Level 1 adjacency is formed when the area addresses match unless configured otherwise. A Level 2 adjacency is formed alongside the Level 1 unless the router is configured to be Level 1-only. If no matching areas exist between the configuration of the local router and the area addresses information in the received hello, only a Level 2 adjacency is formed. If the transmitting router is configured for Level 2-only, the receiving router must be capable of forming a Level 2 adjacency; otherwise, no adjacency forms.

When a router receives a hello packet, it checks for an existing adjacency with the transmitter. If an adjacency is known, it resets the holdtime to the value in the hello received. If the neighbor is not known, the receiving router creates one, indicating the type of adjacency (Level 1 or Level 2) and sets its state to initializing until subsequent received hello packets confirm two-way communication. Routers include the MAC addresses of all neighbors on the LAN that they have received hellos from, allowing for a simple mechanism to confirm two-way communication. Two-way communication is confirmed when subsequent hellos received contain the receiving router's MAC address (SNPA) in an IS Neighbors TLV field. Otherwise, communication between the nodes is deemed one-way, and the adjacency stays at the initialized state. An adjacency must be in and up state for a router to send or process received LSPs.

Pseudonodes

As discussed in the preceding section, all IS-IS routers connected over a common LAN multicast hellos to well-known addresses, thereby forming adjacencies with each other.

After adjacency is determined, link-state information is exchanged (also referred to as LSP flooding). LSP flooding is the essence of dynamic routing information exchange between IS-IS routers. The two key requirements for LSP flooding are as follows:

• Accuracy of information and timeliness of the updates

• Minimum bandwidth usage and low processing overhead

Accuracy and timeliness imply spontaneous and frequent updates. This contradicts the need to conserve network resources, as stipulated by the requirement for minimum bandwidth usage and low processing overhead. This section focuses on the adjacency formation process and network resource management on multiaccess media.

To minimize the complexity of managing multiple adjacencies on multiaccess media, such as LANs, while enforcing efficient LSP flooding to minimize bandwidth consumption, IS-IS models multiaccess links as nodes, referred to as pseudonodes (see Figure 3-6). As the name implies, this is a virtual node, whose role is played by an elected DIS for the LAN. Separate DISs are elected for Level 1 and Level 2 routing. In the election process, only routers with adjacencies in an up state are considered. Election of the DIS is based on the highest interface priority, with the highest SNPA address (MAC address) breaking ties. The default interface priority on Cisco routers is 64.

Despite the critical role of the DIS in LSP flooding, no backup DIS is elected for either Level 1 or Level 2. Fortunately, this doesn't turn out to be a contentious problem because of the frequency of periodic database synchronization that occurs on broadcast links. If the current DIS fails, another router is immediately elected to play the role. As mentioned previously, the DIS transmits hello packets three times faster than the interval for other routers on the LAN. The default hello interval for the DIS is 3.3 seconds rather than the 10 seconds specified for other nodes. This allows for quick detection of DIS failure and immediate replacement.

Figure 3-6 LAN Pseudonode.

As previously expressed, periodic database synchronization on broadcast links allows preemption of the existing DIS without significant disruption of IS-IS operation on such media. This implies that an elected router is not guaranteed to remain the DIS if a new router with a higher priority shows up on the LAN. Any eligible router at the time of connecting to the LAN immediately takes over the DIS role, assuming the pseudonode functionality. No mechanism is specified for making a router ineligible to be the DIS. However, this is achievable, to some extent, by configuring a router's LAN interface with the lowest priority value relative to the priorities of other nodes on the LAN.

The IS-IS specification (ISO 10589) defines three types of designated intermediate systems, as follows:

• LAN Level 1 DIS
• LAN Level 2 DIS
• Partition-designated Level 2 IS

Election of partition-designated Level 2 ISs is specified in ISO 10589 to provide a means for repairing partitioned Level 1 areas in an IS-IS domain. An IS-IS virtual link is established over the Level 2 backbone between partition-designated Level 2 routers, which are elected from among the Level 2 routers in the partitions. Intra-area traffic is then forwarded between the partitions over the virtual link. IS-IS partition repair is not supported on Cisco routers and, therefore, is not discussed further in this book.

The responsibilities of LAN Level 1 and Level 2 DISs include the following:

• Generating pseudonode link-state packets to report links to all systems on the broadcast subnetwork

• Carrying out flooding over the LAN for the corresponding routing level

The newly elected or resigning DIS is also responsible for purging the old pseudonode LSP from the network. A DIS might resign when preempted or when disconnected from the link either by an interface shutdown or the disabling of the IS-IS process. Because of its critical role, detection of DIS failure is expedited using a shorter hello interval, which is 3.3 seconds rather than the 10 seconds used for ordinary nodes.

The IS-IS Routing Engine

Figure 3-7 shows the IS-IS routing engine, which is adapted from the more elaborate representation of the processes that work together to provide the complex of subnetwork-independent functions defined in ISO 10589. This simplified representation shows only the relevant dependencies between various processes of the IS-IS protocol within the framework of a conventional router's forwarding architecture. The receiving and forwarding processes specified in ISO 10589 are not necessarily applicable to an IP router and are therefore not discussed. Identical but separate routing engine architecture is maintained for each of the two levels of routing.

IP routers using Integrated IS-IS as the routing protocol conform to requirements for IP packet handling as specified by RFC 1812 (Requirements for Internet Gateways). Such IP routers must handle the ISO packets relevant to the operation of IS-IS and also must support other IP router functionality, such as Internet Message Protocol (ICMP) and Address Resolution Protocol (ARP).

Figure 3-7 IS-IS routing engine.

The Routing Information Base

The Routing Information Base is composed of two databases that are central to the operation of IS-IS: the Link-State database and the Forwarding database. The Link-State database is fed with routing information by the update process.

The Update Process

The update process generates local link-state information, based on the adjacency database built by the subnetwork-dependent functions, which the router advertises to all its neighbors in link-state packets. A router also receives similar link-state information from every adjacent neighbor, keeps copies of LSPs received, and re-advertises them to other neighbors. Routers in an area maintain identical Level 1 Link-State databases, which are synchronized using SNPs. This means that routers in an area will have identical views of the area topology, which is necessary for routing consistency within the area. A Level 2 Link-State database contains area prefix information that ties all the areas together for inter-area (Level 2) routing.

The Decision Process

The decision process creates the Forwarding database by running the shortest path first (SPF) algorithm (also referred to as the Dijkstra algorithm) on the Link-State database. A router runs separate SPF processes for Level 1 and Level 2.

Routing Table

The IS-IS Forwarding database, which is made up of only best IS-IS routes, is fed into the Routing Information Base (RIB), essentially the IP routing table of a router to be used in packet-switching decisions. When multiple sources exist for routing information in a router, such as static routes and BGP, a Cisco router uses the concept of administrative distances to prefer one routing source to the others. The protocol with the lowest administrative distance wins. (Table 3-3 lists administrative distances for various routing protocols.) The accepted best route is then installed in the routing table. Routing table information might be processed further into the fast-switching cache or the Cisco Express Forwarding (CEF) Forwarding Information Base (FIB) to speed up switching packets through the router. Typically, IS-IS is used in conjunction with BGP for routing IP packets. BGP brings in external routes, whereas IS-IS, as an IGP, is responsible for internal routes (mostly next-hop information for the BGP routes). Consequently, little overlap occurs in routing information obtained from either source, allowing IS-IS and BGP routes to coexist in the routing table.

Table 3-3 Administrative Distances of Routing Protocols

Route Protocol	Administrative Distance
RIP v1 and v2	120
IGRP	100
EIGRP Internal	90
EIGRP External	170
OSPF	110
Integrated ISIS	115
BGP Internal	20
BGP External	200
Static to Next Hop	1
Static to Interface	1
Connected	0




Addressing Concepts in Integrated IS-IS

This section is a short prelude to Chapter 4, "Addressing in Integrated IS-IS," introducing only the key concepts for addressing in the IS-IS environment.

As a protocol originally designed for routing CLNP packets, IS-IS used the node-based addressing scheme of CLNP as its basic addressing premise. Integrated IS-IS, which can be used for routing IP packets, inherits many concepts from the original specification, including the CLNS addressing scheme for identifying network nodes. Therefore, it is a fundamental requirement that even when Integrated IS-IS is used in an IP-only environment, the nodes must have ISO NSAP addresses (referred to as NETs). However, IP requires the links to be addressed with IP subnets. Fortunately, the format for CLNS addresses used on IP routers is simple; most people can deal with the two addressing schemes and solve the single issue of routing IP.

Chapter 4 reviews CLNS addressing and provides practical examples of how they are used on IP routing. IP addressing on the links conforms to basic IP addressing principles and has no relationship with the CLNS addressing scheme. The latter exists solely for use by the IS-IS protocol.

As Integrated IS-IS for IP routing is enabled on the interfaces, the IP subnets are automatically added to the router's LSP by using the IP reachability and related TLVs introduced by RFC 1195. The IP prefixes are then assembled into an IP Link-State database, which is the fed to SPF algorithm to determine the best routes.

Security

IS-IS enforces basic security through packet authentication by using special TLVs. ISO 10589 specifies TLV Type 10, which can be present in all IS-IS packet types. RFC 1195 also specifies TLV Type 133 for authentication, which removes password length restrictions imposed by ISO 10589. Both specifications define only simple passwords transmitted as clear text without encryption.

Simple, clear-text password authentication obviously does not provide enough protection against malicious attacks on the network, even though it can help isolate operator configuration errors related to adjacency setups. TLV Types 10 and 133 both provide accommodation for future TLV field types, which might permit more complex and secured authentication using schemes such as HMAC-MD5. An IETF draft proposal specifies this approach for improved and sophisticated authentication of IS-IS packets.

Only the simple passwords specified in ISO 10589 are supported in available (at the time of writing) Cisco IOS releases.

A unique security advantage of IS-IS compared to other IP routing protocols is that IS-IS packets are directly encapsulated over the data link and are not carried in IP packets or even CLNP packets. Therefore, to maliciously disrupt the IS-IS routing environment, an attacker has to be physically attached to a router in the IS-IS network, a challenging and inconvenient task for most network hackers. Other IP routing protocols, such as RIP, OSPF, and BGP, are susceptible to attacks from remote IP networks through the Internet because routing protocol packets are ultimately embedded in IP packets, which makes them susceptible to remote access by intrusive applications.

Summary

This chapter reviews the basic concepts underlying the design of the IS-IS routing protocol. The chapter also discusses the two-level hierarchy for controlling distribution of routing information within IS-IS areas and between them: Level 1 and Level 2, respectively. You learned that technically all IS-IS routers belong to one physical Level 1 area because of the node-based addressing scheme of CLNP. The related issue of suboptimal interarea routing resulting from the architecture proposed in ISO 10589 and adopted by RFC 1195 is discussed in detail in Chapter 7, "General Network Design Issues." Chapter 7 also discusses workarounds and IS-IS protocol enhancements that address this major limitation of the original IS-IS protocol architecture.

Other characteristics of the IS-IS protocol discussed in this chapter include functional organization into subnetwork-dependent and subnetwork-independent capabilities, IS-IS packet formats, addressing, and security.

Tied into the subnetwork-dependent capabilities are processes that relate to adjacency discovery, formation, and maintenance. On broadcast links, management of the potentially complex database synchronization process between the many possible adjacent routers is achieved by the election of the designated IS to provide the pseudonode functionality.

The section on IS-IS packet formats elaborated on the basic building blocks—namely, the header and the TLV fields. It was noted that a key strength of the IS-IS protocol is the simplicity by which it can be extended through the introduction of new TLVs without major changes to the protocol architecture. Perhaps the most confusing aspect of IS-IS is the need to deal with two addressing schemes when using it for routing IP. Because Integrated IS-IS adapts the original IS-IS to carry IP information, most of the original architecture (including node addressing) is ported. Integrated IS-IS supports dual-mode operation, in which both IP and CLNP packets are routed essentially by the same IS-IS process. The next chapter covers CLNP addressing and helps alleviate some of the challenges in dealing with this dichotomy.

Like most protocols, security is a concern for IS-IS even though neither ISO 10589 nor RFC 1195 specified any strong authentication schemes for dealing with malicious attacks within an internetworking environment. The simple, clear-text passwords specified provide a useful way to control network misconfiguration and to implement configuration policies.

An IETF draft specification (IS-IS HMAC-MD5 Authentication) proposes more secured authentication of IS-IS packets by using HMAC-MD5 authentication schemes.

References

draft-ietf-isis-3way-02.txt: Three-way Handshake for IS-IS Point-to-Point Adjacencies

draft-ieft-isis-hmac-01.txt: IS-IS HMAC-MD5 Authentication

ISO 9542, "End System to Intermediate System Routing Exchange Protocol." For use in conjunction with ISO 8473. Also published as RFC 995.

ISO/8473/Add.3 Protocol for providing the connectionless-mode network service-Addendum 3: Provision of the underlying service assumed by the ISO 8473 over subnetworks, which provide the OSI data link service.