Troubleshooting Integrated IS-IS | Routing TCP/IP, Volume 1 (2nd Edition)

The basic methods for troubleshooting IS-IS are very similar to the methods for troubleshooting OSPF, as discussed in Chapter 8. A major aspect of troubleshooting Integrated IS-IS that is different from the other IP routing protocols is that IS-IS uses CLNS PDUs rather than IP packets. If you are troubleshooting the protocol itself, remember that you are troubleshooting CLNS, not IP.

As with all routing protocols, the first troubleshooting step is to check the route table for accurate information. If an expected route entry is missing or incorrect, the remainder of the troubleshooting task is to determine the source of the problem.

After the route table, the link-state database is the most important source of troubleshooting information. As recommended in Chapter 8, it is good practice to keep a copy of the L1 link-state database for every area, and a copy of the L2 link-state database. These stored copies of the databases should be updated regularly, as part of your routine baselining procedures. When things go wrong, these stored databases provide a steady-state reference.

When examining an individual router's configuration, consider the following:

Does the net statement under the IS-IS configuration specify the correct NET? Are the Area ID and System ID correct for this router? Does the NET comply with whatever CLNS addressing convention is being used in this network?
Is IS-IS enabled on the correct interfaces with the ip router isis or ipv6 router isis command?
Are the IP addresses and subnet masks or prefixes correct? It is doubly important to check these in an Integrated IS-IS environment because a misconfigured IP address will not prevent an IS-IS adjacency from being partially established.

Troubleshooting IS-IS Adjacencies

The command show clns is-neighbors displays the IS-IS neighbor table. The entire table is displayed by default, or you can specify a particular interface. From this table, you can observe whether all expected neighbors are present and whether they are the correct type. For more information, such as the area addresses and IP addresses associated with each neighbor and the uptime of each neighbor, use the show clns is-neighbors detail command.

When examining adjacencies, consider the following:

Are the router levels configured correctly? L1 routers can establish adjacencies only with L1 and L1/L2 routers, and L2 routers can establish adjacencies only with L2 and L1/L2 routers.
Are Hellos being sent from both neighbors? Are the Hellos the correct level, and do they contain the correct parameters? The command debug isis adj-packets is useful for observing Hellos.
If authentication is being used, are the passwords and authentication mode the same between neighbors? Remember that area (level 1) and domain (level 2) authentication do not regulate adjacencies, only the exchange of LSPs.
Are any access lists blocking IS-IS or CLNS?

A change has been made on the router Bonn in Figure 10-54. Bonn and Frankfurt are no longer accessible via IPv4 from other locations. A look at Bonn's IPv4 route table (Example 10-65) shows that there are no IP routes learned via Madrid (interface Serial0/0.1).

Example 10-65. Bonn's IPv4 route table shows IS-IS learned routes from Frankfurt on FA0/0, but nothing from Madrid on Serial0/0.1.

Bonn#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B  BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2        ia - IS-IS inter area, * - candidate default, U - per-user static route        o - ODR, P - periodic downloaded static route Gateway of last resort is not set      172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks C       172.16.24.0/24 is directly connected, Loopback1 C       172.16.25.0/24 is directly connected, Loopback2 i L1    172.16.16.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 i su    172.16.16.0/21 [115/10] via 0.0.0.0, Null0 i L1    172.16.17.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 i L1    172.16.18.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 C       172.16.19.0/24 is directly connected, FastEthernet0/0 C       172.16.9.0/24 is directly connected, Serial0/0.1 Bonn#

The command show clns is-neighbors shows an adjacency exists from Bonn to Madrid (Example 10-66). However, notice Madrid's type is IS rather than L1 or L2. This indicates a problem with the adjacency. debug isis adj-packets gives a hint as to where the problem exists (Example 10-67).

Example 10-66. Bonn's CLNS IS-IS neighbor table shows an adjacency exists to Madrid and to Frankfurt, but there is something wrong with the Madrid adjacency.

Bonn#show clns is-neighbors System Id      Interface   State  Type Priority  Circuit Id          Format Madrid         Se0/0.1     Up     IS   0         00                  Phase V Frankfurt      Fa0/0       Up     L1   64        Bonn.03             Phase V Bonn#

Example 10-67. The details of IS-IS Hellos (IIHs) can be observed with the debug isis adj-packets command. This display is from router Bonn in Figure 10-54 and shows that there is a problem with the IP address on Serial0/0.1.

Bonn#debug isis adj-packets IS-IS Adjacency related packets debugging is on Bonn# ISIS-Adj: Sending serial IIH on Serial0/0.1, length 1499 ISIS-Adj: Rec serial IIH from DLCI 171 (Serial0/0.1), cir type L2, cir id 01, length 1499 ISIS-Adj: No usable IP interface addresses in serial IIH from Serial0/0.1 ISIS-Adj: Sending L1 LAN IIH on FastEthernet0/0, length 1497 ISIS-Adj: Sending L2 LAN IIH on FastEthernet0/0, length 1497 ISIS-Adj: Sending L1 LAN IIH on FastEthernet0/0, length 1497 ISIS-Adj: Rec L1 IIH from 0000.0c8d.34f1 (FastEthernet0/0), cir type L1, cir id 0000.0C0A.2AA9.03, length 1497

Reviewing the IPv4 addresses on Bonn shows that the IP address on Serial0/0.1 have been inadvertently changed. IOS checks the addresses in the TLVs before establishing adjacencies. If the IPv4 address in the Interface Address TLV, 132, does not belong to the same subnet as the receiving interface, an adjacency is formed, but the type of the adjacency will be IS rather then L1 or L2, indicating that there is a problem with the configuration affecting the adjacency. After correcting the problem, Bonn's CLNS IS neighbor table (Example 10-68) and IPv4 route table look good.

Example 10-68. A problem free CLNS neighbor table shows the adjacency type is L1, L2, or L1/L2. Bonn's route table shows IP routes from both adjacent neighbors.

Bonn#show clns is-neighbors System Id      Interface   State  Type Priority  Circuit Id         Format Madrid         Se0/0.1     Up     L2   0         00                 Phase V Madrid         Fa0/0       Up     L1   64        Bonn.03            Phase V Bonn#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B  BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2        ia - IS-IS inter area, * - candidate default, U - per-user static route        o - ODR, P - periodic downloaded static route Gateway of last resort is not set      172.16.0.0/16 is variably subnetted, 11 subnets, 2 masks C       172.16.24.0/24 is directly connected, Loopback1 C       172.16.25.0/24 is directly connected, Loopback2 i L2    172.16.21.0/24 [115/20] via 172.16.9.1, Serial0/0.1 i L1    172.16.16.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 i su    172.16.16.0/21 [115/10] via 0.0.0.0, Null0 i L1    172.16.17.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 i L1    172.16.18.0/24 [115/20] via 172.16.19.2, FastEthernet0/0 C       172.16.19.0/24 is directly connected, FastEthernet0/0 i L2    172.16.8.0/24 [115/20] via 172.16.9.1, Serial0/0.1 C       172.16.9.0/24 is directly connected, Serial0/0.1 i L2    172.16.0.0/21 [115/30] via 172.16.9.1, Serial0/0.1 Bonn#

The output from the command debug isis adj-packets performed on a problem free Bonn is shown in Example 10-69. Information is being received over Serial0/0.1.

Example 10-69. The details of IS-IS Hellos (IIHs) are observed on a correctly configured router, Bonn.

Bonn#debug isis adj-packets IS-IS Adjacency related packets debugging is on Bonn# ISIS-Adj: Sending L1 LAN IIH on FastEthernet0/0, length 1497 ISIS-Adj: Sending L2 LAN IIH on FastEthernet0/0, length 1497 ISIS-Adj: Rec L1 IIH from 0000.0c8d.34f1 (FastEthernet0/0), cir type L1, cir id 0000.0C0A.2AA9.03, length 1497 ISIS-Adj: Rec serial IIH from DLCI 171 (Serial0/0.1), cir type L2, cir id 01, length 1499 ISIS-Adj: Local mode (IP, IPv6), remote mode (IP, IPv6) ISIS-Adj: rcvd state UP, old state UP, new state UP ISIS-Adj: Action = ACCEPT ISIS-Adj: Sending L1 LAN IIH on FastEthernet0/0, length 1497l ISIS-Adj: Sending serial IIH on Serial0/0.1, length 1499 Bonn#

A similar adjacency problem exists with IPv6 in single topology mode, if IPv6 is not configured on every link that is configured with IPv4. When the network in Figure 10-54 was configured with IPv6 in single topology mode, a problem arose between Bonn and Frankfurt. Frankfurt does not support IPv6. Example 10-48 shows the output from the debug is adj-packets on Bonn. The debug's output shows that there is a problem with the link-local address: "No usable IPv6 linklocal addresses in LAN IIH from FastEthernet0/0." IOS on Bonn checks for valid addresses and address families before establishing adjacencies. In single topology mode, if both IPv4 and IPv6 are configured on the router, every link that has an IPv4 address must also have an IPv6 address, every link that has an IPv6 address must also have an IPv4 address, and neighbor routers must also have valid IPv4 and IPv6 addresses. TLV 232 contains the IPv6 Link Local address in Hello packets. If in single topology mode, a neighbor router does not include a valid IPv6 link-local address in its hello packets, the adjacency will be formed as a type IS (again, indicating a problem with the configuration).

There is an IS-IS process configuration command, log-adjacency-changes. This command will log all adjacency changes to the log, whether buffered or sent to a log server. Perusing the log is very useful for troubleshooting adjacency problems that occurred at some time in the past.

Troubleshooting the IS-IS Link-State Database

The IS-IS link-state database is examined with the command show isis database. If the router is an L1/L2, both of the databases are displayed by default. To observe only one of the databases, use the level-1 or level-2 keywords. To examine the LSPs in more detail, use the detail keyword. A single LSP can be observed by specifying its LSPID, as in Example 10-70.

Example 10-70. This LSP is from the L2 database of router Zurich in Figure 10-54.

Zurich#show isis database detail Madrid.00-00 IS-IS Level-2 LSP Madrid.00-00 LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL Madrid.00-00          0x0000007C   0x5874        1023              0/0/0   Auth:         Length: 17   Area Address: 03   Topology:     IPv4 (0x0) IPv6 (0x2)   NLPID:        0xCC 0x8E   Hostname: Madrid   IP Address: 172.16.21.2   IPv6 Address: 2001:DB8:0:15::2   Metric: 10         IS-Extended Zurich.00   Metric: 10         IS-Extended Bonn.00   Metric: 10         IS-Extended Geneva.00   Metric: 10         IS (MT-IPv6) Zurich.00   Metric: 10         IS (MT-IPv6) Bonn.00   Metric: 10         IS (MT-IPv6) Geneva.00   Metric: 10         IP 172.16.21.0/24   Metric: 10         IP 172.16.8.0/24   Metric: 10         IP 172.16.9.0/24   Metric: 10         IPv6 (MT-IPv6) 2001:DB8:0:8::/64   Metric: 10         IPv6 (MT-IPv6) 2001:DB8:0:9::/64   Metric: 10         IPv6 (MT-IPv6) 2001:DB8:0:15::/64 Zurich#

A sequence number that is noticeably higher than the sequence numbers of other LSPs might indicate instability either within the area or on the level 2 backbone. Another hint of instability is an LSP Holdtime that never gets very small. If instability is suspected, use the command show isis spf-log to list all SPF calculations recently performed by the router.

In Example 10-71, the SPF log for router Geneva in Figure 10-54 is shown. Nothing but the periodic SPF calculations triggered by the 15-minute database refreshes are shown until approximately three minutes before the log was displayed. At that time, frequent SPF calculations began occurring, indicating frequent changes of some sort in the network.^[27]

^[27] The first four triggering events were caused by "bouncing" Zurich's serial interface several times, and the next three events were caused by deleting and then misconfiguring the link password. The last event was caused when the correct password was configured.

Example 10-71. This SPF log reveals instability in area 1 of Figure 10-54.

Geneva#sh isis spf-log      Level 1 SPF log    When      Duration   Nodes   Count    Last trigger LSP     Triggers 02:43:09          12       3       1                         PERIODIC 02:28:08          12       3       1                         PERIODIC 02:13:06          12       3       1                         PERIODIC 01:58:05          12       3       1                         PERIODIC 01:43:03          12       3       1                         PERIODIC 01:28:02          12       3       1                         PERIODIC 01:13:00          12       3       1                         PERIODIC 00:57:59          12       3       1                         PERIODIC 00:42:58          12       3       1                         PERIODIC 00:27:56          12       3       1                         PERIODIC 00:12:55          12       3       1                         PERIODIC 00:03:08          8        3       1   0000.0C76.5B7C.00-00  LSPHEADER 00:02:35          8        3       1   0000.0C76.5B7C.00-00  LSPHEADER 00:02:23          8        3       1   0000.0C76.5B7C.00-00  LSPHEADER 00:01:50          8        3       1   0000.0C76.5B7C.00-00  LSPHEADER 00:01:14          4        1       1   0000.0C0A.2C51.00-00  TLVCONTENT 00:00:46          4        2       2   0000.0C0A.2C51.04-00  NEWLSP TLVCONTENT 00:00:20          4        1       3   0000.0C0A.2C51.00-00  NEWADJ TLVCONTENT 00:00:08          8        3       1   0000.0C76.5B7C.02-00  TLVCONTENT Geneva#

To further investigate instabilities revealed by the SPF log, three useful debug commands are available. Example 10-72, Example 10-73, and Example 10-74 show output from these three debug functions. In each case, the debug messages show the results of disconnecting and reconnecting the serial interface of Bonn in Figure 10-54 from the perspective of Frankfurt. The first, debug isis spf-triggers (Example 10-72), displays messages pertaining to events that trigger an SPF calculation. The second command is debug isis spf-events (Example 10-73). This command displays a detailed account of the SPF calculations caused by a triggering event. The third command, debug isis spf-statistics (Example 10-74), displays information about the SPF calculation itself. Of particular interest is the time taken to complete the calculation, which can reveal performance problems on the router.

Example 10-72. debug isis spf-triggers displays messages about events that trigger an SPF calculation.

Frankfurt#debug isis spf-triggers IS-IS SPF triggering events debugging is on Frankfurt# ISIS-Spf: L1, LSP fields changed 0000.0C0A.2AA9.00-00 ISIS-Spf: L1, LSP fields changed 0000.0C0A.2AA9.00-00 Frankfurt#

Example 10-73. debug isis spf-events displays the details of an SPF calculation.

Frankfurt#debug isis spf-events IS-IS SPF events debugging is on Frankfurt# ISIS-Spf: L1 LSP 4 (0000.0C0A.2AA9.00-00) flagged for recalculation from 37D73FA ISIS-Spf: Calculating routes for L1 LSP 4 (0000.0C0A.2AA9.00-00) ISIS-Spf: Add 172.16.19.0/255.255.255.0 to IP RIB, metric 20 ISIS-Spf: Next hop 0000.0C0A.2AA9/172.16.19.1 (Ethernet0) (rejected) ISIS-Spf: Redundant IP route 172.16.24.0/255.255.255.0, metric 20, not added ISIS-Spf: Redundant IP route 172.16.25.0/255.255.255.0, metric 20, not added ISIS-Spf: Aging L1 LSP 4 (0000.0C0A.2AA9.00-00), version 105 ISIS-Spf: Aging IP 172.16.9.0/255.255.255.0, next hop 172.16.19.1 ISIS-Spf: Deleted NDB ISIS-Spf:  Compute L1 SPT ISIS-Spf: 3 nodes for level-1 ISIS-Spf: Move 0000.0C8D.34F1.00-00 to PATHS, metric 0 ISIS-Spf: Add 0000.0C0A.2AA9.03-00 to TENT, metric 10 ISIS-Spf: Move 0000.0C0A.2AA9.03-00 to PATHS, metric 10 ISIS-Spf: thru 0/2147483647/0, delay 0/0/0, mtu 0/2147483647/0, hops 0/0/0, ticks 0/0/0 ISIS-Spf: considering adj to 0000.0C0A.2AA9 (Ethernet0) metric 10, level 1, circuit 3, adj 1 ISIS-Spf:   (accepted) ISIS-Spf: Add 0000.0C0A.2AA9.00-00 to TENT, metric 10 ISIS-Spf:   Next hop 0000.0C0A.2AA9 (Ethernet0) ISIS-Spf: Move 0000.0C0A.2AA9.00-00 to PATHS, metric 10 ISIS-Spf: Add 172.16.19.0/255.255.255.0 to IP RIB, metric 20 ISIS-Spf: Next hop 0000.0C0A.2AA9/172.16.19.1 (Ethernet0) (rejected) ISIS-Spf: Redundant IP route 172.16.24.0/255.255.255.0, metric 20, not added ISIS-Spf: Redundant IP route 172.16.25.0/255.255.255.0, metric 20, not added ISIS-Spf: Aging L1 LSP 2 (0000.0C8D.34F1.00-00), version 101 ISIS-Spf: Aging L1 LSP 3 (0000.0C0A.2AA9.03-00), version 99 ISIS-Spf: Aging L1 LSP 4 (0000.0C0A.2AA9.00-00), version 106 ISIS-Spf: Remove stale 0/0 from IP RIB ISIS-Spf: L1 LSP 4 (0000.0C0A.2AA9.00-00) flagged for recalculation from 37D73FA ISIS-Spf: Calculating routes for L1 LSP 4 (0000.0C0A.2AA9.00-00) ISIS-Spf: Add 172.16.19.0/255.255.255.0 to IP RIB, metric 20 ISIS-Spf: Next hop 0000.0C0A.2AA9/172.16.19.1 (Ethernet0) (rejected) ISIS-Spf: Add 172.16.9.0/255.255.255.0 to IP RIB, metric 20 ISIS-Spf: Next hop 0000.0C0A.2AA9/172.16.19.1 (Ethernet0) (accepted) ISIS-Spf: Redundant IP route 172.16.24.0/255.255.255.0, metric 20, not added ISIS-Spf: Redundant IP route 172.16.25.0/255.255.255.0, metric 20, not added ISIS-Spf: Aging L1 LSP 4 (0000.0C0A.2AA9.00-00), version 107

Example 10-74. debug isis spf-statistics displays statistical information about the SPF calculation.

Frankfurt#debug isis spf-statistics IS-IS SPF Timing and Statistics Data debugging is on Frankfurt# ISIS-Spf:  Compute L1 SPT ISIS-Spf: Complete L1 SPT, ISIS-Spf:  Compute time 0.032/0.032, 2/1 nodes, 0/2 links, 0 suspends ISIS-Spf:  Compute L1 SPT ISIS-Spf: Complete L1 SPT, ISIS-Spf:  Compute time 0.036/0.036, 2/1 nodes, 0/2 links, 0 suspends

Within each area, every router must have an identical link-state database. Additionally, every L1/L2 and L2 router in the IS-IS domain must have an identical L2 database. If you suspect that a router's link-state database is not correctly synchronized, examine the LSP IDs and the checksums. The same LSP IDs should exist in every database, and the checksum of each LSP should be identical in every database.

Two debug commands can help you observe the synchronization process. The first is debug isis update-packets (Example 10-75), which displays information about SNPs and LSPs the router sends and receives. The second command, debug isis snp-packets (Example 10-76), displays information specific to the CSNPs and PSNPs the router sends and receives.

Example 10-75. debug isis update-packets displays information about SNPs and LSPs.

Frankfurt#debug isis update-packets IS-IS Update related packet debugging is on Frankfurt# ISIS-Upd: Rec L1 LSP 0000.0C0A.2AA9.00-00, seq 10, ht 1199, ISIS-Upd: from SNPA 0005.5e6b.50a0 (Ethernet0) ISIS-Upd: LSP newer than database copy ISIS-Upd: Leaf routes changed ISIS-Upd: Rec L1 LSP 0000.0C0A.2AA9.00-00, seq 11, ht 1199, ISIS-Upd: from SNPA 0005.5e6b.50a0 (Ethernet0) ISIS-Upd: LSP newer than database copy ISIS-Upd: Important fields changed ISIS-Upd: Full SPF required ISIS-Upd: Rec L1 LSP 0000.0C0A.2AA9.00-00, seq 12, ht 1199, ISIS-Upd: from SNPA 0005.5e6b.50a0 (Ethernet0) Frankfurt#

Example 10-76. debug isis snp-packets displays detailed information about CSNPs and PSNPs.

Frankfurt#debug isis snp-packets IS-IS CSNP/PSNP packets debugging is on Frankfurt# ISIS-Snp: Rec L1 CSNP from 0000.0C0A.2AA9 (Ethernet0) ISIS-Snp: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF ISIS-Snp: Same entry 0000.0C04.DCC0.00-00, seq 9 ISIS-Snp: Same entry 0000.0C0A.2AA9.00-00, seq 1A ISIS-Snp: Same entry 0000.0C0A.2AA9.01-00, seq 6 ISIS-Snp: Rec L1 CSNP from 0000.0C0A.2AA9 (Ethernet0) ISIS-Snp: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF ISIS-Snp: Same entry 0000.0C04.DCC0.00-00, seq 9 ISIS-Snp: Entry 0000.0C0A.2AA9.00-00, seq 1B is newer than ours (seq 1A), sending PSNP ISIS-Snp: Same entry 0000.0C0A.2AA9.01-00, seq 6 ISIS-Snp: Build L1 PSNP entry for 0000.0C0A.2AA9.00-00, seq 1A ISIS-Snp: Sending L1 PSNP on Ethernet0 ISIS-Snp: Rec L1 CSNP from 0000.0C0A.2AA9 (Ethernet0) ISIS-Snp: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF.FFFF.FF-FF ISIS-Snp: Same entry 0000.0C04.DCC0.00-00, seq 9 ISIS-Snp: Same entry 0000.0C0A.2AA9.00-00, seq 1B ISIS-Snp: Same entry 0000.0C0A.2AA9.01-00, seq 6 ISIS-Snp: Rec L1 CSNP from 0000.0C0A.2AA9 (Ethernet0) ISIS-Snp: CSNP range 0000.0000.0000.00-00 to FFFF.FFFF. FFFF.FF-FF ISIS-Snp: Same entry 0000.0C04.DCC0.00-00, seq 9 ISIS-Snp: Same entry 0000.0C0A.2AA9.00-00, seq 1B ISIS-Snp: Same entry 0000.0C0A.2AA9.01-00, seq 6 Frankfurt#

Case Study: Integrated IS-IS on NBMA Networks

Figure 10-56 shows four routers running IS-IS connected by a partially meshed Frame Relay network. The IP addresses, DLCIs, and NETs are shown. The IS-IS configurations of all routers have been verified as correct, and no authentication is configured.

Figure 10-56. IS-IS is not establishing adjacencies across the Frame Relay network.

The problem with this network is that no routes are being discovered (Example 10-77). The IP addresses of neighbors' Frame Relay interfaces can be pinged, but the addresses of the routers' other interfaces cannot be pinged (Example 10-78). The pings show that the Frame Relay PVCs are operational and that IP is working, but that the routers are not routing.

Example 10-77. The route table of Oslo in Figure 10-56 does not contain any IS-IS routes.

Oslo#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set C    192.168.1.0 is directly connected, TokenRing0 C    192.168.5.0 is directly connected, Serial0 Oslo#

Example 10-78. Pings are successful to other interfaces connected to the Frame Relay network, but addresses reachable through the routers cannot be pinged.

Oslo#ping 192.168.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms Oslo#ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Oslo#ping 192.168.5.3 Type escape sequence to 5, 100-byte ICMP Echos to 192.168.5.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/66/68 ms Oslo#ping 192.168.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Oslo#ping 192.168.5.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.5.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 64/65/68 ms Oslo#ping 192.168.4.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Oslo#

The next step is to check the IS-IS neighbor table. Oslo's neighbor table shows that Hellos have been received (Example 10-79) and that the router knows the System IDs of its neighbors. It also shows that the IP addresses and the area addresses of the neighbors are correct. However, the state of all of the neighbors is Init, indicating that a full adjacency has not been established. A look at the link-state database verifies the absence of adjacencies; the only LSPs in Oslo's database are the router's own LSPs (Example 10-80).

Example 10-79. Oslo's IS-IS neighbor table shows that Hellos are being received but that the adjacency is not complete.

Oslo#show clns is-neighbors detail System Id          Interface   State   Type Priority   Circuit Id         Format 0000.00EF.5678     Se0         Init    L1L2 0 /0       0000.0000.0000.00  Phase V   Area Address(es): 01   IP Address(es): 192.168.5.3   Uptime: 1:11:20 0000.00EF.1234     Se0         Init    L1L2 0 /0       0500.0000.0000.00  Phase V   Area Address(es): 01   IP Address(es): 192.168.5.2   Uptime: 1:11:15 0000.00EF.9ABC     Se0         Init    L1L2 0 /0       0700.0000.0000.00  Phase V   Area Address(es): 01   IP Address(es): 192.168.5.4   Uptime: 1:11:20 Oslo#

Example 10-80. Oslo's link-state database does not contain any LSPs from any of its neighbors.

Oslo#show isis database IS-IS Level-1 Link State Database LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL 0000.00EF.DEF1.00-00* 0x0000001F   0x8460        947           0/0/0 0000.00EF.DEF1.02-00* 0x00000010   0x695E        896           0/0/0 0000.00EF.DEF1.04-00* 0x00000002   0x2F2E        887           0/0/0 0000.00EF.DEF1.05-00* 0x00000008   0x1C3A        847           0/0/0 IS-IS Level-2 Link State Database LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL 0000.00EF.DEF1.00-00* 0x00000013   0x81BE        829           0/0/0 Oslo#

The fact that Hellos are being received, but adjacencies are not being established, points to a problem with the Hellos themselves. If the parameters in the Hellos are not correct, the PDU is dropped. So debug isis adj-packets is enabled to observe the Hellos. Of particular interest in the debug output (Example 10-81) are the "encapsulation failed" messages. These messages show that the router apparently cannot interpret the received Hellos and is dropping them.

Example 10-81. The results of enabling debug isis adj-packets show that Hellos are being dropped because of encapsulation failures.

Oslo#debug isis adj-packets IS-IS Adjacency related packets debugging is on Oslo# ISIS-Adj: Sending L1 IIH on TokenRing0 ISIS-Adj: Encapsulation failed for level 2 IIH on Serial0 ISIS-Adj: Rec serial IIH from DLCI 17 on Serial0, cir type 3, cir id 00 ISIS-Adj: rcvd state 2, old state 1, new state 1 ISIS-Adj: Action = 1, new_type = 3 ISIS-Adj: Sending L2 IIH on TokenRing0 ISIS-Adj: Encapsulation failed for level 1 IIH on Serial0 ISIS-Adj: Sending L1 IIH on TokenRing0 ISIS-Adj: Rec serial IIH from DLCI 18 on Serial0, cir type 3, cir id 07 ISIS-Adj: rcvd state 2, old state 1, new state 1 ISIS-Adj: Action = 1, new_type = 3 ISIS-Adj: Encapsulation failed for level 2 IIH on Serial0 ISIS-Adj: Sending L2 IIH on TokenRing0 ISIS-Adj: Encapsulation failed for level 1 IIH on Serial0 ISIS-Adj: Rec serial IIH from DLCI 16 on Serial0, cir type 3, cir id 05 ISIS-Adj: rcvd state 2, old state 1, new state 1 ISIS-Adj: Action = 1, new_type = 3 ISIS-Adj: Sending L1 IIH on TokenRing0 ISIS-Adj: Encapsulation failed for level 2 IIH on Serial0no debu ISIS-Adj: Sending L2 IIH on TokenRing0 ISIS-Adj: Encapsulation failed for level 1 IIH on Serial0g a ISIS-Adj: Sending L1 IIH on TokenRing0 ISIS-Adj: Rec serial IIH from DLCI 17 on Serial0, cir type 3, cir id 00 ISIS-Adj: rcvd state 2, old state 1, new state 1 ISIS-Adj: Action = 1, new_type = 3 ISIS-Adj: Encapsulation failed for level 2 IIH on Serial0ll

Any time an "encapsulation failed" message is received, suspicion should fall on the data link and its connected interfaces. Examining the interfaces with the show interface serial command reveals no significant error rates, so it is unlikely that the Hellos are being corrupted on the Frame Relay PVCs. The next step is to examine the interface configurations. The interface configurations for the four routers in Figure 10-56 are displayed in Example 10-82 through Example 10-85.

Example 10-82. Oslo's interface configuration.

interface Serial0  ip address 192.168.5.1 255.255.255.0  ip router isis  encapsulation frame-relay  frame-relay interface-dlci 16  frame-relay interface-dlci 17  frame-relay interface-dlci 18

Example 10-83. Stockholm's interface configuration.

interface Serial0  no ip address  encapsulation frame-relay ! interface Serial0.16 point-to-point  ip address 192.168.5.2 255.255.255.0  ip router isis  frame-relay interface-dlci 16

Example 10-84. Copenhagen's interface configuration.

interface Serial0  no ip address  encapsulation frame-relay ! interface Serial0.16 point-to-point  ip address 192.168.5.3 255.255.255.0  ip router isis  frame-relay interface-dlci 16

Example 10-85. Helsinki's interface configuration.

interface Serial0  no ip address  encapsulation frame-relay ! interface Serial0.16 point-to-point  ip address 192.168.5.4 255.255.255.0  ip router isis  frame-relay interface-dlci 16

A comparison of these configurations reveals the problem, although it might not be readily apparent. Stockholm, Copenhagen, and Helsinki are all configured with point-to-point subinterfaces. Oslo is not using subinterfaces. By default, a Cisco serial interface with Frame Relay encapsulation is a multi-point interface. Therefore, Stockholm, Copenhagen, and Helsinki are sending point-to-point IS-IS Hellos, and Oslo is sending L1 and L2 IS-IS LAN Hellos.

IS-IS does not have a configuration option similar to OSPF's ip ospf network command; therefore, Oslo must be reconfigured with point-to-point subinterfaces, and the IP addresses must be changed so that each PVC is a different subnet (Example 10-86).

Example 10-86. After Oslo has been configured with point-to-point subinterfaces and the PVCs have been readdressed as individual subnets, IS-IS routing is functioning.

Oslo#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set C    192.168.1.0 is directly connected, TokenRing0 i L1 192.168.2.0 [115/20] via 192.168.5.5, Serial0.16 i L1 192.168.3.0 [115/20] via 192.168.5.9, Serial0.17 i L1 192.168.4.0 [115/20] via 192.168.5.13, Serial0.18      192.168.5.0 is variably subnetted, 4 subnets, 2 masks C       192.168.5.12 255.255.255.252 is directly connected, Serial0.18 C       192.168.5.8 255.255.255.252 is directly connected, Serial0.17 C       192.168.5.4 255.255.255.252 is directly connected, Serial0.16 C       192.168.5.0 255.255.255.0 is directly connected, Serial0 Oslo#