|
|
This chapter presents problem-solving scenarios focusing on identifying, isolating, and solving problems that block connectivity in internetworks. These kinds of problems also are referred to as reachability problems.
The problem-solving scenarios addressed here provide details concerning specific situations and illustrate the process of problem isolation and resolution. The scenarios provided here span different protocols, media, and problem types. The objective of the scenarios is to illustrate a problem-solving method based on the general problem-solving model defined in Chapter 1, "Troubleshooting Overview." These scenarios are composites of real-world situations.
Each scenario includes the following components:
Subsequent chapters present a series of symptom modules that provide snapshots of common symptoms, possible causes, and suggested actions.
More details concerning scenarios and symptom modules are provided in the section "How to Use This Publication," in Chapter 1.
 | Caution Throughout this and other chapters, the use of debug commands is suggested for obtaining information about network traffic and router status. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internets are experiencing high load conditions. When you finish using a debug command, remember to disable it with its specific undebug command or with the undebug all command. |
Connectivity problems manifest themselves in many ways. Some examples are users' inability to make terminal connections, known routes not appearing in routing tables, or file servers failing to respond to boot requests. Similarly, certain symptoms (such as users being unable to connect to hosts) may result from a variety of problems.
This chapter presents a series of situational discussions and includes application of various diagnostic tools. Every possible scenario obviously cannot be covered. Indeed, the scenarios included here only scratch the surface of possible situations. However, certain common themes typically tie all connectivity problems together. This chapter illustrates the use of troubleshooting tools and techniques to identify those common themes.
The following problem-solving scenarios are presented in this chapter:
In recent years, AppleTalk-based internetworks have grown in size and scope of implementation. Once viewed as a toy protocol, AppleTalk has been stretched to allow handling of more nodes and sharing of services in larger internets. Along with these larger-scale and more complex implementations have come some of the implementation headaches common to any multivendor, enterprise internet. This scenario focuses on several common problems that can block access to servers and services on an AppleTalk internet.
In this case, a number of local networks are segmented with routers, while a remote network is linked over a serial line (refer to Figure 2-1).
Assume that the following symptoms were reported for this AppleTalk internet:
There are a number of problems that might lead to these symptoms. The first step is to characterize this internet's configuration and then develop a list of likely suspect problems.
Some relevant facts regarding the internetworking environment shown in Figure 2-1can be summarized as follows:
Given the situation, a number of problems could explain reported symptoms.
The following problems are likely candidates for symptom #1 (laser printer Slug on Ethernet Segment #3 is reported as not visible on Chooser by Mac User Melvin on Ethernet Segment #2.):
The following problems are likely candidates for symptom #2 (DEC VAX-based AppleShare Server on Ethernet Segment #1 is not visible to any users except users on Ethernet Segment #5--a nonextended network):
The following problems are likely candidates for symptom #3 (AppleShare server Spunky on Ethernet Segment #4 is sometimes visible in Chooser of Mac users in this internet, but no one can access services on that server):
Once a possible problem list is determined, each potential cause must be systematically analyzed. The following discussion considers the possible problems listed and illustrates resolution of discovered problems.
Before continuing with this process, it will be useful to map out the assignment of network numbers/cable ranges and zones (or zone lists) associated with the internet. Figure 2-2 illustrates the known network numbers, cable ranges, and zones associated with this internet.
This analysis starts by considering the problem list associated with Spunky's intermittent availability (symptom #3). At the same time, since the DEC VAX problem shares a possible cause with the Spunky access problem, the analysis evaluates the possibility of a common problem causing both symptoms. After that, the analysis steps through the list of possible problems until all possible causes are exhausted.
It is not unusual to start with a possible problem because it is easy to diagnose. With this in mind, first consider the possibility of a ZIP storm.
Step 1: To detect a ZIP storm, first examine network activity with the show appletalk traffic command.
Look for "ZIP Requests" in the resulting display. Repeat this command after about 30 seconds or so. If the number is greater than 10 and increasing, there is likely to be a ZIP storm.
Step 2: If you observe an apparent ZIP storm, use the show appletalk route command and look for a network that shows up in the table but has "no zone set" indicated for its zone listing. If such a listing appears, determine why the node is not responding to ZIP requests.
For this case, assume that no unusual number of ZIP requests appear and you eliminate a ZIP storm as a cause for symptom #3. All symptoms are still being experienced.
The next possible cause for both symptom #2 and symptom #3 is the existence of duplicate network numbers in the internet. Unfortunately, these are not usually easy to find.
Step 1: First, use show appletalk interface ethernet 6 on Router-R3 to obtain the AppleTalk network number for the local network. In this case, the (non-extended) network number is 2. Figure 2-3 illustrates a typical output for this command.
Step 2: Next, disable AppleTalk using the no appletalk routing global configuration command as illustrated in Figure 2-4.
If there are no duplicate network numbers (another network number 2), no appletalk routing results in network number 2 being aged out of all routing tables in the internet.
Step 3: To determine whether this happens, perform successive show appletalk route 2 commands on Router-R3 until the hop count stabilizes (indicating that a duplicate does exist), or until the route ages out (indicating that a duplicate does not exist).
If there is a duplicate, network 2 will not age out, but instead, appears as a learned route from some other interface. Figure 2-5 illustrates how this change is registered in the show appletalk route 2 display.
Figure 2-5 indicates the neighbor from which the location of the duplicate was learned. Since IP also is enabled in this internet, you can pinpoint the duplicate network number by connecting to the indicated neighbor. Telnet to the indicated neighbor (here at network.node address 8.2), and remember to use the IP address or the router's IP host name (in this case assume Router-R2).
Step 4: Once a connection is made to the neighbor, repeat the show appletalk route 2 command and examine the resulting output for the location of network number 2. Iterate this process until the display indicates that the network is directly connected.
Step 5: When the network is shown as directly connected, you have found the duplicate network number location. Now, you must change one of the routers (Router-R3 or the found router), as well as any other routers connected to the suspect network.
Assume that doing this solves Symptom 3; offnet Macintosh users in the internet now can access AppleShare server Spunky (after Ethernet interface E6 on Router-R3 has been restored to service).
However, users still cannot access the DEC VAX AppleShare server, and the laser printer Slug remains inaccessible.
It is quite possible that there is yet another duplicate network number in the internet, resulting in the DEC VAX being unavailable as an AppleShare server.
However, remember that VAX AppleShare service is accessible to Mac users Biff and Debbie on Ethernet Segment #5 (network number 50). This suggests that it is unlikely that access to the VAX is limited by the same problem resolved in the prior step. It also rules out port configuration mismatch as a problem, as well as duplicate network numbers, because Router-R1 and Router-R3 agree about network configuration (network number/cable range and zone/zone list). This leaves a Phase 1/Phase 2 rule violation as the remaining identified possible cause.
Step 1: To determine whether this is the problem, use the show appletalk global command. Figure 2-6 illustrates the output of this command when the network is in compatibility mode. However, this display indicates that the internet is not in compatibility mode when a Phase 1/Phase 2 rule violation exists. A rule violation is said to exist when any node has a configuration the does not conform to the following rules:
Step 2: Next, use the show appletalk neighbor command at Router-R1 to identify the specific neighboring router that requires compatibility mode. Figure 2-7 illustrates such an listing.
Step 3: In this case, the neighbor needing compatibility mode is the VAX itself. At this point, there are two solution options: upgrade the VAX AppleShare server or use the appletalk proxy-nbp global configuration command.
This command creates what is in effect a virtual network off Router-R1. The command to implement would be as follows:
appletalk proxy-nbp 200 Developers
Note that no router can have the same network number defined as a proxy network, and the specified network number cannot be associated with a physical network.
Adding appletalk proxy-nbp forces Router-R1 to send the proper NBP Lookup Packet out all networks for the zone named "Developers." Using this command then resolves that problem of access to the VAX AppleShare server from extended networks.
However, laser printer Slug is still not accessible from Mac user Melvin on Ethernet Segment #2.
Two possible causes were cited for blocking availability to Slug: either the Router-R1 port is down, or Router-R1 or IR-1 has a configuration problem. Assume that Bobbi and Ernst (on extended network 6-6, zone Marketing) can now access offnet zones and service over Router-R1, but cannot see services on the other side of IR-1. This suggests Router-R1 is probably operational and that the problem probably is with IR-1.
Step 1: Use the show appletalk neighbor command to determine whether
Router-R1 can see IR-1. Look for any neighbors. If IR-1 has a configuration problem, it probably will not appear in the neighbor listing.
Step 2: Before proceeding with any further configuration analysis, verify that the cabling at IR-1 is intact. Try show appletalk neighbor from Router-R1 again. If router IR-1 still does not appear in the neighbor listing at this point, it is safe to suspect that IR-1 is a Phase 1 router and will require upgrading to support of AppleTalk Phase 2 to operate in this internet.
Step 3: For further evidence, use the show appletalk traffic command and look for encapsulation failures. If you see more than 100 encapsulation failures, it might suggest Phase 1/Phase 2 problems, and again bolsters the hypothesis that IR-1 is the problem in this case. Figure 2-8 illustrates the output of the show appletalk traffic command.
Step 4: To verify that IR-1 is a Phase 1 router, first bring up Router-R1 in discovery mode. This is done by (temporarily) setting the AppleTalk address for interface Ethernet1 to 0.0 using the appletalk address interface subcommand. Once this configuration is done, Router-R1 attempts to acquire configuration information for that cable from an operational Phase 1 router.
Making this change has the following effects:
However, this confirms that IR-1 is Phase 1 router (confirmation also can be done using the IR-1 configuration utility).
Step 5: To resolve this access problem, IR-1 must be upgraded to be a Phase 2 AppleTalk router, and the Cisco router must be reconfigured back to its original state (Ethernet interface E1 had an extended network cable range of 6-6).
This scenario focused on diagnosing blocked service access in AppleTalk internets. Modifications discussed in this scenario included the following:
Figure 2-9 illustrates an example final configuration listing for Router-R1, obtained using the write terminal EXEC command, where appletalk proxy-nbp has been added.
With multiprotocol internets, the chances of misconfiguration resulting in connectivity loss are substantially greater than with single-protocol networking environments. Along with the added efficiency and flexibility of multiprotocol internets comes an added level of management complexity.
The following connectivity-related scenario features both Novell and Sun networking systems sharing access to resources over Token Ring and serial media. This scenario illustrates problems facing internets characterized by concurrent bridging and routing.
Consider a corporate network composed of Token Ring segments partitioned with source- route bridges (SRBs) as illustrated in Figure 2-10. Here, the PCs on Ring 4 are unable to connect to Novell servers on Rings 2 and 3, while a PC on Ring 3 cannot communicate with the Sun file server on Ring 4.
Figure 2-10 illustrates a map of the environment discussed in this case. The following summarizes the relevant elements of this internetworking environment:
Given the situation, the following possible problems are the most likely candidates for interconnection failure:
The next step is to eliminate each potential cause as the problem source and then test the network to determine whether it is operational. The following discussion works through the process of problem isolation.
Given the difficulties being experienced, problems with the router configurations are definite possibilities. In particular, if routed protocols are not making it through an environment consisting of SRBs, look for missing multiring interface subcommands. The following steps outline actions to diagnose and remedy potential configuration problems in this kind of environment.
Step 1: Using the write terminal command on the two routers connected to the T1 serial line, look for a multiring interface subcommand for each routed protocol, or the all keyword option (applied to the Token Ring interfaces).
Step 2: Assuming the multiring command is not included or does not cover a particular protocol that is being routed (and subsequently bridged over the SRB as in this scenario), be sure to make any required changes. The following command listing example illustrates a specification of the multiring command that generates RIFs for IP frames but not for Novell IPX frames.
! interface tokenring 0 multiring ip ip address 131.108.2.4 255.255.255.0 novell network 33 !
Refer to the Router Products Configuration and Reference publication for more information about using the multiring command.
Another potential configuration-related problem rests with specifying IP network addresses. If incorrectly specified, a discontinuous network space can be created, resulting in a complete stoppage of all IP traffic at the point of discontinuity.
In this scenario, assume Token Rings 1, 2, 3, and 4 are all configured to be on subnet 131.108.1.0. The interfaces attached to the serial line linking the two sites are assigned IP addresses 192.1.100.1 (Router-Far) and 192.1.100.2 (Router-Corp).
The discontinuity in this example results from the separation of segments in the same subnet (the four Token Rings) by a segment that belongs to a different major network (the serial network).
Step 1: Use the write terminal EXEC command to determine the address specifications associated with the Token Rings and serial lines to which the routers are attached.
Step 2: There are two options for remedying this situation:
The end systems (PCs) attached to the various rings represent another likely set of problem sources in this connectivity scenario. The following steps outline actions to diagnose and remedy potential problems associated with the end systems in this kind of environment.
Step 1: Check the end systems for source-route bridge drivers.
Step 2: Reconfigure the end systems or swap out for systems that have the ability to handle SRB.
Step 3: In addition to missing SRB drivers, end systems may be unable to participate in protocol exchanges because of software problems (bugs). To isolate this kind of problem in a TCP/IP environment, ping the end station.
Step 4: If there is no response, use the show rif and show arp EXEC commands to determine the hardware address of the end station in the ARP and RIF tables. Figure 2-11 and Figure 2-12 illustrate the output of the show rif and show arp commands, respectively, when an end station is properly listed.
Step 5: If the end station does not appear in the table, use the clear rif and clear arp commands. Set the RIF timeout to a small value and ping the end station at intervals greater than the RIF timeout to see if the end station can respond.
Step 6: If the end station does not respond, use a network analyzer, such as a Network General Sniffer, to look for the end system's response to the router's XID-to-NULL SAP packet (DSAP value of 00).
The default timeout for ARP table entries is much larger than the RIF entries (such as four hours for ARP and 15 minutes for RIF). The first time that a station is pinged, there are no ARP or RIF table entries for its hardware address, so both entries are updated with the ARP response from the end station. After the default timeout for RIF, the RIF entry is cleared, whereas the ARP entry remains. When this situation arises, if the end station is pinged again, the router generates an XID packet and sends it to the destination hardware address of the end station using a NULL SAP value (DSAP value of 00) to find the RIF.
Step 7: If you do see the router XID-to-NULL SAP packet, but the end station is unable to respond, there is probably a problem with the end station (host) SRB software and you must upgrade the software on the end system.
(In one case, there was a bug in the IBM RS/6000 where an RS/6000 would not reply to an XID sent using NULL SAP.)
Topics covered in this scenario addressed a number of common SRB and routing problems encountered in IBM internets. Procedures discussed included the following:
Figure 2-13 and Figure 2-14 provide relevant configuration listings for Router-Corp and Router-Far. These configurations illustrate changes required to ensure proper RIF updating and a contiguous network addressing scheme.
Cisco's IBM connectivity options range from support for source-route bridging (SRB) and source-route transparent (SRT) bridging to translational bridging and SDLC transport over TCP/IP. Thus, network managers can tailor router configurations to the specific needs of existing networks and then reconfigure routers to respond to network changes.
The scenario that follows illustrates some of the pitfalls that you may encounter when implementing internetworking solutions in complex IBM networks. This scenario focuses on potential implementation problems associated with translational bridging, SRT, SDLC transport, and SDLC-to-LLC translation.
The large-scale corporate network illustrated in Figure 2-15 is composed of multiple Ethernet and Token Ring segments partitioned with source-route bridges, SRT bridges, a transparent bridge, and a translational bridge.
Connectivity problems on this network are as follows:
Figure 2-15 illustrates a map of the environment discussed in this case as initially configured. The following summarizes the relevant elements of this primarily bridged internetworking environment:
Before attempting to define a specific problem, it is important to identify the most likely causes and to then systematically eliminate each one. Given the situation, the following problems are the best candidates for interconnection failures:
The next step is to eliminate each potential cause as the problem source and then test the network to determine whether it is operational. The following discussion works through the process of problem isolation.
Given that the PCs on Ring #3 are trying to access DEC LAT servers on the other side of several Token Ring networks that are segmented by bridges and routers, it is possible that one or more of the PCs do not support the type of internetworking technology supported by the bridges.
In the first symptom, PC-2 is unable to access either of the target DEC LAT servers (LAT-1 and LAT-2). With an SRB in the path to both, PC-2 itself becomes a suspect. In particular, its ability to support SRB is in question. The following steps suggest ways to determine whether the system is source-route capable:
Step 1: Place a Sniffer on Ring #3 (same ring to which end station PC-2 is connected).
Step 2: Look for any frames sent by the end station (PC-2) with the high-order bit of
the source address set to 1. Figure 2-16 illustrates such Sniffer output, with the
high-order bit of the source address set to 1.
Step 3: If such a frame is not found, the end station does not support RIF and is not able to participate in source routing.
Step 4: To get PC-2's traffic through to LAT-1 and LAT-2, replace SRB-1 with an SRT. This network change is addressed later as part of a comprehensive solution; see "Problem Solution Summary" for a revised map and a description of the network changes involved.
In Symptom #2, PC-1 (which is SRB-capable) on Ring #3 can talk to DEC LAT server LAT-1, but cannot talk to DEC LAT server LAT-2. As with the preceding problem, the key here rests with technology differences between the internetworking devices in the path to the servers and the end station trying to make a connection.
The likely stopping point for traffic in this case is Router-5, which is configured as a source route transparent (SRT) bridge. Because Router-5 is attached to both a Token Ring and an Ethernet segment (and is configured for SRT), it discards packets that include RIF data. Again, as in the prior procedure, determine whether the end system of interest (here,
PC-1) is source-route capable. The steps to remedy this problem are analogous to the prior procedure, with some slight differences:
Step 1: Place a Sniffer on Ring #3 (same ring to which end station PC-1 is connected).
Step 2: Look for frames sent by the end station (PC-1) with the RIF present.
Figure 2-17 illustrates Sniffer output with RIF present.
Step 3: If such a frame is found, PC-1 is source-route capable. The RIF illustrated in Figure 2-17 specifies that the frame came from Ring 001 (hex) over bridge 1 (hex), through Ring 00A (hex) over bridge 1 (hex) to Ring 002 (hex).
Step 4: In contrast to the prior problem discussion, an end station with a RIF is a problem. When Router-5 sees the RIF in packets sent from PC-1, it will drop those packets rather than put them on the Ethernet interface.
Step 5: To get PC-1's traffic through to LAT-2, you have two choices: enable translational bridging on Router-5 or replace SRB-1 with an SRT. This network change is addressed later as part of a comprehensive solution; see "Problem Solution Summary" for a revised map and a description of the network changes involved.
Older Token Ring implementations, such as the IBM 8209, expect a vendor code (OUI field) of the SNAP header to be 000000. Cisco routers modify this field to be 0000F8 to specify that the frame was translated from Ethernet Version 2 to Token Ring. Cisco's modification of this field can cause end stations that expect the SNAP header to be 000000 to drop packets. Use the ethernet-transit-oui global configuration command to remedy this problem.
Step 1: Using the write terminal EXEC command, look for the ethernet-transit-oui global configuration command on Router-1. This command may be required on the router acting as a translational bridge.
Step 2: If frames are getting through the translational bridge, but some workstations
are dropping packets (and this command is not present), specify the
ethernet-transit-oui global configuration command on Router-1. This command forces the router to make the vendor code field 000000.
Refer to the Router Products Configuration and Reference publication for more
information.
If routed protocols are not making it through an environment consisting of SRBs, look for missing multiring Token Ring interface subcommands.
Symptom #3 suggested that Cluster-2 (3174 cluster controller) cannot communicate with FEP-2. Here, SDLC transport (tunneling) is implemented via IP encapsulation. This suggests that Router-4 or Router-5 may be missing the multiring interface subcommand--required as a result of routing between Router-4 and Router-5. The following steps outline actions to diagnose and remedy potential configuration problems in this kind of environment.
Step 1: As an initial step, use the ping EXEC command to determine whether
Router-5 can communicate with Router-4.
Step 2: Using the write terminal EXEC command (on Router-4 and Router-5), look for a multiring interface subcommand that includes the ip keyword option or the all keyword option (applied to the Token Ring interfaces).
Step 3: Assuming that the multiring command is not included or does not cover a particular protocol that is being routed (and subsequently bridged over the SRB as in this scenario), one alternative is to add the multiring ip command to Router-4 (Token Ring interface T0) and Router-5 (Token Ring interface T0), as illustrated in the initial network map (Figure 2-15). Refer to the Router Products Configuration and Reference publication for more information about using the multiring command.
Step 4: Another option is to reconfigure the network so that this problem is eliminated. Refer to Figure 2-18 in the "Problem Solution Summary" discussion to see how this can be done. In this case, removing SRB-1 and SRT-1 remedies the problem without requiring the addition of the multiring ip command.
The last symptom in our scenario indicates that Cluster-1 cannot talk to the AS/400 directly attached to Ring #2.
The following steps outline actions to isolate the reason that connections from Cluster-1 to AS/400 are blocked and to then enable access.
Step 1: Place a network analyzer on Ring #1 (same ring to which Router-3 is connected).
Step 2: Determine whether Router-3 is generating explorer packets.
Step 3: If Router-3 is not generating any explorer packets for the AS/400, check its configuration for inclusion of the partner global command and sdllc xid interface subcommand.
Step 4: If not present, add the partner and sdllc xid commands. These additions force the router to generate explorer packets.
As indicated early in this case, several of the solutions pointed to a redesign of the original network as illustrated in Figure 2-15. Figure 2-18 illustrates a suggested reconfiguration of the internetwork. The modification is the use of a Cisco router (here an AGS+) to replace SRB-1 and SRT-1, and the implementation of SRT on all Main-Net Token Ring links.
This scenario addressed a number of common problems encountered in complex IBM internets. Actions discussed included:
Figure 2-19 through Figure 2-22 provide the complete, final configuration listings for the key routers discussed in this scenario, illustrating configurations required to interconnect this internet.
With the emergence of Novell NetWare as the dominant PC-based network operating environment, network administrators have encountered increasing requirements to interconnect and segment PC LANs running Novell's IPX networking protocol. This scenario focuses on a variety of problems that can impair server access over a routed internet.
Figure 2-23 is a map of the Novell IPX internet discussed in this case. It illustrates an interconnection between two sites over an arbitrary serial network. The following facts summarize the situation:
Since no connections can be made over the serial link, it initially appears that there is a problem with traffic getting through the routers.
The relevant elements of the internetworking environment shown in Figure 2-23 can be summarized as follows:
Given the situation, a number of problems could explain both connectivity symptoms.
The following problems are likely candidates for the first symptom (Client-A cannot access services on Server-1 and Server-2):
The following problems are likely candidates for the second symptom (Client-N cannot access services on NetBIOS server):
Both lists are loosely ordered according to a combination of two criteria: ease of problem determination and likelihood of being the actual problem.
The problems identified as likely to block service access for Client-A and Client-N are essentially the same, with slight variations. 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 a possible problem list is determined, you must analyze each potential cause. The following discussion considers the problems listed and illustrates resolution of discovered problems.
The first step is to determine whether Client-A is attached to the network.This step applies for Client-N as well, and can be done at the same time.
Step 1: Visually inspect each client's physical attachment and attempt to connect to a local server. If a connection can be established, the client is obviously attached.
Step 2: If a connection cannot be established to a local server (either one does not exist or the connection attempt fails), use a protocol analyzer to determine whether clients are sending any packets. Look for packets with each client's hardware address as the source address.
Step 3: As an alternative, use the debug novell-packet EXEC command on the locally connected router (in this case Router-D) and look for each client's source address. If packets appear that include the respective client's hardware address as the source address, the client is active on the network and connectivity to Router-D is functional.
In order to use debug novell-packet, you must disable fast switching (use the no novell route-cache command on Ethernet interface E2). In addition, if you are making a virtual connection to the router, be sure to use the terminal monitor EXEC command so the debug command output will appear on your remote terminal.
In this case, assume that connectivity is verified up to Router-D from both Client-A and Client-N.
The next step is to determine whether the remote servers are attached to their Ethernet segment. This process is very similar to determining whether the clients are attached to the Downtown segment. However, there are some slight differences.
Step 1: As in the prior step, start by visually inspecting the attachment of the servers to their networks.
Step 2: Using a protocol analyzer, determine whether the servers (in this case Server-1, Server-2, and Server-N) are sending any packets on their local networks. Look for packets with each server's hardware address as the source address.
Step 3: Check for connectivity between the servers and Router-M. To do this, use show novell servers to see if the servers are included in the router's list of Novell servers. If they appear in the list, then connectivity is verified up to Router-M.
In this case, assume that connectivity is verified up to Router-M from both Server-1 and Server-N; however, Server-2 does not appear in the show novell servers output for Router-M.
Before continuing, you must determine why Server-2 is not appearing in the Novell server list on Router-M.
Use the write terminal EXEC command to determine whether Novell routing is enabled. Use the novell routing global configuration command if it is not.
Although not necessarily an obvious problem, the fact that Server-2 is not appearing in the server table for Router-M suggests that there is a configuration problem with Server-2.
By default, Novell servers send SAP updates to tell clients what services are available. However, servers running NetWare 3.11 or later can be specifically set to withhold SAP updates. If a server is set to withhold SAP updates, the local router does not broadcast SAP updates across the serial link, and clients cannot access the server's services.
Step 1: To determine whether a server is configured to withhold SAP updates, you must examine the specific server's configuration. Read the server's documentation to determine how to find this information.
Step 2: Assume that Server-2 was set to withhold SAP updates. Change this configuration.
Step 3: Again, check for connectivity between Server-2 and Router-M, using the show novell servers command. Assume that Server-2 appears.
Unfortunately, Client-A is still unable to access Server-1 and Server-2, while Client-N is still unable to access the NetBIOS server (Server-N).
Next, examine the network number specifications for servers and routers on all networks in the internet.
Step 1: Assuming that routing is enabled, compare the specifications for the Novell network number (using the novell network number command) on each router interface.
Step 2: Look for missing or duplicate network number specifications. If you find duplicates, assign unique network numbers for each network segment.
In this case, assume there is a subtle conflict. The network number assigned for the serial link is "ee." Unfortunately, this is also the internal network number assigned to Server-3. The result is that there is no connectivity over the serial line between Midtown and Downtown. The solution is to modify the serial line network number to something else (for example, "af"). Figure 2-24 illustrates this change.
However, when this change is made, there is no change to service availability.
In the process of eliminating the preceding problems, it is highly likely that the status of each router interface has been verified.
Step 1: You can further confirm the status of the router interfaces using the show novell interface command on each router. The interfaces should indicate that the interface is up and that the protocol is up.
Step 2: You can also ping between the routers to confirm that the interfaces are operational.
Again, for the purposes of this case, assume that the interfaces are all functional.
In some cases, NetWare server software may limit the number of users that can access the server simultaneously. If your copy is a limited-user version, you must upgrade the version to support more users.
In this case, the version can be assumed to be a standard version supporting more users. Client-A is still unable to access Server-1 and Server-2, and Client-N is still unable to access Server-N.
Next on the problem list is an encapsulation mismatch. The default on Cisco routers is Novell's Frame Type Ethernet_802.3 encapsulation. If there is a conflict (any entity is configured for a different framing from the rest of the internetwork's entities), you must modify all configurations so that they match.
Step 1: To determine what framing type clients (and servers) are running, you might change the framing type on the local router (Router-D for the clients and Router-M for the servers) to arpa (Novell's Frame Type Ethernet_II).
Step 2: Next, enable debug novell-packet on the local router. If you see a packet with the source address of a client or server, that node is using Frame Type Ethernet_II. (Remember to disable fast switching using the no novell route-cache command before enabling this debug command.)
Step 3: You also can use the show novell traffic EXEC command to look for an incrementing "format errors" counter. This suggests that there is an encapsulation mismatch.
Step 4: As an alternative to using these Cisco-specific commands, you can use a protocol analyzer to capture packets. Examine packets from clients, servers, and routers and determine whether they are all using the same framing type. If not, change configurations on nodes so that all are using the same encapsulation type.
In this case, assume that all nodes are using Frame Type Ethernet_802.3 (the Cisco router default).
Access list problems come up in many connectivity problem lists. For details concerning access list issues, refer to Chapter 5, "Troubleshooting Novell Connectivity."
For the purposes of this case, assume that the write terminal output for both Router-D and Router-M indicates that there are no relevant access list specifications.
MAC addresses are obtained for Novell configurations in one of two ways: either from the router hardware address embedded in the system firmware or by random assignment (when the system software initializes before the interface is initialized). In some rare cases, the randomly generated MAC address for different routers will be the same. If these numbers are not unique, and the routers are on the same internet, communication will not occur. If Router-M and Router-D have the same MAC address, no traffic will traverse the serial link.
Step 1: To determine if this is the problem, use the write terminal command to examine the current configuration of each router in the path (Router-D and Router-M).
Step 2: Check the hardware address specified in the novell routing global configuration command. If this system-generated number matches for both routers, reinitialize one of the routers and see if connectivity over the link is re-established.
Step 3: Test for connectivity between clients and servers.
Step 4: If connectivity is still blocked, reexamine the configuration of the routers.
Step 5: If the routers still have matching MAC addresses, use the show controllers interface-type command to obtain an actual MAC address from each router.
Step 6: Use the novell routing command to enter the selected MAC address (for example, novell routing 00aa.54f1.003e).
In general, this problem occurs more frequently in Token Ring implementations. For the purposes of this case, assume that the addresses are different.
Next, look for a missing or misconfigured Novell helper address specification on one of the routers.
Step 1: To diagnose this configuration problem, use the write terminal EXEC command to look for novell helper-address interface subcommand specifications. This command must include either an all nets specification
(-1.ffff.ffff.ffff) or directed broadcast specification (2b.ffff.ffff.ffff).
Assume that the helper address is not included in the original configuration and is added as a correction. Unfortunately, connectivity to the remote hosts from Client-A and Client-N is still blocked when test connections are attempted.
Another helper address-related problem might be that a NetBIOS server is using reverse broadcast to communicate with clients, but the routers are not configured to accommodate this requirement. In this case, assume that the servers are not attempting to reverse broadcast to clients.
Finding a back door in your internetwork can be an extremely difficult task. A backdoor bridge typically results from the process of migrating from a bridged internetwork to a routed environment. For one reason or another, bridges sometimes are not removed. Unfortunately, if backdoor bridges exist, route information leaks between the networks and routers are defeated. The result is a complete blockage of connectivity between segments.
Step 1: To find a back door, use a protocol analyzer to look for packet loops. In particular, look for routing and SAP updates from remote networks.
Also, look for known remote network numbers that show up on the local network. That is, look for remote network numbers that are not being handled by the router (source address is not the router's).
Step 2: Watch for changes in hop counts. If a back door exists, you are likely to see hop counts incrementing up to 16; routes may disappear and then reappear unpredictably.
Step 3: If you observe any of these situations, isolate the local Ethernet into smaller segments (using a fanout or similar device).
Step 4: Examine the traffic on each segment with a protocol analyzer. If a packet appears from a known remote node (has a remote source address), the back door is located on that segment.
If a backdoor bridge is discovered (as illustrated in Figure 2-26), you must remove the link. This link might be inadvertently configured within a wiring concentrator or might be two bridges anywhere in your network.
Removing this interconnection finally establishes connectivity between the two segments. Client-A and Client-N are now able to access the Midtown servers.
This scenario focused on diagnosing blocked connectivity in Novell IPX internets. Four problems were discovered and resolved:
Figure 2-27 and Figure 2-28 provide representative configuration listings for Router-M and Router-D as discussed in this scenario. These configurations illustrate the configuration commands required to interconnect the two Ethernet segments over the T1 line. (Remember to reenable fast switching using the novell route-cache command if it was disabled during troubleshooting.)
Many of the world's largest internetworks employ TCP/IP as their backbone network protocol. However, that does not mean that these networks employ universal internetworking implementations. In fact, TCP/IP internetworks--sometimes comprising thousands of internetworking nodes--can span organizational domains that employ completely different topologies, routing protocols, and possibly conflicting administrative objectives. The challenge is to provide the requisite level of connectivity between hosts in different domains and on different major networks, while providing adequate security for each organization attached to the internetwork. This scenario focuses on the issue of balancing connectivity and security.
This scenario addresses connectivity problems in TCP/IP internetworks. Figure 2-29 illustrates an organization's interconnections from one subnet to its corporate network and interconnections to external networks.
Sun-1, Sun-2, and Sun-3 on the Ethernet segment attached to Router-Eng are unable to communicate with hosts in the main corporate network or outside the organization through Router-Eng. Several backdoor routes also exist, which allow other networks to access the Engineering Segment.
Because external access is not being reliably controlled, and users on the engineering segment are unable to get through to the corporate network via Router-Eng, this is both a security problem and a connectivity problem.
The relevant elements of the internetworking environment shown in Figure 2-29 can be summarized as follows:
Given the situation, the following candidates are likely causes of this network's interconnection problems:
The next step is to analyze each potential cause as the problem source and then test the network to determine whether it is operational after any modifications are made. The following discussion considers these possible problems and alternatives for providing the proper access and security.
Because the UNIX workstation-based routers on the engineering segment are using RIP to route among themselves, while the corporate network uses IGRP, the first configuration issue to consider is route redistribution.
Step 1: Use the write terminal EXEC command to review the configuration on Router-Eng. In order for RIP routes and IGRP routes to be passed between the engineering segment and the corporate network, Router-Eng must be configured for redistribution.
Step 2: Assuming that Router-Eng does not have redistribution configured, add appropriate redistribution commands.
Figure 2-30 illustrates a partial configuration for Router-Eng that would establish RIP-IGRP route redistribution for this network.
Note the following points about this brief example:
Step 3: At this point, you might perform an extended ping from Router-Main to one or more of the UNIX nodes on the engineering segment. Assuming that no access controls are in place, the ping should be successful and now Sun-1, Sun-2, and Sun-3 should be able to communicate with the corporate network resources.
However, setting up redistribution does not provide any means of blocking the uncontrolled backdoor access available through the asynchronous lines on the UNIX routers (Sun-1 and Sun-2).
Step 4: The next step is to set up access lists to allow Sun-1, Sun-2, and Sun-3 on the engineering segment to access the corporate network, but to block access from outside the corporation to resources on the corporate network.
Step 5: Figure 2-31 illustrates example additions for Router-Eng to control access to the corporate network.
These access list entries provide the following controls:
This scenario focused on solving two problems in TCP/IP internets:
Of these two, implementing redistribution is relatively straightforward, while access lists can be fairly complicated and can yield unpredictable results.
Figure 2-34 illustrates a complete router configuration for Router-Eng (obtained with the write terminal command).
A common problem when bringing new internetworking nodes on-line is that systems on one side of the new node often are unable to communicate with systems on the other side. The problem scenario that follows explores this kind of situation in the context of a private X.25 WAN. In this case, several problems are uncovered during troubleshooting before a final resolution is achieved.
No traffic of any kind can pass through a newly installed router used to interconnect an Ethernet-based network segment to a private X.25 wide area network (WAN). Local area networks (LANs) previously interconnected via the X.25 WAN continue to communicate without disruption of service. However, users trying to make connections cannot get through to resources on the new segment.
Figure 2-35 illustrates a map of an X.25 WAN. The following list summarizes relevant elements of this internetworking environment:
Given this situation, the following problems are the best candidates for interconnection failure:
Next, eliminate each potential cause as a problem source and then test the network to determine whether it is operational. The following discussion works through the problem isolation process.
The following procedure illustrates the process of isolating hardware-related problems.
Step 1: The first thing to do is determine the condition of the router. Use the show version command. Figure 2-36 illustrates a typical display that the system returns when interfaces are minimally operational and the system can communicate with them. In this case, the interface of interest is associated with an MCI controller.
Step 2: In addition to the basic information provided in the show version output, use the show controllers command to examine the types of appliques on a router and the status of the appliques. Figure 2-37 illustrates an example output of the show controllers mci command. In this case, the environment requires a DTE applique to attach the router to a CSU/DSU device. In contrast, a DCE applique typically would be required if the router were connecting directly to a host (DTE interface).
Step 3: Next, determine whether the interface is operational using the show interfaces serial command. Figure 2-38 illustrates the output from this command. This particular output indicates that both the serial interface and line protocol are down. These symptoms suggest that there is either a router hardware problem or a cabling problem. In most new installations, this would point to a cabling error. However, you must be sure to check both.
Step 4: The next step is to check the hardware. Specific tests to determine whether the hardware is operating normally depend on the system type. For instance, you would inspect the applique LEDs on an AGS+, but with an IGS, you would attach a breakout box to the serial port and check the breakout box status LEDs. Refer to Chapter 1 for some general information about interpreting hardware LEDs and other diagnostics. Refer to your hardware installation and maintenance publication for specifics.
Step 5: In this case, assume that the router hardware is operational, but that the transmit clock (obtained from the CSU/DSU) is not active. The cable is the most likely problem candidate.
To determine whether it is the cable from the modem to the router or from the modem to the switch, configure the CSU/DSU to operate in local loop mode. This terminates use of the line clock (from the T1 service) and forces the CSU/DSU to use the local clock.
Step 6: Next, inspect the interface status with the show interfaces serial command. Assuming that the line protocol remains down, a bad cable connection is extremely likely.
To remedy this problem, replace the cable and inspect the interface. Assume that the result is the display shown in Figure 2-39. This display output indicates that the interface is operational and that the cable is working properly. Unfortunately, traffic still is not getting through. However, the display provides a clue about the nature of the remaining problem. This clue is discussed in the next section.
At this point, hardware problems associated with the serial connection to the X.25 WAN have been eliminated. However, traffic still is unable to get through Router-New. The following procedure steps through the process of isolating problems associated with the LAN interface, the LAN in general, and network hosts.
Step 1: Now determine the status of the router's LAN interface, the LAN media, and the resources on the LAN. Again, the show interface command is useful for inspecting the condition of the interface and determining whether it is communicating with devices on the Ethernet. Figure 2-40 illustrates the output resulting from using the show interfaces ethernet command. In this case, the interface is alive and properly connected.
Step 2: Although the output in Figure 2-40 indicates that the interface is operational and that it is seeing traffic on the network, it does not indicate whether the router is able to communicate with specific end nodes on the Ethernet or whether the host configuration allows the host to communicate with the router. To determine whether the host can reach the router, use the ping and clear commands in coordination with the Ping function on the UNIX end system.
First, use the ping privileged EXEC command to verify that the router can communicate with each host on the local Ethernet. Figure 2-41 illustrates a successful acknowledgment (Echo Reply) to the Internet Control Message Protocol (ICMP) Echo Request (Ping).
Step 3: Step 2 verified that the router is able to communicate with a specific host. However, to verify that the host configuration is correctly specified, ping the router from the host.
Step 4: Next, use the clear arp privileged EXEC command on the router and ping from the router to the host. Figure 2-42 illustrates the successful ping transmission and acknowledgment.
The ping is successful, which demonstrates that the host can reply to the router. All LAN-related and host configuration problems are now eliminated. It is time to examine the router's configuration.
Figure 2-43 and Figure 2-44 illustrate the effect of the ping exchange on
Router-New's ARP cache (after the clear arp command was executed).
Figure 2-43 illustrates that before the ping transmission, the ARP cache does
not include the target host. After the ping, the ARP entry for the host is included in the ARP cache for Router-New (Figure 2-44).
In the second ping exchange (refer to Figure 2-42), only 80 percent of the returns are successful. This is the expected behavior. Because the end station is not in the original ARP table, the first ping packet is dropped and an ARP request is substituted instead. After the station replies, the subsequent pings work.
Traffic still is not traversing the router. After eliminating all serial hardware problems, LAN problems, and host configuration problems, it appears that a router configuration problem exists. In fact, there may be more than one.
Step 1: The first step in evaluating the router software configuration is to enable X.25 debugging on the router. Use the debug x25-events privileged EXEC command. If you intend to keep the output of the debug command, you must remember to spool the output to a file. The procedure for setting up such a debug output file is described at the beginning of Chapter 10, "Debug Command Reference."
Given the situation, the router is likely to immediately report events. The first to appear are call requests, next are facilities, and finally, cause and diagnostic codes. Figure 2-45 illustrates the debug output for this scenario. This information suggests that an invalid virtual circuit is being attempted. Refer to Appendix A, "X.25 Cause and Diagnostics," for more information about specific fields presented in this debug output.
Step 2: At this point, you must compare the configuration files of the various routers in the WAN with the configuration file for Router-New.
Contact your X.25 service provider (or network manager) for this information.
There are a number of configurable X.25 parameters that must match for all routers in the WAN. Key parameters include the following:
In this case, assume that the virtual circuit channel sequencing is not correctly defined in the configuration for Router-New.
The values for Highest Outgoing Channel (HOC), Highest Incoming Channel (HIC), Highest Two-way Channel (HTC), Lowest Outgoing Channel (LOC), Lowest Incoming Channel (LIC), and Lowest Two-way Channel (LTC) are all set to the default in Router-New. However, the WAN requires that these be specifically configured. Because of this mismatch, the router is unable to complete any virtual circuits.
Fixing these errors allows the router to successfully perform ICMP pings, but regular traffic still is not getting through.
Step 3: Again, the answer is buried in the configuration file. In this case, the x25 map command does not include the broadcast keyword. Because the IP internetwork uses IGRP (a dynamic routing protocol), the broadcast keyword is required. Figure 2-46 summarizes the changes made to the configuration file that finally allows traffic through the router.
Introducing new internetworking systems into LAN-to-WAN internets is not a trivial matter. The key to resolving multilayered problems is to address each possible problem individually. In this case, multiple causes involved both media problems and software misconfigurations. Connectivity to Site-New was established after making the following changes:
Internetworking problems are rarely one-dimensional. Problem isolation requires a certain amount of patience and a methodical approach. It is also important to note that subtle protocol variations can wreak havoc in networks if not fully accounted for during the initial configuration. Thus, it is critical to coordinate efforts with all responsible organizations--especially when third parties, such as WAN service vendors, are involved.
|
|
