 |
 |
|
||
|
|
In order to provide a complete context for the discussion of ISIS concepts, the initial sections of this document describe ISIS in the hierarchical, or multi-area sense. However, many of the interesting complexities of multi-area ISIS will not be addressed at this time.
ISIS operates very much like other link state protocols including OSPF. It includes the hierarchical concept of segmenting the routing domain into areas and dividing those areas into one backbone and multiple non-backbone areas. As a loop prevention mechanism, all inter-area traffic must traverse the backbone. Routers within an ISIS domain utilize a hello mechanism to discover neighbors and form adjacencies with them to support the distribution of routing information. As a link-state protocol, the information (LSPs) exchanged between adjacent routers describes each individual router in an area including that particular router's set of interfaces. Each router then stores this information in a Link State Database (LSDB). In a stable environment, each router in the area will maintain an identical copy of the LSDB. Using the data present in the database, and assuming that the database is complete, each router in the area will be able to accurately describe the complete topology of the area. Finally, with the database built and the topology known, each router then uses the Dijkstra algorithm to calculate a shortest path tree from itself to all reachable destinations. This results in a set of routes that can be posted in the local routing table.
Note that although the LSDB may contain information about reachability beyond the area, the scope of the granular link information used by the Dijkstra algorithm is limited to a single area. These concepts and their significance are described in some detail in the following sections.
Dividing the routing domain into distinct areas provides a number of benefits. It becomes increasingly computationally challenging for a router to calculate SPF trees as the size of the LSDB increases. Furthermore, the likelihood of links changing state also increases as routers are added to an area. For these reasons, logically dividing the domain into smaller areas tends to increase stability and generally positively influence convergence times. Another benefit lies in the ability to provide aggregation, or summarization, of address space at area borders. Summarization allows one area to shield another from an (overwhelming) amount of granularity by hiding prefixes that are more specific. Doing so minimizes the impact that topological changes in one area have on another and thus increases the overall stability of the domain.
ISIS provides two distinct mechanisms for routing within the domain. Level 1 (L1) algorithms govern the operation of ISIS within a single area while Level 2 (L2) algorithms govern inter area communication. The following diagram depicts a typical ISIS topology.
Figure 1. The ISIS Topology
For those familiar with OSPF, a key distinction between the two protocols should be evident. The distinction lies in the location of area borders. In OSPF, an Area Border Router (ABR) is one that has one interface in the backbone and one or more interfaces in another area. The key point is that the area boundary lies within the router itself. With ISIS, on the other hand, routers exist fully within areas. Said another way, in OSPF, common links between routers must always exist in the same area and thus the border between areas can only exist within a router. In ISIS, L2 routers from differing areas communicate directly with one another, thus placing the area border directly on the link instead of in the router (see in Figure 2).
Figure 2. Area Borders; OSPF vs. ISIS
It was mentioned earlier that ISIS, like OSPF, maintains a single backbone area and multiple non-backbone areas. At this point, one might ask the question, "Where is the backbone area in ISIS?" The backbone area in ISIS is actually the set of all participating L2 routers, as shown in Figure 3.
Figure 3. The ISIS Backbone
Although used in TCP/IP networks to distribute IP related information, ISIS still an ISO protocol. Whereas other IP routing protocols leverage IP itself for transport, ISIS packets are carried directly over Layer 2 based on ISO-defined addressing semantics and encoding. Therefore, an ISO addressing structure must be configured within an ISIS domain in order to support the flow of ISIS traffic. In IP-only environments, it is typical to see one ISO-based address assigned per router throughout the domain. This address, although configured in the router configuration section, acts very much like a loopback interface in that it is software based and thus very stable. Like the loopback interface, this software interface will not change state as long as the router remains functional.
ISIS uses Network Service Access Point (NSAP) based addressing mechanisms. Most ISIS implementations use some variant of the ICD format. The following is a brief excerpt from Howard Berkowitz's book, Designing Addressing Architectures for Routing and Switching, which describes some of the more formal formats for NSAP based addressing:
|
NSAPs are used in ATM addressing and in ISIS, most commonly the ICD encapsulation: There are three potential formats for private ATM network endpoint identifiers and one for public network identifiers:
A given ATM system may support the public E.164 format, all three of the NSAP encodings, or both. ATM addressing format discussions speak in terms of the NSAP format. This can be confusing, because while the format of the OSI Network Service Access Point address is used, ATM does not use the OSI Network Service. The encoding of an NSAP address simply has proven convenient for identifying endpoints in a large network. NSAP addresses for ATM applications are 20 bytes long. They are split into an initial domain part (IDP) and a domain-specific part (DSP). In the IDP, the first byte, the authority and format identifier (AFI), defines the layout and length of the rest of the address. DCC codes identify countries. International Code Designator (ICD) codes identify internationally recognized countries, although, somewhat confusingly, some governments have multiple ICD values assigned to them. The U.S. government, for example, has 0004 for network research, 0005 for civilian agencies, and 0006 for military agencies. The E.164 15-digit format is defined for the largest network, the worldwide public telecommunications network. The DSP includes fields relevant to routing the call inside the ATM service identified by the IDP. The high-order domain specific part (HO-DSP) gives information needed to reach a specific point with an end system identifier (ESI). The Selector (SEL) byte is not used by the ATM network, but can be used to send information meaningful to the end station. |
ISO NSAP addresses, when used in ISIS networks, can take a number of forms; however, they follow the same general ISO-based structure. In ISO, each address represents a point of connection to the network, or a Network Service Access Point (NSAP). End nodes can have multiple NSAP addresses that are differentiated by the last byte known as the NSAP Selector. In ISO, the NSAP Selector indicates which upper layer process should receive a given PDU. This is similar to the way that TCP/UDP port numbers work in the TCP/IP protocol. The N Selector of 00 is reserved for the Network Entity Title (NET) for a particular NSAP address. The NSAP address also contains the Area ID of the router along with six bytes used to uniquely identify the router, known as the System ID. The Area ID itself can be defined with as little as one byte or as many as thirteen, depending on the addressing structure used. The following addresses all represent valid NETs.
Figure 4. Valid NETs
Naturally, good network designs make use of logically organized and reasonably meaningful addressing mechanisms. Some recognized and accepted conventions exist for the NET addressing.
Area ID: The most popular format for the Area ID is the OSI NSAP format. This format dictates the use of a single byte AFI and 1 to 12 bytes of domain or area identifier. Generally, the use of three bytes is sufficient for most large-scale networks. For example, 47.0001 can represent ISIS Area 1. It is important to note that the entire 3 bytes are considered to be the Area address, and thus, format conventions aside, the actual area address here is 47.0001.
System ID: The System ID must be configured using 6 bytes and must be unique throughout the domain. Usually one chooses between the MAC address from the router and an IP address configured on the router to populate this field. As the loopback address of a router tends to be strategically assigned, it is often wise to chose this address and represent it within the System ID using Binary Coded Decimal (BCD) notation. For example, the IP address 192.168.255.1 would translate to 1921.6825.5001 in BCD.
Configuring the ISIS NET on a Cisco router is done at the router configuration level. Using the global command, router isis, one enters the router configuration level for ISIS. From there, the following syntax can be used to enter a valid NET.
net network-entity-title
Keep in mind that the n-selector must be set to 00.
The following example enables the ISIS process and configures a NET with a system ID of 1501.0001.0001 and an area ID of 47.0001.
NewYork(config)#router isis NewYork(config-router)#net 47.0001.1501.0001.0001.00
During this initial configuration step, it is also wise to specify the system type, or level, in which the router will participate. In the router configuration mode, the command is-type is used to designate a router as L1, L2, or both. The default for this command is L1/L2. However, even if it is your intent to leave the router as L1/L2, for clarity reasons it is always wise to enter the command into the configuration.
The following example illustrates the command syntax used to designate a router as L1.
NewYork(config)#router isis NewYork(config-router)#is-type level-1
As with OSPF, before two routers begin to share link-state information, they must agree on a number of parameters and subsequently form an adjacency. First and foremost, they must share a common physical link so that they can transmit information between each other. Interestingly, unlike OSPF, which requires that a common IP subnet be shared across physical links, ISIS makes no such stipulation. This is essentially because ISIS makes use of direct Layer Two encapsulations and thus has no dependency on IP for direct communication. Hence, two physically connected routers could be adjacent and not be able to route IP packets directly between themselves. Interestingly, in this case, should a secondary path exist between the routers, IP packets can be forward from router to router around the misconfigured link. This can be a challenging mistake to uncover, and dictates that, when troubleshooting IP reachability over ISIS links, you check not only ISIS adjacencies, but also IP addressing.
ISIS adjacencies are formed between routers of the same level. For example, routers in an ISIS domain can be L1, L2, or both. L1 routers become adjacent only with other L1 routers and L2 routers form adjacencies only with other L2 routers. L1/L2 routers form separate adjacencies per level. For example, should a L1/L2 router become adjacent with another L1/L2 router, two separate adjacencies are formed. Should the same router form an adjacency with a single-level router, a single adjacency of the same level is formed. The following figure contains some examples.
Figure 5. ISIS Adjacency Variations
Keep in mind that ISIS domains are broken into areas. L2 routers route between areas and thus can and do form adjacencies with other routers with different Area IDs. However, L1 routers become adjacent only with routers with matching Area IDs.
Before adjacencies can be formed, the ISIS process must be up and running from a router configuration perspective with a valid NET assigned. From there, at least one more step must be taken. Just like OSPF, ISIS is turned up on an interface basis. To enable ISIS on a particular interface, the following interface level command is used:
ip router isis
The following example illustrates the proper syntax for turning up the ISIS process on interface S1 and E0 of this particular router.
NewYork(config)#interface ethernet 0 NewYork(config-if)#ip router isis NewYork(config-if)#exit NewYork(config)#interface serial 1 NewYork(config-if)#ip router isis
Here is a look at a more complete configuration inclusive of the basic commands necessary for a functional ISIS implementation.
interface Ethernet0 ip address 150.100.1.2 255.255.255.0 ip router isis ! interface Serial1 ip address 150.100.3.2 255.255.255.0 ip router isis ! router isis net 47.0001.1501.0001.0001.00
In order to verify your ISIS configuration, a number of commands are helpful. First, the show clns command is useful to verify that you've properly turned up the ISIS protocol for the correct area and interfaces. The following is the output of the show clns command for the router we configured above.
NewYork#sh clns Global CLNS Information: 2 Interfaces Enabled for CLNS NET: 47.0001.1501.0001.0001.00 Configuration Timer: 60, Default Holding Timer: 300, Packet Lifetime 64 ERPDU's requested on locally generated packets Running ISIS in IP-only mode (CLNS forwarding not allowed)
Notice that a number of key items appear in the output of this command, including the number of interfaces configured for CLNS routing, the area IDs setup on the router, as well as some timers. More detail on the specifics of the timers is provided when we look closely at the packets used by the ISIS protocol.
The show ip protocol command is also helpful when turning up routing protocols. It is always a good idea to become familiar with the output of commands of this nature when working with new protocols or configurations.
When the router has been entered into a valid ISIS network, some additional commands are used to verify that the correct neighbors have been identified and the corresponding adjacencies formed. Consider the basic topology in Figure 6.
Figure 6. A Sample ISIS Topology
The three routers in the diagram form a single, flat Level 1 topology. The area used in this case is 47.0001. Given the full mesh, one would anticipate that two neighbors have been found and two adjacencies formed on each router. In order to verify this, two commands are helpful. The command, show clns is-neighbors, is used to verify that neighbors have been found. The following is the output of the show clns is-neighbors command performed on the Ottawa router.
Ottawa#sh clns is-neighbors System Id Interface State Type Priority Circuit Id Format 1501.0001.0001 Se0 Up L1 0 00 Phase V 0000.0200.0001 Et0 Up L1 64 1501.0003.0001.0 Phase V
|
The command show clns neighbor can also be used to check adjacencies, however the output of the command is slightly varied from is-neighbors. Officially, show clns neighbors will show both ES and IS neighbors, though ES neighbors are irrelevant in IP-only ISIS environments. show clns is-neighbors includes the segment priorities for DIS purposes and thus I find it to be the better of the two similar show commands, though you can see neighbor status with either. |
This command provides a nicely summarized look at what ISIS neighbors have been located on which interfaces of the local router. The System ID is the unique six-byte identifier for the neighboring routers. As you can imagine, the more routers in a network, the more valuable it is to use meaningful System IDs so that you can easily recognize them within the output of commands such as this one. Along with System ID, a few other key pieces of information are present in this output. The State column actually indicates the status of the adjacency with the neighboring router while the Type column depicts the level of the adjacency. The Priority and Circuit ID columns have to do with the election of Designated Intermediate Systems (DISs) on multi-access segments. This is discussed later in this document.
Finally, the command show isis database displays the link state database currently in use by the router. Included in this output is a summary of the Link State Protocol Data Units (LSP) received from the set of routers adjacent to the local router. As previously mentioned, the databases of all routers in the same area of a stable topology must be identical for ISIS to function correctly. The following is the output of the show isis database command performed on the Ottawa router.
Ottawa#sh isis database ISIS Level-1 Link State Database LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL 0000.0200.0001.00-00 0x00000006 0x2F0F 829 0/0/0 0000.0200.0001.01-00 0x00000002 0x46F2 934 0/0/0 1501.0001.0001.00-00 0x0000000B 0x3821 872 0/0/0 1501.0003.0001.00-00 0x00000009 0x7984 843 0/0/0 1501.0003.0001.01-00 0x00000003 0x4ED0 836 0/0/0
The output of this command is fully examined below when we investigate the set of LSPs that ISIS uses in flat networks. Of note are the ATT, P, and OL bits explained below:
ATT: The Attached bit is set to indicate that the transmitting router is Level 1/2 and has connectivity to the L2 backbone. L1 participating routers can set a default route to that router. This is discussed further in the routing section.
P: The Partition bit is set to indicate that the transmitting router has repair partition capabilities. However, this functionality is not available in most ISIS implementations, including Cisco's, and thus is usually unset.
OL: The Overload bit is set to indicate that the transmitting router has an incomplete LSDB. Routers communicating with the transmitting router are only able to direct traffic destined to that router if the traffic is destined to that router's connected interfaces. If you think about it, this bit acts very much like a "road closed, local traffic only" sign. Routers are not able to direct traffic toward that router that would need to transit the router -- until the OL bit becomes unset, indicating that the router now has a complete view of the network.
Interestingly or confusingly, depending on your perspective, routers are able to have multiple area addresses. Cisco's implementation supports up to three area addresses per router. From an adjacency perspective, two L1 routers will form an adjacency if any one of their configured areas matches. Consider the diagram in Figure 7.
Figure 7. ISIS Adjacencies with Multiple Areas
The routers in Figure 7 are each members of two areas, yet only share one common area. These routers will form an adjacency. Keep in mind, however, that ISIS Area IDs only affect the formation of adjacencies. Once these two routers become adjacent, they will consider the Level 1 area as simply one area with multiple Area IDs, and IP routing will take place as normal.
You might ask, "Why on earth would you configure multiple areas if they are just going to end up treated as a single area anyway?" The answer is that an ISIS multi-area can be a very handy tool for networks in transition, allowing a phased approach to be taken with minimal disruption to connectivity during the migration from one Area ID to another. However, aside from networks in flux, it is generally advisable to lean toward simplicity and use only one Area ID per area.
The ISIS protocol has some unique characteristics related to networks that are multi-access in nature. In the following two sections we will look at ISIS on both broadcast and non-broadcast multi-access networks.
Much like OSPF, ISIS treats a broadcast medium differently from a typical point-to-point link. The concepts of the Pseudonode and Designated Intermediate System are introduced as a means of delivering more efficient flooding on mediums of this nature.
Consider the LAN segment depicted in Figure 8. Left alone, these four routers would each advertise the link state of the common LAN segment. As you may imagine, this doesn't represent the most effective use of resources since multiple routers are tracking and communicating state for the same medium. To make things more efficient, ISIS leverages the concept of a pseudonode that is used to represent the entire LAN segment. To the rest of the domain, the pseudonode looks like a normal router. Among the routers connected to the segment, a designated intermediate system (DIS) is elected to represent the pseudonode to the rest of the network. Now, instead of the area being flooded with multiple LSPs from multiple routers describing the same connectivity, the rest of the network sees only the pseudonode advertisement from the DIS. The rest of the routers on the segment can then advertise a single link to the pseudonode while the DIS, on behalf of the pseudonode, advertises a single link to each router. Thus LSP flooding in the area is drastically reduced.
Figure 8. The Designated Intermediate System
The DIS election takes place using Hello packets. A Hello packet contains a Priority field that sets a particular interface's DIS priority value. This value can range from 1-127 and is set to 64 by default. The router with the highest priority becomes the DR. Should there be a tie, the highest MAC address (SNPA) among the tying routers will indicate the DIS. Given that the MAC address is a unique identifier, no further tiebreaker values are required. By looking at the output of the show clns is-neighbors command, the DIS can be identified from the circuit ID column. Here again is the output of the show clns is-neighbors command
System Id Interface State Type Priority Circuit Id Format
1501.0001.000 1 Se0 Up L1 0 00 Phase V
0000.0200.000 1 Et0 Up L1 64 1501.0003.0001.0 Phase V
The Priority and Circuit ID columns are pertinent to DIS elections. As you can imagine, the Priority column lists the configured or default DIS priority for the interface in question. The Circuit ID lists the LAN ID of the DIS for the segment. A LAN ID is simply a concatenation of the router's System ID and Circuit ID. The appended Circuit ID simply differentiates the router's various interfaces and generally starts at 00 and increments. In the example, you can see that the router with the System ID 1501.0003.0001 is the DIS for this router's E0 segment.
The DIS priority can be modified by using the interface command isis priority. It should be noted that because adjacencies are formed on a Level basis, a separate DR is elected for each of L1 and L2 adjacencies. As such, one must set the DR priority for each level in which a particular interface participates. The following example illustrates the syntax for setting the L1 and L2 DR priorities.
Chicago(config)#int e0 Chicago(config-if)#isis priority 100 level-1 Chicago(config-if)#isis priority 100 level-2
After entering this command, looking at the show clns is-neighbors on the neighboring router displays the updated priority.
NewYork#sh clns is-nei System Id Interface State Type Priority Circuit Id Format Chicago Et0 Up L1 100 Chicago.01 Phase V 1501.0003.000 1 Se1 Up L1 0 00 Phase V
Also notice that the more readable hostname of the Chicago router has been substituted for the System ID. More recent ISIS implementations (this one is 12.0(5)) support the dynamic mapping of System IDs to hostnames. There is an ISIS TLV (Type/Length/Value) that supports the propagation of hostnames that makes this possible.
ISIS handles the LAN somewhat differently from OSPF. Whereas OSPF elects both a DR and Backup DR (BDR), ISIS elects only the DIS. Furthermore, whereas routers in an OSPF network only form adjacencies with the DR and BDR, routers in the ISIS network form adjacencies with all other routers on the segment.
There are a couple of reasons for these differences. One of the most significant has to do with the way link state information is flooded on the LAN. In ISIS, routers simply send LSPs once to a multicast address on the segment and do not require an acknowledgement from the other routers on the segment to indicate that the LSP was received successfully. In OSPF, however, the DR is responsible for receiving an explicit acknowledgement for each Link State Advertisement (LSA) transmitted on the segment.
This might suggest that LSDBs in ISIS would have a tendency to become out of synch more often than those in OSPF. However, ISIS compensates for the lack of explicit acknowledgements by having the DIS periodically transmit an update known as the Complete Sequence Numbers Packet (CSNP). The CSNP describes the set of all known LSPs by the DR and should match the LSDBs for each router on the segment. Should a router notice that a particular LSP is missing, it will multicast that LSP to the segment. Should a router notice that it is missing one or more LSPs, it will multicast a Partial Sequence Numbers Packet (PSNP) to indicate which LSPs it is missing. The DIS will respond to the PSNP and multicast the missing LSPs. The upcoming section on PDU structure will fully detail the contents of both CSNP and PSNP packets.
Non Broadcast Multi Access Networks (NBMA) such as Frame Relay and ATM generally require some additional attention when configuring routing protocols. These types of networks possess no inherent broadcasting capabilities and therefore routing protocols that depend on broadcasting over multi-access media for neighbor-to-neighbor communications need some help to properly function here. In general, it is necessary to instruct the routers connected to such media to either treat it as a set of point-to-point links or a single broadcast domain. Cisco offers a number of configuration options at Layer Two including the use of physical interfaces with frame relay maps or frame relay interface-dlci statements, or the use of point-to-point and point-to-multipoint sub interfaces. However, not all of these options work well with ISIS, and care must be taken with all such that a given topology works as you intend.
Those familiar with the OSPF protocol likely are familiar with the ip ospf network type command. This command is necessary to support the OSPF adjacency formation process in situations where different Layer Two configuration options are used on different routers connected to the same medium. Without it, network type mismatches are bound to occur. It was previously mentioned that ISIS-speaking routers would form an adjacency only when they have agreed to a set of criteria. As with OSPF, one of those criteria happens to be network type.
ISIS supports two network types: broadcast and point-to-point. Should one router on a segment decide that the network is point-to-point and another router on the same segment decide on LAN, the adjacency formation process will not be successful as the routers do not agree on the network type. Indeed, in this case, one router will be using LAN hellos, the other Point-to-Point hellos. This type of mismatch will actually affect all types of networks and thus is not limited to NBMA networks. However, the likelihood of it occurring on an NBMA network is much greater.
For example, in a frame network, should one decide to use point-to-point sub-interfaces on one router and point-to-multipoint interfaces on the other, the default ISIS Hellos transmitted will not match and the adjacency will not be formed. This naturally assumes all other parameters like level and area etc are configured correctly. Unlike OSPF where one can manually override the routers default behavior with the ip ospf network command, Cisco has no such knob in its ISIS implementation. Hence, it becomes necessary to use the same types of interfaces on NBMA networks to ensure that the necessary adjacencies can be formed.
The following table illustrates how ISIS treats the four different ways to configure a frame relay interface. Given that you cannot change the ISIS behavior in each case, understanding these dependencies will enable you make wise decisions when planning networks and naturally avoid unnecessary troubleshooting when adjacencies are not formed due to incompatible ISIS network types. The troubleshooting section details some helpful debug commands in the event that you suspect a network type mismatch.
| Frame Relay Configuration | ISIS Network Type |
| Physical Interface | Broadcast |
| Point to Point Sub-Interface | Point to point |
| Point to Multi Point Sub-Interface | Broadcast |
When configuring broadcast network types in partial mesh, hub-and-spoke environments, it is essential to ensure that the hub router becomes the DIS for the segment. In this setup, spoke routers that are not connected directly via PVCs will not hear one another's LSPs directly and therefore LSDB synchronization will not work properly. However, so long as the hub router is the DIS, the CSNP process will allow spokes to request with PSNP those LSPs they do not properly receive, thereby bringing the LSDB into proper synchronization. The interface command isis priority value can be used as previously described to influence the DIS election, with the highest priority winning out.
Additionally, when not using frame-relay interface-dlci commands, it is necessary to add the command frame-relay map clns dlci broadcast to each interface that is to participate in the OSPF process. Doing so will enable the ISO packets to be mapped properly to the appropriate DLCIs.
If given a choice, I personally find that using point-to-point subinterfaces at both hub and spoke(s) to be the most straightforward to configure, as you also eliminate any distance vector split horizon issues at the hub router. However, in the CCIE Lab, should a physical interface be required at the hub, or a point to multipoint interface, using frame-relay interface-dlci or maps for CLNS and IP work equally well. The key point is to ensure that both hub and spoke(s) agree on the network type.
[IE-ISIS-WP2-F02]
[2002-10-30-01]
|