Troubleshooting ISO CLNS Connectivity

ISO CLNS End System Connectivity

Figure 9-1 illustrates Area 1 of Domain 1 in an ISO CLNS network segment that contains three domains. In Area 1, some end systems cannot communicate with other end systems. The following facts summarize the situation:

• ES1 cannot communicate with ES2, an end system that is on the same network segment.
  

• ES1 cannot communicate with ES4, an end system that is on a different network segment from ES1 but is in the same area as ES1.
  

• ES1 cannot communicate with an end system that is outside of area 1 but is in domain 1.
  

Many times, these symptoms are caused by simple configuration errors, such as inadvertently assigning duplicate addresses. By using debug and management tools, problems can be quickly isolated.

Figure 9-1 : Initial ISO CLNS Connectivity Scenario Map

Environment Description

The relevant elements of the internetworking environment shown in Figure 9-1 can be summarized as follows:

• Area 1 consists of six routers (Router-R1 through Router-R6) and six end systems (ES1 through ES6). End systems ES1 through ES3 are on the same Ethernet segment, ES4 and ES5 share another Ethernet segment, and ES6 is on the same Ethernet segment as Router-R5 and Router-R6.
  

• Router-R2 and Router-R5 are connected by a point-to-point link. Both routers connect to the domain 1 backbone and are considered Level 2 routers, although in this discussion they participate in both Level 1 and Level 2 routing.
  

• Router-R3 has a point-to-point connection to Router-R4 and another point-to-point connection to Router-R6.
  

• The addressing scheme for domain 1, the areas within domain 1, and the systems within area 1 are based on the topology shown in Figure 9-2 and summarized in Table 9-1.
  

Figure 9-2 : ISO CLNS Scenario Area and Domain Topology Map

.

Table 9-1 : Domain 1 Area 1 System IDs

End System/ Router	System ID (6 bytes)
ES1	0000.0000.0001
ES2	0000.0000.0002
ES3	0000.0000.0003
ES4	0000.0000.0004
ES5	0000.0000.0005
ES6	0000.0000.0006
Router-R1	0000.0000.1001
Router-R2	0000.0000.1002
Router-R3	0000.0000.1003
Router-R4	0000.0000.1004
Router-R5	0000.0000.1005
Router-R6	0000.0000.1006

Table 9-1 shows a simplified way of maintaining address consistency within an area. Given the domain 1 and area 1 addresses shown in Figure 9-2, the complete (NSAP) address for ES1 would be the following:

49.0001.0001.0001.0000.0000.0001.00

Note that the six-byte system ID and the one-byte n-selector are appended to the domain and area address. Similarly, the NSAP address for Router-R1 would be the following:

49.0001.0001.0001.0000.0000.1001.00

Diagnosing and Isolating Problem Causes between ES1 and ES2

The following problems are likely candidates for the first symptom. (ES1 cannot communicate with ES2, a host on the same network segment.)

• ES2 or ES1 does not support an implementation of the End System-to-Intermediate System (ES-IS) protocol that allows the two systems to dynamically discover one another and place the routing entries into the adjacency database.
  

• Static entries are missing or misconfigured in the end systems.
  

This list is ordered according to a combination of two criteria: ease of problem determination and the likelihood of being the actual problem. In general, it is useful to eliminate most likely problems first, and then to tackle more complex problems as necessary. The problem-solving process that follows illustrates this strategy.

Once you develop a list of possible problems, analyze each potential cause. The following discussion considers the problems for this scenario.

Checking Adjacency Databases in the End Systems

A number of mechanisms place system entries in adjacency databases. For a description of the various messages that end systems (ESs) and intermediate systems (ISs) use to advertise their presence on the network, see the Internetworking Technology Overview publication. These messages include the following:

• IS hello (ISH) packets
  

• ES hello (ESH) packets
  

• Redirect (RD) messages
  

• Link state packets (LSPs)
  

Common causes for a missing entry in the adjacency database are end systems that require manual installation of a static entry and end systems that do not fully support the ES-IS protocol, which means that they cannot dynamically discover other systems in the network.

To correct a missing entry in the adjacency database, follow these steps:

Step 1 Look in the adjacency database on each system and verify that addresses exist for the other systems that are directly attached. Create static entries in the adjacency database for the missing NSAP to Subnetwork Point of Attachment (SNPA) mappings.

Step 2 Check the ES-IS implementation on ES1 and ES2. Doing so may require contacting the software supplier or researching the system documentation.

Step 3 Depending on the ES-IS implementation on the end system, you might need to create static entries for other ESs that are on the same physical interface or ISs on the same interface.

If ES1 and ES2 have entries for one another in their adjacency databases, they should be able to directly communicate.

Diagnosing and Isolating Problem Causes Between ES1 and ES4

The following problems are likely candidates for the second symptom. (ES1 cannot communicate with ES4, a host on a different network segment in the same area.)

• Either ES1 or ES4 does not support an implementation of the ES-IS protocol that allows the systems to dynamically discover their intermediate systems (Router-R1 and Router-R4). This problem is described in the section "Checking Adjacency Databases in the End Systems" earlier in this section.
  

• There is a connectivity problem between ES1 and ES4.
  

Checking Connectivity from the Router to the End System

The steps that follow focus on using the EXEC trace and show EXEC commands to verify connectivity from the router to the end system. Systematically verify each link in the path.

Step 1 At Router-R1, use the trace EXEC command to verify connectivity to ES4. Based on the network installation map, which should resemble Figure 9-1, you can see that the path to ES4 is through Router-R3 and Router-R4. Use the trace command on the NSAP address for ES4. Figure 9-3 shows an example of the trace command output.

Figure 9-3 : Output from the trace Command

It is most likely that connectivity problems will occur between ES4 and Router-R4, rather than between the routers.

Step 2 Use EXEC show commands to display the routing table and adjacency database information for the router.

If you get a response from Router-R3 but not from Router-R4, Router-R4 does not have an entry for ES4. Establish a connection to Router-R4 and display the routing table information.

If you are running ISO-Interior Gateway Routing Protocol (IGRP), use the show clns route EXEC command. (See Figure 9-4.)

Figure 9-4 : Output of the show clns route Command

If you are running IS-IS, use the show isis routes EXEC command. (See Figure 9-5.)

Figure 9-5 : Output of the show isis routes Command

Step 3 Next, use the show clns neighbors command to see whether Router-R4 has adjacency information for ES4. (See Figure 9-6.) If the show clns neighbors EXEC command shows a system ID for ES4 and its SNPA value is valid, there might be a problem with a misconfigured area address as described in the next step.

Figure 9-6 : Output of the show clns neighbors Command

Step 4 Use the show clns neighbors detail EXEC command to show which area address ES4 is advertising in its ESH packets. (See Figure 9-7.) If the area address being advertised is different from that of the area configured for Router-R4, the router has no indication that ES4 is in its area and therefore does not forward packets to it.

Figure 9-7 : Output of the show clns neighbors detail Command

Correct the area address entry on ES4.

Step 5 If the routing table entry for ES4 shows that it exists, but is on a different network, there are two possibilities: duplicate end system addresses exist within the area, or a routing loop exists. To check on duplicate end system addresses, use the show clns route EXEC command and the show clns neighbors EXEC command at each point in the path to the suspect ES4 until you locate the problem. In the case of a duplicate address that causes another end system to masquerade as ES4, reconfigure the duplicate system to its proper NSAP address.

Step 6 To see if there is a routing loop, you can check the conditions that follow. In general, a routing loop within an area is a transient condition caused by a topology change. However, if a loop persists, use the trace route EXEC command to discover where the loop occurs.

Step 7 If you are running the ISO-IGRP, turn on debugging with the debug clns igrp packet privileged EXEC command. Refer to the Debug Command Reference publication for a description of debug output.

Step 8 If you are running the IS-IS protocol, you can perform a quick check of the LSP databases and verify that they are synchronized, as follows:

• Look at all sequence numbers of all LSPs and see whether they are the same. LSPs are sorted, so it is fairly easy to perform a visual check on the LSP display for each router. Figure 9-8 shows a sample display emphasizing the LSP sequence numbers. This method is suitable for a small network.
  

Figure 9-8 : Output of the show isis database Command Showing LSP Sequence Numbers

• You can use the debug isis update packets privileged EXEC command and look at the debug output to pinpoint the problem. Refer to the Debug Command Reference publication for a description of debug output.
  

Verifying IS-IS Connections

In IS-IS, use the following procedure to verify that connections exist between the routers and end systems:

Step 1 If the show isis routes EXEC command does not show ES4, yet it appears in the adjacency database displayed by show clns neighbors, there is no connectivity between Router-R4 and the pseudo node. The pseudo node is a fictitious node that reports all the end system and intermediate system nodes on a subnetwork. The node information is present in a pseudo node IS-IS LSP. Router-R4 will have a connection to the pseudo node, which provides a connection to all other reported end systems.

Use the show isis database EXEC command to verify that Router-R4 is generating both an LSP and a pseudo node LSP, as shown in Figure 9-9.

Figure 9-9 : Output of the show isis database Command Showing LSP and Pseudo Node LSP

Step 2 Next, use the show isis database detail 000.000.0004.01-00 level-1 command to display the contents of the pseudo node for ES4 Level 1 LSP. You are looking for the end system (ES4) to be listed in the LSP of the pseudo node. If the end system does not appear, there is probably a bug in the designated router.

If you use the clns host global configuration command to map the name ES4 to its associated NSAP address, you can use the name rather than the system ID in the show isis database detail EXEC command. Figure 9-10 shows how the clns host command is used.

Figure 9-10 : Example of the clns host Command

Step 3 If ES4 appears in the pseudo node LSP, verify that Router-R4 appears in the pseudo node LSP, as shown in Figure 9-11.

Figure 9-11 : Output Showing Pseudo Nodes for ES and IS

The pseudo node advertises all ESs and ISs on the subnetwork. By looking at the command output, you should see that the pseudo node has a link to ES4 and to Router-R4, and that Router-R4 has a connection back to the pseudo node. If all these pieces of the connection exist, there is connectivity between Router-R4 and ES4.

A pseudo node may exist, but Router-R4 is not yet in the pseudo node LSP because IS-IS was not configured on its Ethernet interface. The reason a pseudo node would exist for Router-R4 is because it may have been flooded through that path through another router.

Another problem not to be overlooked in this instance is that IS-IS routing was not enabled on RouterR4's Ethernet interface.

Step 4 Continue to work backward from Router-R4. Verify in an LSP from Router-R3 that a connection exists to Router-R4. Verify that Router-R3 has a connection to the pseudo node on the Ethernet shared with Router-R1 (and Router-R2) and that the pseudo node has a connection back to Router-R3, Router-R2, and Router-R1.

Step 5 Verify in the LSP for Router-R1 that it has a connection to the pseudo node in Router-R3. If there is no connection to the pseudo node, verify that the LSP sequence numbers are the same for Router-R1 as they are for Router-R3.

Step 6 After verifying that all the connections exist in the various LSP databases as shown by the show isis database detail level1 EXEC command, connectivity should exist between ES1 and ES4. If there is a topology change---for example, a router is moved or wiring connections are changed---some time can pass before the change is detected, the new LSP is flooded throughout the network, and all the routers and end systems generate new routing tables with the updated information.

Verifying ISO-IGRP Connections

In ISO-IGRP, use the following steps to verify that connections exist between the routers and end systems along the path from ES1 to ES4:

Step 1 Turn on debugging in Router-R3 using the debug clns igrp packet privileged EXEC command and look at the update packets that are coming in from Router-R4. If you see that Router-R4 is advertising ES4, determine why Router-R3 is not putting ES4 in its routing table.

Step 2 At Router-R3, use the trace EXEC command to verify the path back to Router-R1.

Step 3 For each router in the path from Router-R1 to Router-R4, use the show clns routes EXEC command to verify the router is learning the path.

Step 4 After using the debug command, use the no debug clns igrp packets command to turn it off.

Diagnosing Problem Causes between ES1 and an End System outside Its Area

For the third connectivity symptom (ES1 cannot communicate with an end system outside its own area, such as ES8), the problem-solving steps are the same as those in the section "Diagnosing and Isolating Problem Causes Between ES1 and ES4" earlier in this chapter.

• Use the trace EXEC command to address the end system SNPA.
  

• Verify each link along the path and display the routing table contents by using the show clns route EXEC command (or the show isis routes EXEC command) and the show clns neighbors EXEC command.
  

End System Problem Solution Summary

This scenario focused on diagnosing end system connectivity problems.

• Misconfigured addresses were corrected.
  

• Connectivity was verified by displaying adjacency tables (IS-IS) and routing tables (ISO-IGRP).
  

• Routing for IS-IS or ISO-IGRP was enabled as required.
  

Figure 9-12, Figure 9-13, and Figure 9-14 provide representative configuration listings for routers discussed in this scenario.

Figure 9-12 : Partial Configuration Listing for Router-R1

Figure 9-13 : Partial Configuration Listing for Router-R3

Figure 9-14 : Partial Configuration Listing for Router-R4

ISO CLNS Connectivity over WANs

Figure 9-15 illustrates various subnetworks that communicate through a Frame Relay cloud. The following facts summarize the situation:

• End system ES1 cannot communicate with ES2, an end system that is reached through the WAN, but is part of a fully meshed, logical network.
  

• ES4 cannot communicate with ES5, an end system that is reached through a permanent virtual circuit (PVC) on a subinterface.
  

• ES4 cannot communicate with ES1, an end system that is reached through ES5 and relies on subinterfaces and PVCs on both Router-R5 and Router-R1.
  

Figure 9-15 : ISO CLNS Communication through a WAN Using Subinterfaces and PVCs

Environment Description

The relevant elements of the internetworking environment shown in Figure 9-15 can be summarized as follows:

• Router-R1, Router-R2, and Router-R3 are fully meshed and participate in multiaccess, broadcast communication.
  

• Router-R1 uses subinterfaces on its physical port S1 to communicate with the meshed network (S1.1) and to provide a PVC to Router-R5 (S1.2). A subinterface is occasionally referred to as a "virtual interface" or a "virtual port."
  

• Router-R5 uses subinterfaces on its physical port S0 to provide two PVCs: one to Router-R1 (S0.1) and one to Router-R4 (S0.2).
  

• Router-R1 and Router-R4 cannot communicate directly, but must have their packets forwarded by Router-R5.
  

Diagnosing and Isolating Problem Causes between ES1 and ES2 over a WAN

Given the situation, a number of problems might explain connectivity symptoms.

The following problems are likely candidates for the first symptom. (ES1 cannot communicate with ES2, a host reached through the WAN.)

• One of the routers (Router-R1 or Router-R2) does not have an entry in the adjacency database because the routers have missing or incorrect frame-relay map interface configuration commands.
  

• ES1 or ES2 does not support an implementation of the ES-IS protocol that allows the two systems to dynamically discover one another and place the entries into the adjacency database.
  

• Static entries are missing or misconfigured in the end systems.
  

IS-IS and ISO-IGRP protocols treat WANs as if they are multiaccess broadcast networks. In this situation, where a meshed network exists between the end systems, the routing protocol looks at the WAN as if it was a "solid wire" network like Ethernet. Other than the addition of frame-relay map commands in the routers, verifying ES-to-ES connectivity is the same as described in the section "Diagnosing and Isolating Problem Causes between ES1 and ES2," earlier in this chapter.

The information that follows explores the router as the cause of the connectivity problem.

Checking for Missing or Incorrect map Commands

A common cause for a missing entry in an adjacency database on the router is a missing or incorrect frame-relay map command. Assume the Data Link Connection Identifier (DLCI) values for routers are as shown in the following list:

• Router-R1: DLCI 16 to R2
  

• Router-R1: DLCI 17 to R3
  

• Router-R1: DLCI 18 to R4
  

• Router-R2: DLCI 21to R1
  

• Router-R2: DLCI 23 to R3
  

• Router-R3: DLCI 31 to R1
  

• Router-R3: DLCI 32 to R2
  

Step 1 If you are running ISO-IGRP, look in the adjacency database on each router and verify that entries exist for the other router that is accessed through the Frame Relay WAN. Use the show clns neighbors EXEC command to display the adjacency information, as shown in Figure 9-16.

Figure 9-16 : Output of the show clns neighbors Command

Step 2 If the adjacency information is missing, check the router configuration and look for missing or incorrect frame-relay map commands. The frame-relay map commands are required whether you are running ISO-IGRP or IS-IS over the router interface.

At Router-R1 you must have interface configuration commands on the port that provide the connection to the WAN. For the DLCI values in this scenario, the commands would be the following.

interface serial 1

encapsulation frame-relay

interface serial 1.1 multipoint

frame-relay map clns 16 broadcast

frame-relay map clns 17 broadcast

interface serial 1.2

frame-relay interface-dlci 19

Similarly, Router-R2 must have interface configuration commands that point to Router-R1 and Router-R3.

frame-relay map clns 21 broadcast

frame-relay map clns 23 broadcast

And Router-R3 must have interface configuration commands that point to RouterR1 and Router-R2.

frame-relay map clns 31 broadcast

frame-relay map clns 32 broadcast

Step 3 Verify that ISO-IGRP or IS-IS routing is enabled for the router interface with the clns router iso-igrp or clns router isis interface configuration command on each router.

interface serial 0
encapsulation x25
x25 address 777777022
clns router static area0099
no clns checksum

clns is-neighbor 49.0001.0000.0c00.1b87.00 7777770020
clns route 49.0001 49.0001.0000.0c00.1b87.00 
clns route 49.0000.0000.0000.01 49.0001.0000.0c00.1b87.00 

interface serial 0
encapsulation x25-dce
x25 address 777777020
clns router static area01
no clns checksum
clns is-neighbor 49.0099.0000.0c00.029e.00 7777770022
clns route 49.0099 49.0099.0000.0c00.029e.00 
clns route 49.0000.0000.0000.99 49.0099.0000.0c00.029e.00