IS-IS Protocol Concepts
| ‚ < ‚ Free Open Study ‚ > ‚ |
| The goal of this section is to help you understand the operation, features, strengths, and limitations of the various architectural concepts underlying the IS-IS protocol. In particular, the following points are discussed:
IS-IS Nodes, Links, and AreasIS-IS inherits the following ISO classification and definition of the two basic types of net-work nodes:
End systems are hosts in a network that typically do not have extensive routing capabilities. Intermediate systems refer to routers whose primary function is to route packets. Network nodes are interconnected by links. Again, in IS-IS, only two basic links types are of practical relevance:
Point-to-point links interconnect pairs of nodes, while broadcast type links are multipoint and can interconnect more than two nodes at the same time. Transport technologies, such as serial (T1, DS-3, and so on) and Packet-over-SONET (PoS) links, are inherently point-to-point, while local-area network (LAN) media, such as Ethernet, are typical broadcast-type links. Nonbroadcast multiaccess (NBMA) transport media, such as Asynchronous Transfer Mode (ATM) and Frame Relay, can be configured to operate as simulated broadcast or point-to-point links. Because broadcast links inherently imply connected nodes are fully meshed, NBMA media should be configured as broadcast links only when the routers are fully meshed by the underlying permanent virtual circuits (PVC) . Nonfully meshed NBMA environments should use point-to-point setups, which align with the underlying topology of PVC interconnections and are simpler to manage and troubleshoot. A network running the IS-IS routing protocol frequently is referred to as an IS-IS routing domain. A large IS-IS routing domain can be partitioned into multiple areas for the purpose of scaling routing over the entire domain. A routing area can be of any arbitrary size ; the number of nodes that it contains largely is defined at the discretion of the network designer. Key factors normally taken into consideration when creating areas include memory and processing capacities of the routers involved. The larger the area is, the higher the resource (memory and CPU capacity) needs per router are for maintaining the IS-IS database and computing routes fast enough to sustain reasonable convergence times when changes occur in the network. All IS-IS routers in the domain are assigned to at least one IS-IS area. Each IS-IS node has a unique node-based address referred to as a network service access point ( NSAP ). NSAPs are discussed later in this chapter, but, for now, all you need to know is that the NSAP has an area identifier component that defines the native area of each node. Figure 10-1 shows the layout of an IS-IS domain carved into three areas with the following simple area-identifiers: 49.001, 49.002, and 49.003. As depicted, the areas are interconnected through the region known as the backbone. From this diagram, it is also apparent that each node wholly sits in a specific area and that the area boundaries cut across the links to other areas. Each IS-IS area is specified in ISO 10589 to be a stub ‚ meaning that interarea routing inform -ation remains only within the backbone. A recent IETF-sponsored enhancement 6 removes this restriction. This capability is available in Cisco IOS Software as a feature known as IS-IS route leaking. Figure 10-1. IS-IS Areas AdjacenciesAs a link-state protocol, IS-IS relies on current and complete knowledge of the network topology to compute routes accurately and optimally. Some key functions of routers partici-pating in IS-IS routing involve discovering, establishing, and maintaining routing adjacencies with neighbor routers. The type and manner in which an adjacency is formed between two routers depend on the type of link interconnecting them. This section addresses the two types of IS-IS adjacencies, which correlate with the two types of links discussed earlier. The adjac-ency types are listed here:
Formation and maintenance of adjacencies between IS-IS routers take place through the exchange of special packets, referred to as hellos. Routers need to form both ES-IS and IS-IS adjacencies over either point-to-point or broadcast links. Even though ES-IS is not necessary for IP routing, IS-IS adjacency formation on point-to-point links is dependent on ES-IS adjac-ency detection on such links. Therefore, Cisco IOS Software enables the ES-IS protocol even if IS-IS is enabled for only IP routing. ES-IS uses end-system hellos ( ESHs ) and intermediate-system hellos ( ISHs ) for ES-IS adjacencies, while IS-IS uses intermediate system-to-intermediate system hellos ( IIHs ). ES-IS AdjacenciesIn ES-IS, end systems advertise ESHs to routers by addressing them to the MAC address 09-00-2B-00-00-05 (AllIntermediateSystems). On the other hand, routers advertise ISHs to 09-00-2B-00-00-04 (AllEndSystems). ES-IS essentially provides a host-discovery mech-anism in the ISO CLNS environment. Through this mechanism, end systems locate the closest router though which they can transit data to nonconnected media. Routers, in turn , learn about end systems in their area. Routers also discover each other through the ES-IS adjacency process. Figure 10-2 shows ISH and ESH transmissions between routers and a workstation on a LAN. Figure 10-2. ES-IS Adjacencies IS-IS AdjacenciesFor routers to exchange routing information, they need to transcend ES-IS adjacencies and form IS-IS adjacencies with their neighbors. An interesting point to note is that ES-IS adjacency is required to trigger advertisement of IIHs on point-to-point links, which ultimately can lead to IS-IS adjacencies. The IS-IS adjacencies on point-to-point links are formed and maintained a little differently than on broadcast links. Also, IIHs used on point-to-point links have a slightly different format than those used on broadcast multipoint links. The following are the three types of specified IIHs:
The point-to-point IIHs and LAN IIHs have slightly varied information in their fixed header areas. For example, the point-to-point IIHs have a local circuit ID, whereas LAN IIHs have a LAN ID. Also, point-to-point IIHs don't have the priority information found in LAN IIHs. IS-IS packet formats are covered later in this chapter, in the section titled "IS-IS Packets." Complete formats of hello packets are provided at the end of the chapter in the section titled "Additional IS-IS Packet Information." IS-IS has a two-level routing hierarchy, and, as alluded to previously, the type of adjacency formed between IS-IS routers determines the type of routing relationship between them (that is, Level 1, Level 2, or both). Routing information is exchanged through the use of link-state packets (LSPs), with control provided by sequence number packets (SNP). LSPs and SNPs will be discussed further in the section "IS-IS Link-State Database." On multiaccess links such as broadcast LANs or multipoint ATM and Frame Relay links in which more then two nodes are connected to the same link, forming adjacencies between all of them results in n x ( n ‚ 1)/2 adjacencies, where n is the number of connected nodes. In IS-IS, all nodes on multipoint links actually detect each other by means of the hellos multicast across the medium. Each node, therefore, forms n ‚ 1 adjacencies on such media. A node declares a neighbor to be adjacent if that neighbor is announced in the list of detected neighbors. Reliably updating and synchronizing databases with each of these adjacent neighbors certainly is resource-demanding. Therefore, to reduce the amount of effort required for database synchronization, IS-IS models such multipoint links as virtual nodes, also referred to as a pseudonodes ( PSN ) (see Figure 10-3). Figure 10-3. Broadcast-Link Pseudonode One of the routers on the multipoint link is elected as a designated router to play the role of the PSN. In ISO terminology, the designated router is referred to as the designated intermediate system ( DIS ). Election of the DIS is based on interface priorities of the routers connecting to the multiaccess link, with the highest MAC address being the tiebreaker in the case of LAN media. The default priority is 64 on Cisco routers and can be modified with the isis priority value interface-level configuration command. The priority information is carried only in LAN-type hellos, as mentioned previously. The role of the DIS is to facilitate synchronization of the IS-IS link-state databases between routers connected to the multipoint medium. It does this by periodically multicasting summaries of all known LSPs over the medium. The DIS also generates a PSN LSP that lists all known neighbors on the multipoint link. All nodes on the multipoint medium become adjacent to both the PSN and the actual router acting as the DIS. All nodes on the LAN must consistently acknowledge the same DIS for IS-IS operations to work well on the LAN. DIS election is preemptive; at any point, the most qualified router takes over the role. Three-way reliable adjacency formation is specified in ISO 10589 for only broadcast links but not for point-to-point links. Therefore, unlike point-to-point hellos, LAN hello packets contain a list of IS neighbors on the LAN that hellos have been received from. A LAN router moves its side of the adjacency with a specific neighbor to UP state when it receives a hello from that neighbor in which it is listed. Both ISO 10589 and RFC 1195 do not specify point-to-point hellos to carry the IS neighbor list. The recent IETF draft 5 proposes standardization of the three-way handshake method for adjacency formation on point-to-point links. This is supported in Cisco IOS Software Release 12.OS and later. Figure 10-4 illustrates the adjacency formation process on point-to-point links. Figure 10-4. Point-to-Point IS-IS Adjacencies As shown, RTA and RTB both advertise hellos to each other in which they list only themselves in the list of known neighbors, indicating that they haven't heard from each other yet. After they receive each other's hello, each lists the other in the neighbor list in subsequent hello exchanges. This results in both routers moving their adjacencies to the UP state. The same process is used on multiaccess links. Hierarchical RoutingAs indicated earlier, IS-IS areas provide a means for scaling routing in the IS-IS domain. Regular IS-IS areas and the backbone interconnecting them are organized into a two-level routing hierarchy. Routing within an area is referred to as Level 1 routing. Routing between the respective areas in a domain is referred to as Level 2 routing. Figure 10-5 shows an IS-IS domain partitioned into two areas: 49.001 and 49.002. It is interesting to note that, although Level 1 routing is restricted only to the confines of each area, Level 2 routing occurs within the stretch of the backbone, which can overlap well into any area based on configuration of the routers. Figure 10-5. IS Routing Hierarchy IS-IS routers can be Level 1 only (L1), Level 2 only (L2), or both Level 1 and Level 2 (Level 1 ‚ 2), based on their configuration. The configuration of a router determines the type of adjacency (Level 1 or Level 2) that it can form with its neighbors, regardless of the type of link. This, in turn, determines the level of routing (Level 1 or Level 2) that a router can participate in. In the default mode of operation, Cisco routers are Level 1 ‚ 2 and can form any kind of adja-cency with their neighbors. A router in one area can form only a Level 2 adjacency with a router in another area, so only Level 2 routing occurs between them. However, depending on their configuration, two routers in the same area can form a Level 1 adjacency or both Level 1 and Level 2 adjacencies with each other. Typically, routers that are Level 2, by virtue of their connectivity to the backbone, also engage in Level 1 routing within their respective areas, making them Level 1 ‚ 2 routers. Level 1 ‚ 2 routers facilitate access to other areas for Level 1 ‚ only routers in the area. Level 1 ‚ 2 routers flag their connectivity to the backbone in their Level 1 routing advertisements. As specified in ISO 10589, IS-IS Level 1 areas are stubs, and the Level 1 ‚ only routers have no visibility into routes in other areas within the same domain. They depend on a default route to the nearest Level 2 router to forward packets to destinations outside the local area. Relying on a default route to the nearest Level 2 router potentially could result in suboptimal determination of the best exit to other destinations in the network. RFC 2966 6 standardizes domain-wide prefix advertisement (IS-IS route leaking) by allowing interarea routes to be advertised from the Level 2 backbone into Level 1 areas. This capability enables optimal path selection by Level 1 routers for destinations outside their local areas. IS-IS PacketsBecause the objective of this book is to assist with troubleshooting IP routing problems, it would not be an overstatement to point out here that familiarity with the variety of packets and their formats used by a routing protocol is key to understanding the protocol nuances required for successful troubleshooting. This section reviews the various types of IS-IS packets and studies the generic IS-IS packet format. In ISO parlance, packets are referred to as protocol data units ( PDU ). The complete formats of each packet type are provided at the end of the chapter in the section titled "Additional IS-IS Packet Information." Three categories of IS-IS packets exist:
Various types of packets exist under each of the packet categories. Each type is assigned a type number, as shown in Table 10-1. All IS-IS packets are multicast on LAN media to one of the following addresses, depending on the level of routing for which it is intended:
Table 10-1. IS-IS Packet Types
Generic IS-IS Packet FormatEach type of IS-IS packet is made up of a packet header and a number of optional variable-length fields referred to as Type-Length-Value ( TLV ) fields. The fields of each packet type vary slightly from each other, consisting of the generic fields and packet type specific fields, as shown in Figure 10-6. Figure 10-6. IS-IS Packet Header The generic header fields are described as follows :
The TLV fields are so named because each is described by the following three attributes:
By specification, each IS-IS packet type includes only specific TLV types. The number of actual TLVs present in a real packet is determined by the configuration and environment of the origina-ting router. Most of the currently specified TLVs can be present in both Level 1 and Level 2 packets. A few, however, are dedicated to only Level 1 or Level 2 packets. RFC 1195 specifies additional TLVs to those specified in IS0 10589. Tables 10-2 and 10-3 list TLVs specified by ISO 10589 and RFC 1195, respectively. Table 10-2. TLVs Specified by ISO 10589
Table 10-3. TLVs Specified by RFC 1195
Most enhancements to the original IS-IS protocol (ISO 10589) have occurred through the intro-duction of new TLVs instead of new packet types. This points largely to the flexibility and extensibility of the IS-IS protocol. For example, TLVs introduced by RFC 1195 adapted IS-IS for routing IP in addition to CLNP. Table 10-4 lists recently introduced TLVs within the IETF that provide various extensions and additional capabilities to the IS-IS protocol. TLVs 22, 134, and 135 are IS-IS extensions for MPLS-based traffic engineering. Table 10-4. Some TLVs Specified by IETF Extensions to IS-IS
IS-IS MetricsThe following IS0 10589 and RFC 1195 TLVs carry metric information in addition to their primary objects:
Obviously, each TLV would have a different overall format, but they all have the same set of metric fields. Figure 10-7 shows the format of the value field in the IP Internal Reachability TLV. Other fields of the TLV include the Type and value fields, all 1 byte each. Figure 10-7. IP Internal Reachability TLV The following four metric types are specified by ISO 10589 and have been adopted by RFC 1195:
The default metric type must be supported on all nodes in the routing domain. The other metric types ‚ delay, expense, and error ‚ are optional and are intended for differentiated routing of quality of service (QoS) ‚ enabled CLNP packets. The IS-IS QoS metrics are not applicable to IP traffic differentiation, which is based on the precedence bits in the IP header. In any case, Cisco's implementation of IS-IS supports only the required default metric type. As depicted in Figure 10-7, each type of metric is 1 byte long. Bit 8 indicates the presence of the metric type in the TLV, and bit 7 classifies the metric as internal or external. Internal metrics refers to routes generated within the IS-IS domain, while external metrics refers to routes originating outside the IS-IS domain or from another routing protocol source, such as OSPF. Consequently, only 6 bits are available for defining the actual value of the metric. This gives a maximum cost of 63 per link, in the case of the default metric type. On Cisco routers, the cost of a link is determined by the value applied to the outgoing interface. A value of 10 is assigned by default on all interface. The cost is not derived automatically from the interface bandwidth, as in the case of OSPF. The total metric of a complete path is the sum of cost values on all outgoing interfaces from source to destination. ISO 10589 specifies 1023 as the maximum path cost. Recent IETF-driven extensions 7 to IS-IS propose using the mostly unused QoS metric fields as part of the default metric type field to allow higher-cost values for the default metric type. The following LSP TLVs, which were recently introduced to support MPLS TE, support a wider field for the default metric type:
Figure 10-8 shows the format of each prefix element contained in the Extended IP Reach-ability TLV. Figure 10-8. Format of Prefix in Extended IP Reachability TLV The following is the list of fields in the Extended IP Reachability TLV:
The 4-byte metric field (32 bits) permits large metric values, which, as specified, should not be more than the value MAX_PATH_METRIC (0xFE000000). Prefixes with metrics larger than MAX_PATH_METRIC are to be ignored in SPF computations . Consult the RFC draft 7 for further details. Cisco IOS Software releases from the 12.0S and 12.0T trains support the expanded IS-IS metric values for the default type, also known as wide metrics. The IS-IS router-level command metric-style [ narrow wide ] enables and disables wide IS-IS metrics. A "hidden" option of the command metric-style transition is provided for only migration purposes. When enabled, this command allows a router to send and receive both narrow and wide metrics. IS-IS AuthenticationBoth ISO 10589 and RFC 1195 specify authentication mechanisms (TLV 10 and 133, respec-tively), in an attempt to tackle protocol security concerns. Only minor differences exist between the formats of these TLVs; however, significant commonality is that they both specify only clear-text password schemes. However, both TLVs provide reserved fields for future advanced authentication options. Well, the future is already here! A new IETF draft 10 proposes a protocol extension that uses an HMAC-MD5 authentication option in addition to the previously spec-ified clear-text password schemes. Most existing IS-IS implementations use TLV 10 over TLV 133, even in pure IP environments. The IS-IS HMAC-MD5 authentication extension therefore extends application of this TLV by defining a new authentication type 54 (or 0x36 in hexa-decimal) within TLV 10. The clear-text password is authentication Type 1. ISO CLNP AddressingAn interesting paradigm concerning IS-IS is that it is deeply rooted in CLNP to the extent that, even if it is used for routing only IP, CLNP addresses still must be configured on the IP routers. Therefore, it is important for network operations staff using IS-IS in pure IP environments to become comfortable with the CLNP addressing architecture. CLNP addresses are referred to as network service access points ( NSAPs ). Obvious differences between IP addressing and CLNP addressing are as follows:
NSAP FormatA simplified version of the CLNS NSAP format, specified in ISO 10589 and associated specifications, was adopted by RFC 1195 in adapting IS-IS for IP routing. This format, as shown in Figure 10-9, delineates only three key components in an NSAP address:
Figure 10-9. NSAP Format for IP Routing The maximum length of an NSAP is 160 bits (20 bytes), compared to the 32 bits (4 bytes) of an IP address. The NSEL is 1 byte long. The SysID is specified in ISO 10589 to be of variable length, ranging from 1 byte to 8 bytes long. However, Cisco follows the US GOSIP standard, which specifies 6 bytes fixed-length for the SysID. The AreaID field is a variable-length field from 1 to 13 bytes. A key component of the AreaID that RFC 1195 seems to gloss over is the Authority and Format Identifier ( AFI ). The AFI is the first byte of the AreaID, and it specifies a top-level ISO addressing authority as well as encoding of the NSAP. Table 10-5 lists the AFI values for seven ISO top-level addressing domains. Each domain features two AFI values for binary and decimal encoding of the remainder of the address following the AFI field. Table 10-5. AFI Values
Various address-registration authorities oversee allocation of addresses from each of the top-level domains. For example, ICD ISO 6523 addresses are allocated through national-level registration authorities, such as the United States National Institute of Standards (NIST) or the British Standards Institute (BSI). The U.S. NIST is responsible for allocation of ISO 6523 ICD (AFI 47) addresses to organizations in the United States, including U.S. federal government institutions. Similarly, the American National Standards Institute (ANSI) is the national reg-istration authority for ISO DCC (AFI 39) addresses in the United States. AFI 49 designates a private NSAP address space similar to the private IP address space specified in RFC 1918 11 . NSAP ExamplesFigure 10-10 shows examples of NSAP addresses. Example 1 is a complete, full-length (20 bytes) address, while Example 2 is a shorter-length address from the private space. Figure 10-10. NSAP Examples As mentioned earlier, the system ID (SysID) is a 6-byte field that uniquely represents a node in an IS-IS domain. Frequently, network administrators use a MAC address for the SysID. However, this is not necessary. Also, a router might have many LAN interfaces and, therefore, many MAC addresses making it unclear which is best suitable for the purpose. Most ISPs who use IS-IS as IGP have figured out a creative and decisive way to define the system ID and, therefore, the NSAP address on a router. The system ID is created from a loopback address. In many cases, an IP loopback address is defined on a router for other purposes, such as network management or specifying the router ID for BGP peering. To create the system ID, the loopback IP address, which is in dotted -decimal format is first padded with zeros to obtain the 12-digit address, as shown in Figure 10-10, Example 3. The digits then are regrouped in fours to obtain the 6-byte hexadecimal system ID, which can be used for defining a unique NSAP for the router. Guidelines for Defining NSAP AddressesThe following provides a summary of the guidelines for selecting or defining NSAP addresses on routers in an IS-IS routing domain:
The concept of configuring multiple NSAPs per node for a single instance of IS-IS routing allows a router to be associated with more than one Level 1 area, a concept referred to as multihoming. The effect of multihoming is that all the areas configured are merged into a single area, allowing Level 1 LSPs to be advertised across previous area boundaries. In essence, multihoming is used for transitional purposes, such as network renumbering , partitioning, or merging IS-IS areas in a domain. The technique permits nondisruptive network reconfiguration. |
| ‚ < ‚ Free Open Study ‚ > ‚ |
EAN: 2147483647
Pages: 260