Chapter 10. Troubleshooting the IS-IS Routing Protocol

This chapter covers common problems that might result in faulty operation of the IS-IS protocol, and discusses procedures to troubleshoot them. Most of the time, faulty operation results from misconfigurations, which could be easily discerned by carefully reviewing configurations of the routers involved and the output of basic CLNS- and IS-IS- related show commands. However, some issues might present more of a challenge. Such issues might require advanced knowledge of the IS-IS protocol architecture and capabilities, evaluation of packet captures, and complicated network-wide debugging procedures.

To quickly evaluate and resolve problems, in every case, you need a solid technical understanding of the IS-IS protocol. In addition, you need to know how to configure, debug, and interpret the various associated show commands available in Cisco IOS Software. The Cisco implementation of the IS-IS protocol adds many nonstandardized features and associated configuration commands, commonly referred to as knobs .

This chapter discusses functional problems and includes practical examples that show you how to troubleshoot IS-IS problems, from the very basic to the more advanced. The Cisco Technical Assistance Center (TAC) is the authoritative resource for service- impacting issues and outages that require immediate attention. Experience shows, however, that even when an issue is referred to the Cisco TAC, problems can be resolved faster if the person calling in the case has a good knowledge of the protocol, can describe the symptoms adequately, and can work collaboratively with the support engineer.

Link-state routing protocols, such as OSPF and IS-IS, are generally more complicated to troubleshoot than are distance-vector protocols. Compared to OSPF, however, IS-IS seems to be easier to work with by far. But this simplicity is not obvious because the operation of Integrated IS-IS in IP environments still occurs within the framework of the Connectionless Network Protocol (CLNP). This requires knowledge of CLNP, including its node-based addressing scheme, which differs from the link-based addressing scheme used in IP. Chapter 5, "The IS-IS Link-State Database," provides detailed insight into CLNP addressing and helps demystify the subject.

Before delving into the actual troubleshooting methodology, it might be useful to review some Cisco IOS show commands commonly used for troubleshooting IS-IS routing problems. The following is a short list of important commands:

• show clns neighbor ” Enables you to verify the status of adjacencies

• show clns interface ” Enables you to verify the configuration of an active CLNS interface

• show isis database ” Enables you to check for the presence of all expected LSPs

• show isis spf-log ” Enables you to check how frequently the SPF process is being run and the associated triggers

Some of these commands are discussed in Chapter 9, "Configuring IS-IS for IP Routing on Cisco Routers." The next section provides a detailed explanation of these key troubleshooting and monitoring commands as a prelude to the ensuing discussions on troubleshooting methodology. For example, the show isis database command enables you to check both the Level 1 and Level 2 databases. If you do not understand the output, however, the command is not a useful troubleshooting tool. An important point is that an IS-IS router uses only a single LSP for each level of routing. An LSP might be fragmented if there are too many TLVs to be contained in its maximum size of 1492 bytes. In most cases, however, each router generates just a single LSP for Level 1 or Level 2 routing. Because you have to deal with a single LSP, IS-IS appears to be much easier to troubleshoot than OSPF. That said, it is still important to understand all the information in an LSP.

When troubleshooting complicated problems, you might have to debug IS-IS activities on the router. The following list identifies useful IS-IS protocol debugging commands. Although debugging is generally CPU- intensive , these commands do not overburden the processor. However, always assess the routers situation before enabling any of these commands. You should enable only a single debugging command at a time, and you should capture the console screen for later review:

• debug isis adj-packets

• debug isis update-packets

• debug spf-events

The log- adjacency -changes and ignore-lsp-errors router-level configuration commands generate status-logging information that can prove useful in troubleshooting. The router logs can be exported to a SYSLOG server and used for management and troubleshooting purposes.