Banner
HomeTOCPrevNextGlossSearchHelp

Table of Contents

Troubleshooting AppleTalk Connectivity

Troubleshooting AppleTalk Connectivity

Troubleshooting AppleTalk Connectivity

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:


AppleTalk Internetworking Terminology

The following discussion establishes a framework for analyzing AppleTalk internetworking problems.


Networks and Internetworks

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.


Phase 1 and Phase 2 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.

Note Some routers can be configured for Phase 1, Phase 2, or transition mode. Cisco recommends that routers be configured for Phase 2 at the earliest opportunity, subject to limitations in software (such as routers that do not allow nonextended Ethernet configurations for Phase 2). Cisco recommends against the use of transition mode, which is an interim solution at best. Transition mode implementations can be avoided by using enhancements available in Cisco routers.


Nonextended and Extended Networks

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.

Note There are no inherent problems in transporting traffic from extended networks across nonextended networks. However, there are certain implementation rules that apply to internetworks that use both Phase 1 and Phase 2 routers. These rules are discussed in "Identifying a Phase 1 and Phase 2 Rule Violation," later in this chapter.


AURP Tunnel

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.


Exterior Router

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

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).


AppleTalk Internetworking Guidelines

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:


Common AppleTalk Internetworking Problems

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.


Configuration Mismatch

A configuration mismatch occurs when the following AppleTalk rule is violated:

All AppleTalk routers on a given cable must agree on the configuration of that cable (meaning that all routers must have matching network numbers, default zone, and zone list).

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.

Figure 4-1 : Output of the show appletalk interface Command that Illustrates Port Mismatch

s2517.gif

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.


Duplicate Network Numbers

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.


Phase 1 and Phase 2 Rule Violations

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.

Table 4-1 : Comparison of Phase 1 and Phase 2 NBP Packet Types

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.

Note Just because a router is configured for nonextended networks does not mean it is a Phase 1 router. A Cisco router running Software Release 8.2 or a later release is a Phase 2-compliant router regardless of how the interfaces are configured.


ZIP Problems

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 List Errors

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.


Unstable Routes

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.


Unexpected Back Door

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.


Preventing AppleTalk Configuration Problems

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:


AppleTalk Problem-Prevention Suggestions

Table 4-2 provides a list of suggestions intended to reduce problems when you are configuring a router for AppleTalk.

Table 4-2 : AppleTalk Problem-Prevention Suggestions

Preventive Action Comments
Upgrade to Phase 2 wherever possible. To minimize interoperability problems, upgrade all routers to Phase 2. Phase 1/Phase 2 networks can be problematic, as can AppleTalk networks using nonextended Ethernet.
When you are configuring or making changes to a router or interface for AppleTalk, enable the debug apple events privileged EXEC command. The debug apple events privileged EXEC command tracks the progress and status of changes in the internetwork and alerts you to any errors. You also should run this command periodically when you suspect network problems. However, in a stable network, this command does not return any information. Remember to disable this command with the no debug apple events command when you have completed diagnostic activities.
You may want to add the configuration command appletalk event-logging and establish a syslog server at your site, which will keep a running log, with timestamps, of significant events on your network.
Minimize the number of different zones in the internetwork. Give all of the backbone/wide-area network (WAN) connections the same zone name (such as ZZSerial) or have WAN connections share the zone name of the smaller of the two sites that it connects.
In most internetworks, it is not desirable to have the zone names for all backbone or WAN connections appear in the Chooser list. If you make the zone name of all the WAN links the same (ZZSerial), only that entry appears in the Chooser menu.
Design your network with special attention to the direction in which traffic will flow. Careful zone-mapping design can minimize unnecessary NBP traffic. Note that in System 6, if a user opens the Chooser, the Macintosh continually sends NBP BrReq packets. In System 7, a logarithmic backoff minimizes the amount of traffic generated.
Taking this action can be particularly important in WANs where traffic traversing WAN links (such as X.25) can be quite expensive.
Zones should be named for the convenience of end users and not for diagnostic purposes. Zones should not be used as cable labels (in other words, do not identify one zone per cable with names like "Bld2 S/W Serial T1"). In general, a mixture of location and departmental naming conventions works best (for example, "Bldg 13 Engineering").
Control the number of zones used. Many routers have specific limits on the number of routes and zones they can handle. These limits usually result from memory constraints, but are sometimes fixed limits or are related to available bandwidth. If you exceed such a limit on a cable connected to one of these devices, zones may come and go unpredictably.
Cisco routers do not impose fixed limits. However, it recommended that you not configure all zones on all cables.
Use the appletalk timers global configuration command in busy networks with large numbers of internetwork routers on a single network. On very busy networks with many LocalTalk-to-EtherTalk routers, the LocalTalk Link Access Protocol (LLAP) routers may not send RTMP updates every 10 seconds as they should, which results in unnecessary route flapping. To prevent this problem, adjust the AppleTalk timers by using the appletalk timers 10 30 90 command. The first number should always be 10, and the third number should always be three times the value of the second number. However, setting the second and third numbers to excessively high values can result in slow routing convergence when network topology changes.
Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork. Check with a qualified technical support representative before changing AppleTalk timer values.


AppleTalk Protocol Startup Tips

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.

  1. Bring up the interface in discovery mode (using the appletalk discovery interface configuration command). The debug apple events privileged EXEC command will let you know when the process is complete by displaying an "operational" message.

  2. After discovery is complete, and while in interface configuration mode, enter the no appletalk discovery interface configuration command for the specific AppleTalk interface being initialized. This action allows the acquired information to be saved and requires that the configuration be validated at port startup. The router exits out of discovery mode for normal operation (it is recommended that discovery mode only be used when initially configuring networks). Thereafter, all routers should be configured for seed, or nondiscovery, mode.

  3. Issue the write memory privileged EXEC command to save the acquired information to nonvolatile RAM.

  4. Verify the configuration with the show configuration EXEC command.


Internetwork Reconfiguration Problem Prevention

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.


Changing Zone Names

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).


Forcing an Interface Up

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.


AppleTalk Diagnostic Techniques

Use the following suggestions from router technical support representatives to help speed problem diagnosis and ensure efficient data gathering in the event of failures:

  • The debug apple events privileged EXEC command is completely silent in a stable network. If the command produces any output, unnecessary changes are occurring on the internetwork. To monitor the internetwork for configuration and status changes, you can continuously log the output from this command to a syslog daemon on a UNIX host.

  • To identify problem nodes, you can run ping tests. For example, ping appletalk 2.24 pings AppleTalk node 2.24. Use this command to verify that the node is reachable from the router. The ping privileged EXEC command also supports a number of AppleTalk parameters, which provide additional troubleshooting capabilities. In particular, use the NBP option when AppleTalk zones are listed in the Chooser, but services are not available. If a configuration contains the appletalk name-lookup-interval global configuration command, the NBP option of the AppleTalk ping function displays nodes by their NBP registration name.


AppleTalk Service Availability Scenario

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.


Symptoms

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.

Figure 4-2 : Initial AppleTalk Connectivity Scenario Map

fig_1.gif

Assume that the following three symptoms were reported for this AppleTalk internetwork:

  1. Macintosh user Melvin on Ethernet segment 2 reports that the laser printer Slug (attached to the LocalTalk network connected to IR-1) is not visible on his Chooser.

  2. DEC VAX-based AppleShare server on Ethernet segment 1 is not visible to any users except Macintosh users Debbie and Biff on Ethernet segment 5.

  3. AppleShare server Spunky on Ethernet segment 4 is sometimes visible in the Choosers of Macintosh users in this internetwork, but no one can access services on that server. Although users on the same network as Spunky can see local services, they find it difficult to access offnet services.

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.


Environment Description

Some relevant facts regarding the internetworking environment shown in Figure 4-2 can be summarized as follows:

  • Three Cisco routers (Router-R1, Router-R2, and Router-R3) and a non-Cisco internetwork router (IR1) provide interconnection between local Ethernet segments and a LocalTalk network attached to IR-1.

  • Remote service is provided via Router-R2 and the remotely located Cisco Router-R4 to an AppleTalk network (Far-Net) that is not controlled by local network administration.

  • Macintosh users in the same zone as the DEC VAX can see all zones and can access offnet services.

  • Users on all the local networks can access AppleTalk services on directly connected network cables.

  • The routers in this internetwork are in the process of being converted from Phase 1 support to Phase 2 support.

  • The only other protocol used in this internetwork is TCP/IP.

  • With the exception of one LocalTalk segment, local networks are IEEE 802.3 thin Ethernets; the serial link is a dedicated T1 link (1.544 Mbps).

  • The network applications intended to run over the T1 line include typical AppleTalk network services.


Diagnosing and Isolating Problem Causes

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):

  • Misconfigured router (Router-R1 or IR-1)

  • Ethernet port on Router-R1 is shut down

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):

  • Duplicate network number

  • Phase 1 and Phase 2 internetworking rule violation

  • Network or port configuration mismatch

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.)

  • Duplicate network number

  • Zone Information Protocol (ZIP) storm

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.

Figure 4-3 : AppleTalk Zone and Network Number/Cable Range Assignments

s1881.gif


Problem Resolution Process

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.


Looking for a ZIP Storm

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.


Isolating Duplicate Network Numbers

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.

Figure 4-4 : show appletalk interface ethernet 6 Command Output

s2391.gif

Step 2 Next, disable AppleTalk using the no appletalk routing global configuration command as illustrated in Figure 4-5.

Figure 4-5 : Disabling AppleTalk at the Router

s2392.gif

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 : show appletalk route 2 Command Output

s2503.gif

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.


Identifying a Phase 1 and Phase 2 Rule Violation

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:

  • There can be no wide cable range specifications in the Phase 2 extended portion of the internetwork. (Cable ranges must be specified to include only a single network number, such as 2-2 or 10-10.)

  • Multiple zones cannot be assigned to networks or cable ranges.

Figure 4-7 : show appletalk globals Command Output

s2504.gif

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.

Figure 4-8 : show appletalk neighbors Command Output

s2505.gif

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.


Establishing Printer Service over the Internetwork

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 IR1. 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 IR1 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.

Figure 4-9 : show appletalk traffic Command Output

s2506.gif

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:

  • Ethernet interface 1 on Router-R1 comes up as a nonextended network.

  • All nodes on the attached network cable range 6-6 are isolated.

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).


Problem Solution Summary

This scenario focused on diagnosing blocked service access in AppleTalk internetworks. Modifications discussed in this scenario included the following:

  • Upgrading a Phase 1-only router to support Phase 2 removed blocked print service.

  • Using the appletalk proxy-nbp command allowed access to a DEC VAX-based AppleShare server requiring Phase 1 compatibility.

  • Eliminating duplicate network numbers ensured access to AppleShare server Spunky.

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.

Figure 4-10 : Complete AppleTalk Router-R1 Final Configuration

s2397.gif


Example AppleTalk Enhanced IGRP Diagnostic Session

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.

Figure 4-11 : AppleTalk Network Running AppleTalk Enhanced IGRP and RTMP

s3288.gif

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.

Note Table 4-3 and Table 4-4 do not address hardware problems that might contribute to network connectivity problems. For information on troubleshooting hardware problems, see the "Troubleshooting Router Startup Problems" chapter.

Table 4-3 : Multiprotocol AppleTalk Internetwork Diagnostics (RTMP and 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.

Table 4-4 : Single-Protocol AppleTalk Internetwork (AppleTalk Enhanced IGRP Only)

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.


AppleTalk Connectivity Symptoms

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:


Users Cannot See Zones or Services on Remote Networks

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.

Table 4-5 : AppleTalk: Users Cannot See Zones or Services on Remote Networks

Possible Cause Suggested Actions
Configuration mismatch Step 1 Examine the output of the show appletalk interface EXEC command for a "port configuration mismatch" message, which indicates that the configuration disagrees with its listed neighbor.
Step 2 If the output of the show appletalk interface EXEC command does not include the "port configuration mismatch" message, use the clear interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist.
Step 3 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, verify that the configuration for each router agrees with respect to network number or cable range and with respect to zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its configuration information from the network. (That is, put the router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or appletalk cablerange 00 on an extended network.)
Step 4 If router configurations do not agree, modify them as necessary.
Step 5 If the problem persists, try to determine which router is at fault.
The show appletalk interface command displays the network and node address of the conflicting router.

If the appletalk name-lookup-interval global configuration command is enabled, the show appletalk interface command displays the NBP registration name.

If you are unable to identify the misconfigured router using the node address, determine the hardware address of the conflicting router with the show appletalk arp EXEC command. This command also allows you to determine the vendor code. (An explanation of vendor codes is available in RFC 1340.)

Step 6 As an alternative, configure all routers but one for discovery mode and restart the routers that are in discovery mode.


Services on a Network Not Visible to Other Networks

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.

Table 4-6 : AppleTalk: Services Not Visible to Other AppleTalk 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.


Interface Fails to Start AppleTalk

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.

Table 4-7 : AppleTalk: Interface Fails to Start AppleTalk

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.


Some Zones Missing from Chooser

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.

Table 4-8 : AppleTalk: Zones Not Appearing in Chooser

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.


Services Not Always Available

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.

Table 4-9 : AppleTalk: Services Not Always Available

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.


Services Visible, but Users Cannot Connect

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.

Table 4-10 : AppleTalk: Services Visible but Users Cannot Connect

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.


Zone List Changes Each Time Chooser Is Opened

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.

Table 4-11 : AppleTalk: Zone List Constantly Changing

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.


Connections to Services Drop

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.

Table 4-12 : AppleTalk: Services Drop Unexpectedly

Possible Cause Suggested Actions
Unstable routes Step 1 See Table 4-8 for suggested actions.


Port Seems Stuck in Restarting or Acquiring Mode

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.

Table 4-13 : AppleTalk: 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.


Old Zone Names Still Appear in Chooser

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.

Table 4-14 : AppleTalk: Old Zone Names Appear in 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.

Note AppleTalk does not provide a way to update ZIP tables when changing the mapping of zone names to networks/cable ranges. For example, if the zone name for network number 200 is Twilight Zone, but you decide to change the zone to No Parking Zone, the zone name on the interface can be changed, and the new zone name takes effect locally. However, unless you keep network 200 off the internetwork long enough for it to be completely aged out of the routing tables, some routers will continue to use the old zone name (called ghost zones). Alternatively, if you cannot keep the network off the internetwork that long, change the underlying network number when you change the zone name of a cable.


Routes Not Propagated through AURP Tunnel

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.

Table 4-15 : AppleTalk: Routes Not Propagated through AURP Tunnel

Possible Cause Suggested Actions
Routes are not redistributed between AURP and RTMP. Step 1 Use the show appletalk interface EXEC command to verify that the interfaces on the AURP exterior routers are in the up state.
Step 2 If the tunnel interfaces on the exterior routers are properly connected to the network and are operational, but AppleTalk routes remain invisible on one side of the AURP tunnel, issue the debug apple redistribution privileged EXEC command to help determine whether routes are being redistributed among routing protocols.
Step 3 Issue the appletalk route-redistribution global configuration command on any AURP tunnel interfaces. This command specifies that routing information be redistributed among Apple routing protocols. The output from the debug apple redistribution command will indicate that routes are now being redistributed among routing protocols.


Slow Performance from ARA Dial-In Connection

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.

Table 4-16 : AppleTalk: Slow Performance from ARA Dial-In 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.


ARA Client Unable to Connect to ARA Server

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.

Table 4-17 : AppleTalk: ARA Client Unable to Connect to 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.


ARA Connection Hangs after "Communicating At..." Message

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.

Table 4-18 : AppleTalk: ARA Connection Hangs after Issuing "Communicating At..." Message

Possible Cause Suggested Actions
MNP4 Link Request packets sent by ARA stack in client are being responded to by the serving modem instead of the ARA server Step 1 Check the version numbers of the ARA software on the client and the Cisco IOS software on the access server. If you are using ARA version 1.0 and Cisco IOS Release 10.2 or earlier, it is advisable to upgrade to ARA 2.0 and Cisco IOS Release 10.2 or later. ARA 2.0 modifies the framing of MNP4 Link Request packets, allowing them to be passed to the access server rather than responded to by the serving modem.
Step 2 If it is not possible to upgrade your software, try modifying the behavior of the modem to use a LAPM-to-No Error Correction fallback instead of a LAPM-to-MNP4-to-No Error Correction fallback. The modem will no longer listen for and respond to MNP4 messages, allowing MNP4 packets to reach the access server.
NOTE: Many modems cannot be configured in this manner.

Step 3 If your modem does not use LAPM error correction, it might be possible to modify all ARA client scripts to extend the 500 ms (millisecond) pause before exiting. Configure an additional delay that takes into account the behavior of the serving modem.


Enhanced IGRP Router Stuck in Active Mode

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        


 Note
It is essential to note that the occasional appearance of these messages is not cause for concern. This is simply the manner in which an Enhanced IGRP router recovers if it does not receive replies to its queries from all of its neighbors. However, if these error messages occur frequently, the problem should be investigated.

Table 4-19 describes possible causes and suggests actions when an AppleTalk Enhanced IGRP router is stuck in Active mode.

Table 4-19 : AppleTalk: Enhanced IGRP Router 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.

HomeTOCPrevNextGlossSearchHelp
-

Copyright 1988-1996 © Cisco Systems Inc.