Operation of Integrated IS-IS
| The ISO often uses different terms than the IETF to describe the same entities, a fact that can sometimes cause confusion. ISO terms are introduced and defined in this section, but in most cases the more familiar IETF terminology used throughout the rest of this book is used in this chapter. [7] Some ISO terms are so fundamental that they should be discussed before getting into any specifics of the IS-IS protocol.
Figure 10.1. Hosts are End Systems in ISO terminology, and routers are Intermediate Systems. A router is an Intermediate System (IS), and a host is an End System (ES). Accordingly, a protocol that provides communication between a host and a router is known as ES-IS, and a protocol that routers use to speak to each other (a routing protocol) is IS-IS (Figure 10.1). Whereas IP uses router discovery mechanisms, such as Proxy ARP or IRDP, or simply has a default gateway configured on hosts, CLNP uses ES-IS to form adjacencies between End Systems and Intermediate Systems. ES-IS has no relevance to IS-IS for IP and is not covered in this book. Note ES-IS Note SNPA An interface attached to a subnetwork is a Subnetwork Point of Attach ment (SNPA). An SNPA is somewhat conceptual because it actually defines the point at which subnetwork services are provided, rather than an actual physical interface. The conceptual nature of SNPAs fits with the conceptual nature of subnetworks themselves , which can consist of multiple data links connected by data link switches. Note PDU A data unit passed from an OSI layer of one node to the peer OSI layer of another node is called a Protocol Data Unit (PDU). So a frame is a Data Link PDU (DLPDU), and a packet is a Network PDU (NPDU). The data unit that performs the equivalent function of the OSPF LSA is the Link State PDU (LSP). [8] Unlike LSAs, which are encapsulated behind an OSPF header and then an IP packet, an LSP is itself a packet.
IS-IS AreasAlthough both IS-IS and OSPF use areas to create a two-level hierarchical topology, a fundamental difference exists in the way in which the two protocols define their areas. OSPF area borders are marked by routers, as shown in Figure 10.2. Some interfaces are in one area, and other interfaces are in another area. When an OSPF router has interfaces in more than one area, it is an Area Border Router (ABR). Figure 10.2. OSPF area borders fall within routers, and the routers that connect the areas are ABRs. Note Level 1 and level 2 routers Figure 10.3 shows the same topology as shown in Figure 10.2 but with IS-IS areas. Notice that all the routers are completely within an area, and the area borders are on links, not on routers. The routers that connect the areas are level 2 routers, and routers that have no direct connectivity to another area are level 1 routers. Figure 10.3. IS-IS areas fall on links, and the routers that connect the areas are level 2 routers. An intermediate system can be a level 1 (L1) router, a level 2 (L2) router, or both (L1/L2). L1 routers are analogous to OSPF nonbackbone Internal Routers, L2 routers are analogous to OSPF backbone routers, and L1/L2 routers are analogous to OSPF ABRs. In Figure 10.3, the L1/L2 routers are connected to L1 routers and to L2 routers. These L1/L2 routers must maintain both a level 1 link state database and a level 2 link state database, in much the same way that an OSPF ABR must maintain a separate database for each area to which it is attached. The set of L2 routers (including L1/L2 routers) and their interconnecting links is the IS-IS backbone; as with OSPF, inter-area traffic must traverse this backbone. Every level 1 router within an area (including the area's L1/L2 routers) maintains an identical link state database. Unlike OSPF ABRs, L1/L2 routers do not advertise L2 routes to L1 routers. Therefore, an L1 router has no knowledge of destinations outside of its own area. In this sense, an L1 router is similar to a router in an OSPF totally stubby area. To route a packet to another area, an L1 router must forward the packet to an L1/L2 router. When an L1/L2 router sends its level 1 LSP into an area, it signals other L1 routers that it can reach another area by setting a bit known as the Attached (ATT) bit in the LSP. [9]
Recall from Chapter 9, "Open Shortest Path First," that OSPF runs its SPF algorithm to compute routes within an area, but that inter-area routes are computed using a distance vector algorithm. This situation is not true of IS-IS. L1/L2 routers, maintaining separate level 1 and level 2 link state databases, will calculate separate SPF trees for the level 1 and level 2 topology. ISO 10589 describes a procedure by which IS-IS routers can create virtual links to repair partitioned areas, just as OSPF can. This feature is not supported by Cisco or by most other router vendors and is not further described here. Because an IS-IS router resides completely within a single area, the Area ID (or area address) is associated with the entire router rather than an interface. A unique feature of IS-IS is that a router can have up to three area addresses, which can be useful during area transitions. A configuration case study later in this chapter, "An Area Migration," demonstrates the use of multiple area addresses. Each IS-IS router must also have a way to uniquely identify itself within the routing domain. This identification is the function of the System ID , which is analogous to the OSPF Router ID. Both the Area ID and the System ID are defined on an IS-IS router by a single address, the Network Entity Title (NET). Note Area ID Note SystemID Network Entity TitlesEven when IS-IS is used to route only TCP/IP, IS-IS is still an ISO CLNP protocol. Consequently, the packets by which IS-IS communicates with its peers are CLNS PDUs, which in turn means that even in an IP-only environment, an IS-IS router must have an ISO address. The ISO address is a network address, known as Network Entity Title (NET), described in ISO 8348. [10] The length of a NET can range from 8 to 20 octets; the NET describes both the Area ID and the System ID of a device, as shown in Figure 10.4.
Figure 10.4. The NET specifies the Area ID and the System ID of an IS or ES. The ISO designed the NET to be many things to many systems, and depending upon your viewpoint, the address format is either extremely flexible and scalable or it is a cumbersome muddle of variable fields. Figure 10.5 shows just three of the many forms an ISO NET can take. Although the fields preceding the System ID are different in each example, the System ID itself is the same. ISO 10589 specifies that the field can be from one to eight octets in length, but that the System ID of all nodes within the routing domain must use the same length. Most commonly, the length is six octets [11] and is usually the Media Access Control (MAC) identifier of an interface on the device. The System ID must be unique for each node within the routing domain.
Figure 10.5. Three NET formats: A simple eight-octet Area ID/System ID format (a); an OSI NSAP format (b); and a GOSIP NSAP format [12] (c).
Also of interest in the examples of Figure 10.5 is the NSAP Selector (SEL). In each case, this one-octet field is set to 0x00. A Network Service Access Point (NSAP) describes an attachment to a particular service at the network layer of a node. So when the SEL is set to something other than 0x00 in an ISO address the address is an NSAP address. This situation is similar to the combination of IP destination address and IP protocol number in an IP packet, which addresses a particular service at the network layer of a particular device's TCP/IP stack. When the SEL is set to 0x00 in an ISO address, the address is a NET, the address of a node's network layer itself. As the variety of formats in Figure 10.5 implies, a detailed discussion of the configuration of NETs is beyond the scope of this book. A good reference for further study is RFC 1237. [13] In most cases, Integrated IS-IS will be run in a dual CLNP/IP environment, and the NET will be assigned based on the CLNP requirements. In an IP-only environment, the NET might be assigned based on a standard such as GOSIP. If you are free to choose any NET for an IP-only environment, choose the simplest format that will serve the needs of your internetwork.
Regardless of the format, the following three rules apply:
IS-IS Functional OrganizationOne of the primary reasons for having a layered network architecture like the OSI model is so that the functions of each layer are independent from the layer below. The network layer, for example, must adapt to many types of data links, or subnetworks. To further this adaptability, the network layer consists of two sublayers (Figure 10.6). The Subnet work Independent sublayer provides consistent, uniform network services to the transport layer. The Subnetwork Dependent sublayer accesses the services of the data link layer on behalf of the Subnetwork Independent sublayer. As the two names imply, the Subnetwork Dependent sublayer depends upon a specific type of data link, so that the subnetwork independent sublayer can be independent of the data link. Figure 10.6. The OSI network layer consists of two sublayers. The organization of the network layer, specified in ISO 8648, [14] is actually more complex than that shown in Figure 10.6. The two basic sublayers are introduced here because ISO 10589 presents much of its description of the operation of IS-IS within the framework of the functions of these sublayers.
Subnetwork Dependent FunctionsThe subnetwork dependent functions are, of course, the functions of the subnetwork dependent sublayer. Their job is to hide the characteristics of different kinds of data links (subnetworks) from the functions of the subnetwork independent sublayer. The following subnetwork dependent functions are important to routing:
In contrast to the four network types defined by OSPF, IS-IS defines only two: broadcast subnetworks and point-to-point or general topology subnetworks. Broadcast subnetworks are defined the same as they are under OSPF ”multi-access data links that support multicasting. Point-to-point (nonbroadcast) subnetworks can be permanent, such as a T1 link, or dynamically established, such as X.25 SVCs. Note IS-IS network types Neighbors and AdjacenciesIS-IS routers discover neighbors and form adjacencies by exchanging IS-IS Hello PDUs. Hellos are transmitted every 10 seconds, and on Cisco routers this interval can be changed on a per interface basis with the command isis hello-interval . Although IS-IS Hellos are slightly different for broadcast and point-to-point subnetworks, the Hellos include the same essential information, described in the section "IS-IS PDU Formats." An IS-IS router uses its Hello PDUs to identify itself and its capabilities and to describe the parameters of the interface on which the Hellos are sent. If two neighbors are in agreement about their respective capabilities and interface parameters, they become adjacent. IS-IS forms separate adjacencies for level 1 and level 2 neighbors. L1 routers form L1 adjacencies with L1 and L1/L2 neighbors, and L2 routers form L2 adjacencies with L2 and L1/L2 neighbors. Neighboring L1/L2 routers form both an L1 adjacency and an L2 adjacency. An L1 router and an L2 router will not establish an adjacency . Once an adjacency is established, the Hellos act as keepalives . Each router sends a hold time in its Hellos, informing its neighbors how long they should wait to hear the next Hello before declaring the router dead. The default hold time on Cisco routers is three times the Hello interval and can be changed on a per interface basis with the command isis hello- multiplier . The IS-IS neighbor table can be observed with the command show clns is-neighbors (Figure 10.7). The first four columns of the display show the System ID of each neighbor, the interface on which the neighbor is located, the state of the adjacency, and the adjacency type. The state will be either Init, indicating that the neighbor is known, but is not adjacent, or Up, indicating that the neighbor is adjacent. The priority is the router priority used for electing a Designated Router on a broadcast network, as described in the next section. Figure 10.7. The command show clns is-neighbors displays the IS-IS neighbor table. Note Circuit ID, LAN ID, and Pseudonode ID The sixth column shows the Circuit ID , a one-octet number that the router uses to uniquely identify the IS-IS interface. If the interface is attached to a broadcast multiaccess network, the Circuit ID is concatenated with the System ID of the network's Designated Router, and the complete number is known as the LAN ID . In this usage, the Circuit ID is more correctly called the Pseudonode ID . For example, in Figure 10.7 the LAN ID of the link attached to interface E0 is 0000.0c76.5b7c.02. The System ID of the Designated Router is 0000.0c76.5b7c, and the Pseudonode ID is 02. The last column indicates the format of the adjacency. For Integrated IS-IS the format will always be Phase V, indicating OSI/DECnet Phase V. The only other adjacency format is DECnet Phase IV. Designated RoutersIS-IS elects a Designated Router (or more officially, a Designated IS) on broadcast multi-access networks for the same reason OSPF does. Rather than having each router connected to the LAN advertise an adjacency with every other router on the network, the network itself is considered a router ”a pseudonode. Each router, including the Designated Router, advertises a single link to the pseudonode. The DR also advertises, as the representative of the pseudonode, a link to all of the attached routers. Unlike OSPF, however, an IS-IS router attached to a broadcast multi-access network establishes adjacencies with all of its neighbors on the network, not just the DR. Each router multicasts its LSPs to all of its neighbors, and the DR uses a system of PDUs called Sequence Number PDUs (SNPs) to ensure that the flooding of LSPs is reliable. The reliable flooding process, and SNPs, are described in a later section, "The Update Process." The IS-IS Designated Router election process is quite simple. Every IS-IS router interface is assigned both an L1 priority and an L2 priority in the range of 0 to 127. Cisco router interfaces have a default priority of 64 for both levels, and this value can be changed with the command isis priority . The router advertises its priority in the Hellos sent from each interface ”the L1 priority is advertised in L1 Hellos, and the L2 priority is advertised in L2 Hellos. If the priority is 0, the router is ineligible to become the DR. Interfaces to nonbroadcast networks, on which a DR is not elected, also have a priority of 0 (notice the priority of the serial interface in Figure 10.7). The router with the highest priority becomes the DR. In a tie, the router with the numerically highest System ID becomes the DR. As the L1 and L2 priorities suggest, separate DRs are elected on a network for level 1 and level 2. This outcome is necessary because of the separate L1 and L2 adjacencies that can exist on a single LAN, as shown in Figure 10.8. Because an interface can have separate priorities for each level, the L1 DR and the L2 DR on a LAN might or might not be the same router. Figure 10.8. Separate adjacencies are established for level 1 and for level 2, so separate DRs must be elected for level 1 and level 2. The DR assigns the LAN ID to the network. As discussed in the preceding section, the LAN ID is a concatenation of the DR's System ID and its Pseudonode ID for the attached network. All other routers on the network will use the LAN ID assigned by the DR. Figure 10.9 shows the neighbor table of a router whose E0 interface is attached to the same network as the E0 interface of the router of Figure 10.7. By comparing these two tables, you can see that three routers are attached to the Ethernet: 0000.0c0a.2aa9, 0000.0c0a.2c51, and 0000.0c76.5b7c. All have a priority of 64, so the one with the numerically highest System ID is the DR. That router, 0000.0c76.5b7c, identifies the network with Circuit ID 02. Therefore, the LAN ID shown in both Figure 10.7 and Figure 10.9 is 0000.0c76.5b7c.02. Figure 10.9. The E0 interface of this router is attached to the same network as the E0 interface of the router in Figure 10.7. Appending the Circuit ID to the System ID is necessary because the same router can be the DR on more than one network. Notice in Figure 10.7 that the same router is the DR on the network attached to E0 and the network attached to E1. It is the Circuit ID, 02 on E0 and 03 on E1, which makes the LAN ID unique for each network. Note IS-IS Designated router process compared to OSPF The IS-IS DR process is more primitive (or less complex, depending upon one's viewpoint) than the OSPF DR process in two ways. First, IS-IS does not elect a Backup Designated Router. If the IS-IS DR fails, a new DR is elected. Second, the IS-IS DR is not as stable as the OSPF DR. If an OSPF router becomes active on a network with an existing DR, the new router will not become the DR even if its priority or Router ID is higher. As a result, the OSPF DR usually is the router that has been active on the network for the longest time. In contrast to the OSPF rules, a new IS-IS router with a higher priority than the existing DR, or an equal priority and a higher System ID, will become the new DR. Each time the DR is changed, a new set of LSPs must be flooded. Subnetwork Independent FunctionsThe functions of the subnetwork-independent sublayer define how CLNS delivers packets throughout the CLNP internetwork and how these services are offered to the transport layer. The routing function itself is divided into four processes: the Update process, the Decision process, the Forwarding process, and the Receive process. As the names of the last two processes suggest, the Forwarding process is responsible for transmitting PDUs, and the Receive process is responsible for the reception of PDUs. These two processes, as described in ISO 10589, are more relevant to CLNS NPDUs than to IP packets, and so are not described further. The Update ProcessThe Update process is responsible for constructing the L1 and L2 link state databases. To do so, L1 LSPs are flooded throughout an area, and L2 LSPs are flooded over all L2 adjacencies. The specific fields of the LSPs are described in the section "IS-IS PDU Formats." Each LSP contains a Remaining Lifetime, a Sequence Number, and a Checksum. The Remaining Lifetime is an age. The difference between an IS-IS LSP's Remaining Lifetime and an OSPF LSA's Age parameter is that the LSA Age increments from zero to MaxAge, whereas the LSP Remaining Lifetime begins at MaxAge and decrements to zero. The IS-IS MaxAge is 1200 seconds (20 minutes). Like OSPF, IS-IS ages each LSP as it resides in the link state database, and the originator must periodically refresh its LSAs to prevent the Remaining Lifetime from reaching zero. The IS-IS refresh interval is 15 minutes minus a random jitter of up to 25%. If the Remaining Lifetime reaches zero, the expired LSP will be kept in the link state database for 60 seconds, known as the ZeroAgeLifetime . If any router receives a LSP with an incorrect Checksum, the router will purge the LSP by setting the LSP's Remaining Lifetime to zero and reflooding it. The purge causes the LSP's originator to send a new instance of the LSP. This procedure is yet another way that IS-IS differs from OSPF, where only the originator can purge an OSPF LSA. On error-prone subnetworks, allowing receiving routers to initiate purges can significantly increase the LSP traffic. To override this behavior, the command ignore-lsp-errors can be added to the IS-IS routing configuration. When a router with this option enabled receives a corrupted LSP, it ignores it rather than purging it. The originator of the corrupted LSP will still know that the LSP was not received through the use of SNPs, described later in this section. Note Sequence Number The Sequence Number is an unsigned, 32-bit linear number. When a router first originates an LSP, it uses a Sequence Number of one, and each subsequent instance of the LSP has its Sequence Number incremented by one. If the Sequence Number increments to the maximum (0xFFFFFFFF), the IS-IS process must shut down for at least 21 minutes (MaxAge + ZeroAgeLifetime) to allow the old LSPs to age out of all databases. On point-to-point subnetworks, routers send L1 and L2 LSPs directly to the neighboring router. On broadcast subnetworks, the LSPs are multicast to all neighbors. Frames carrying L1 LSPs have a destination MAC identifier of 0180.c200.0014, known as AllL1ISs. Frames carrying L2 LSPs have a destination MAC identifier of 0180.c200.0015, known as AllL2ISs. Note Mac identifiers for broadcasting L1and L2 LSPs IS-IS uses SNPs both to acknowledge the receipt of LSPs and to maintain link state database synchronization. There are two types of SNPs: Partial SNPs (PSNPs) and Complete SNPs (CSNPs). On a point-to-point subnetwork, a router uses a PSNP to explicitly acknowledge each LSP it receives. [15] The PSNP describes the LSP it is acknowledging by including the following information:
When a router sends an LSP on a point-to-point subnetwork, it sets a timer for a period known as minimumLSPTransmissionInterval . If the timer expires before the router receives a PSNP acknowledging receipt of the LSP, a new LSP will be sent. On Cisco routers, the default minimumLSPTransmissionInterval is five seconds and can be changed on a per interface basis with the command isis retransmit-interval . On broadcast subnetworks, LSPs are not acknowledged by each receiving router. Instead, the DR periodically multicasts a CSNP that describes every LSP in the link state database. The default CSNP period is 10 seconds and can be changed with the command isis csnp-interval . L1 CSNPs are multicast to AllL1ISs (0180.c200.0014), and L2 CSNPs are multicast to AllL2ISs (0180.c200.0015). When a router receives a CSNP, it compares the LSPs summarized in the PDU with the LSPs in its database. If the router has an LSP that is missing from the CSNP or a newer instance of an LSP, the router multicasts the LSP onto the network. If another router sends the updated LSP first, however, the router will not send another copy of the same LSP. If the router's database does not contain a copy of every LSP listed in the CSNP or if the database contains an older instance of an LSP, the router multicasts a PSNP listing the LSPs it needs. Although the PSNP is multicast, only the DR responds with the appropriate LSPs. An interesting feature of IS-IS is its ability to signal other routers if it runs out of memory and cannot record the complete link state database. The memory overload might be due to an area that has been allowed to grow too large, a router with insufficient memory, or a transitory condition such as the failure of a DR. If a router cannot store the complete link state database, it will set a bit in its LSP called the Overload (OL) bit. The OL bit signals that the router might not be able to make correct routing decisions because of its incomplete database. The other routers still route packets to the overloaded router's directly connected networks, but do not use the router for transit traffic until it has issued an LSP with the OL bit cleared. Because a set OL bit prevents the router from being used as a hop along a route, the bit is frequently called the hippity bit (as in hippity-hop, believe it or not). Memory should be allocated equally to the L1 and the L2 database, but a router can be in an overload condition at one level and normal in the other. If you want to intentionally set an IS-IS router to act only as an end node, the OL bit can be set manually with the command set-over-load-bit . The command show isis database displays a summary of the IS-IS link state database, as shown in Figure 10.10. The router Brussels in this figure is an L1/L2 router, so it has both L1 and L2 databases. The LSP ID shown in the first column consists of the System ID of the originating router, concatenated with two more octets. The first octet following the System ID is the Pseudonode ID. If this octet is nonzero, the LSP was originated by a DR. The System ID and the nonzero Pseudonode ID together make the LAN ID of a broadcast subnetwork. Figure 10.10. The IS-IS database can be observed with the command show isis database. The last octet is the LSP Number. Occasionally, an LSP can be so large that it exceeds the MTU that can be supported by the router buffers or the data link. In this case, the LSP is fragmented ”that is, the information is conveyed in multiple LSPs. The LSP IDs of these multiple LSPs consist of identical System IDs and Pseudonode IDs, and distinct LSP Numbers . An asterisk following the LSP ID indicates that the LSP is originated by the router on which the database is being observed. For example, the database shown in Figure 10.10 is taken from a router named Brussels. The L1 LSP with an ID of 0000.0c76.5bB7c.00-00 is originated by Brussels, as are four other LSPs. The second and third columns of the database display show the Sequence Number and Checksum of each LSP. The fourth column, LSP Holdtime, is the Remaining Lifetime of the LSP in seconds. If you enter the show isis database command repeatedly, you can observe the numbers decrementing . When the LSP is refreshed, the Remaining Lifetime is reset to 1200 seconds and the Sequence Number is incremented by one. The last column indicates the state of the Attached (ATT) bit, the Partition (P) bit, and the Overload (OL) bit of each LSP. L2 and L1/L2 routers will set the ATT bit to one to indicate that they have a route to another area. The P bit indicates that the originating router has partition repair capability. Cisco (and most other vendors) does not support this function, so the bit is always set to zero. The OL bit is set to one if the originating router is experiencing a memory overload and has an incomplete link state database. A complete LSP can be observed by using the command show isis database detail along with the level and the LSP ID, as shown in Figure 10.11. The meanings of the individual fields of the LSP are given in "IS-IS PDU Formats." Figure 10.11. The command show isis database detail is used to observe complete LSPs in the database. The Decision ProcessOnce the Update process has built the link state database, the Decision process uses the information in the database to calculate a shortest path tree. The process then uses the shortest path tree to construct a forwarding database (route table). Separate SPF calculations are run for the L1 routes and the L2 routes. ISO 10589 specifies the following metrics (one required and three optional) to be used by IS-IS to calculate the shortest path: Note IS-IS metrics
Each metric is expressed as an integer between 0 and 63, and a separate route is calculated for each metric. Therefore, if a system supports all four metrics, the SPF calculation must be run four times for both L1 routes and L2 routes. Because of the potential for many iterations of the SPF calculation for every destination, resulting in many different route tables, and because the optional metrics provide rudimentary Type of Service routing at best, Cisco supports only the default metric. Cisco assigns a default metric of 10 to every interface, regardless of the interface type. The command isis metric changes the value of the default metric, and the default can be changed separately for level 1 and level 2. If the metrics are left at 10 for every interface, every subnetwork is considered equal and the IS-IS metric becomes a simple measure of hop count, where each hop has a cost of 10. The total cost of a route is a simple sum of the individual metrics at each outgoing interface, and the maximum metric value that can be assigned to any route is 1023. This small maximum is frequently pointed out as a limitation of IS-IS because it leaves little room for metric granularity in large internetworks. The flip side of this criticism, however, is that limiting the metric to 1023 makes the SPF algorithm more efficient. IS-IS not only classifies routes as L1 or L2 but also classifies routes as internal or external . Internal routes are paths to destinations within the IS-IS routing domain, and external routes are paths to destinations external to the routing domain. Whereas L2 routes may be either internal or external, L1 routes are always internal. Note Internal and external routes Given multiple possible routes to a particular destination, an L1 path is preferred over an L2 path. Within each level, a path that supports the optional metrics is preferred over a path that supports only the default metric. (Again, Cisco supports only the default metric, so the second order of preference is not relevant to Cisco routers.) Within each level of metric support, the path with the lowest metric is preferred. If multiple equal-cost, equal-level paths are found by the Decision process, they are all entered into the route table. Cisco's IS-IS implementation will perform equal-cost load balancing on up to six paths. Note Load balancing The previous section, "The Update Process," discussed the last octet of the LSP ID, known as the LSP Number, used to track fragmented LSPs. The Decision process pays attention to the LSP Number for several reasons. First, if an LSP with an LSP Number of zero and a nonzero Remaining Lifetime is not present in the database, the Decision process will not process any LSPs from the same system that have nonzero LSP Numbers. For example, if the LSP IDs 0000.0c76.5b7c.00-01 and 0000.0c76.5b7c.00-02 exist in the database, but the database contains no LSP with an LSP ID of 0000.0c76.5b7c.00-00, the first two LSPs are not processed . This approach ensures that incomplete LSPs do not cause inaccurate routing decisions. Also, the Decision process will accept the following information only from LSPs whose LSP Number is zero:
The Decision process ignores these settings in LSPs whose LSP Number is nonzero. In other words, the first LSP in a series of fragments speaks for all the fragments for these three settings. Note IS-IS supports VLSM Figure 10.12 shows a route table from a Cisco IS-IS router. Notice that the L1 and L2 routes are indicated and that three destinations have multiple paths. A mask is associated with each route, indicating support for VLSM. Finally, the route table indicates that the administrative distance of IS-IS routes is 115. Figure 10.12. This route table shows both level 1 and level 2 IS-IS routes. Another duty of the Decision process in L1 routers is to calculate the path to the nearest L2 router, for inter-area routing. As previously discussed, when an L2 or L1/L2 router is attached to another area, the router will advertise the fact by setting the ATT bit in its LSP to one. The Decision process in L1 routers will choose the metrically closest L1/L2 router as the default inter-area router. When IS-IS is used to route IP, a default IP route to the L1/L2 is entered into the route table. For example, Figure 10.13 shows a link state database for an L1 router and its associated route table. LSP 0000.0c0a.2c51.00-00 has an ATT = 1. Based upon this information, the Decision process has chosen the router with System ID 0000.0c0a.2c51 as the default inter-area router. The route table shows a default route (0.0.0.0) via 10.1.255.6, with a metric of 10. Although it is not readily apparent from the information shown in Figure 10.13, 10.1.255.6 and System ID 0000.0c0a.2c51 refer to the same router. Figure 10.13. Integrated IS-IS adds a default IP route to the nearest L1/L2 router whose ATT bit is set to one. The information in Figure 10.13 illustrates a basic problem of working with Integrated IS-IS, particularly when troubleshooting. Although TCP/IP is the protocol being routed, the protocol determining the routes, including all the route control packets and addresses, is a CLNS protocol. Sometimes correlating the CLNS information with the IP information can be difficult. One command that can be useful is which-route. The command is used primarily to determine the route table in which a particular CLNS destination is located. However, which-route can also yield useful information about the IP addresses associated with a particular CLNS address. In Figure 10.14 the System ID/Circuit ID 0000.0c0a.2c51.00, shown in the database of Figure 10.13 as having ATT = 1, is used as the argument to which-route . The result shows, among other things, that the next-hop address for the queried System ID is 10.1.255.6. Figure 10.14. The command which-route can reveal some information tying CLNS addresses to IP addresses. IS-IS PDU FormatsIS-IS uses nine PDU types in its processes, and each PDU is identified by a five-bit type number. The PDUs fall into three categories, as shown in Table 10.1. Table 10.1. IS-IS PDU types.
The first eight octets of all of the IS-IS PDUs are header fields that are common to all PDU types, as shown in Figure 10.15. These first fields are described here, and the PDU-specific fields are described in subsequent sections. Figure 10.15. The first eight octets of the IS-IS PDUs. Intradomain Routeing Protocol Discriminator is a constant assigned by ISO 9577 [16] to identify NPDUs. All IS-IS PDUs have a value of 0x83 in this field.
Length Indicator specifies the length of the fixed header in octets. Version/Protocol ID Extension is always set to one. ID Length describes the length of the System ID field of NSAP addresses and NETs used in this routing domain. This field is set to one of the following values:
The System ID of Cisco routers must be six octets, so the ID Length field of a Cisco-originated PDU will always be zero. PDU Type is a five-bit field containing one of the PDU type numbers shown in Table 10.1. The preceding three bits (R) are reserved and are always set to zero. Version is always set to one, just like the Version/Protocol ID Extension in the third octet. Reserved is always set to all zeroes. Maximum Area Addresses describes the number of area addresses permitted for this IS area. The number is set to one of the following values:
Cisco IOS supports a maximum of three areas, so the Maximum Area Addresses field in IS-IS PDUs originated by Cisco routers will always be zero. In Figure 10.16, an analyzer capture of an IS-IS PDU shows the first eight octets of the PDU. Figure 10.16. This analyzer capture shows the first eight fields of an IS-IS PDU, along with its data link header. The PDU-specific fields following the common header fields are also part of the header; they vary according to PDU type and are discussed in the sections dealing with specific PDU types. CLV FieldsThe variable-length fields following the PDU-specific fields are C ode/Length/Value (CLV) [17] triplets, as shown in Figure 10.17. The Code is a number specifying the information content of the value field, the Length specifies the length of the Value field, and the Value field is the information itself. As the one-octet size of the Length field implies, the maximum size of the Value field is 255 octets.
Figure 10.17. IS-IS Code/Length/Value triplets perform the same function for IS-IS as Type/Length/Value triplets perform for EIGRP. Table 10.2 lists the IS-IS CLV codes. The table also indicates whether the CLV is specified in ISO 10589 or in RFC 1195. The ISO-specified CLVs are designed for use with CLNP, although most of them are also used with IP. The RFC-specified CLVs are designed only for IP. If a router does not recognize a particular CLV code, it will ignore the CLV. This arrangement allows CLVs for CLNP, IP, or both to be carried in the same PDU. Table 10.2. CLV codes used with IS-IS.
Although many of the CLVs are used by more than one IS-IS PDU type, only one (Authentication) is used by all PDUs. As the formats of the IS-IS PDUs are described in the following sections, the CLVs used by each PDU are listed. The format of each CLV is described only once, the first time it is listed. Table 10.3 summarizes which CLVs are used with which PDUs. Table 10.3. The CLVs used by each IS-IS PDU.
The IS-IS Hello PDU FormatThe purpose of the IS-IS Hello PDU is to allow IS-IS routers to discover IS-IS neighbors on a link. Once the neighbors have been discovered and have become adjacent, the job of the Hello PDU is to act as a keepalive to maintain the adjacency and to inform the neighbors of any changes in the adjacency parameters. The upper limit on the size of an IS-IS PDU is defined by either the buffer size of the originating router or the MTU of the data link on which the PDU is transmitted. ISO 10589 specifies that IS-IS Hellos must be padded to within one octet less than this maximum, partly to allow a router to implicitly communicate its MTU to its neighbors. More important, sending Hellos at or near the link MTU is intended to help detect link failure modes in which small PDUs pass but larger PDUs are dropped. The benefit of this design decision, weighed against the expense of sending such large Hellos over low-speed serial links, is debatable. There are two kinds of IS-IS Hellos: LAN Hellos and point-to-point Hellos. The LAN Hellos can be further divided into L1 and L2 LAN Hellos. The format of the two types of LAN Hellos is identical, as shown in Figure 10.18. Figure 10.19 shows an analyzer capture of a level 2 LAN Hello. Figure 10.18. The IS-IS LAN Hello PDU format. Figure 10.19. This analyzer capture of a LAN Hello shows the fields unique to a Hello PDU. Circuit Type is a two-bit field (the preceding six bits are reserved and are always zero) specifying whether the router is an L1 (01), L2 (10), or L1/L2 (11). If both bits are zero (00), the entire PDU is ignored. Source ID is the System ID of the router that originated the Hello. Holding Time is the period a neighbor should wait to hear the next Hello before declaring the originating router dead. PDU Length is the length of the entire PDU in octets. Priority is a seven-bit field used for the election of a DR. The field carries a value between 0 and 127 with the higher number having the higher priority. L1 DRs are elected by the priority in L1 LAN Hellos, and L2 DRs are elected by the priority in L2 LAN Hellos. LAN ID is the System ID of the DR plus one more octet (the Pseudonode ID) to differentiate this LAN ID from another LAN ID that might have the same DR. The following CLVs can be used by an IS-IS LAN Hello: [18]
Figure 10.20 shows the format of the IS-IS point-to-point Hello PDU. It is almost identical to the LAN Hello except that there is no Priority field and there is a Local Circuit ID field instead of a LAN ID field. Unlike LAN Hellos, L1 and L2 information is carried in the same point-to-point Hello PDU. Figure 10.20. The IS-IS point-to-point Hello PDU. Local Circuit ID is a one-octet ID assigned to this circuit by the router originating the Hello and is unique among the router's interfaces. The Local Circuit ID in the Hellos at the other end of the point-to-point link may or may not contain the same value. The IS-IS point-to-point Hello does not use the IS Neighbors CLV. With that exception, the same CLVs are used as the LAN Hello. Area Addresses CLVThe Area Addresses CLV (Figure 10.21) is used to advertise the area addresses configured on the originating router. As the multiple Address Length/Area Address fields imply, a router can be configured with multiple area addresses. There will never be more than three Address Length/Area Address fields in PDUs originated by Cisco routers because that is the maximum number of area addresses supported. Figure 10.21. The Area Addresses CLV. Figure 10.22 shows part of an IS-IS Hello PDU; Variable Length Field #3 is an Area Addresses CLV with a total length of six octets. There are two area addresses: 47.0002 (three octets), and 0 (one octet). Figure 10.22. An Area Addresses CLV is shown as Variable Length Field #3. The analyzer also indicates the total addresses listed in the CLV (2) for convenience, but this information is not one of the CLV fields. Intermediate System Neighbors CLV (Hello)The IS Neighbors CLV (Figure 10.23) lists the System IDs of all neighbors from whom a Hello has been heard within the last Hold Time. Note that this CLV gives the IS-IS LAN Hello a function similar to the OSPF function of listing all recently- heard -from neighbors in order to verify two-way communication. Figure 10.23. The IS Neighbors CLV for Hello PDUs. This CLV is used only in LAN Hellos; it is not carried in point-to-point Hellos, where no DR election is performed. It is also different from the IS Neighbors CLV used by LSPs, and the two are distinguished by their type numbers. L1 LAN Hellos list L1 neighbors only, and L2 LAN Hellos list L2 neighbors. Although fields carrying System IDs are frequently of variable length, the fields of this CLV are always six octets. The length can be fixed because the System IDs always belong to routers on LANs, and are therefore always MAC identifiers. Variable Length Field #5 in Figure 10.24 shows an IS Neighbors CLV in which a single neighbor, 0000.0c0a.2aa9, is listed. Figure 10.24. An IS Neighbors CLV is shown as Variable Length Field #5. Padding CLVThe Padding CLV is used to pad a Hello PDU out to at least its minimum-allowed size. Since the maximum size of a Value field is 255 octets, multiple Padding CLVs are often used. The bits in the Value field can be arbitrary because they are ignored; Cisco sets all these bits to zero (Figure 10.25). Figure 10.25. The last Variable Length Fields of the Hello PDU shown in Figure 10.19 are Padding CLVs, which bring the size of the PDU to the 1497-octet length shown in Figure 10.19. With the addition of the 3-octet LLC header and the 18-octet Ethernet header, the entire frame size is the 1518-octet Ethernet MTU. Authentication Information CLVThe Authentication Information CLV (Figure 10.26) is used when authentication is configured. The Authentication Type field contains a number between 0 and 255 that specifies the type of authentication used and hence the type of information contained in the Authentication Value field. The only authentication type currently defined by ISO 10589 or supported by Cisco is a cleartext password, which is Authentication Type 1. Figure 10.26. The Authentication Information CLV. Variable Length Field #1 in Figure 10.22 is an Authentication Information CLV. The password is "jeff," which is displayed as the hex representation of its ASCII characters . Protocols Supported CLVThe Protocols Supported CLV (Figure 10.27) is specified in RFC 1195, and its purpose is to indicate whether the originator of the PDU supports CLNP only, IP only, or both. For each protocol supported, the corresponding one-octet Network Layer Protocol Identifier (NLPID), specified in ISO/TR 9577, is listed in the CLV. IP is 0x81. Variable Length Field #2 in Figure 10.22 is a Protocols Supported CLV. Figure 10.27. The Protocols Supported CLV. IP Interface Address CLVThe IP Interface Address CLV (Figure 10.28) contains the IP address or addresses of the interface out which the PDU was sent. Because the Length field is one octet, an interface of an IS-IS router can theoretically have up to 255 IP addresses. Variable Length Field #4 in Figure 10.24 is an IP Interface Address CLV, indicating that the captured Hello PDU was transmitted from an interface with an address of 10.1.3.1. Figure 10.28. The IP Interface Address CLV. The IS-IS Link State PDU FormatThe IS-IS LSP performs essentially the same function as the OSPF LSA. An L1 router floods a L1 LSP throughout an area to identify its adjacencies and the state of those adjacencies. An L2 router floods L2 LSPs throughout the level 2 domain, identifying adjacencies to other L2 routers and address prefixes that the advertising L2 router can reach. Figure 10.29 shows the format of the IS-IS LSP. The format is the same for both L1 LSPs and L2 LSPs. Figure 10.29. The IS-IS LSP format. PDU Length is the length of the entire PDU in octets. Remaining Lifetime is the number of seconds before the LSP is considered to be expired. LSP ID is the System ID, the Pseudonode ID, and the LSP Number of the LSP. The LSP ID is described in more detail in "The Update Process." Sequence Number is a 32-bit unsigned integer. Checksum is the checksum of the contents of the LSP. P is the Partition Repair bit. Although the bit exists in both L1 and L2 LSPs, it is relevant only in L2 LSPs. When this bit is set, it indicates that the originating router supports the automatic repair of area partitions. Cisco IOS does not support this function, so the P bit of LSPs originated by Cisco routers will always be zero. ATT is a four-bit field indicating that the originating router is attached to one or more other areas. Although the bits exist in both L1 and L2 LSPs, they are relevant only in L1 LSPs that have been originated by L1/L2 routers. The four bits indicate which metrics are supported by the attachment. Reading from left to right, the bits indicate:
Cisco IOS supports only the default metric, so bits 5 through 7 will always be zero. OL is the Link State Database Overload bit. Under normal circumstances, this bit will be zero. If the originating router is experiencing a memory overload condition, it will set the OL bit to one. Routers receiving an LSP with the OL bit set will not use the originating router as a transit router, although they will still route to destinations on the originator's directly connected links. IS Type is a two-bit field indicating whether the originating router is an L1 or an L2:
An L1/L2 router sets the bits according to whether the LSP is an L1 or an L2 LSP. The following CLVs can be used by an L1 LSP:
The following CLVs can be used by an L2 LSP:
Figure 10.30 shows an L1 LSP that was originated by an L1/L2 router. Figure 10.30. An analyzer capture of an LSP. Intermediate System Neighbors CLV (LSP)The Intermediate System Neighbors CLV used by LSPs (Figure 10.31) lists the originating router's IS-IS neighbors (including pseudonodes) and the metrics of the router's link to each of its neighbors. Figure 10.31. The Intermediate System Neighbors CLV for LSPs. Virtual Flag , although eight bits long, has a value of either 0x01 or 0x00. A 0x01 in this field indicates that the link is a level 2 virtual link to repair an area partition. The field is relevant only to L2 routers that support area partition repair; Cisco does not, so the field will always be 0x00 in Cisco-originated LSPs. R is a reserved bit and is always zero. I/E , associated with each of the metrics, indicates whether the associated metric is internal or external. The bit has no meaning in IS Neighbors CLVs because all neighbors are by definition internal to the IS-IS domain. Therefore, this bit is always zero in IS Neighbors CLVs. Default Metric is the six-bit default metric for the originating router's link to the listed neighbor and contains a value between 0 and 63. S , associated with each of the optional metrics, indicates whether the metric is supported (zero) or unsupported (one). Cisco does not support any of the three optional metrics, so the bit is always set to one and the associated six-bit metric fields are all zeroes. Neighbor ID is the System ID of the neighbor, plus one more octet. If the neighbor is a router, the last octet is 0x00. If the neighbor is a pseudonode, the System ID is that of the DR and the last octet is the Pseudonode ID. Figure 10.32 shows part of an IS Neighbors CLV. Figure 10.32. Part of an IS Neighbors CLV in an LSP. IP Internal Reachability Information CLVThe IP Internal Reachability Information CLV (Figure 10.33) lists IP addresses and associated masks within the routing domain that are directly connected to the advertising router. The CLV is used by both L1 and L2 LSPs, but never appears in an LSP describing a pseudonode. The metric fields are identical to the IS Neighbors CLV, except that no I/E bit is associated with the optional metrics. Instead, the bit is reserved and is always zero. Like the IS Neighbors CLV, the I/E bit in this CLV is always zero because the addresses advertised in the CLV are always internal.Figure 10.34 shows an analyzer capture of an IP Internal Reachability Information CLV. Figure 10.33. The IP Internal Reachability Information CLV. Figure 10.34. An analyzer capture of an IP Internal Reachability Information CLV. IP External Reachability Information CLVThe IP External Reachability Information CLV lists IP addresses and associated masks external to the routing domain, which can be reached via one of the originating router's interfaces. Its format is identical to the Internal Reachability Information CLV shown in Figure 10.33 except for the code, which is 130. However, unlike the Internal Reachability Information CLV, this CLV can be used only by L2 LSPs. The I/E bit determines the metric type for all four metrics ”I/E = 0 for internal metrics, and I/E = 1 for external metrics. Inter-Domain Routing Protocol Information CLVThe Inter-Domain Routing Protocol Information CLV (Figure 10.35) allows L2 LSPs to transparently carry information from external routing protocols through the IS-IS domain. The CLV serves the same purpose as the Route Tag fields of RIPv2, EIGRP, and OSPF packets. Route tagging is covered in Chapter 14, "Route Maps." Figure 10.35. The Inter-Domain Routing Protocol Information CLV. Inter-Domain Information Type specifies the type of information contained in the variable-length External Information field. If the type field is 0x01, the External Information is of a format used by the local interdomain routing protocol. Chapter 14 includes examples of using route maps to set such local information. If the type field is 0x02, the External Information is a 16-bit autonomous system number, which is used to tag all subsequent External IP Reachability entries until either the end of the LSP or the next occurrence of the Inter-Domain Routing Protocol Information CLV. The IS-IS Sequence Numbers PDU FormatSNPs are used to maintain the IS-IS link state database by describing some or all of the LSPs in the database. A DR periodically multicasts a CSNP (Figure 10.36) to describe all the LSPs in the pseudonode's database. Because there is an L1 database and an L2 database, CSNPs are also either L1 or L2. Some link state databases can be so large that the LSPs cannot all be described in a single CSNP. For this reason, the last two fields of the CSNP header are the Start LSP ID field and the End LSP ID field, which together describe the range of LSPs described in the CSNP. Figure 10.37 shows how these two fields are used. In this CSNP, the full database is described; therefore, the LSP ID range starts with 0000.0000.0000.00.00 and ends with ffff.ffff.ffff.ff.ff. If two CSNPs were required to describe the database, the range of the first CSNP might be something like 0000.0000.0000.00 to 0000.0c0a.1234.00.00 and the range of the second CSNP might be 0000.0c0a.1235.00.00 to ffff.ffff.ffff.ff.ff. Figure 10.36. The IS-IS CSNP format. Figure 10.37. This analyzer capture shows the header of an L1 CSNP. A PSNP (Figure 10.38) is similar to a CSNP, except that the former describes only some LSPs rather than the entire database. Therefore, no Start and End fields are necessary as they are with CSNPs. A router sends a PSNP on a point-to-point subnetwork to acknowledge received LSPs. On a broadcast subnetwork, PSNPs request missing or more recent LSPs. Like CSNPs, there are both L1 and L2 PSNPs. Figure 10.38. The IS-IS PSNP format. Only two CLVs are used by SNPs, whether they are CSNP or PSNP and whether they are L1 or L2:
LSP Entries CLVThe LSP Entries CLV (Figure 10.39) summarizes an LSP by listing its Remaining Lifetime, LSP ID, Sequence Number, and Checksum. These fields not only identify the LSP but also completely identify a particular instance of an LSP. Figure 10.40 shows part of an LSP Entries CLV. Figure 10.39. The LSP Entries CLV. Figure 10.40. Part of the LSP Entries CLV of the CSNP in Figure 10.37. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}