Chapter 9

Troubleshooting Intermediate System-Intermediate System (IS-IS)

This chapter covers the following topics:

• IS-IS Fundamentals

• Troubleshooting IS-IS Adjacency Issues

• Troubleshooting Missing Routes

• Troubleshooting IS-IS Path Selection

Intermediate System-to-Intermediate System (IS-IS) is a link-state routing protocol that is commonly found in service providers and some enterprise networks. IS-IS provides fast convergence, supports a large number of networks, and can support multiple protocols. Cisco uses IS-IS in a lot of underlying technologies, such as Overlay Transport Virtualization (OTV), Application Centric Infrastructure (ACI), and Software Defined Access (SD-Access).

This chapter focuses on identifying and troubleshooting issues that are caused with forming IS-IS neighbor adjacency, path selection, missing routes, and problems with convergence.

• L1 ← → L1

• L2 ← → L2

• L1-L2 ← → L1

• L1-L2 ← → L2

• L1-L2 ← → L1-L2

IS-IS uses the link-state packets (LSP) for building a link-state packet database (LSPDB) similar to OSPF’s link-state database (LSDB). IS-IS then runs the Dijkstra Shortest Path First (SPF) algorithm to construct a loop-free topology of shortest paths.

Figure 9-1 demonstrates these basic differences between OSPF and IS-IS. Notice that the IS-IS backbone extends across four areas, unlike OSPF’s backbone, which is limited to Area 0.

Figure 9-1 Comparison of Areas Between OSPF and IS-IS

In Figure 9-2, NX-1 and NX-2 form an L1 adjacency with each other, and NX-4 and NX-5 form an L1 adjacency with each other. Although NX-2 and NX-4 are L1-L2 routers, NX-1 and NX-5 support only an L1 connection. The area address must be the same to establish an L1 adjacency. NX-2 establishes an L2 adjacency with NX-3, and NX-3 establishes an L2 adjacency with NX-4. NX-2 and NX-4 are L1-L2 routers and can form an L1 and L2 adjacency on them.

Figure 9-2 IS-IS Adjacencies

All L1 IS-IS routers in the same level maintain an identical copy of the LSPDB, and all L1 routers do not know about any routers or networks outside of their level (area). In a similar fashion, L2 routers maintain a separate LSPDB that is identical with other L2 routers. L2 routers are aware only of other L2 routers and networks in the L2 LSPDB.

L1-L2 routers inject L1 prefixes into the L2 topology. L1-L2 routers do not advertise L2 routes into the L1 area, but they set the attached bit in their L1 LSP, indicating that the router has connectivity to the IS-IS backbone network. If an L1 router does not have a route for a network, it searches the LSPDB for the closest router with the attached bit, which acts as a route of last resort.

The dynamic length in the Inter-Domain Part (IDP) portion of the NET address causes unnecessary confusion. Instead of reading the NET address left to right, most network engineers read the NET address from right to left. In the most simplistic form, the first byte is always the selector (SEL) (with a value of 00), with the next 6 bytes as the system ID, and the remaining 1 to 13 bytes are the Area Address, as shown in Figure 9-3.

Figure 9-3 Expanded NSAP Address Structure

Figure 9-4 demonstrates three variations of NET addressing:

• A simple 8-byte NET address structure. The Authority and Format Identifier (AFI) is not needed because the length does not enter into the Inter-Domain Part (IDP) portion of the NSAP address. Notice that the Area Address is 1-byte, which provides up to 256 unique areas.

• A common 10-byte NET address structure. The private AFI (49) is used, and the area uses 2 bytes, providing up to 65,535 unique areas. Notice that the Area Address is 49.1234.

• Typical Open System Interconnection (OSI) NSAP address that includes the domain address. Notice that the Area Address is 49.0456.1234 and that the private AFI (49) is used.

Figure 9-4 Example NET Address Structures

IS protocol data units (PDU) (packets) follow a common header structure that identifies the type of the PDU. Data specific to each PDU type follows the header, and the last fields use optional variable-length fields that contain information specific to the IS PDU type.

IS packets are categorized into three PDU types, with each type differentiating between L1 and L2 routing information:

• IS-IS Hello (IIH) Packets: IIH packets are responsible for discovering and maintaining neighbors.

• Link State Packets (LSP): LSPs provide information about a router and associated networks. Similar to an OSPF LSA, except OSPF uses multiple LSAs.

• Sequence Number Packets (SNP): Sequence number packets (SNP) control the synchronization process of LSPs between routers.

  • Complete sequence number packets (CSNP) provide the LSP headers for the LSPDB of the advertising router to ensure the LSPDB is synchronized.

  • Partial sequence number packets (PSNP) acknowledge receipt of a LSP on point-to-point networks and request missing link state information when the LSPDB is identified as being out of sync.

Table 9-1 provides an explanation for the fields listed in the IS Protocol Header.

ISO 10589 states that a value of 0 in the IS packet header is treated in a special way in for the IS Type, LSPF Database Overload Bit, and Maximum Area Addresses field. A value of zero infers the default setting indicated in Table 9-1.

TLVs provide functionality and scalability to the IS protocol. Developing new features for the IS protocol involves the addition of TLVs to the existing structure. For example, IPv6 support was added to the IS protocol by adding TLV #232 (IPv6 Interface Address) and #236 (IPv6 Reachability).

ISO standards classify network media into two categories: broadcast and general topology.

Broadcast networks provide communication to multiple devices with a single packet. Broadcast interfaces communicate in a multicast fashion using well-known Layer 2 addresses so that only the nodes running IS-IS process the traffic. IS-IS does not send unicast traffic on broadcast network types, because all routers on the segment should be aware of what is happening with the network.

Table 9-2 provides a list of destination MAC addresses used for IS communication.

General topology networks are based off network media that allows communication only with another device if a single packet is sent out. General topology networks are often referred to in IS-IS documentation as point-to-point networks. Point-to-point networks communicate with a directed destination address that matches the Layer 2 address for the remote device. NBMA technologies such as Frame Relay may not guarantee communication to all devices with a single packet. A common best practice is to use point-to-point subinterfaces on NMBA technologies to ensure proper communication between IS-IS nodes.

Routers that form an L1-L2 adjacency with another IS-IS router send both L1 and L2 IIHs on broadcast links. To save bandwidth on WAN links, point-to-point links use the Point-to-Point Hello, which services both L1 and L2 adjacencies.

Table 9-3 provides a brief overview of the five IS Hello packet types.

Table 9-4 provides a brief list of information included in the IIH Hello Packet.

Table 9-5 provides a list of common TLVs found in IIH PDUs.

• System ID (6 bytes): The system ID is extracted from the NET address configured on the router.

• Pseudonode ID (1 byte): The pseudonode ID identifies the LSP for a specific pseudonode (virtual router) or for the physical router. LSPs with a pseudonode ID of zero describe the links from the system and can be called non-pseudonode LSPs.

  LSPs with a nonzero number indicate that the LSP is a pseudonode LSP. The pseudonode ID correlates to the router’s circuit ID for the interface performing the designated intermediate system (DIS) function. The pseudonode ID is unique among any other broadcast segments for which the same router is the DIS on that level. Pseudonodes and DIS are explained later in this chapter.

• Fragment ID (1 byte): If an LSP is larger than the max MTU value of the interface it needs to be sent out of, that LSP must be fragmented. IS-IS fragments the LSP as it is created, and the fragment-ID allows the receiving router to process fragmented LSPs.

Figure 9-5 shows two LSP IDs. The LSP ID on the left indicates that it is for a specific IS router, and the LSP ID on the right indicates that it is for the DIS because the pseudonode ID is not zero.

Figure 9-5 LSP ID Structure

• Partition Bit: The partition bit identifies whether a router supports the capability for partition repair. Partition repair allows a broken L1 area to be repaired by L2 routers that belong to the same area as the L1 routers. Cisco and most other network vendors do not support partition repair.

• Attached Bit: The next four bits reflect the attached bit set by a L1-L2 router connected to other areas via the L2 backbone. The attached bit is in L1 LSPs.

• Overload Bit: The overload bit indicates when a router is in an overloaded condition. During SPF calculation, routers should avoid sending traffic through this router. Upon recovery, the router advertises a new LSP without the overload bit, and the SPF calculation occurs normally without avoiding routes through the previously overloaded node.

• Router Type: The last two bits indicate whether the LSP is from a L1 or L2 router.

IS-IS overcomes this inefficiency by creating a pseudonode (virtual router) to manage the synchronization issues that arise on the broadcast network segment. A router on the broadcast segment, known as the Designated Intermediate System (DIS), assumes the role of the pseudonode. If the acting DIS router fails, another router becomes the new DIS and assumes the responsibilities. A pseudonode and DIS exist for each IS-IS level (L1 and L2) which means that a broadcast segment can have two pseudonodes and two DISs.

By inserting the logical pseudonode into a broadcast segment, the multi-access network segment is converted into multiple point-to-point networks in the LSPDB.

The DIS advertises a pseudonode LSP that indicates the routers that attach to the pseudonode. The pseudonode LSP acts like an OSPF Type-2 LSA because it indicates the attached neighbors and informs the nodes which router is acting as the DIS. The system IDs of the routers connected to the pseudonode are listed in the IS Reachability TLV with an interface metric set to zero because SPF uses the metric for the non-pseudonode LSPs for calculating the SPF tree.

The pseudonode advertises the complete sequence number packets (CSNP) every 10 seconds. IS-IS routers check their LSPDBs to verify that all LSPs listed in the CSNP exist, and that the sequence number matches the version in the CSNP.

• If an LSP is missing or the router has an outdated (lower sequence number) LSP than what is contained in the CSNP, the router advertises a partial sequence number packet (PSNP) requesting the correct or missing LSP. All IS-IS routers receive the PSNP, but only the DIS sends out the correct LSP, thereby reducing traffic on that network segment.

• If a router detects that the sequence number in the CSNP is lower than the sequence number for any LSP that is stored locally in its LSPDB, it advertises the local LSP with the higher sequence number. All IS-IS routers receive the LSP and process it accordingly. The DIS should send out an updated CSNP with the updated sequence number for the advertised LSP.

• Intra-area routes are routes that are learned from another router within the same level and area address.

• Inter-area routes are routes that are learned from another L2 router that came from a L1 router or from a L2 router from a different area address.

• External routes are routes that are redistributed into the IS-IS domain. External routes can choose between two metric types:

  • Internal metrics are directly comparable with IS-IS path metrics and are selected by default by Nexus switches. IS-IS treats these routes with the same preferences as those advertised normally via TLV #128.

  • External metrics cannot be comparable with internal path metrics.

IS-IS best-path selection follows the processing order shown in the following steps to identify the route with the lowest path metric for each stage.

Step 1. L1 intra-area routes

L1 external routes with internal metrics

Step 2. L2 intra-area routes

L2 external routes with internal metric

L1→L2 inter-area routes

L1→L2 inter-area external routes with internal metrics

Step 3. Leaked routes (L2→L1) with internal metrics

Step 4. L1 external routes with external metrics

Step 5. L2 external routes with external metrics

L1→L2 inter-area external routes with external metrics

Step 6. Leaked routes (L2→L1) with external metrics

Step 1. Enable the IS-IS feature. The IS-IS feature must be enabled with the global configuration command feature isis.

Step 2. Define an IS-IS process tag. The IS-IS process must be defined with the global configuration command router isis instance-tag. The instance-tag can be up to 20 alphanumeric characters in length.

Step 3. Define the IS-IS NET address. The NET address must be configured with the command net net-address.

Step 4. Define the IS-IS type (optional). By default, Nexus switches operate at L1-L2 IS-IS types. This means that an L1 adjacency is formed with L1 neighbors, a L2 adjacency is formed with L2 neighbors, and two sessions (L1 and L2) are formed with another L1-L2 IS-IS peer.

The IS-IS router type is changed with the command is-type {level-1 | level- 1-2 | level-2}.

Step 5. Enable L1 route propagation to L2 networks (optional). Nexus switches do not propagate L1 networks to L2 networks automatically. The command distribute level-1 into level-2 {all | route-map route-map-name}.

Step 6. Enable IS-IS on interfaces. The interface that IS-IS is enabled on is selected with the command interface interface-id. The IS-IS process is then enabled on that interface with the command ip router isis instance-tag.

The configuration in Example 9-1 enables IS-IS only on interfaces Ethernet1/1, VLAN 10, and Loopback 0.

Example 9-1 Baseline IS-IS Configuration

Click here to view code image

IS-IS requires that neighboring routers form an adjacency before LSPs are processed. The IS-IS neighbor adjacency process consists of three states: down, initializing, and up. This section explains the process for troubleshooting IS-IS neighbor adjacencies on Nexus switches.

Figure 9-6 provides a simple topology with two Nexus switches that are used to explain how to troubleshoot IS-IS adjacency problems.

Figure 9-6 Simple Topology with Two NX-OS Switches

Example 9-2 displays the output of the nondetailed command on NX-1. Notice that there is an entry for the L1 adjacency and a separate entry for the L2 adjacency. This is expected behavior for L1-L2 adjacencies with other routers.

Example 9-2 Display of IS-IS Neighbors

Click here to view code image

Table 9-7 provides a brief overview of the fields used in Example 9-2. Notice that the Holdtime for NX-2 is relatively low because NX-2 is the DIS for the 10.12.1.0/24 network.

Example 9-3 displays the show isis adjacency command using the summary and detail keywords. Notice that the optional detail keyword provides accurate timers for transition states for a particular neighbor.

Example 9-3 Display of IS-IS Neighbors with summary and detail Keywords

Click here to view code image

Besides enabling IS-IS on the network interfaces on Nexus switches, the following parameters must match for the two switches to become neighbors:

• IS-IS interfaces must be Active.

• Connectivity between devices must exist using the primary subnet.

• MTU matches.

• L1 adjacencies require the area address to match the peering L1 router, and the system ID must be unique between neighbors.

• L1 routers can form adjacencies with L1 or L1-L2 routers, but not L2.

• L2 routers can form adjacencies with L2 or L1-L2 routers, but not L1.

• DIS requirements match.

• IIH Authentication Type & Credentials (if any).

Some of the output in Example 9-4 has been omitted for brevity, but the following relevant information is shown in the output:

• The IS-IS interface is operating as a L1-L2 interface (Cisco default).

• The Default MTU is 1500 for Ethernet.

• The LAN ID (pseudonode ID) is NX-1.01.

• L1 and L2 metrics are set to 10 (Cisco default).

• Two IS-IS adjacencies have formed at the L1 and L2 level.

• The priority for the interface is 64 for L1 and L2 (Cisco default).

• The IS-IS interface is operating as a L1-L2 interface (Cisco default).

• The Default MTU is 1500 for Ethernet.

• The LAN ID (pseudonode ID) is NX-1.01.

• L1 and L2 metrics are set to 10 (Cisco default).

• Two IS-IS adjacencies have formed at the L1 and L2 level.

• The priority for the interface is 64 for L1 and L2 (Cisco default).

Example 9-4 IS-IS Interface Verification

Click here to view code image

The command show isis lists the IS-IS interfaces and provides an overview of the IS-IS configuration for the router that might seem more efficient. Example 9-5 displays the command. Notice that the System ID, MTU, metric styles, area address, and topology mode are provided.

Example 9-5 IS-IS Protocol Verification

Click here to view code image

Example 9-6 Identification if Passive IS-IS Is Configured for a Level

Click here to view code image

Now that a passive interface has been identified, the configuration must be examined for the following:

• The interface parameter command isis passive-interface {level-1 | level-2 | level-1-2}, which makes only that interface passive for the specified IS-IS level.

• The global IS-IS configuration command passive-interface default {level-1 | level-2 | level-1-2}, which makes all interfaces under that IS-IS process passive. The interface parameter command no isis passive-interface {level-1 | level-2 | level-1-2} takes precedence over the global command and makes that interface active.

Example 9-7 displays the configuration on NX-1 and NX-2 that prevents the two Nexus switches from forming an IS-IS adjacency on L1 or L2. The Ethernet1/1 interfaces must be active on both switches per IS-IS level for an adjacency to form. The interfaces can be made active by removing the command isis passive-interface level-1 from Ethernet1/1 on NX-1 and setting the command no isis passive-interface level-1-2 to Interface Ethernet1/1 on NX-2 to allow an adjacency to form on L1 and L2.

Example 9-7 IS-IS Configuration with Passive Interfaces

Click here to view code image

Example 9-8 displays the use of this command. Notice that there is a separation of authentication errors from other errors. Executing the command while specifying an interface provides more granular visibility to the packets received or transmitted for an interface.

Example 9-8 IS-IS Traffic Statistics

Click here to view code image

Debug functionality is used to acquire granularity on various processes on the router. Specifically, the command debug isis {adjacency | iih | lsp {flooding | generation}} displays the processing of packets that have reached the supervisor on the switch. This allows for users to verify whether packets were received or advertised from a router.

Example 9-9 displays the transmission and receipt of L1 and L2 IIH packets.

Example 9-9 IS-IS Hello Debugs

Click here to view code image

Debug commands are generally the least preferred method for finding root cause because of the amount of data that could be generated while the debug is enabled. NX-OS provides event-history that runs in the background without performance hits that provides another method of troubleshooting. The command show isis event-history [adjacency | dis | iih | lsp-flood | lsp-gen] provides helpful information when troubleshooting IS-IS. The iih keyword provides the same information as the debug command in Example 9-9.

Example 9-10 displays the show isis even-history iih command. Examine the difference in the sample output on NX-1 with the previous debug output. There is not much difference of information.

Example 9-10 Hello Packet Visibility from IS-IS Event-History

Click here to view code image

Performing IS-IS debugs shows only the packets that have reached the supervisor CPU. If packets are not displayed in the debugs or event-history, further troubleshooting must be taken by examining quality of service (QoS) policies, control plane policing (CoPP), or just verification of the packet leaving or entering an interface.

QoS policies may or may not be deployed on an interface. If they are deployed, the policy-map must be examined for any drop packets, which must then be referenced to a class-map that matches the IS-IS routing protocol. The same process applies to CoPP policies because they are based on QoS settings as well.

Example 9-11 displays the process for checking a switch’s CoPP policy with the following logic:

1. Examine the CoPP policy with the command show running-config copp all. This displays the relevant policy-map name, classes defined, and the police rate.

2. Investigate the class-maps to identify the conditional matches for that class-map.

3. After the class-map has been verified, examine the policy-map drops for that class with the command show policy-map interface control-plane. If drops are found, the CoPP policy needs to be modified to accommodate a higher IS-IS packet flow.

Example 9-11 Verification of CoPP for IS-IS

Click here to view code image

Another technique to see if the packets are reaching the Nexus switch is to use the built in Ethanalyzer. The Ethanalyzer is used because IS-IS uses Layer 2 addressing, which restricts packet captures on Layer 3 ports. The command ethanalyzer local interface inband [capture-filter “ether host isis-mac-address”] [detail] is used. The capture-filter restricts traffic to specific types of traffic, and the filter ether host isis-mac-address restricts traffic to IS-IS based on the values from Table 9-2. The optional detail provides a packet-level view of any matching traffic. The use of Ethanalyzer is shown in Example 9-12 to identify L2 IIH packets.

Example 9-12 Verification of IS-IS Packets Using Ethanalyzer

Click here to view code image

The subnet mask was changed on NX-2 from 10.12.1.200/24 to 10.12.1.200/25 for this section. This places NX-2 in the 10.12.1.128/25 network, which is different from NX-1 (10.12.1.100).

When examining the IS-IS neighbor table, note that NX-1 is in INIT state with NX-2, but NX-2 does not detect NX-1. This is shown in Example 9-13.

Example 9-13 NX-1 Stuck in INIT State with NX-2

Click here to view code image

The next plan of action is to check the IS-IS event-history for adjacency and IIH on NX-1 and NX-2. NX-1 has adjacency entries for NX-2, whereas NX-2 does not have any adjacency entries. After checking the IIH event-history, NX-2 displays that it cannot find a usable IP address, as shown in Example 9-14.

Example 9-14 NX-1 and NX-2 Event-History

Click here to view code image

The next step is to check and correct IP addressing/subnet masks on the two IS-IS router’s interfaces so that connectivity is established.

To demonstrate the troubleshooting process for mismatch MTU, the MTU on NX-1 is set to 1000, whereas the MTU remains at 1500 for NX-2.

The first step is to check the IS-IS adjacency state as shown in Example 9-15. NX-1 does not detect NX-2, whereas NX-2 detects NX-1.

Example 9-15 NX-1 Does Not Detect NX-2

Click here to view code image

The next step is to examine the IS-IS IIH event-history to identify the problem. In Example 9-16, NX-1 is sending IIH packets with a length of 997, and they are received on NX-2. NX-2 is sending IIH packets with a length of 1497 to NX-1, which are received. The length of the IIH packets indicates an MTU problem.

Example 9-16 NX-1 IS-IS Adjacency Event-History with MTU Mismatch

Click here to view code image

MTU is examined on both switches by examining the MTU values with the command show interface interface-id and looking for the MTU value, as shown in Example 9-17. The MTU on NX-2 is larger than NX-1.

Example 9-17 Examination of Interface’s MTU

Click here to view code image

Cisco introduced a feature that disables the MTU padding after the router sends the first five IIHs out of an interface. This eliminates wasted bandwidth while still providing a mechanism for checking the MTU between routers. Nexus switches disable the IIH padding with the interface parameter command no isis hello padding [always]. The always keyword does not pad any IIH packets, which allows NX-1 to form an adjacency but could result in problems later. The best solution is to modify the interface MTU to the highest MTU that is acceptable between the two device’s interfaces.

Example 9-18 Duplicate System-ID

Click here to view code image

Typically, a duplicate System-ID occurs when the IS-IS configuration from another switch is copied. The System-ID portion of the NET address needs to be changed for an adjacency to form.

Example 9-19 displays NX-1 and NX-2’s IS-IS adjacency tables. Notice that both Nexus switches have established an L2 adjacency, but there is not an L1 adjacency like those shown previously in this chapter.

Example 9-19 Only an L2 IS-IS Adjacency

Click here to view code image

Through logical deduction, NX-1 and NX-2 can establish and maintain bidirectional transmission of IS-IS packets because the L2 adjacency is established. This indicates incorrect authentication parameters, invalid timers, or that the area numbers do not match.

Example 9-20 displays the IS-IS event-history for NX-1 and NX-2. Notice that the error message No common area is displayed before the message indicating that the L1 IIH is received.

Example 9-20 IS-IS Event-History Indicates Different Areas

Click here to view code image

The final step is to verify the configuration and check the NET Addressing. Example 9-21 displays the NET entries for NX-1 and NX-2. NX-1 has an area of 49.0012 and NX-2 has an area of 49.0002.

Example 9-21 Verification of NET Addressing

Click here to view code image

Changing the area portion of the NET address to match on either Nexus switch allows for the L1 adjacency to form.

The IS-IS level that a Nexus switch operates at is set with the IS-IS configuration command is-type {level-1 | level-1-2 | level-2-only).

The setting is verified by looking at the IS-IS process as shown in Example 9-22.

Example 9-22 Verification of IS-IS Process Level Type

Click here to view code image

Other topology designs may specify that a specific interface should establish only a specific IS-IS level adjacency. This is accomplished with the interface parameter command isis circuit-type {level-1 | level-1-2 | level-2-only}.

This setting is verified by looking at the IS-IS process as shown in Example 9-23. Notice that Ethernet1/1 is set to allow only L1 connections.

Example 9-23 Verification of IS-IS Interface Level Type

Click here to view code image

It is possible to set the Nexus switch to a specific IS-IS level functionality with a different setting for a circuit from the global IS-IS setting. When the settings are combined, the Nexus switch uses the most restrictive level when forming an adjacency. Table 9-8 displays the capable adjacencies for a router based solely on the IS-IS router type, and IS-IS circuit-type.

If IIH packets are missing from the event-history, the IS-IS Router and Interface-level settings need to be verified on both routers.

An adjacency will not form between IS-IS Nexus switches that have one broadcast interface and an IS-IS point-to-point interface. Neither device shows an IS-IS adjacency, but the general topology switch reports the message Fail: Receiving P2P IIH over LAN interface xx in the IS-IS IIH event-history. IS-IS event-history indicates which neighbor has advertised the P2P interface. When those messages are detected, the interface type needs to be changed on one node to ensure that they are consistent.

Example 9-24 displays NX-2’s IS-IS event-history and the relevant configurations for NX-1 and NX-2.

Example 9-24 IS-IS Mismatch of Interface Types

Click here to view code image

Adding the command isis network point-to-point to NX-2’s Ethernet1/1 interface sets both interfaces to the same type, and then an adjacency forms.

IS-IS provides two types of authentication: plaintext and a MD5 cryptographic hash. Plaintext mode provides little security, because anyone with access to the link can see the password with a network sniffer. MD5 cryptographic hash uses a hash instead, so the password is never included in the PDUs, and this technique is widely accepted as being the more secure mode. All IS-IS authentication is stored in TLV#10 that is part of the IIH.

Nexus switches enable IIH authentication with the interface parameter command isis authentication key-chain key-chain-name {level-1 | level-2}. The authentication type is identified with the command isis authentication-type {md5 | cleartext} {level-1 | level-2}.

Example 9-25 displays MD5 authentication on NX-1’s Ethernet1/1 interface.

Example 9-25 L1 IIH Authentication on NX-1

Click here to view code image

After configuring L1 IIH authentication on NX-1’s Ethernet1/1 interface, the L1 adjacency is dropped between NX-1 and NX-2. NX-2 is actually trying to bring up the NX-1 session, but is stuck in an INIT state, as shown in Example 9-26. The L2 adjacency is maintained because no changes were made to the L2 authentication.

Example 9-26 L1 Adjacency Is Affected by L1 IIH Authentication on NX-1

Click here to view code image

In lieu of checking configuration, the authentication parameters are displayed for an interface with the command show isis interface [interface-id]. Example 9-27 displays the output for NX-1. Notice that the L1 portion has authentication, whereas the L2 portion does not have authentication enabled.

Example 9-27 Viewing of IIH Authentication

Click here to view code image

The password in the keychain is viewed with the command show key chain key-chain-name [mode decrypt]. The optional mode decrypt keywords display the password in plaintext as displayed in Example 9-28.

Example 9-28 Viewing Keychain Passwords

Click here to view code image

Upon enabling authentication, it is important to check the syslog for error messages that indicate bad authentication. For those that do, verify the authentication options and password on all peers for that network link.

Figure 9-7 provides a sample topology in which all Nexus switches are in the same area with only L1 adjacencies. NX-2 and NX-4 have been configured with the same system ID of 0000.0000.0002. NX-3 sits between NX-2 and NX-4 and has a different system ID, therefore allowing NX-2 and NX-4 to establish full neighbor adjacencies.

Figure 9-7 Duplicate System ID Topology

From NX-1’s perspective, the first apparent issue is that NX-4’s 10.4.4.0/24 network is missing, as shown in Example 9-29.

Example 9-29 NX-1’s Routing Table with Missing NX-4’s 10.4.4.0/24 Network

Click here to view code image

On NX-2 and NX-4, there are complaints about LSPs with duplicate system IDs: L1 LSP—Possible duplicate system ID, as shown in Example 9-30.

Example 9-30 Syslog Messages with LSPs with Duplicate System IDs

Click here to view code image

Example 9-31 displays the routing table of the two Nexus switches with the Possible duplicate system ID syslog messages. Notice that NX-2 is missing only NX-4’s interface (10.4.4.0/24), whereas NX-4 is missing the 10.12.1.0/24 and NX-1’s Ethernet interface (10.1.1.0/24). Examining the IS-IS database displays a flag (*) that indicates a problem with NX-2.

Example 9-31 Routing Tables of NX-2 and NX-4

Click here to view code image

A quick check of the router’s system ID is done by examining the IS-IS processes on both Nexus switches that reported the Possible duplicate system ID using the show isis | i system command. Notice that in Example 9-32, NX-2 and NX-4 have the same system ID.

Example 9-32 Verification of IS-IS System IDs

Click here to view code image

Interface Metric = Interface Bandwidth/Reference Bandwidth

The default reference bandwidth for NX-OS is 40 Gbps, whereas other Cisco OSs (IOS and IOS XR) statically set the interface link metric to 10 regardless of interface speed. Table 9-9 provides the default IS-IS metric for common network interface types using the default reference bandwidth.

Notice in Table 9-9 that there is no differentiation in the link cost associated to a Fast Ethernet Interface and a 40-Gigabit Ethernet interface on IOS routers. In essence, suboptimal routing can exist when Nexus switches interact with IOS-based devices in an IS-IS topology. For example, Figure 9-8 displays a topology in which connectivity between R1 and R2 should take the 10 Gigabit Path (R1

Figure 9-8 Topology to Demonstrate Problems with Interface Metrics

NX-3→NX-4→R2) because the 1 Gigabit link between R1 and R2 should be used only as a backup path.

Example 9-33 displays the routing table of R1 with the default interface metrics on all the devices. Traffic between 172.16.1.0/24 and 172.32.2.0/24 flows across the backup 1 Gigabit link (10.12.1.0/24), which does not follow the intended traffic patterns. Notice that the IS-IS path metric is 20 to the 172.32.2.0/24 network using the 1 Gigabit link.

Example 9-33 R1’s Routing Table with Default Interface Metrics Bandwidth

Click here to view code image

Now one of the beautiful things about IS-IS is how it structures networks as objects that exist on top of the routers themselves. Instead of viewing the routing table, the IS-IS topology table is viewed with the command show isis topology. The IS-IS topology table lists the total path metric to reach the destination router, next-hop node, and outbound interface. Example 9-34 displays the topology table from R1 and NX-3’s perspective. R1 is selecting the path to R2 via the direct link on Gi0/1.

Example 9-34 R1’s and NX-3’s IS-IS Topology Table with Default Metric

Click here to view code image

Notice how R1 and NX-3 have conflicting metric values when they point to each other. To ensure that routing takes the optimal path, three options ensure optimal routing:

• Statically set the IS-IS metric on IS-IS devices that are not Nexus switches. IOS-based devices use the interface parameter command isis metric metric-value.

• Statically set the IS-IS metric on a Nexus interface to reflect network links that are more preferred with the interface parameter command isis metric metric-value {level-1 | level-2}.

• Change the reference bandwidth on Nexus switches to a higher value to make those links more preferred. The reference bandwidth is set with the IS-IS process configuration command reference-bandwidth reference-bw {gbps | mbps}.

There are not any intermediary routers between R1 and R2, so the only option that makes sense is to modify the IS-IS metrics on R1 and R2. Example 9-35 displays the metric for the 10.12.1.0/24 link being statically set to 40, and the metric being set to 4 for the 10 Gbps interface. The value correlates to a reference bandwidth of 40 Gbps.

Example 9-35 Setting Static IS-IS Metric on R1 and R2

Click here to view code image

Now that the change has been made, let’s examine the IS-IS routing table and topology table on R1 and NX-3, as shown in Example 9-36. Now the interface metrics match for the 10.13.1.0/24 and 10.24.1.0/24 networks. In addition, R1 is now selecting the 10 Gbps path as the preferred path to reach R2.

Example 9-36 IS-IS Routing and Topology Table After Static Metric Configuration

Click here to view code image

RFC 3784 provided a method for the interface metric to use a 24-bit number that allows for the metric to be set between 1 and 16,777,214. The 24-bit metrics are available in the Extended IS Reachability TLV (22) and the Extended IP Reachability TLV (135), and are commonly referred to as wide metrics.

Nexus switches accept narrow or wide metrics and advertise only wide metrics by default. IOS and IOS XR accept and advertise only narrow metrics by default, which causes problems when integrating non-Nexus switches in a topology. Figure 9-9 displays a simple L1 topology with multiple device types. All devices and interfaces have IS-IS enabled on them.

Figure 9-9 Simple IS-IS L1 Topology with Multiple Device Types

Example 9-37 displays R1’s and NX-2’s IS-IS routing entries. R1 does not have any IS-IS routes in the routing table, whereas NX-2 has routes to all the networks in the topology.

Example 9-37 R1’s and NX-2’s IS-IS Routing Table Entries

Click here to view code image

The first step to identify missing routes is to verify neighbor adjacencies and then check the IS-IS topology table. Example 9-38 displays the topology table on R1 and NX-2. R1 displays double asterisks (**) for all the metrics to the other routers, whereas NX-2 has populated metrics. This is because R1 is configured only for narrow metrics, which use different TLVs than the wide metric TLVs that are advertised from NX-2.

Example 9-38 IS-IS Topology Table with Mismatched Metric Types

Click here to view code image

To confirm the theory, the metric types are checked on R1 and NX-2 by looking at the IS-IS protocol, as shown in Example 9-39. R1 is set to accept and generate only narrow metrics, whereas NX-OS accepts both narrow and wide metrics while advertising only wide metrics.

Example 9-39 Checking IS-IS Metric Configuration

Click here to view code image

The Nexus switches are placed in metric transition mode using the command metric-style transition, which makes the Nexus switch populate the LSP with narrow and wide metric TLVs. This allows other routers that operate in narrow metric mode to compute a total path metric for a topology.

Example 9-40 displays the configuration and verification on NX-2 for IS-IS metric transition mode.

Example 9-40 IS-IS Metric Transition Mode Configuration and Verification

Click here to view code image

Example 9-41 displays the IS-IS topology table and routing table for the IOS routers now that the Nexus switches are placed in IS-IS metric transition mode.

Example 9-41 Verification of IOS Devices After NX-OS Metric Transition Mode

Click here to view code image

Figure 9-10 IS-IS Topology to Demonstrate IS-IS L1 to L2 Route Propagation

Example 9-42 displays all four Nexus switches' routing tables. Notice that NX-3 is missing the 10.1.1.0/24 network. This network exists in NX-2’s routing table as an IS-IS L1 route. The same behavior exists for NX-4’s 10.4.4.0/24 network, which appears on NX-3.

Example 9-42 Routing Table of NX-1, NX-2, NX-3, and NX-4

Click here to view code image

The next step is to examine the IS-IS database with the command show isis database [level-1 | level-2] [detail] [lsp-id] to make sure that the appropriate LSPs are in the LSPDB. LSPs are restricted by specifying an IS-IS level or the specific LSPID for an advertising router.

Example 9-43 displays all the LSPs for L1 and L2 in NX-2’s LSPDB. From the output, NX-2 has received NX-1’s L1 LSP and has received NX-3’s L2 LSP.

Example 9-43 NX-2’s LSPDB

Click here to view code image

Table 9-10 explains some of the key fields in the output from Example 9-43.

Using the optional detail keyword provides a list of all the networks, metrics, and TLV types when viewing the LSPDB. Example 9-44 displays all of NX-2’s L2 IS-IS LSP information in detail. The output includes every network that NX-2 advertises to other L2 neighbors. Notice that the 10.1.1.0/24 network entry is not present on NX-2’s LSP, nor is the 10.4.4.0/24 network entry on NX-3’s LSP.

Example 9-44 Examination of NX-2’s L2 Detailed LSPDB

Click here to view code image

The IS-IS LSPDB indicates that NX-1’s L1 routes are not propagating to NX-2’s L2 database, and the same behavior is occurring between NX-4 and NX-3. This is caused by a difference in operational behavior between NX-OS and other Cisco operating systems (IOS, IOS XR, etc.). Nexus switches require explicit configuration with the command distribute level-1 into level-2 {all | route-map route-map-name} on L1-L2 routers to insert L1 routes into the L2 topology.

Example 9-45 displays the relevant IS-IS configuration on NX-2 and NX-3 to enable L1 route propagation into the L2 LSPDB.

Example 9-45 Configuration for L1 Route Propagation

Click here to view code image

Example 9-46 displays NX-3’s LSP that was advertised to NX-2, now that L1 route propagation has been configured on NX-2 and NX-3. Notice that it now includes the L1 route 10.4.4.0/24.

Example 9-46 NX-3’s LSP After Enabling Route Propagation

Click here to view code image

Example 9-47 displays NX-2’s and NX-4’s routing table after the L1 route propagation was configured on NX-2 and NX-3. Now the 10.1.1.0/24 and 10.4.4.0/24 network are reachable on both the L1-L2 switches.

Example 9-47 NX-2 and NX-4’s Routing Table After L1 Route Propagation

Click here to view code image

Suboptimal Routing

As mentioned in the previous section, L1-L2 routers act as a gateway for L1 routers to the L2 IS-IS backbone. L1-L2 routers do not advertise L2 routes into the L1 area, but they set the attached bit in their L1 LSP indicating that the router has connectivity to the IS-IS backbone network. If an L1 router does not have a route for a network, it searches the LSPDB for the closest router with the attached bit, which acts as a route of last resort.

In Figure 9-11, Area 49.1234 connects to Area 49.0005 and Area 49.0006. NX-1 and NX-3 are L1 routers, and NX-2 and NX-4 are L1-L2 routers.

Figure 9-11 IS-IS InterArea Topology

The problem comes from the suboptimal routing that occurs when NX-1 tries to connect with 10.6.6.0/24 network, as it crosses the higher cost 10.24.1.0/24 network link. The same problem occurs for NX-3 connecting with the 10.5.5.0/24 network. Example 9-48 displays the suboptimal path taken by both NX-1 and NX-3.

Example 9-48 Suboptimal Path Selection

Click here to view code image

NX-1# trace 10.6.6.6 so lo0
traceroute to 10.6.6.6 (10.6.6.6) from 192.168.1.1 (192.168.1.1), 30 hops max, 40 byte packets
 1  10.12.1.2 (10.12.1.2)  1.95 ms  1.36 ms  1.397 ms
 2  10.24.1.4 (10.24.1.4)  2.758 ms  2.498 ms  2.423 ms
 3  172.16.46.6 (172.16.46.6)  4.037 ms *  4.103 ms

NX-3# trace 10.5.5.5 so lo0
traceroute to 10.5.5.5 (10.5.5.5) from 192.168.3.3 (192.168.3.3), 30 hops max, 40 byte packets
 1  10.34.1.4 (10.34.1.4)  1.826 ms  1.127 ms  1.249 ms
 2  10.24.1.2 (10.24.1.2)  2.434 ms  2.461 ms  2.19 ms
 3  172.16.25.5 (172.16.25.5)  5.262 ms

Example 9-49 displays the IS-IS database on NX-1 and NX-3. The attached bit ‘A’ is detected for NX-2 and NX-4. In essence, the attached bit provides a L1 default route toward the advertising L1-L2 router.

Example 9-49 IS-IS Database for Area 49.1234

Click here to view code image

NX-1# show isis database
IS-IS Process: NXOS LSP database VRF: default
IS-IS Level-1 Link State Database
  LSPID                 Seq Number   Checksum  Lifetime   A/P/O/T
  NX-1.00-00          * 0x0000001D   0xC67A    1038       0/0/0/1
  NX-2.00-00            0x00000021   0xAF03    1120       1/0/0/3
  NX-3.00-00            0x0000001F   0xD222    1055       0/0/0/1
  NX-4.00-00            0x00000021   0x94B5    1154       1/0/0/3

Now NX-1 and NX-2 must identify the closest router with the attached bit. Normally this is a manual process of cross-referencing the IS-IS database with the IS-IS topology table, but NX-OS does this for you automatically. The IS-IS topology table for NX-1 and NX-3 is displayed in Example 9-50.

Example 9-50 IS-IS Topology for Area 49.1234

Click here to view code image

NX-1# show isis topology
IS-IS process: NXOS
VRF: default
IS-IS Level-1 IS routing table
NX-2.00, Instance 0x00000022
   *via NX-2, Ethernet1/2, metric 4
NX-3.00, Instance 0x00000022
   *via NX-3, Ethernet1/1, metric 4
NX-4.00, Instance 0x00000022
   *via NX-3, Ethernet1/1, metric 8
0000.0000.0000.00, Instance 0x00000022, Default
   *via NX-2, Ethernet1/2, metric 4

NX-3# show isis topology
IS-IS process: NXOS
VRF: default
IS-IS Level-1 IS routing table
NX-1.00, Instance 0x0000001F
   *via NX-1, Ethernet1/1, metric 4
NX-2.00, Instance 0x0000001F
   *via NX-1, Ethernet1/1, metric 8
NX-4.00, Instance 0x0000001F
   *via NX-4, Ethernet1/2, metric 4
0000.0000.0000.00, Instance 0x0000001F, Default
   *via NX-4, Ethernet1/2, metric 4

Example 9-51 displays the routing table of NX-1 and NX-3. Notice that an entry does not exist for the 10.5.5.0/24 or 10.6.6.0/24 networks, so the default network is used instead. Notice that the default route correlates with the IS-IS topology table entry from Example 9-50.

Example 9-51 NX-1 and NX-3’s Routing Table

Click here to view code image

NX-1# show ip route isis

! Output omitted for brevity

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.12.1.2, Eth1/2, [115/4], 00:07:05, isis-NXOS, L1
10.24.1.0/24, ubest/mbest: 1/0
    *via 10.12.1.2, Eth1/2, [115/44], 00:07:05, isis-NXOS, L1
10.34.1.0/24, ubest/mbest: 1/0
    *via 10.13.1.3, Eth1/1, [115/8], 00:04:39, isis-NXOS, L1
172.16.25.0/24, ubest/mbest: 1/0
    *via 10.12.1.2, Eth1/2, [115/8], 00:07:05, isis-NXOS, L1
172.16.46.0/24, ubest/mbest: 1/0
    *via 10.13.1.3, Eth1/1, [115/12], 00:04:39, isis-NXOS, L1

NX-3# show ip route isis

! Output omitted for brevity

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.34.1.4, Eth1/2, [115/4], 00:07:32, isis-NXOS, L1
10.12.1.0/24, ubest/mbest: 1/0
    *via 10.13.1.1, Eth1/1, [115/8], 00:05:11, isis-NXOS, L1
10.24.1.0/24, ubest/mbest: 1/0
    *via 10.34.1.4, Eth1/2, [115/44], 00:07:32, isis-NXOS, L1
172.16.25.0/24, ubest/mbest: 1/0
    *via 10.13.1.1, Eth1/1, [115/12], 00:05:11, isis-NXOS, L1
172.16.46.0/24, ubest/mbest: 1/0
    *via 10.34.1.4, Eth1/2, [115/8], 00:07:32, isis-NXOS, L1

Suboptimal routing is corrected by route leaking, a technique that redistributes the L2 level routes into the L1 level. IS-IS route leaking is configured with the command distribute level-2 into level-1 {all | route-policy route-policy-name}. Example 9-52 displays the highlighted L2 route-leaking configuration.

Example 9-52 IS-IS L2 Route-Leaking Configuration

Click here to view code image

Let’s verify the change by checking the IS-IS database to see if the 10.5.5.0/24 and 10.6.6.0/24 networks are being advertised by NX-2 and NX-4 into IS-IS L1 for Area 49.1234. After that is verified, check the routing table to verify that those entries are added to the RIB. Example 9-53 displays the IS-IS Database with L2 Route Leaking.

Example 9-53 IS-IS Database with L2 Route Leaking

Click here to view code image

Example 9-54 verifies that NX-1 and NX-3 are forwarding traffic using the optimal path.

Example 9-54 Path Check After L2 Route Leaking

Click here to view code image

Example 9-55 provides the necessary configuration to demonstrate the process of redistribution. NX-1 redistributes the connected routes for 10.1.1.0/24 and 10.11.11.0/24 in lieu of them being advertised with the IS-IS routing protocol. Notice that the route-map is a simple permit statement without any conditional matches.

Example 9-55 NX-1 Redistribution Configuration

Click here to view code image

The route is redistributed on NX-1 and is injected into the IS-IS database with the 10.1.1.0/24 and 10.11.11.0/24 prefix. The redistribution of prefixes is verified by looking at the LSPDB on other devices, such as NX-2, as shown in Example 9-56.

Example 9-56 Verification of Redistributed Networks

Click here to view code image

R. Callon. IETF, http://tools.ietf.org/html/rfc1195, December 1990.

RFC 3784, Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE). Tony Li, Henk Smit. IETF, https://tools.ietf.org/html/rfc3784, June 2004.

Edgeworth, Brad, Aaron Foss, Ramiro Garza Rios. IP Routing on Cisco IOS, IOS XE and IOS XR. Indianapolis: Cisco Press, 2014.

Cisco. Cisco NX-OS Software Configuration Guides, http://www.cisco.com.