- Overview of OSI Protocols and IS-IS Routing
- Operation of IS-IS for CLNS/CLNP
- IP and OSI Routing with Integrated IS-IS
- Basic Integrated IS-IS Router Configuration
- Modeling WAN Networks in Integrated IS-IS
- Summary
- Configuration Exercise: Configuring a Multiarea IS-IS Network
- Answers to Configuration Exercise: Configuring a Multiarea IS-IS Network
This chapter is from the book
This chapter is from the book
This chapter is from the book
Operation of IS-IS for CLNS/CLNP
This section describes the operation of IS-IS. As mentioned earlier, IS-IS is used for routing CLNS/CLNP data, while Integrated IS-IS is used for routing IP. Integrated IS-IS is described in the next section.
OSI Addressing
OSI network layer addressing is done through NSAP addresses that identify any system in the OSI network. These OSI addresses are often simply referred as NSAPs.
NOTE
A variety of NSAP formats are used for different systems, and each OSI routing protocol uses a different representation of NSAP. NSAPs usually are represented in hexadecimal format with a variable length of up to 40 hex digits. NSAPs also are used in ATM. Later in this section, you will see the format interpreted by Cisco IOS Software.
The LSPs, hello PDUs, and other routing PDUs are OSI-format PDUs; therefore, every IS-IS router requires an OSI address even if it is routing only IP. IS-IS uses the OSI address in the LSPs to identify the router, build the topology table, and build the underlying IS-IS routing tree.
The NSAPs contain the following:
The OSI address of the device
The link to the higher-layer process
NOTE
The NSAP address can be thought of as the equivalent of a combination of IP address and upper-layer protocol in an IP header.
Dijkstra's algorithm, which is used for both IS-IS and OSPF, requires a point-to-point connection between devices. OSPF uses the router ID to represent each router for this connection, while IS-IS uses the NET (a subset of the NSAP discussed in the following section).
NSAP Address Structure
Cisco routers can route CLNS data that uses addressing conforming to the ISO 10589 standard. The NSAP structure is illustrated in Figure S-6.
)
Figure S-6 Structure of NSAP Addresses
An OSI NSAP address can be up to 20 octets long and consists of the following parts, as shown in Figure S-6:
The authority and format ID (AFI) specifies the format of the address and the authority that assigned that address. The AFI is 1 byte.
The interdomain ID (IDI) identifies this domain. The IDI can be up to 10 bytes.
The AFI and IDI together make up the interdomain part (IDP) of the NSAP address. This can loosely be equated to an IP classful major network.
The high-order domain-specific part (DSP) (HODSP) is used for subdividing the domain into areas. This can be considered loosely as the OSI equivalent of a subnet in IP.
The system ID identifies an individual OSI device (an ES or an IS). In OSI, a device has an address, just as it does in the DECnet protocol. This is different from IP, in which an interface has an address. OSI does not specify a fixed length for the system ID, but it does specify that it be consistent for all devices. Cisco IOS Software fixes the system ID as the 6 bytes preceding the 1-byte NSAP selector (NSEL).
NOTE
A Media Access Control (MAC) address is often used for the system ID.
The NSEL (also known as the N-selector, the service identifier or the process ID) identifies a process on the device. It is a loose equivalent of a port or socket in IP. The NSEL is 1 byte long. It is not used in routing decisions. When the NSEL is set to 00, the address identifies the device itself—its network level address. In this case, the NSAP is known as a network entity title (NET).
The HODSP, system ID, and NSEL together make up the domain-specific part (DSP) of the NSAP address.
IS-IS Versus ISO-IGRP NSAPs
IS-IS and ISO-IGRP interpret NSAPs differently, as shown in Figure S-7.
)
Figure S-7 How IS-IS and ISO-IGRP Interpret NSAP Addresses
IS-IS uses a two-layer architecture, joining the IDP and HODSP fields and treating them as its area address (Level 2), with the remaining system ID used for Level 1 routing. When used with IS-IS, therefore, the NSAP is divided into three parts, as shown in Figure S-7: 1 octet for NSEL, 6 octets for the system ID, and from 1 to 13 octets for the area address or area ID field. An NSAP has a variable length of 8 to 20 octets. It is usually longer than 8 bytes to permit some granularity in the allocation of areas.
NOTE
Figure S-7 shows field length in bytes (or octets), where the NSAP address usually is represented in hexadecimal. NSAP addresses, like ATM addresses, are 160 bits long:
ISO-IGRP routes are based on a three-level architecture: domain (using the AFI and IDI fields for Level 3), area (using the HODSP field for Level 2), and system ID (for Level 1). What IS-IS treats simply as the area ID, ISO-IGRP splits into a domain and an area. ISO-IGRP sets the 2 bytes to the left of the system ID as the area ID or area address field, allowing for a theoretical 65,535 areas in an ISO-IGRP network. Everything else (a maximum of 11 bytes) is treated as a domain ID. Therefore, the minimum length for an ISO-IGRP NSAP is 10 bytes (1-byte NSEL, 6-byte system ID, 2-byte area, and minimum 1-byte domain).
ISO-IGRP sends routing information based on domain (variable length), area (length fixed by the protocol at 2 bytes), and finally system ID (fixed at 6 bytes). The NSEL is not used by ISO-IGRP.
Network Entity Title
As discussed earlier, if the NSEL field is 00, the NSAP refers to the device itself—that is, it is the equivalent of the Layer 3 OSI address of that device.
This address with the NSEL set to 00 is known as the NET. The NET is used by routers to identify themselves in the LSPs. Therefore, it forms the basis for the OSI routing calculation.
NET Is NSAP with NSEL = 00
A key point is that an NSAP address in which the NSEL is set to 00 is called the NET.
NETs and NSAPs are specified in all hexadecimal digits and must start and end on a byte boundary.
Official NSAP prefixes are required for CLNS routing. Addresses starting with the value of 49 (AFI = 49) are considered to be private addresses (analogous to RFC 1918 for IP addresses). These addresses are routed by IS-IS; however, this group of addresses should not be advertised to other CLNS networks.
Addresses starting with AFI values 39 and 47 represent the ISO data country code and ISO international code designator, respectively.
As shown in Figure S-7 and the examples in the next section, the Cisco IOS Software IS-IS routing process interprets the NSAP address as follows (from the right, or least-significant digit, end):
The last byte is the NSEL field and must be specified as a single byte, with two hex digits, preceded by a period (.). In a NET, this N-selector field is set to (00).
The preceding 6 bytes (this length is fixed by Cisco IOS Software) are the system ID. It is customary to use either a MAC address from the router or (for Integrated IS-IS) an IP address (for example, the IP address of a loopback interface) as part of the system ID.
The IS-IS routing process of Cisco IOS Software treats the rest of the address as the area ID, or area address, as follows:
It is 1 to 13 bytes long.
Using a 1-byte field for area limits the scope for area definitions. Thus, the customary area ID consists of 3 bytes, with an AFI of 1 byte and 2 additional bytes for the area ID. For example, in the address 49.0001.0000.0c12.3456.00, the AFI is 49 and the additional 2 bytes are 0001, for an effective area ID of 49.0001.
Cisco IOS Software attempts to summarize the area ID as much as possible. For example, if an IS-IS network is organized with major areas subdivided into minor areas, and this is reflected in the area ID assignments, then:
Between the minor areas, Cisco IOS Software will route based on the whole area ID.
Between the major areas, Cisco IOS Software will summarize the area ID portion up to the major area boundary.
NSAP Examples
The following examples illustrate how an NSAP address is interpreted by IS-IS and ISO-IGRP.
The NSAP 49.0001.aaaa.bbbb.cccc.00 consists of the following:
For IS-IS:
Area = 49.0001
System ID = aaaa.bbbb.cccc
N-selector = 00
For ISO-IGRP:
Domain = 49
Area = 0001
System ID = aaaa.bbbb.cccc
N-selector = ignored by ISO-IGRP
The NSAP 39.0f01.0002.0000.0c00.1111.00 consists of the following:
For IS-IS:
Area = 39.0f01.0002
System ID = 0000.0c00.1111
N-selector = 00
For ISO-IGRP:
Domain = 39.0f01
Area = 0002
System ID = 0000.0c00.1111
N-selector = ignored by ISO-IGRP
Identifying Systems in IS-IS
In IS-IS, the area ID is associated with the IS-IS routing process; a router can be a member of only one Level 2 area. Recall from earlier in the chapter that a router can belong to only one area. The area ID or area address uniquely identifies the routing area, and the system ID identifies each node.
Restrictions on Areas and System IDs
Restrictions on areas and system IDs are as follows:
All routers in an area must use the same area address. Indeed, the shared area address actually defines the area.
An ES might be adjacent to a Level 1 router only if they both share a common area address. In other words, ESs recognize only ISs (and ESs on the same subnetwork) that share the same area address.
Area routing (Level 1) is based on system IDs. Therefore, each device (ES and IS) must have a unique system ID within the area, and all system IDs must be the same length. Cisco mandates a 6-byte system ID.
All Level 2 ISs come to know about all other ISs in the Level 2 backbone. Therefore, they, too, must have unique system IDs within the area.
System IDs
The system ID must be unique inside an area. As noted earlier, it is customary to use either a MAC address from the router or (particularly for Integrated IS-IS) to code the IP address (for example, of a loopback interface) into the system ID.
It is generally recommended that the system IDs remain unique across the domain; that, way there can never be a conflict at Level 1 or Level 2 if a device is moved into a different area, for example.
All the system IDs in a domain must be of equal length. This is an OSI directive; Cisco enforces this by fixing the length of the system ID at 6 bytes in all cases.
Subnetwork Point of Attachment and Circuits
Two other terms used in IS-IS are subnetwork point of attachment (SNPA) and circuit.
An SNPA is the point at which subnetwork services are provided. This is similar to the Layer 2 address corresponding to the Layer 3 (NET or NSAP) address. The SNPA is usually taken from the following:
The MAC address on a LAN interface.
The virtual circuit ID for X.25 or ATM.
The data-link connection identifier (DLCI) for Frame Relay.
For High-Level Data Link Control (HDLC) interfaces, the SNPA is simply HDLC.
A link is the path between two neighbor ISs and is defined as being "up" when communication is possible between the two neighbors' SNPAs.
A circuit is an interface; interfaces are uniquely identified by a Circuit ID. The router assigns a one octet Circuit ID to each interface on the router, as follows:
In the case of point-to-point interfaces, this is the sole identifier for the circuit—for example, 03.
In the case of LAN interfaces (and other broadcast multi-access interfaces), this circuit ID is tagged to the end of the system ID of the DIS to form a 7-byte LAN ID. An example is 1921.6811.1001.03, where 03 is the circuit ID.
Example of NET Addresses in IS-IS Network
Figure S-8 shows examples of the NETs for routers in an IS-IS domain. Observe the following in Figure S-8:
The 6-byte system IDs are unique across the network.
The 3-byte area IDs are common to areas and distinct between areas.
The 1-byte N-selectors are set to 00, indicating that these are NETs.
)
Figure S-8 NSAP Addresses in an IS-IS Network
IS-IS PDUs
The OSI stack defines a unit of data as a protocol data unit (PDU). A frame therefore is regarded by OSI as a data-link PDU, and a packet (or datagram, in the IP world) is regarded as a network PDU.
Three types of PDUs (with 802.2 Logical Link Control encapsulation) are shown in Figure S-9. As the figure shows, the IS-IS and ES-IS PDUs are encapsulated directly in a data-link PDU (there is no CLNP header and no IP header), while true CLNP (data) packets contain a full CLNP header between the data-link header and any higher-layer CLNS information.
)
Figure S-9 OSI Protocol Data Units
IS-IS and ES-IS PDUs contain multiple sets of variable-length fields, depending on the function of the PDU. Each field contains a type code, a length, and then the appropriate values—hence the abbreviation TLV, for Type, Length, Value fields—as shown in Figure S-9.
Four general types of packets exist, and each type can be Level 1 or Level 2:
LSP—Used to distribute link-state information
Hello PDU (ESH, ISH, IS-IS Hello [IIH])—Used to establish and maintain adjacencies
Partial sequence number PDU (PSNP)—Used to acknowledge and request link-state information
Complete sequence number PDU (CSNP)—Used to distribute a router's complete link-state database
LSPs and hello PDUs are detailed in the following sections; the use of PSNP and CSNP is described in the section, "Link-State Database Synchronization."
Link State Packets
This section describes the IS-IS LSPs.
Network Representation
In OSI, there are two main types of physical links:
Broadcast—Multiaccess media types that support addresses referring to groups of attached systems and are typically LANs.
Nonbroadcast—Media types that must address ESs individually and that are typically WAN links. These include point-to-point links, multipoint links, and dynamically established links.
Consequently, IS-IS supports only two media representations for its link states:
Broadcast for LANs
Point-to-point for all other media
NOTE
IS-IS has no concept of an NBMA network. It is recommended that point-to-point links (for example, subinterfaces) be used instead of NBMA networks such as native ATM, Frame Relay, or X.25.
LSP Contents
In IS-IS, a router describes itself with an LSP. The router's LSP contains the following:
An LSP header, describing these items:
The PDU type and length
The LSP ID and sequence number
The remaining lifetime for this LSP (used to age out LSPs)
Type Length Value (TLV) variable-length fields:
The router's neighbor ISs (used to build the map of the network)
The router's neighbor ESs
Authentication information (used to secure routing updates)
Attached IP subnets (optional for Integrated IS-IS)
The LSP sequence numbers enable receiving routers to ensure that they use only the latest LSPs in their route calculations, thus avoiding duplicate LSPs being entered in the topology tables.
When a router reloads, the sequence number is set initially to 1. The router might then receive its own old LSPs back from its neighbors (which has the last good sequence number before the router reloaded). It records this number and reissues its own LSPs with the next-highest sequence number.
The Remaining Lifetime field in the LSP is used by the LSP aging process to ensure that outdated and invalid LSPs are removed from the topology table after a suitable period. The LSP remaining lifetime counts down from 1200 seconds (20 minutes) to 0.
NOTE
IS-IS uses an LSP refresh interval of 15 minutes, as specified by ISO 10589. Each IS-IS router that originates an LSP is responsible for updating its entries using this timer. The Remaining Lifetime timer is how long an LSP is kept as valid in an IS-IS LSP database.
LAN Representation
Dijkstra's algorithm, used for IS-IS, requires a virtual router (pseudonode) for broadcast media to build a weighted directed graph of the shortest paths from a single source vertex to all other vertices.
For this reason, the DIS is elected to generate an LSP representing a virtual router connecting all attached routers to a star-shape topology. The DIS is shown in Figure S-10. The decision process for the election of the DIS is based first on the router with the highest configured priority and second on the router with the highest MAC address.
)
Figure S-10 IS-IS Designated Intermediate System Is Elected to
Represent the LAN
In IS-IS, all routers on the LAN establish adjacencies with all other routers and with the DIS. Thus, if the DIS fails, another router can take over immediately with little or no impact on the topology of the network.
This is different from OSPF behavior. In OSPF, once the designated router (DR) and a backup DR (BDR) are elected, the other routers on the LAN establish adjacencies only with the DR and the BDR (the BDR is elected, and in the case of DR failure, is then promoted to the DR).
LSP Variables
IS-IS LSPs include specific information about the router's attachments. This information is included in multiple TLV fields in the main body of the LSP:
The links to neighbor routers (ISs), including the metrics of those interfaces
The links to neighbor ESs
NOTE
If Integrated IS-IS is operational, the attached IP subnets are described as ESs, using a special TLV specified for IP information.
The metrics of IS-IS links are associated with the outgoing interface toward the neighbor IS (router). Up to four metrics can be specified, as follows:
Default metric (required): cost—No automatic calculation of the metric for IS-IS takes place, compared to some routing protocols that calculate the link metric automatically based on bandwidth (OSPF) or bandwidth/delay (EIGRP). Using narrow metrics (the default), an interface cost is between 1 and 63 (a 6-bit metric value). All links use the metric of 10 by default. The total cost to a destination is the sum of the costs on all outgoing interfaces along a particular path from the source to the destination, and the least-cost paths are preferred.
Delay, expense, and error (optional)—These metrics are intended for use in type of service (ToS) routing. These could be used to calculate alternative routes referring to the DTR (delay, throughput, and reliability) bits in the IP ToS field.
Extended Metric
In IS-IS, using the old-style narrow cost metric discussed previously, the total path metric is limited to 1023 (the sum of all link metrics along a path between the calculating router and any other node or prefix). This small metric value proved insufficient for large networks and provided too little granularity for new features such as traffic engineering and other applications, especially with high-bandwidth links.
Cisco IOS Software addresses this issue with the support of a 24-bit metric field, the so-called wide metric. Using the new metric style, link metrics now have a maximum value of 16,777,215 (224–1) with a total path metric of 4,294,967,295 (232–1).
Running different metric styles within one network poses a serious problem: Link-state protocols calculate loop-free routes because all routers (within one area) calculate their routing tables based on the same link-state database. This principle is violated if some routers look at old-style (narrow) and some at new-style (wider) TLVs. However, if the same interface cost is used for both the old- and new-style metrics, the SPF computes a loop-free topology.
Hello Messages
IS-IS uses hello PDUs to establish adjacencies with other routers (ISs) and ESs. Hello PDUs carry information about the system, its parameters and capabilities.
IS-IS has three types of hello PDUs, as follows:
ESH, sent by an ES to an IS
ISH, sent by an IS to an ES
IIH, used between two ISs
The three types of hello PDUs are shown in Figure S-11.
)
Figure S-11 Three Types of IS-IS Hello PDUs
IS-IS Communication
ISs use IIHs to establish and maintain their neighbor relationships. When an adjacency is established, the ISs exchange link-state information using LSPs.
ISs also send out ISHs. ESs listen for these ISHs and randomly pick an IS (the one that sent the first ISH they hear) to forward all their packets to. Hence, OSI ESs require no configuration to forward packets to the rest of the network.
ISs (routers) listen to the ESHs and learn about all the ESs on a segment. ISs include this information in their LSPs.
For particular destinations, ISs might send redirect (RD) messages to ESs to provide them with an optimal route off the segment. This process is similar to IP Redirect.
Adjacencies
Separate adjacencies are established for Level 1 and Level 2. If two neighboring routers in the same area run both Level 1 and Level 2, they establish two adjacencies, one for each level. The Level 1 and Level 2 adjacencies are stored in separate Level 1 and Level 2 adjacency tables.
On LANs, the two adjacencies are established with specific Layer 1 and Layer 2 IIH PDUs. Routers on a LAN establish adjacencies with all other routers on the LAN and send LSPs to all routers on the LAN (unlike OSPF, in which routers establish adjacencies only with the designated router).
On point-to-point links, there is a common IIH format, part of which specifies whether the hello relates to Level 1, Level 2, or both.
By default, hello PDUs are sent every 10 seconds; the timeout to declare a neighbor down (that is, missing three hello packets) is 30 seconds. These timers are adjustable. (The commands to adjust the timers are not discussed in this book.)
LAN Adjacencies
IIH PDUs announce the area ID. Separate IIH packets announce the Level 1 and Level 2 neighbors. Adjacencies are established based on the area address announced in the incoming IIHs and the type of the router.
For example, in Figure S-12, routers from two different areas are connected to the same LAN. On this LAN, the following is true:
The routers from one area accept Level 1 IIH PDUs only from their own area and, therefore, establish adjacencies only with their own area routers.
The routers from a second area similarly accept Level 1 IIH PDUs only from their own area.
The Level 2 routers (or the Level 2 process within any Level 1–2 router) accept only Level 2 IIH PDUs and establish only Level 2 adjacencies.
)
Figure S-12 IS-IS Adjacencies Are Based on Area Address and Type of
Router
WAN Adjacencies
On point-to-point links (that is, on a WAN), the IIH PDUs are common to both Level 1 and Level 2 but announce the level type and the area ID in the hellos. This is illustrated in Figure S-13.
)
Figure S-13 On a WAN, Area Address and Router Type Are Announced in a
Common IIH PDU
As shown in Figure S-13, the following is true:
Level 1 routers in the same area (which includes links between Level 1–only and Level 1–2 routers) exchange IIH PDUs specifying Level 1 and establish a Level 1 adjacency.
Level 2 routers (in the same area or between areas, and including links between Level 2–only and Level 1–2 routers) exchange IIH PDUs specifying Level 2 and establish a Level 2 adjacency.
Two Level 1–2 routers in the same area establish both Level 1 and Level 2 adjacencies, and maintain these with a common IIH PDU specifying both the Level 1 and Level 2 information.
Two Level 1–2 routers in different areas establish only a Level 2 adjacency.
Two Level 1 routers that might be physically connected but are not in the same area (including a Level 1–only to a Level 1–2 router in a different Level 1 area) exchange Level 1 IIH PDUs but ignore these because the area IDs do not match. Therefore, they do not establish adjacency.
Level 2 Adjacencies
Figure S-14 shows examples of the following:
Level 1–only routers establishing Level 1 adjacencies
Level 2 routers establishing only Level 2 adjacencies (between areas)
Level 1–2 routers establishing both Level 1 and Level 2 adjacencies with their Level 1–2 neighbors in the same area
)
Figure S-14 Level 2 Adjacencies Must Be Continuous
NOTE
In OSPF, there is a backbone area; here there is a backbone path. The path of connected Level 2 routers is called the backbone. All individual areas and the backbone must be contiguous. Level 2 adjacency exists independent of the area and must be contiguous. In the example in Figure S-14, the backbone is maintained by routers B, C, D, G, and H. A backbone is a set of contiguous Level 1–2 and Level 2 routers.
Link-State Database Synchronization
IS-IS link-state database synchronization is accomplished using special PDUs: PSNPs and CSNPs. These special PDUs bear the generic name of sequence number PDUs (SNPs),
SNPs (PSNPs and CSNPs) ensure that LSPs are sent reliably. SNPs contain LSP descriptors—not the actual, detailed LSP information, but headers describing the LSPs.
PSNPs usually contain only one LSP descriptor block. They are used as follows:
To acknowledge receipt of an LSP
To request a complete LSP for an entry missing in the originating router's topology database
CSNPs are a list of the LSPs held by a router.
CSNPs are sent periodically on LANs. Receiving routers can compare the list of LSPs in the CSNP with their link-state database and request (with a PSNP) any missing LSPs.
CSNPs are sent on point-to-point links when the link comes active. In Cisco IOS Software, periodic CSNPs can be configured on point-to-point links.
Figure S-15 shows an example of link-state database synchronization on a point-to-point link. In this figure, the following is true:
A link fails.
The R2 router notices this failure and issues a new LSP noting the change.
The R1 router receives the LSP, stores it in its topology table, and sends a PSNP back to R2 to acknowledge receipt of the LSP.
)
Figure S-15 Link-State Database Synchronization on a Point-to-Point
Link
On a LAN, the DIS periodically (every 10 seconds) sends CSNPs listing the LSPs that it holds in its link-state database. This is multicast to all IS-IS routers on the LAN.
Figure S-16 shows an example of link-state database synchronization on a LAN. In the example, the R2 router is the DIS. R2 sends a CSNP. The R1 router compares this list of LSPs with its topology table and realizes that it is missing one LSP. Therefore, it sends a PSNP to the DIS (R2) to request the missing LSP. The DIS reissues that LSP, and the R1 router acknowledges it with a PSNP (these last two steps are not shown in this figure but are similar to those in Figure S-15).
)
Figure S-16 Link-State Database Synchronization on a LAN