This is a Tutorial excerpt from ISIS I: Routing In Single Areas by Peter A. Van Oene.

If you're not a Certification Zone Subscriber and you would like complete, unrestricted access to the rest of this and every other Tutorial, Study Quiz, Lab Scenario, and Practice Exam available at Certification Zone, become a Subscriber today!

Building the ISIS Foundation

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.

Overview

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.

Area Structure

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

Addressing

Do I need CLNS routing enabled for ISIS IP routing?

It is commonly misunderstood that ISIS uses CLNP PDUs for communication, which leads to the question of whether or not one requires CLNS routing enabled on a given router for ISIS routing of IP to occur. ISO 10589, the ISO document that defines the ISIS protocol, actually defines a set of ISIS PDUs to be used exclusively for ISIS routing. Beyond those PDUs, ISIS borrows some ES-IS (ISO 9542) PDUs for use in hello mechanisms. However, no actual CLNP PDUs, as defined in ISO 8473, are used to support the ISIS protocol. Here is a list of the PDUs used in ISIS as described in ISO 10589:

  • ESH PDU ISO 9542 End System Hello Protocol Data Unit
  • ISH PDU ISO 9542 Intermediate System Hello Protocol Data Unit
  • RD PDU ISO 9542 Redirect Protocol Data Unit I
  • IH Intermediate system to Intermediate system Hello Protocol Data Unit
  • LSP Link State Protocol Data Unit
  • SNP Sequence Numbers Protocol Data Unit
  • CSNP Complete Sequence Numbers Protocol Data Unit
  • PSNP Partial Sequence Numbers Protocol Data Unit

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:

  • NSAP encoding of International Code Designator (ICD), a format that allows the registration of blocks for recognized international organizations

  • NSAP encoding of E.164 public ISDN, which encodes the same E.164 phone numbers as the basic E.164 specification, but as 64 bits rather than 15 decimal digits.

  • OSI NSAP using ISO 3166 country codes, a format that allows the registration of national networks

  • E.164 for public interconnection, using decimal encoding.

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.

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

ISIS and Tags

The router isis command actually enables the addition of a tag within the syntax. This tag can be used to differentiate ISIS processes on the router should you be using more than one. Typically, a meaningful name is used. This tag is significant only to the local router, much like an OSPF Process ID. The tag is not mandatory, and should you exclude it, Cisco will default a null tag.

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

Forming Adjacencies

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

Link State Databases in ISIS & OSPF

Those familiar with the OSPF protocol will recall that the link state database in OSPF for a particular area contains a variety of LSA types, depending on the nature of the information a particular router is advertising. Furthermore, a single router may originate multiple different LSAs depending on that router's role in the network. Finding out what a particular router advertises can therefore be a multistage process. In contrast, the ISIS database includes a single LSP for every router in the area and thus one can look simply at that LSP to ensure that a particular router is behaving correctly.

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:

Multi-Area

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.

Multi-Access Networks

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.

LANs

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.

LANs - The Designated Intermediate System

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.

LANs - Flooding on the LAN

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.

Behavior Differences when New Routers Join LANs

ISIS and OSPF behave somewhat differently when new routers are introduced to otherwise stable LANs. Since OSPF routers only maintain adjacencies to the DR and BDR, changing DRs requires a significant amount of adjacency rebuilding. Furthermore, an OSPF DR accumulates and maintains significant state information with respect to the rest of the routers on the LAN. For these reasons, OSPF attempts not to perform DR transitions if at all possible. This is a key reason why OSPF maintains a BDR as well. DISs in ISIS networks, on the other hand, are not required to maintain the same amount of state due to not having to continuously keep track of which routers have acknowledged which LSPs. Furthermore, ISIS routers maintain adjacencies with all other routers on the segment to begin with, and changing DISs can take place without any modification of the existing adjacencies. Hence, DIS reelection can take place relatively quickly and does not represent the same issues as it does in OSPF networks. For this reason, should a new router with a higher priority enter into a stable ISIS network, a reelection will take place. Whereas, should the same event occur on an OSPF LAN, the existing DR would be preserved. Because of this, it is said that ISIS is deterministic in its DIS selection since the highest priority router will generally be the DIS. Whereas in OSPF, the first router active on the segment tends to assume the DR role.

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.

NBMA Networks

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 ConfigurationISIS Network Type
Physical InterfaceBroadcast
Point to Point Sub-InterfacePoint to point
Point to Multi Point Sub-InterfaceBroadcast

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]

This is a Tutorial excerpt from ISIS I: Routing In Single Areas by Peter A. Van Oene.

If you're not a Certification Zone Subscriber and you would like complete, unrestricted access to the rest of this and every other Tutorial, Study Quiz, Lab Scenario, and Practice Exam available at Certification Zone, become a Subscriber today!