|
|
This chapter presents protocol-related troubleshooting information for AppleTalk connectivity problems. The emphasis is on symptoms and problems associated with AppleTalk network connectivity.
This chapter consists of the following sections:
The symptom modules presented in this chapter consist of the following sections:
The following discussion establishes a framework for analyzing AppleTalk internetworking problems.
Distinguishing problems that occur on a single cable segment from problems that occur on an entire network is difficult to do without making an explicit distinction between networks and internetworks. For this discussion, the term network refers to individual networks as defined by their associated, unique AppleTalk network numbers or cable ranges. The term internetwork refers to the entire collection of networks connected via internetwork routers.
In AppleTalk, the terms Phase 1 and Phase 2 are often confusing. Cisco refers to routers as being Phase 1 or Phase 2 with respect to their ability to support the AppleTalk Phase 2 enhancements. Cisco routers dynamically determine whether their neighbors are Phase 2 compliant, and operate in Phase 1 compatibility mode if necessary. Most currently offered routers are Phase 2 routers. Older routers that have not been upgraded may be Phase 1 routers.
To describe a network or interface, Cisco uses the terms nonextended and extended. A nonextended network contains a single network number (such as network 2) and does not allow two nodes on a single network segment to belong to different zones.
An extended network can contain multiple consecutive network numbers (Cisco refers to this as a cable range), though it does not require it (for example, 3-3 is a valid extended cable range). An extended network also allows multiple zones to be configured on a single network segment. Nonextended networks use Advanced Research Projects Agency (ARPA) Ethernet Type II encapsulation on Ethernet. Extended networks use Subnetwork Access Protocol (SNAP) encapsulation, which is also used by Fiber Distributed Data Interface (FDDI), Token Ring, and most other newer media.
The AppleTalk Update-based Routing Protocol (AURP) allows two noncontiguous AppleTalk networks to communicate by way of a tunnel through a backbone network. AppleTalk traffic and AURP routing information are encapsulated in the backbone protocol header (for example, IP), sent through the backbone network, and stripped of the foreign header upon arriving at the far end of the tunnel.
An exterior router is a router that borders an AppleTalk network and a backbone network using another protocol, such as IP. Exterior routers are connected to an AURP tunnel and are responsible for encapsulating and de-encapsulating AppleTalk traffic as it is passed in and out of the backbone network. An exterior router places the AppleTalk data in the protocol header used by the backbone, which affords the AppleTalk traffic the same advantages as any other traffic on the backbone. In addition, exterior routers use AURP routing updates to maintain routing tables for AppleTalk destinations located on the far side of the AURP tunnel.
AppleTalk Remote Access (ARA) is an Apple protocol that allows a remote user on a Macintosh personal computer to access the resources of a remote site via a point-to-point connection to an ARA server (such as a Cisco access server).
Internetworks based on the AppleTalk networking protocol suite can be complex. The fact that AppleTalk was designed to be easy to use does not necessarily make AppleTalk internetworks easy to administer. Before exploring specific symptoms, the following discussions outline some hints and suggestions for AppleTalk internetwork troubleshooters.
When you are setting up an AppleTalk internetwork, remember these two guidelines:
The following discussion covers some of the most common problems associated with AppleTalk internetworks. The problems include the following:
The problem descriptions outline the general nature of each problem and provide some diagnostic notes. Specific actions associated with each problem are detailed in the symptom modules, later in this chapter, that include these problems as likely causes. These problems do not represent all known AppleTalk internetworking problems. Indeed, only a small subset of potential pitfalls are covered. However, these problems are commonly encountered when creating, upgrading, or modifying AppleTalk internetworks.
A configuration mismatch occurs when the following AppleTalk rule is violated:
To protect against configuration errors that violate this rule, AppleTalk routers block activation of any port on which a violation of this rule exists. At interface initialization, if other routers on the network do not agree with the way a Cisco router is configured, the Cisco router will not allow AppleTalk to become operational on that interface. Cisco routers attempt to restart such an interface every 2 minutes to avoid outages that result from transient conditions.
However, if the router is already operational, and another router whose configuration does not match becomes active, the router will continue to operate on that interface until the interface is reset. At that point, the interface will fail to become active, and the router will declare a port configuration mismatch in the show appletalk interface EXEC command.
Figure 4-1 is an example of show appletalk interface command output when a configuration mismatch exists.
You can display the Name Binding Protocol (NBP) registered name of the conflicting router, which can simplify resolution of a port mismatch problem. To see registered NBP names, enable the appletalk name-lookup-interval global configuration command. When that command is enabled, the show appletalk interface EXEC command displays nodes by NBP registration name.
Network numbers are analogous to postal codes--both are used to route information to the proper destination. A duplicate network number or postal code causes confusion about the location of the proper destination that can prevent delivery. In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, some packets are not routed to their intended destinations and are lost or misdirected. Duplicate network numbers can cause other connectivity and performance problems as well.
When Phase 1 and Phase 2 routers are in the same internetwork, the internetwork specifications must conform to the following rules:
If these rules are not followed, connectivity between the nonextended and extended portions of an internetwork becomes degraded or is even lost. In particular, services located on nonextended networks serviced by Phase 1 routers will not be visible on the other side of the Phase 1 router.
Phase 1 AppleTalk has three types of NBP packets, and Phase 2 AppleTalk has four types of NBP packets. This difference can lead to communication problems between Phase 1 and Phase 2 routers. Table 4-1 lists the NBP packet types for AppleTalk Phase 1 and Phase 2.
| Phase 1 NBP Packet | Phase 2 NBP Packet |
|---|---|
| BrRq (Broadcast Request) | BrRq (Broadcast Request) |
| LkUp (Lookup) | FwdReq (Forward Request) |
| LkUp (Lookup) | |
| LkUp-Reply (Lookup Reply) | LkUp-Reply (Lookup Reply) |
As shown in Table 4-1, Forward Request packets do not exist in Phase 1. Only Phase 2 routers know what to do with them. Phase 1 routers that receive Forward Request packets simply drop them.
Routers use the Zone Information Protocol (ZIP) to exchange zone information, and end systems use ZIP to acquire zone lists. No AppleTalk mechanism forces routers to update zone lists. After a zone has been acquired, routers do not make another ZIP request unless the network has aged out of the routing table for some reason. For that reason, you must use care when adding or removing zone names from an active network.
A ZIP storm occurs when a router propagates a route for which it currently has no corresponding zone name; the route is then propagated by downstream routers.
Cisco routers provide a firewall against ZIP storms in the internetwork. If a Cisco router receives a routing update from a neighbor, it does not propagate that new route until it receives the accompanying zone name.
You can use the show appletalk traffic EXEC command to check if a ZIP storm is in progress. Look for AppleTalk traffic counters for ZIP requests that increment very rapidly. Use the debug apple zip privileged EXEC command to identify the network for which the zone is being requested by neighboring routers. You can also use the show apple private EXEC command to check on the number of pending ZIP requests.
If you determine that a ZIP storm is occurring, search for the router that injected the network number into the internetwork (and that is causing the excessive ZIP traffic). The show appletalk traffic and show appletalk route EXEC commands provide information that can help you find the suspect router. When you find the offending node, stop it from propagating invalid routes. This might require you to upgrade the software on the router.
Access lists provide a powerful way to control traffic and limit access to resources on an AppleTalk network. However, improperly implemented access lists can lead to a number of failures on your internetwork. Typical problem symptoms associated with incorrectly specified access lists include services for a particular network that are not visible to other networks, zones that are missing from the Chooser, and services that are visible in the Chooser, but are not accessible.
Excessive load on internetworks that have many routers can prevent some routers from sending Routing Table Maintenance Protocol (RTMP) updates every 10 seconds as they should. Because routes begin to be aged out after the loss of two successive RTMP updates, the failure of RTMP updates to arrive results in unnecessary route changes. Zones may fade in and out of the Chooser or exhibit other unpredictable behavior. Route instability associated with load problems is known as route flapping.
A back door is any unexpected path or route through an internetwork. The existence of a back door can result from a number of different events: IP gateways establishing a DDP/IP link unexpectedly; bridges being installed without notice; or even users connecting networks with dial-up connections. Back doors typically cause a change in performance over the internetwork and connectivity problems. Performance problems usually occur because all traffic between two sites is going through a lower-bandwidth circuit, or because all traffic is being sent through a single gateway. Connectivity problems can result when routing loops form or when duplicate network numbers are introduced.
This section offers a number of preventative measures and tips for avoiding and addressing configuration problems in AppleTalk internetworks. It consists of the following topics:
Table 4-2 provides a list of suggestions intended to reduce problems when you are configuring a router for AppleTalk.
When bringing an interface up on an existing cable where a long zone list is defined, the following actions will help you avoid mistakes and save effort.
It is common to create configuration conflicts when changing zone names or cable range numbers. In particular, problems arise when routers exist on the internetwork about which you are not (administratively) aware.
Remember that many devices can act as routers (for example, Pathworks servers or UNIX workstations running CAP to do print and file sharing). In general, if you are changing zone names or cable range numbers in your internetwork, all routers should be shut down, or a Cisco router will see a conflict and prevent AppleTalk from initializing on the interface.
Use the show appletalk neighbors EXEC command to determine on which routers to disable AppleTalk routing. Routers that are on the same network segment and that have sent RTMP updates in the last 10 seconds should have Appletalk disabled. Disable AppleTalk routing on all of the appropriate interfaces, wait approximately 10 minutes, and then bring up the master seed router.
When changing a zone name on an existing network, perform the following actions:
Step 1 Disable AppleTalk on all interfaces on the cable for about 10 minutes. This allows all routers in the internetwork to age out the network number from their routing tables.
Step 2 Configure the new zone list.
Step 3 Re-enable AppleTalk on all interfaces.
These actions are required because AppleTalk makes no provisions for informing neighbors in the internetwork about a changed zone list. Routers only make ZIP queries when a new or previously aged-out network appears on the internetwork.
Adding a new zone to an extended cable configuration will result in the router refusing to bring up its interface for AppleTalk after the interface has been reset. This is because its configuration no longer matches that of its neighbors (configuration mismatch error).
In certain situations, you might need to force an interface to come up despite the fact that its zone list conflicts with that of another router on the network. This can be done using the appletalk ignore-verify-errors global configuration command. Usually this other router would be one over which you have no administrative control, but which you are certain has an incorrect zone list.
The appletalk ignore-verify-errors command allows you to bypass the default behavior of an AppleTalk interface, which is to not come up if its zone list conflicts with that of its neighbors. However, you should use this command with extreme caution; bringing up an interface with a zone list that conflicts with that of other routers can cause serious network problems. In addition, the other router must be reconfigured at some point so that all the routers on the network agree on the zone list.
Once all the AppleTalk routers on the network have conforming zone lists, the appletalk ignore-verify-errors command should be disabled using the no form of the command. For complete information on the appletalk ignore-verify-errors global configuration command, see the Router Products Configuration Guide and the Router Products Command Reference publications.
Use the following suggestions from router technical support representatives to help speed problem diagnosis and ensure efficient data gathering in the event of failures:
In recent years, AppleTalk-based internetworks have grown in size and scope of implementation. Once viewed as a simple protocol for small networks, AppleTalk has been stretched to allow handling of more nodes and sharing of services in larger internetworks. Along with these larger-scale and more complex implementations have come some of the implementation headaches common to any multivendor enterprise internetwork. This scenario focuses on several common problems that can block access to servers and services on an AppleTalk internetwork.
As shown in Figure 4-2, a number of local networks are segmented with routers, and a remote network is linked over a serial line.
Assume that the following three symptoms were reported for this AppleTalk internetwork:
There are several problems that might lead to these symptoms. The first step is to characterize the configuration of this internetwork and then develop a list of likely suspect problems.
Some relevant facts regarding the internetworking environment shown in Figure 4-2 can be summarized as follows:
Given the situation, a number of problems could explain reported symptoms.
The following problems are likely candidates for symptom number 1 (laser printer Slug on Ethernet segment 3 is reported as not visible on Chooser by Macintosh user Melvin on Ethernet segment 2):
The following problems are likely candidates for symptom number 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 number 3. (AppleShare server Spunky on Ethernet segment 4 is sometimes visible in the Chooser of Macintosh systems in this internetwork. However, no one can access services on that server.)
After you identify a possible problem list, you must systematically analyze each potential cause. 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 internetwork. Figure 4-3 illustrates the known network numbers, cable ranges, and zones.
This analysis starts by considering the problem list associated with the intermittent availability of Spunky (symptom number 3). Because the DEC VAX problem shares a possible cause with the Spunky availability problem, the analysis also evaluates the possibility of a common problem causing both symptoms. After that, the analysis steps through the list of possible causes 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 output. 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" 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 have eliminated a ZIP storm as a cause for symptom number 3. All symptoms are still being experienced.
The next possible cause for both symptom number 2 and symptom number 3 is the existence of duplicate network numbers in the internetwork. Unfortunately, these are not usually easy to find.
Step 1 First, use the show appletalk interface ethernet 6 command on Router-R3 to obtain the AppleTalk network number for the local network. In this case, the (nonextended) network number is 8. Figure 4-4 illustrates a typical output for this command.
Step 2 Next, disable AppleTalk using the no appletalk routing global configuration command as illustrated in Figure 4-5.
If there are no duplicate network numbers (another network number 8), the command no appletalk routing results in network number 8 being aged out of all routing tables in the internetwork.
Step 3 To determine whether this happens, perform successive show appletalk route 8 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 8 will not age out, but instead appears as a learned route from some other interface. Figure 4-6 illustrates how this change is registered in the show appletalk route 2 display.
Figure 4-6 indicates the neighbor from which the location of the duplicate was learned. Because IP is also enabled in this internetwork, you can pinpoint the duplicate network number by connecting to the indicated neighbor. Use Telnet to connect to the indicated neighbor (here at network.node address 8.2), using the IP address or host name of the router. (In this case, assume Router-R2.)
Step 4 When a connection is made to the neighbor, repeat the show appletalk route 8 command and examine the resulting output for the location of network number 8. Repeat 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 restoring service to Ethernet interface 6 on Router-R3 solves symptom 3 and that offnet Macintosh users in the internetwork can now access AppleShare server Spunky. However, users still cannot access the DEC VAX AppleShare server, and the laser printer Slug remains inaccessible.
It is possible that another duplicate network number in the internetwork is making the DEC VAX unavailable as an AppleShare server. However, remember that DEC VAX AppleShare service is accessible to Macintosh users Biff and Debbie on Ethernet segment 5 (network number 50), which eliminates a duplicate network number as the cause of the problem. DEC VAX AppleShare service to Macintosh users Biff and Debbie also rules out port configuration mismatch as a problem, because Router-R1 and Router-R3 agree about network configuration (network number/cable range and zone/zone list). This leaves a Phase 1 and Phase 2 rule violation as the remaining identified possible cause.
Step 1 To determine whether this is the problem, use the show appletalk globals command. Figure 4-7 illustrates the output of this command when the network is in compatibility mode. However, this display shows that the internetwork is not in compatibility mode, which indicates a Phase 1 and Phase 2 rule violation. A rule violation exists when any node has a configuration that does not conform to the following rules:
Step 2 Next, use the show appletalk neighbors command at Router-R1 to identify the specific neighboring router that requires compatibility mode. Figure 4-8 illustrates such a listing.
Step 3 In this case, the neighbor in need of compatibility mode is the DEC VAX itself. You can upgrade the DEC VAX AppleShare server or use the appletalk proxy-nbp global configuration command to create what is in effect a virtual network off Router-R1. The command 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 that 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 for the zone named "Developers" to all networks. Using this command resolves the problem of access to the DEC VAX AppleShare server from extended networks.
However, laser printer Slug is still not accessible from Macintosh 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 that Router-R1 is probably operational and that the problem probably is with IR-1.
Step 1 Use the show appletalk neighbors 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 the show appletalk neighbors command 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 AppleTalk Phase 2 to operate in this internetwork.
Step 3 For further evidence, use the show appletalk traffic command and look for encapsulation failures. More than 100 encapsulation failures suggest Phase 1 and Phase 2 problems and support the hypothesis that IR-1 is the problem in this case. Figure 4-9 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 using the appletalk address interface command to temporarily set the AppleTalk address for Ethernet interface 1 to 0.0. When 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 a Phase 1 router. (You can also confirm that IR-1 is a Phase 1 router by 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 Ethernet interface 1 on Router-R1 must be reconfigured to its original state (an extended network cable range of 6-6).
This scenario focused on diagnosing blocked service access in AppleTalk internetworks. Modifications discussed in this scenario included the following:
Figure 4-10 illustrates an example final configuration listing for Router-R1 obtained using the write terminal EXEC command, where appletalk proxy-nbp has been added.
This section presents a sample diagnostic and troubleshooting session in an AppleTalk Enhanced IGRP environment. In this example network, AppleTalk Enhanced IGRP is running on the backbone, while RTMP is running on the edges, on the LANs with connected Macintosh PCs. This network topology is illustrated in Figure 4-11.
Six Cisco routers are in the network shown in Figure 4-11. Four of the routers border LAN segments with connected Macintosh PCs. Router A runs RTMP on Ethernet interface 0 and AppleTalk Enhanced IGRP on Ethernet interface 1; Router C runs RTMP on Ethernet interface 0 and AppleTalk Enhanced IGRP on serial interface 1; and Router D and Router F run RTMP on Ethernet interface 1 and AppleTalk Enhanced IGRP on Ethernet interface 0.
Unlike the border routers, which run two routing protocols, Router B and Router E both run AppleTalk Enhanced IGRP exclusively on all of their interfaces. This is the Enhanced IGRP backbone of the network.
It is important to note that Macintosh PCs do not understand AppleTalk Enhanced IGRP, so only RTMP should be running on LAN segments with connected Macintosh PCs. Furthermore, while it may be desirable or necessary in certain network topologies, Cisco generally recommends that you not enable AppleTalk Enhanced IGRP and RTMP on the same interface, because doing so produces unnecessary bandwidth and processor overhead that might affect network performance. Only one or the other should be enabled on each interface. Allow route redistribution to exchange routing information between the two routing processes.
The following diagnostic tables (Table 4-3 and Table 4-4) illustrate step-by-step procedures for troubleshooting poor or lost connectivity in an internetworking environment like that shown in Figure 4-11. Potential trouble areas are identified and are ordered based on the likelihood of their being the actual problem. A series of actions is then suggested for each problem. Table 4-3 encompasses the diagnostic and troubleshooting procedures for the multiprotocol portions of the Apple network shown in Figure 4-11, that is, the sections of the network running both RTMP and AppleTalk Enhanced IGRP. Table 4-4 addresses the single-protocol backbone of the Apple network in Figure 4-11, that is, the routers running only AppleTalk Enhanced IGRP.
| Possible Problem | Suggested Actions |
|---|---|
| AppleTalk Enhanced IGRP is not globally configured on the appropriate routers. | Step 1 Check the configuration of Router A using the write terminal privileged EXEC command. Look for an appletalk routing eigrp global configuration command entry. This command turns on AppleTalk Enhanced IGRP routing on the router.
Step 2 If AppleTalk Enhanced IGRP routing is not enabled on Router A, use the appletalk routing eigrp 100 global configuration command to enable it. The number indicated by the command is the AppleTalk Enhanced IGRP router ID. This number must be unique on the network (although a router can have more than one router ID configured). Step 3 Perform the same actions on Router C, Router D, and Router F. The appletalk routing eigrp global configuration command must be enabled on all routers that are running AppleTalk Enhanced IGRP. The router ID must be different for each router. |
| AppleTalk Enhanced IGRP is not enabled on the appropriate interfaces. | Step 1 Issue the write terminal privileged EXEC command on Router A and examine the interface configurations. In order for an interface to generate AppleTalk Enhanced IGRP routing updates, the appletalk protocol eigrp interface configuration command must be present.
Step 2 In the network shown in Figure 4-11, Router A should have AppleTalk Enhanced IGRP enabled only on Ethernet interface 1. Use the appletalk protocol eigrp interface configuration command to tell the interface to begin sending routing updates. Step 3 Perform the same actions on Router C, Router D, and Router F. On Router C, only serial interface 0 should have AppleTalk Enhanced IGRP enabled; on Router D, only Ethernet interface 0; and on Router F, only Ethernet interface 0. |
| Routes are not being redistributed between RTMP and AppleTalk Enhanced IGRP. | Step 1 Use the write terminal privileged EXEC command on Router A to determine whether route redistribution is disabled. Route redistribution is enabled by default on a router when the appletalk routing global configuration command is issued. However, it can be explicitly disabled using the no appletalk route-redistribution global configuration command.
Step 2 If route redistribution is disabled, enable it using the appletalk route-redistribution global configuration command. If routes are not properly redistributed between RTMP and AppleTalk Enhanced IGRP, routing tables will not be accurate and packets will be lost. Step 3 Ensure that routes are being redistributed on all routers that border both the RTMP and the AppleTalk Enhanced IGRP environments. In Figure 4-11, this includes Router A, Router C, Router D, and Router F. |
| AppleTalk Enhanced IGRP is running on a LAN with connected Macintosh PCs. | Step 1 Use the write terminal privileged EXEC command on Router A to make sure that only RTMP is enabled on Ethernet interface 0, which is connected to the LAN running the Macintosh PCs. Macintoshs do not understand AppleTalk Enhanced IGRP.
Step 2 If RTMP is disabled, issue the appletalk protocol rtmp interface configuration command. Step 3 If necessary, disable AppleTalk Enhanced IGRP on Ethernet interface 0 using the no appletalk protocol eigrp interface configuration command. Step 4 Perform the same actions on Router C, Router D, and Router F. These routers all border network segments with connected Macintosh PCs. |
| AppleTalk Enhanced IGRP and RTMP are running simultaneously on the same interface. | Step 1 Use the write terminal privileged EXEC command on Router A, Router C, Router D, and Router F to determine whether AppleTalk Enhanced IGRP and RTMP are both enabled on the same interface.
Step 2 Running both AppleTalk Enhanced IGRP and RTMP on the same interface is generally not advised because doing so needlessly increases bandwidth and processor overhead. Determine which routing protocol should be running on each interface and disable the other if necessary. |
| Possible Problem | Suggested Actions |
|---|---|
| AppleTalk Enhanced IGRP is not globally configured on the appropriate routers. | Step 1 Check the configuration of Router B using the write terminal privileged EXEC command. Look for an appletalk routing eigrp global configuration command entry. This command turns on AppleTalk Enhanced IGRP routing on the router.
Step 2 If AppleTalk Enhanced IGRP routing is not enabled on Router B, use the appletalk routing eigrp 200 global configuration command to enable it. The number indicated by the command is the AppleTalk Enhanced IGRP router ID. This number must be unique on the network (although a router can have more than one router ID configured). Step 3 Perform the same actions on Router D. The appletalk routing eigrp global configuration command must be enabled on all routers that are running AppleTalk Enhanced IGRP. The Router ID must be different for each router. |
| AppleTalk Enhanced IGRP is not enabled on the appropriate interfaces. | Step 1 Issue the write terminal privileged EXEC command on Router B and examine the interface configurations. In order for an interface to generate AppleTalk Enhanced IGRP routing updates, the appletalk protocol eigrp interface configuration command must be present.
Step 2 In the network shown in Figure 4-11, Router B should have AppleTalk Enhanced IGRP enabled on all of its interfaces. Use the appletalk protocol eigrp interface configuration command to tell the interface to begin sending routing updates. Step 3 Perform the same actions on Router E. Router E should also have AppleTalk Enhanced IGRP enabled on all of its interfaces. |
| Route redistribution is not occurring between AppleTalk Enhanced IGRP routers. | Step 1 Use the write terminal privileged EXEC command on Router B to determine if route redistribution is occurring between Router B and Router E. Route redistribution between AppleTalk Enhanced IGRP routers can be disabled using the no appletalk route-redistribution global configuration command.
Step 2 If the no redistribute eigrp command is present, re-enable redistribution between Router B and Router E using the appletalk route-redistribution global configuration command. If routes are not properly redistributed between the routers, routes known to one router will not appear in the routing tables of others and connectivity between nodes will be lost. Step 3 Be certain that the appletalk route-redistribution global configuration command is enabled on Router E as well. Otherwise, routes known to Router B will not be advertised to Router E. |
| Timer value is mismatched. | Step 1 Issue the show appletalk eigrp neighbors EXEC command on Router B. Make sure that all directly connected AppleTalk Enhanced IGRP routers appear in the output.
Step 2 Examine the Uptime field in the show appletalk eigrp neighbors output. A continuously resetting uptime counter indicates that Hello packets from the neighboring router are arriving sporadically. This may be caused by a timer value mismatch or by hardware problems. Step 3 Issue the show interface EXEC command to determine if the interface and line protocol are up. Look for high numbers in the queue fields and excessive drop counts. If there are many drops, if the queue count is high, or if the interface or line protocol are down, there is probably something wrong with the interface or other hardware. For more information on troubleshooting hardware, see the "Troubleshooting Router Startup Problems" and the "Troubleshooting Serial Line Problems" chapters. Step 4 Use the write terminal privileged EXEC command on all AppleTalk Enhanced IGRP routers in the network. (In the network shown in Figure 4-11, this includes all of the routers.) Look for appletalk eigrp-timers interface configuration command entries. The values configured by this command must be the same for all AppleTalk Enhanced IGRP routers on the network. Step 5 If there are routers with conflicting timer values, reconfigure them to bring them into conformance with the rest of the routers on the network. These values can be returned to their defaults with the no appletalk eigrp-timers interface configuration command. |
| RTMP is enabled on AppleTalk Enhanced IGRP-only interfaces. | Step 1 Use the write terminal privileged EXEC command on Router B and Router E to determine whether AppleTalk Enhanced IGRP and RTMP are both enabled on the same interface.
Step 2 Running both AppleTalk Enhanced IGRP and RTMP on the same interface is generally not advised because doing so needlessly increases bandwidth and processor overhead. Disable RTMP on the router interfaces using the no appletalk protocol rtmp interface configuration command. |
The symptom modules that follow pertain to AppleTalk internetwork problems. Each module is presented as a set of general problems. Symptoms are discussed in the following sections:
Symptom: Although users are able to access services on their own network, offnet zones and services expected to be available from the Chooser are not accessible. Table 4-5 outlines a possible cause and suggests actions when access is blocked to offnet zones and network resources.
Symptom: Users find that the AppleTalk services for a particular network do not appear in their Choosers. Table 4-6 outlines possible causes and suggests actions when services on a network are not visible to other networks.
| Possible Causes | Suggested Actions |
|---|---|
| Configuration mismatch | Step 1 See Table 4-5 for suggested actions. |
| Duplicate network numbers | Step 1 The network on which AppleTalk services do not appear in the Chooser is likely to be the network that has been assigned the duplicate network number.
Change the network number of the affected network or remove AppleTalk from the interface for the affected network. In either case, if the network number persists, you probably have found the duplicate network number. If the network number disappears from the internetwork within a few minutes, you have not found the duplicate. Step 2 If you changed the network number on the interface, no further action is required. If not, change it to a unique network number now. Remember to reenter the zone name and any other interface configurations for AppleTalk on that interface. |
| Phase 1 and Phase 2 rule violations | Step 1 Use the show appletalk globals EXEC command to determine whether the internetwork is in compatibility mode.
Step 2 Enable the appletalk name-lookup-interval global configuration command and use the show appletalk neighbors EXEC command to determine which specific neighbor (by NBP name) is in compatibility mode. Step 3 Select one of three solutions: Ensure that all routers are in compliance with the two Phase 1 and Phase 2 rules. Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 compliance and reconfigure the internetwork. Use the appletalk proxy-nbp global configuration command. To use appletalk proxy-nbp, create at least one virtual network on the router that has the same zone name as the network where the unreachable services exist. This forces the router to use Phase 1-type NBP lookups (in addition to Phase 2-style Forward Requests) when sending NBP requests through the network. Because the lookup is defined for Phase 1 routers, the Phase 1 router will properly route the request on to the service, and a reply should be received. |
| Misconfigured access lists | Step 1 Disable access lists on suspect routers and see whether connectivity returns.
Step 2 If connectivity returns, an access list error is the likely suspect. Check access lists and associated configuration commands for errors. Step 3 Modify any access lists as necessary. Step 4 If connection problems persist, consult with your router technical support representative for more assistance. |
Symptom: Router interface connected to a network will not initialize AppleTalk operation. Table 4-7 outlines possible causes and suggests actions when an AppleTalk interface fails to initialize.
| Possible Causes | Suggested Actions |
|---|---|
| Configuration mismatch | Step 1 See Table 4-5 for suggested actions. |
| Phase 1 and Phase 2 rule violations | Step 1 See Table 4-6 for suggested actions. |
Symptom: Users on different networks report that zones associated with a particular network do not appear in their Choosers. Table 4-8 outlines possible causes and suggests actions for zones not appearing in the Chooser on networks that are connected by a router.
| Possible Causes | Suggested Actions |
|---|---|
| Configuration mismatch | Step 1 See Table 4-5 for suggested actions. |
| ZIP storm | Step 1 Use the show appletalk traffic command to look for the number of ZIP requests. Note the number and repeat the show appletalk traffic command after about 30 seconds.
Step 2 Compare the two numbers. If the number of ZIP requests is greater than 10 and is increasing, a ZIP storm is probably occurring. Step 3 Use the show appletalk route EXEC command to see whether a network shows up in the table, even though the display indicates that no zone is set. If you find a network for which no zone is set, a node on that network is probably not responding to ZIP requests, resulting in the ZIP storm. Step 4 Determine why the node is not responding to ZIP requests. Step 5 ZIP storms may result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem. |
| Misconfigured access lists | Step 1 See Table 4-6 for suggested actions. |
| Unstable routes | Step 1 Use the show interfaces EXEC command to check traffic load. You may need to segment the network further to limit traffic on interfaces with a load that is greater than 50 percent.
Step 2 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. Step 3 Use the appletalk timers global configuration command to correct the problem. Suggested parameter values for the command are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second. NOTE: You can return the timers to their defaults (10, 20, 60) by using the no appletalk timers global configuration command. Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork. This type of problem often can be alleviated by simply segmenting the network to limit the number of routers on a segment. |
| Too many zones in internetwork | Step 1 If the Macintosh is running a version of System 6, upgrade it to the most recent version of System 7.
The Chooser in System 6 could only display a limited number of zones, which presents problems in large internetworks that have many zones. |
Symptom: Users report that services are intermittently unavailable. Services come and go without warning. Table 4-9 outlines possible causes and suggests actions for intermittent loss of AppleTalk services.
| Possible Causes | Suggested Actions |
|---|---|
| Duplicate network numbers | Step 1 See Table 4-6 for suggested actions. |
| ZIP storm | Step 1 See Table 4-8 for suggested actions. |
| Unstable routes | Step 1 See Table 4-8 for suggested actions. |
| Overloaded network, where routes are being aged out | Step 1 Use the show interfaces EXEC command to check traffic load.
Step 2 For interfaces with more than a 50 percent load, you may need to segment the network further to limit traffic. Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. Then use the appletalk timers global configuration command to correct the problem. Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork. |
Symptom: Users report that AppleTalk services appear in their Choosers, but they are unable to access the services. Table 4-10 outlines possible causes and suggests actions when services appear in the Chooser but are not accessible.
| Possible Causes | Suggested Actions |
|---|---|
| Duplicate network numbers | Step 1 See Table 4-6 for suggested actions. |
| ZIP storm | Step 1 See Table 4-8 for suggested actions. |
| Misconfigured access lists | Step 1 See Table 4-6 for suggested actions. |
Symptom: Users report that whenever they open the Chooser, the zone list appears to change. Table 4-11 outlines possible causes and suggests actions when zones change whenever the Chooser is opened.
| Possible Causes | Suggested Actions |
|---|---|
| Unstable routes | Step 1 See Table 4-8 for suggested actions. |
| Routers on the network have different zone lists. | Step 1 Verify that all router configurations agree on zone lists.
Step 2 If the router configurations do not agree, reconfigure the routers so that their zone lists match for relevant networks. |
Symptom: Users complain that their sessions with AppleTalk services suddenly drop for no apparent reason. Table 4-12 outlines a possible cause and a suggests an action when AppleTalk network services are unexpectedly lost.
| Possible Cause | Suggested Actions |
|---|---|
| Unstable routes | Step 1 See Table 4-8 for suggested actions. |
Symptom: A router is unable to discover routes or to poll neighbors on an attached cable. Table 4-13 outlines possible causes and suggests actions for a router port stuck in restarting or acquiring mode.
| Possible Causes | Suggested Actions |
|---|---|
| Crossed serial circuits with multiple lines between two routers. | Step 1 Check physical attachment of serial lines to ensure that they are correctly wired.
Step 2 If needed, rewire and use the output of the show interfaces and show appletalk interface commands to confirm that the interface and line protocol are up. Step 3 If the router is still unable to find routes, consult your router technical support representative for more assistance. |
| Router is in discovery mode, and no seed router exists on the network. | Step 1 Put the router in nondiscovery mode.
Step 2 Use the appletalk address or appletalk cable-range interface configuration command to assign a network number or cable range. Step 3 If the router is still unable to find routes, consult your router technical support representative for more assistance. |
| Conflicting zone lists | Step 1 Issue the show appletalk route EXEC command. Look for neighboring nodes that have the same cable-range but a different zone list.
Step 2 Bring the zone lists into agreement. |
| Software problem | Step 1 If the router issues a message that says "restart port pending," upgrade to the latest system software maintenance release or contact your router technical support representative. |
Symptom: Users report that they are seeing zones that were deleted from the network. Table 4-14 outlines possible causes and suggests actions when old AppleTalk zones continue to appear in the Chooser.
| Possible Causes | Suggested Actions |
|---|---|
| Configuration mismatch | Step 1 See Table 4-5 for suggested actions. |
| Invalid zone names in the routing tables | Step 1 Check the network numbers for each AppleTalk interface in the router configuration.
Step 2 Remove any network number that is associated with an old zone name. Step 3 Use the show appletalk zones command to verify that the ghost zone no longer appears in the list. |
Symptom: AppleTalk routes are not propagated through an AURP tunnel. Routes that are known to exist on one side of the tunnel do not appear in the routing tables of the exterior router on the other side of the tunnel. Table 4-15 shows a possible cause and suggests actions for routes not being propagated through an AURP tunnel.
Symptom: Remote dial-in ARA sessions exhibit slow performance. Table 4-16 describes a possible cause and suggests actions when performance is slow over an ARA connection.
| Possible Cause | Suggested Actions |
|---|---|
| Flow control is not enabled, is enabled only on one device (either DTE or DCE), or is misconfigured. | Step 1 Configure hardware flow control on the line using the flowcontrol hardware line configuration command. Cisco recommends configuring hardware flow control for access server-to-modem connections.
NOTE: If for some reason you are unable to use flow control, it is recommended that you limit the line speed to 9600 bps. Faster speeds will likely result in lost data. Step 2 After enabling hardware flow control on the access server or router line, initiate a reverse Telnet session to the modem via that line. For more information, see the section "Initiating a Reverse Telnet Session to a Modem," in the "Troubleshooting Serial Line Problems" chapter. Step 3 Issue a modem command string that includes the RTS/CTS Flow command for your modem. This command ensures that the modem is using the same method of flow control (that is, hardware flow control) as the Cisco access server or router. See your modem documentation for exact configuration command syntax. For more information see the section "Troubleshooting Access Server to Modem Connectivity" in the "Troubleshooting Serial Line Problems" chapter. |
Symptom: ARA client (such as a Macintosh) attempts to connect to an ARA server (such as a Cisco access server) and is unable to initiate a remote session. User may be able to connect briefly but the connection is immediately terminated. Table 4-17 describes possible causes and suggests actions when an ARA client is unable to connect to an ARA server.
| Possible Causes | Suggested Actions |
|---|---|
| Missing arap network command entry | Step 1 If you are running Cisco Internetwork Operating System (Cisco IOS) Release 10.2 or later on a Cisco access server, configure the arap network global configuration command to run ARA.
Step 2 Issue the write terminal privileged EXEC command to be certain that the command is configured. |
| AppleTalk routing is not enabled on the appropriate access server or router interface | Step 1 Issue the show apple interfaces EXEC command to determine if the interfaces are operational and whether AppleTalk routing is enabled on the correct interfaces.
Step 2 If AppleTalk routing is not enabled on the proper interfaces, refer to the Router Products Configuration Guide for detailed information on configuring an interface for AppleTalk routing. |
| Modem, serial line, or hardware problems | Step 1 For modem and serial line troubleshooting information, see the "Troubleshooting Serial Line Problems" chapter. For hardware troubleshooting information, see the "Troubleshooting Router Startup Problems" chapter. |
Symptom: ARA client (for example, a Macintosh) tries to connect to an ARA server (such as a Cisco access server) over client and server modems. The client receives a connect message such as "Communicating at 14.4 Kbps," but then hangs for 10-30 seconds, and finally shows a "connection failed" message. Table 4-18 shows a possible cause and suggests actions for a modem connection hanging after issuing a "communicating at..." message.
Symptom: An AppleTalk Enhanced IGRP router is stuck in Active mode. An Enhanced IGRP router can be in either Passive or Active mode. A router is said to be Passive for Network A when it has an established path to Network A in its routing table.
If the Enhanced IGRP router loses the connection to Network A, it becomes Active for that network. The router sends out queries to all of its neighbors in order to find a new route to Network A. The router remains in Active mode until it has either received replies from all of its neighbors or until the active timer, which determines the maximum period of time a router will stay Active, has expired.
If the router receives a reply from each of its neighbors, it computes the new next hop to Network A and becomes Passive for that network. However, if the active timer expires, the router removes from its neighbor table any neighbors that did not reply, again enters Active mode, and issues a "Stuck-in-Active" message to the console:
%DUAL-3-SIA: Route 2.24 Stuck-in-Active
Table 4-19 describes possible causes and suggests actions when an AppleTalk Enhanced IGRP router is stuck in Active mode.
| Possible Causes | Suggested Actions |
|---|---|
| Active timer value is misconfigured | Step 1 The active timer determines the maximum period of time that an Enhanced IGRP router will wait for replies to its queries. If the active timer value is set too low, there might not be enough time for all of the neighboring routers to send their replies to the Active router.
Step 2 Check the configuration of each Enhanced IGRP router using the write terminal privileged EXEC command. Look for the timers active-time router configuration command associated with the appletalk routing eigrp global configuration command. Step 3 The value set by the timers active-time command should be consistent among routers. Cisco strongly recommends configuring a value of 3 (3 minutes, which is the default value) to allow all Enhanced IGRP neighbors to reply to queries. |
| Interface or other hardware problem | Step 1 If queries and replies are not sent and received properly, the active timer will time out and cause the router to issue an error message. Issue the show appletalk eigrp neighbors EXEC command and examine the Uptime and Q Cnt (queue count) fields in the output.
If the uptime counter is continually resetting or if the queue count is consistently high, there might be a problem with hardware. Step 2 Determine where the problem is occurring by looking at the output of the stuck in Active error message, which will indicate the AppleTalk address of the problematic node. Step 3 Make sure the suspect router is still functional. Check the interfaces on the suspect router. Make sure the interface and line protocol are up and determine whether the interface is dropping packets. For more information on troubleshooting hardware, see the "Troubleshooting Router Startup Problems" and the "Troubleshooting Serial Line Problems" chapters. Step 4 Make sure the suspect router has not had its configuration changed in a manner that could effect the convergence of the Enhanced IGRP routing protocol. Static routes, for example, can cause problems. Step 5 Try jumpstarting the Enhanced IGRP router using the clear appletalk eigrp neighbors privileged EXEC command. This causes the router to clear its neighbor table, enter Active mode, and attempt to reacquire its neighbor information. |
| Flapping route | Step 1 If there is a flapping serial route (caused by heavy traffic load), queries and replies might not be forwarded reliably. Route flapping caused by heavy traffic on a serial link can cause queries and replies to be lost, resulting in the active timer timing out.
Step 2 Take steps to increase the bandwidth of the link. |
|
|