Troubleshooting AppleTalk

This chapter presents protocol-related troubleshooting information for AppleTalk connectivity and performance problems. In addition to general AppleTalk problems, this chapter also covers AppleTalk Enhanced IGRP, ARA, AURP, and FDDITalk problems.

The first section of this chapter, "AppleTalk Configuration and Troubleshooting Tips," discusses preventative measures and tips to help you configure and troubleshoot your AppleTalk internetwork. The remaining sections describe specific AppleTalk symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.

AppleTalk Configuration and Troubleshooting Tips

This section offers configuration and troubleshooting tips that can help you prevent or more easily repair problems in AppleTalk internetworks.

It consists of the following sections:

Preventing AppleTalk Problems

Table 7-1 lists suggestions to help you avoid problems when configuring a router for AppleTalk.

Table 7-1 : AppleTalk Problem-Prevention Techniques

Preventive Action Description

Every router connected to a network must agree on the configuration of that network Every router on an AppleTalk network (that is, on a single cable segment) must agree on the configuration of the network. Therefore, network numbers, cable ranges, timer values, zone names, and other parameters should be the same for every router on the segment.

Every network number in an internetwork must be unique Network numbers must be unique throughout the entire AppleTalk network. Duplicate network numbers can cause connectivity- and performance-related problems.

Upgrade to AppleTalk Phase 2 wherever possible To minimize interoperability problems, upgrade all router Ethernet interfaces to Phase 2. Phase 1/Phase 2 networks can be problematic, as can non-extended AppleTalk networks.

When you change a router or interface configuration, enable the debug apple error privileged EXEC command to log errors The debug apple error privileged EXEC command tracks the progress and status of changes in the internetwork and alerts you to any errors. You can also run this command periodically when you suspect network problems. In a stable network, this command will return no output.
You can establish a syslog server at your site and add the configuration command appletalk event-logging to the router. This will keep a running log, with timestamps, of significant events on your network.
Disable this command with the no debug apple error command when you have completed diagnostic activities.

Design your network with attention to the direction in which traffic will flow and minimize the number of different zones in the internetwork Careful zone mapping can minimize unnecessary NBP¹ traffic. Planning is particularly important in WANs where traffic traversing WAN links (such as X.25) can be quite expensive.
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.
Give all of the backbone/WAN connections the same zone name rather than put them in a zone with a LAN.
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 (for example, ZZSerial), only that entry appears in the Chooser menu.

Set AppleTalk timers to the default values throughout the internetwork A stable network almost never has non-default timer values configured. 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.

¹ NBP=Name Binding Protocol

Preventive Action	Description
Every router connected to a network must agree on the configuration of that network	Every router on an AppleTalk network (that is, on a single cable segment) must agree on the configuration of the network. Therefore, network numbers, cable ranges, timer values, zone names, and other parameters should be the same for every router on the segment.
Every network number in an internetwork must be unique	Network numbers must be unique throughout the entire AppleTalk network. Duplicate network numbers can cause connectivity- and performance-related problems.
Upgrade to AppleTalk Phase 2 wherever possible	To minimize interoperability problems, upgrade all router Ethernet interfaces to Phase 2. Phase 1/Phase 2 networks can be problematic, as can non-extended AppleTalk networks.
When you change a router or interface configuration, enable the debug apple error privileged EXEC command to log errors	The debug apple error privileged EXEC command tracks the progress and status of changes in the internetwork and alerts you to any errors. You can also run this command periodically when you suspect network problems. In a stable network, this command will return no output. You can establish a syslog server at your site and add the configuration command appletalk event-logging to the router. This will keep a running log, with timestamps, of significant events on your network. Disable this command with the no debug apple error command when you have completed diagnostic activities.
Design your network with attention to the direction in which traffic will flow and minimize the number of different zones in the internetwork	Careful zone mapping can minimize unnecessary NBP¹ traffic. Planning is particularly important in WANs where traffic traversing WAN links (such as X.25) can be quite expensive. 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. Give all of the backbone/WAN connections the same zone name rather than put them in a zone with a LAN. 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 (for example, ZZSerial), only that entry appears in the Chooser menu.
Set AppleTalk timers to the default values throughout the internetwork	A stable network almost never has non-default timer values configured. 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.

Using the test appletalk and ping appletalk Commands

In Cisco IOS Release 11.1 and later, use the test appletalk privileged EXEC command to help identify problem nodes. Use the nbp options of the command to perform informational lookups of NBP-registered entities. The information returned when using the nbp options is useful when AppleTalk zones are listed in the Chooser but services in those zones are unavailable.

When running the test appletalk facility, use the confirm option to check that a name of a specified type is registered on a device. For example, nbp confirm 24279.173 my-mac:AFPServer@engineering confirms that the name "my-mac" is registered on the device 24279.173 in the engineering zone. The object type is AFPServer.

In software releases prior to Cisco IOS Release 11.0, the ping appletalk EXEC command serves a similar function. Use this command to verify that a node is reachable from the router (for example, ping appletalk 2.24 pings AppleTalk node 2.24). The ping privileged EXEC command also supports several AppleTalk parameters that 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.

Preventing Internetwork Reconfiguration Problems

Configuration conflicts can occur when zone names or cable range numbers are changed. In particular, problems arise when routing devices exist on the internetwork about which you are not administratively aware.

Many devices can act as routers (for example, Novell servers, 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, shut down all routers so that a Cisco router does not see a conflict and prevent AppleTalk from initializing on the interface.

Before changing the configuration, use the show appletalk neighbors EXEC command to determine which routers you should disable AppleTalk routing on.You should disable AppleTalk on all routers that are on the same network segment and that have sent RTMP updates in the last 10 seconds. Disable AppleTalk routing on all of the appropriate interfaces, wait approximately 10 minutes, and then bring up the seed router.

Changing Zone Names

When changing a zone name on an existing network, perform the following actions:

Step 1 Disable AppleTalk on all router interfaces on the cable for approximately 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 make ZIP queries only when a new (or previously aged-out) network appears on the internetwork.

Adding a new zone to an extended cable configuration prevents the router from bringing up an AppleTalk interface after the interface has been reset. This is because its configuration no longer matches that of its neighbors (that is, it detects a configuration mismatch error).

AppleTalk Discovery Mode

When bringing an interface up on an existing cable where a long zone list is defined, using AppleTalk discovery mode will help you save effort and avoid mistakes.

Bring up the interface in discovery mode (using the appletalk cable-range 0-0 interface configuration command). When a router is in discovery mode, the router changes its configuration to match the advertised cable range if the advertised cable range is different from that configured on the router. The debug apple events privileged EXEC command will let you know when the discovery process is complete by displaying an "operational" message.
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 saves the acquired information and forces the configuration to be validated at port startup.
The router should not be in discovery mode for normal operation (it is recommended that discovery mode be used only when initially configuring networks). After the initial configuration, configure all routers for seed, or nondiscovery, mode.
Use the copy running-config startup-config privileged EXEC command to save the acquired information to nonvolatile RAM (NVRAM).
Verify the configuration with the show running-config privileged EXEC command.

Forcing an Interface Up

In certain situations, you might need to force an interface to come up even though its zone list conflicts with that of another router on the network. You can do this using the appletalk ignore-verify-errors global configuration command. Usually the other router is one over which you have no administrative control but which you know has an incorrect zone list.

The appletalk ignore-verify-errors command allows you to bypass the default behavior of an AppleTalk interface. By default, the AppleTalk interface will 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 in the internetwork agree on the zone list.

After all the AppleTalk routers on the network segment have conforming zone lists, disable the appletalk ignore-verify-errors command using the no form of the command. For complete information on the appletalk ignore-verify-errors global configuration command, see the Cisco IOS Network Protocols Command Reference, Part 1.

Users Cannot Access Zones or Services

Symptom: Users cannot access zones or services that appear in the Chooser. Users might or might not be able to access services on their own network.

Table 7-2 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-2 : AppleTalk: Users Cannot Access Zones or Services

Possible Problems	Solution
Configuration mismatch	Step 1 Use the show appletalk interface EXEC command. Check the output for a "port configuration mismatch" message. If the command output contains a mismatch message, the router configuration disagrees with that of the listed neighbor. If the command output does not include the message, use the clear apple interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist. Step 2 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, check to see if all router configurations agree on the network number or cable range and the zone or zone list. Step 3 If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment. Step 4 If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cablerange 00 command on an extended network. This causes the router to get its configuration information from the network. For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" later in this chapter.
Duplicate network numbers or overlapping cable-range	In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, packets might not be routed to their intended destination. If AppleTalk services do not appear in the Chooser for particular networks, those networks probably have duplicate network numbers. Step 1 Change the network number or cable-range of the suspect network to a unique value using the appletalk cable-range interface configuration command. Step 2 Use the show appletalk route privileged EXEC command to view the routing table. If the network number or cable-range continues to appear in routing tables, you have found the duplicate (because the other network using that number will continue to send routing updates). If the network number or cable-range disappears from the internetwork after 40 seconds, you have not found the duplicate. Change the network number or cable-range specification back to its previous value and try again to isolate the duplicate network number. Step 3 If you changed the network number or cable-range on the interface, 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 To resolve the problem, you can perform one of the following actions: Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 and reconfigure the internetwork Ensure that all routers are in compliance with the two Phase 1 and Phase 2 rules For more information on Phase 1 and Phase 2 rule violations, see the section "Phase 1 and Phase 2 Rule Violations" later in this chapter.
Misconfigured access lists or other filters	Step 1 Use the show appletalk access-list EXEC command on routers in the path from source to destination. Step 2 Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. If there are distribution lists or other filters configured, disable them. Step 3 After disabling access lists, check whether remote zones and services become accessible. Step 4 If zones and services are now available, a misconfigured access list is the likely problem. To isolate the problem access list, enable lists one at a time until connectivity fails. Step 5 Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally. Step 6 If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.

AppleTalk Configuration Mismatches

A configuration mismatch will occur if all of the AppleTalk routers on a given cable do not agree on the configuration of that cable. This means that all routers must have matching network numbers, a matching default zone, and a matching zone list.

To protect against configuration errors that violate this rule, Cisco 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 router is configured, the 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. When the show appletalk interface EXEC command is issued, the router will indicate a port configuration mismatch.

Following is sample output from the show appletalk interface command when a configuration mismatch exists:

Ethernet 0 is up, line protocol is up
AppleTalk routing disabled, Port configuration mismatch
AppleTalk cable range is 4-5
AppleTalk address is 4.252, Valid
AppleTalk zone is "Maison Vauquer"
AppleTalk port configuration conflicts with 4.156
AppleTalk discarded 8 packets due to input errors
AppleTalk discarded 2 packets due to output errors
AppleTalk route cache is disabled, port initializing

Line 2 of the command output shows that routing has been disabled due to a port configuration mismatch. Line 6 indicates the AppleTalk address of the conflicting router.

You can also display the 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. This causes the show appletalk interface EXEC command output to display nodes by NBP registration name.

Phase 1 and Phase 2 Rule Violations

When Phase 1 and Phase 2 routers are connected to the same internetwork, the internetwork specifications must conform to the following two rules:

There can be no "wide" cable range specifications in the Phase 2 extended portion of the internetwork. That is, no cable ranges can span more than a single (unary) network number. For example, the cable ranges 2--2, 9--9, and 20--20 are all acceptable. The cable ranges 10--12 and 100--104 are not acceptable.
Multiple zones cannot be assigned to unary cable ranges.

If these rules are not followed, connectivity between the nonextended and extended portions of an internetwork becomes degraded and might be lost. In particular, services located on nonextended networks using Phase 1 routers will not be visible on the other side of the Phase 1 router.

Note On Cisco routers, Phase 1 refers to the router Ethernet interfaces being configured with a single network address and Ethernet I encapsulation, instead of with a cable-range and Ethernet SNAP encapsulation. A Cisco router running Software Release 8.2 or later is a Phase 2-compliant router regardless of how the interfaces are configured.

Other Phase 1 and Phase 2 issues include the handling of NBP packets. 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 7-3 lists the NBP packet types for AppleTalk Phase 1 and Phase 2.

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

Phase 1 NBP Packet Phase 2 NBP Packet

BrRq (Broadcast Request) BrRq (Broadcast Request)

-- FwdReq (Forward Request)

LkUp (Lookup) LkUp (Lookup)

LkUp-Reply (Lookup Reply) LkUp-Reply (Lookup Reply)

Phase 1 NBP Packet	Phase 2 NBP Packet
BrRq (Broadcast Request)	BrRq (Broadcast Request)
--	FwdReq (Forward Request)
LkUp (Lookup)	LkUp (Lookup)
LkUp-Reply (Lookup Reply)	LkUp-Reply (Lookup Reply)

As shown in Table 7-3, 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.

Zones Missing from Chooser

Symptom: Certain zones do not appear in the Chooser. The zones are not visible from multiple networks. In some cases, when the Chooser is opened, the zone list changes.

Table 7-4 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-4 : AppleTalk: Zones Missing from Chooser

Possible Problems Solution

Configuration mismatch Step 1 Use the show appletalk interface EXEC command. Check the output for a "port configuration mismatch" message.

If the command output contains a mismatch message, the router configuration disagrees with that of the listed neighbor.

If the command output does not include the message, use the clear apple interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist.

Step 2 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, check to see if all router configurations agree on the network number or cable range and the zone or zone list.
Step 3 If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment.
Step 4 If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cablerange 00 command on an extended network. This causes the router to get its configuration information from the network.
For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.

Misconfigured access lists or other filters Step 1 Use the show appletalk access-list EXEC command on routers in the path from source to destination.
Step 2 Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. If there are distribution lists or other filters configured, disable them.
Step 3 After disabling access lists, check whether remote zones and services become accessible.
Step 4 If zones and services are now available, a misconfigured access list is the likely problem. To isolate the problem access list, enable lists one at a time until connectivity fails.
Step 5 Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally.
Step 6 If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.

Route flapping (unstable route) Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP¹ updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.
Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface.
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
[...]

Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network.

If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment.

Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following:

Router#debug apple events

AppleTalk Events debugging is on

Router#

%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41

Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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.

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.

ZIP storm 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.
Note: 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.
Step 1 Use the show appletalk traffic command and check the field showing the number of ZIP requests.

Router#sh apple traffic

[...]

ZIP: 44 received, 35 sent, 6 netinfo

[...]

Router#

Compare this value with the value shown by the command 30 seconds later.

Step 2 If the traffic counters for ZIP requests are incrementing very rapidly (by more than 10 every 30 seconds) a ZIP storm is probably occurring.

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.

Step 3 Identify 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.

For example, you can use the show appletalk route EXEC command to view the AppleTalk routing table. Check to see if a network shows up in the routing 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. Access lists or other filters might be the cause.

ZIP storms can also result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem.

Too many zones in internetwork The Chooser in System 6 can display only a limited number of zones, which presents problems in large internetworks that have many zones.
If the Macintosh is running a version of System 6, upgrade it to System 7 or System 7.5.

¹ RTMP=Routing Table Maintenance Protocol

Possible Problems	Solution
Configuration mismatch	Step 1 Use the show appletalk interface EXEC command. Check the output for a "port configuration mismatch" message. If the command output contains a mismatch message, the router configuration disagrees with that of the listed neighbor. If the command output does not include the message, use the clear apple interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist. Step 2 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, check to see if all router configurations agree on the network number or cable range and the zone or zone list. Step 3 If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment. Step 4 If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cablerange 00 command on an extended network. This causes the router to get its configuration information from the network. For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.
Misconfigured access lists or other filters	Step 1 Use the show appletalk access-list EXEC command on routers in the path from source to destination. Step 2 Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. If there are distribution lists or other filters configured, disable them. Step 3 After disabling access lists, check whether remote zones and services become accessible. Step 4 If zones and services are now available, a misconfigured access list is the likely problem. To isolate the problem access list, enable lists one at a time until connectivity fails. Step 5 Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally. Step 6 If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.
Route flapping (unstable route)	Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP¹ updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes. Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface. `Ethernet0 is up, line protocol is up` `Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)` `Internet address is 192.168.52.26/24` `MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255` `[...]` Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network. If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment. Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following: `Router#debug apple events` `AppleTalk Events debugging is on` `Router#` `%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41` Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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. 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.
ZIP storm	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. Note: 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. Step 1 Use the show appletalk traffic command and check the field showing the number of ZIP requests. `Router#sh apple traffic` `[...]` `ZIP: 44 received, 35 sent, 6 netinfo` `[...]` `Router#` Compare this value with the value shown by the command 30 seconds later. Step 2 If the traffic counters for ZIP requests are incrementing very rapidly (by more than 10 every 30 seconds) a ZIP storm is probably occurring. 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. Step 3 Identify 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. For example, you can use the show appletalk route EXEC command to view the AppleTalk routing table. Check to see if a network shows up in the routing 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. Access lists or other filters might be the cause. ZIP storms can also result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem.
Too many zones in internetwork	The Chooser in System 6 can display only a limited number of zones, which presents problems in large internetworks that have many zones. If the Macintosh is running a version of System 6, upgrade it to System 7 or System 7.5.

No Devices in Chooser

Symptom: Zones appear in the Chooser, but no when a service (such as AppleShare) and a zone are selected, no devices appear in the device list.

Table 7-5 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-5 : AppleTalk: No Devices in Chooser

Possible Problems Solution

Misconfigured access lists Step 1 Use the show appletalk access-list EXEC command on routers in the path from source to destination.
Step 2 Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command.
Step 3 After disabling access lists, check whether devices appear in the Chooser.
Step 4 If devices now appear in the Chooser, a misconfigured access list is probably filtering NBP traffic. To isolate the problem access list, enable lists one at a time until devices no longer appear.
Step 5 Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally.
Step 6 If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.
For detailed information about filtering NBP traffic using access lists, refer to the Cisco IOS Network Protocols Configuration Guide, Part 1.

Possible Problems	Solution
Misconfigured access lists	Step 1 Use the show appletalk access-list EXEC command on routers in the path from source to destination. Step 2 Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. Step 3 After disabling access lists, check whether devices appear in the Chooser. Step 4 If devices now appear in the Chooser, a misconfigured access list is probably filtering NBP traffic. To isolate the problem access list, enable lists one at a time until devices no longer appear. Step 5 Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally. Step 6 If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved. For detailed information about filtering NBP traffic using access lists, refer to the Cisco IOS Network Protocols Configuration Guide, Part 1.

Network Services Intermittently Unavailable

Symptom: Network services are intermittently unavailable. Services come and go without warning.

Table 7-6 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-6 : AppleTalk: Network Services Intermittently Unavailable

Possible Problems Solution

Duplicate network numbers or overlapping cable-range In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, packets might not be routed to their intended destination.
If AppleTalk services do not appear in the Chooser for particular networks, those networks probably have duplicate network numbers.
Step 1 Change the network number or cable-range of the suspect network to a unique value using the appletalk cable-range interface configuration command.
Step 2 Use the show appletalk route privileged EXEC command to view the routing table. If the network number or cable-range continues to appear in routing tables, you have found the duplicate (because the other network using that number will continue to send routing updates).

If the network number or cable-range disappears from the internetwork after 40 seconds, you have not found the duplicate. Change the network number or cable-range specification back to its previous value and try again to isolate the duplicate network number.

Step 3 If you changed the network number or cable-range on the interface, remember to reenter the zone name and any other interface configurations for AppleTalk on that interface.

Route flapping (unstable route) Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.
Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface.
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
[...]

Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network.

If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment.

Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following:

Router#debug apple events

AppleTalk Events debugging is on

Router#

%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41

Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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.

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.

ZIP storm 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.
Note: 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.
Step 1 Use the show appletalk traffic command and check the field showing the number of ZIP requests.

Router#sh apple traffic

[...]

ZIP: 44 received, 35 sent, 6 netinfo

[...]

Router#

Compare this value with the value shown by the command 30 seconds later.

Step 2 If the traffic counters for ZIP requests are incrementing very rapidly (by more than 10 every 30 seconds) a ZIP storm is probably occurring.

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.

Step 3 Identify 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.

For example, you can use the show appletalk route EXEC command to view the AppleTalk routing table. Check to see if a network shows up in the routing 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. Access lists or other filters might be the cause.

ZIP storms can also result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem.

Possible Problems	Solution
Duplicate network numbers or overlapping cable-range	In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, packets might not be routed to their intended destination. If AppleTalk services do not appear in the Chooser for particular networks, those networks probably have duplicate network numbers. Step 1 Change the network number or cable-range of the suspect network to a unique value using the appletalk cable-range interface configuration command. Step 2 Use the show appletalk route privileged EXEC command to view the routing table. If the network number or cable-range continues to appear in routing tables, you have found the duplicate (because the other network using that number will continue to send routing updates). If the network number or cable-range disappears from the internetwork after 40 seconds, you have not found the duplicate. Change the network number or cable-range specification back to its previous value and try again to isolate the duplicate network number. Step 3 If you changed the network number or cable-range on the interface, remember to reenter the zone name and any other interface configurations for AppleTalk on that interface.
Route flapping (unstable route)	Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes. Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface. `Ethernet0 is up, line protocol is up` `Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)` `Internet address is 192.168.52.26/24` `MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255` `[...]` Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network. If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment. Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following: `Router#debug apple events` `AppleTalk Events debugging is on` `Router#` `%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41` Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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. 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.
ZIP storm	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. Note: 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. Step 1 Use the show appletalk traffic command and check the field showing the number of ZIP requests. `Router#sh apple traffic` `[...]` `ZIP: 44 received, 35 sent, 6 netinfo` `[...]` `Router#` Compare this value with the value shown by the command 30 seconds later. Step 2 If the traffic counters for ZIP requests are incrementing very rapidly (by more than 10 every 30 seconds) a ZIP storm is probably occurring. 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. Step 3 Identify 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. For example, you can use the show appletalk route EXEC command to view the AppleTalk routing table. Check to see if a network shows up in the routing 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. Access lists or other filters might be the cause. ZIP storms can also result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem.

Old Zone Names Appear in Chooser (Phantom Zones)

Symptom: Old AppleTalk zone names continue to appear in the Chooser. Even after zone names are removed from the configuration, "phantom" zones continue to appear in the Chooser.

Table 7-7 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-7 : AppleTalk: Old Zone Names Appear in Chooser (Phantom Zones)

Possible Problems	Solution
Configuration mismatch	Step 1 Use the show appletalk interface EXEC command. Check the output for a "port configuration mismatch" message. If the command output contains a mismatch message, the router configuration disagrees with that of the listed neighbor. If the command output does not include the message, use the clear apple interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist. Step 2 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, check to see if all router configurations agree upon network number or cable range and the zone or zone list. Step 3 If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment. Step 4 If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cablerange 00 command on an extended network. This causes the router to get its configuration information from the network. For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.
Invalid zone names in routing table	AppleTalk does not provide a way to update ZIP tables when changing the mapping of zone names to networks or 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 (this is called a phantom zone). 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. Step 1 Use the show running-config privileged EXEC command to view the router configuration. Check the network numbers configured for each AppleTalk interface. Step 2 Make sure that there are no network numbers configured that were previously assigned to a zone that has been deleted. Change the cable-range using the appletalk cable-range interface configuration command or disable the network until it is aged out of routing tables. Step 3 Use the show appletalk zones command to verify that the zone no longer appears in the zone list.

Connections to Services Drop

Symptom: Users complain that their AppleTalk sessions suddenly drop for no apparent reason.

Table 7-8 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-8 : AppleTalk: Connections to Services Drop

Possible Problems Solution

Route flapping (unstable route) Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.
Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface.
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
[...]

Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network.

If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment.

Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following:

Router#debug apple events

AppleTalk Events debugging is on

Router#

%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41

Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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.

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.

Possible Problems	Solution
Route flapping (unstable route)	Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes. Step 1 Use the show interfaces EXEC command to check the traffic load. Check the load for each interface. `Ethernet0 is up, line protocol is up` `Hardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)` `Internet address is 192.168.52.26/24` `MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255` `[...]` Step 2 If the load is less than 50 percent, reconfiguring timer values might solve the problem by allowing RTMP updates more time to propagate through the network. If the load is more than 50 percent, you might need to segment the network to reduce the number of routers (and therefore the amount of traffic) on each network segment. Step 3 Use the debug apple events privileged EXEC command to determine whether routes are being aged incorrectly. The output should resemble the following: `Router#debug apple events` `AppleTalk Events debugging is on` `Router#` `%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41` Step 4 If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values 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. 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.

Interface Fails to Initialize AppleTalk

Symptom: Router interface connected to a network will not initialize AppleTalk.

Table 7-9 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-9 : AppleTalk: Interface Fails to Initialize AppleTalk

Possible Problems	Solution
Configuration mismatch	Step 1 Use the show appletalk interface EXEC command. Check the output for a "port configuration mismatch" message. If the command output contains a mismatch message, the router configuration disagrees with that of the listed neighbor. If the command output does not include the message, use the clear apple interface privileged EXEC command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist. Step 2 Enter the show appletalk interface EXEC command again. If its output still contains a "port configuration mismatch" message, check to see if all router configurations agree upon network number or cable range and the zone or zone list. Step 3 If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment. Step 4 If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cablerange 00 command on an extended network. This causes the router to get its configuration information from the network. For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.
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 To resolve the problem, you can perform one of the following actions: Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 and reconfigure the internetwork Ensure that all routers are in compliance with the two Phase 1 and Phase 2 rules For more information on Phase 1 and Phase 2 rule violations, see the section "Phase 1 and Phase 2 Rule Violations" earlier in this chapter.

Port Stuck in Restarting or Acquiring Mode

Symptom: A router port is stuck in restarting or acquiring mode (as shown in the output of the show apple interface privileged EXEC command). The router cannot discover routes or poll neighbors on an attached cable.

Table 7-10 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-10 : AppleTalk: Port Stuck in Restarting or Acquiring Mode

Possible Problems Solution

Router is in discovery mode, and no seed router exists on the network Step 1 Put the router in non-discovery mode by assigning a network number or cable range to the problem interface using the appletalk address or appletalk cable-range interface configuration command.
Step 2 If the problem persists, consult your technical support representative for more assistance.

Crossed serial circuits with multiple lines between two routers Step 1 Check the physical attachment of serial lines to ensure that they are correctly wired.
Step 2 If necessary, rewire the lines and check 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 still cannot find routes, consult your technical support representative for more assistance.

Software problem If the router issues a message that says "restart port pending," upgrade to the latest system software maintenance release or contact your technical support representative.

Possible Problems	Solution
Router is in discovery mode, and no seed router exists on the network	Step 1 Put the router in non-discovery mode by assigning a network number or cable range to the problem interface using the appletalk address or appletalk cable-range interface configuration command. Step 2 If the problem persists, consult your technical support representative for more assistance.
Crossed serial circuits with multiple lines between two routers	Step 1 Check the physical attachment of serial lines to ensure that they are correctly wired. Step 2 If necessary, rewire the lines and check 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 still cannot find routes, consult your technical support representative for more assistance.
Software problem	If the router issues a message that says "restart port pending," upgrade to the latest system software maintenance release or contact your technical support representative.

AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers

Symptom: Macintosh clients cannot connect to servers in an AppleTalk Enhanced IGRP network environment.

Table 7-11 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-11 : AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers

Possible Problem Solution

Routers not establishing neighbors properly For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" later in this chapter.

Routes missing from routing table For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routes Missing from Routing Table" later in this chapter.

Appletalk Enhanced IGRP enabled on network with connected Macintosh computers Macintosh computers do not understand AppleTalk Enhanced IGRP. RTMP must be enabled on interfaces with Macintosh computers on the connected LAN segment.
Step 1 Use the show running-config privileged EXEC command on routers to make sure that RTMP is enabled on interfaces connected to LAN segments with connected Macintosh computers.
Step 2 If RTMP is not enabled, enable it using the appletalk protocol rtmp interface configuration command.
Step 3 If desired, disable AppleTalk Enhanced IGRP on the interface using the no appletalk protocol eigrp interface configuration command.

Possible Problem	Solution
Routers not establishing neighbors properly	For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" later in this chapter.
Routes missing from routing table	For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routes Missing from Routing Table" later in this chapter.
Appletalk Enhanced IGRP enabled on network with connected Macintosh computers	Macintosh computers do not understand AppleTalk Enhanced IGRP. RTMP must be enabled on interfaces with Macintosh computers on the connected LAN segment. Step 1 Use the show running-config privileged EXEC command on routers to make sure that RTMP is enabled on interfaces connected to LAN segments with connected Macintosh computers. Step 2 If RTMP is not enabled, enable it using the appletalk protocol rtmp interface configuration command. Step 3 If desired, disable AppleTalk Enhanced IGRP on the interface using the no appletalk protocol eigrp interface configuration command.

AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors

Symptom: AppleTalk Enhanced IGRP routers do not establish neighbors properly. Routers that are connected do not appear in the neighbor table.

Table 7-12 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-12 : AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors

Possible Problem Solution

AppleTalk Enhanced IGRP is not globally configured on the appropriate routers Step 1 Use the show running-config privileged EXEC command to check the configuration of routers that should be running Enhanced IGRP. Look for appletalk routing eigrp global configuration command entries. This command enables AppleTalk Enhanced IGRP routing on the router.
Step 2 If AppleTalk Enhanced IGRP routing is not enabled on the router, use the appletalk routing eigrp router-id global configuration command to enable it.

Make sure that the router ID is unique throughout the network.

Step 3 Perform the same actions on other routers that should be running AppleTalk Enhanced IGRP. The router ID must be different for each router.

AppleTalk Enhanced IGRP is not enabled on interfaces Use the show running-config privileged EXEC command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries.
This command must be present in order for an interface to generate AppleTalk Enhanced IGRP Hello messages and routing updates.

Timer values are mismatched Step 1 Use the show appletalk eigrp neighbors EXEC command. 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 might be caused by a timer value mismatch or by hardware problems.
Step 3 Use 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 Hardware and Booting Problems" and the "Troubleshooting Serial Line Problems" chapters.

Step 4 Use the show running-config privileged EXEC command on all AppleTalk Enhanced IGRP routers in the network. 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 any routers have conflicting timer values, reconfigure them to conform 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.

Older version of the Cisco IOS software If problems persist, upgrade to the latest release of the Cisco IOS software.

Possible Problem	Solution
AppleTalk Enhanced IGRP is not globally configured on the appropriate routers	Step 1 Use the show running-config privileged EXEC command to check the configuration of routers that should be running Enhanced IGRP. Look for appletalk routing eigrp global configuration command entries. This command enables AppleTalk Enhanced IGRP routing on the router. Step 2 If AppleTalk Enhanced IGRP routing is not enabled on the router, use the appletalk routing eigrp router-id global configuration command to enable it. Make sure that the router ID is unique throughout the network. Step 3 Perform the same actions on other routers that should be running AppleTalk Enhanced IGRP. The router ID must be different for each router.
AppleTalk Enhanced IGRP is not enabled on interfaces	Use the show running-config privileged EXEC command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries. This command must be present in order for an interface to generate AppleTalk Enhanced IGRP Hello messages and routing updates.
Timer values are mismatched	Step 1 Use the show appletalk eigrp neighbors EXEC command. 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 might be caused by a timer value mismatch or by hardware problems. Step 3 Use 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 Hardware and Booting Problems" and the "Troubleshooting Serial Line Problems" chapters. Step 4 Use the show running-config privileged EXEC command on all AppleTalk Enhanced IGRP routers in the network. 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 any routers have conflicting timer values, reconfigure them to conform 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.
Older version of the Cisco IOS software	If problems persist, upgrade to the latest release of the Cisco IOS software.

AppleTalk Enhanced IGRP: Routes Missing from Routing Table

Symptom: Routes are missing from the routing table of routers running AppleTalk Enhanced IGRP. Clients (Macintosh computers) on one network cannot access servers on a different network. Clients might or might not be able to connect to servers on the same network. The problem might occur in internetworks running only Enhanced IGRP or in an internetwork running Enhanced IGRP and RTMP.

Table 7-13 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-13 : AppleTalk Enhanced IGRP: Routes Missing from Routing Table

Possible Problem Solution

Routers not establishing neighbors properly For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" earlier in this chapter.

AppleTalk Enhanced IGRP is not enabled on interfaces Use the show running-config privileged EXEC command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries.
This command must be present in order for an interface to generate AppleTalk Enhanced IGRP Hello messages and routing updates.

Older version of the Cisco IOS software If problems persist, upgrade to the latest release of the Cisco IOS software.

Possible Problem	Solution
Routers not establishing neighbors properly	For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" earlier in this chapter.
AppleTalk Enhanced IGRP is not enabled on interfaces	Use the show running-config privileged EXEC command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries. This command must be present in order for an interface to generate AppleTalk Enhanced IGRP Hello messages and routing updates.
Older version of the Cisco IOS software	If problems persist, upgrade to the latest release of the Cisco IOS software.

AppleTalk Enhanced IGRP: Poor Performance

Symptom: Network performance in an AppleTalk Enhanced IGRP environment is poor. Connections between clients and servers are slow or unreliable.

Table 7-14 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-14 : AppleTalk Enhanced IGRP: Poor Performance

Possible Problem Solution

AppleTalk Enhanced IGRP and RTMP are running simultaneously on the same interface Use the show running-config privileged EXEC command on network routers. Check the interface configurations to determine whether AppleTalk Enhanced IGRP and RTMP are both enabled on the same interface.
Running both AppleTalk Enhanced IGRP and RTMP on the same interface increases bandwidth and processor overhead. Determine whether both routing protocols need to be running on the interface and disable one or the other if necessary or desired.

Older version of the Cisco IOS software If problems persist, upgrade to the latest release of the Cisco IOS software.

AppleTalk Enhanced IGRP: Router Stuck in Active Mode

Symptom: An AppleTalk Enhanced IGRP router is stuck in Active mode. The router repeatedly sends error messages similar to the following to the console:

%DUAL-3-SIA: Route 2.24 Stuck-in-Active

Note Occasional messages of this type are not a cause for concern. This is how 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, you should investigate the problem.

For a more detailed explanation of Enhanced IGRP Active mode, see the section "Enhanced IGRP Active/Passive Modes" later in this chapter.

Table 7-15 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-15 : AppleTalk Enhanced IGRP: Router Stuck in Active Mode

Possible Problems Solution

Active timer value is misconfigured 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 1 Check the configuration of each Enhanced IGRP router using the show running-config privileged EXEC command. Look for the timers active-time router configuration command entry associated with the appletalk routing eigrp global configuration command entry.
Step 2 The value set by the timers active-time command should be consistent among routers in the same autonomous system. A value of 3 (3 minutes, the default value) is strongly recommended 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. Use the show appletalk eigrp neighbors EXEC command and examine the Uptime and Q Cnt (queue count) fields in the output.
Router#show appletalk eigrp neighbor
AT/EIGRP Neighbors for process 1, router id 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 200.41 Et0 10 0:00:37 0 3000 0 2

If the uptime counter is continually resetting or if the queue count is consistently high, there might be a hardware problem.

Step 2 Determine where the problem is 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 Hardware and Booting Problems" chapter.

Flapping route 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.
Take steps to reduce traffic on the link, or increase the bandwidth of the link.

Older version of the Cisco IOS software If problems persist, upgrade to the latest release of the Cisco IOS software.

Possible Problems	Solution
Active timer value is misconfigured	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 1 Check the configuration of each Enhanced IGRP router using the show running-config privileged EXEC command. Look for the timers active-time router configuration command entry associated with the appletalk routing eigrp global configuration command entry. Step 2 The value set by the timers active-time command should be consistent among routers in the same autonomous system. A value of 3 (3 minutes, the default value) is strongly recommended 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. Use the show appletalk eigrp neighbors EXEC command and examine the Uptime and Q Cnt (queue count) fields in the output. `Router#show appletalk eigrp neighbor` `AT/EIGRP Neighbors for process 1, router id 1` `H Address Interface Hold Uptime SRTT RTO Q Seq` `(sec) (ms) Cnt Num` `0 200.41 Et0 10 0:00:37 0 3000 0 2` If the uptime counter is continually resetting or if the queue count is consistently high, there might be a hardware problem. Step 2 Determine where the problem is 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 Hardware and Booting Problems" chapter.
Flapping route	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. Take steps to reduce traffic on the link, or increase the bandwidth of the link.
Older version of the Cisco IOS software	If problems persist, upgrade to the latest release of the Cisco IOS software.

Enhanced IGRP Active/Passive Modes

An Enhanced IGRP router can be in either Passive or Active mode. A router is said to be passive for a network when it has an established path to that network in its routing table.

If the Enhanced IGRP router loses the connection to a network, it becomes active for that network. The router sends out queries to all of its neighbors in order to find a new route to the network. 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 the network 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.

AURP: 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. Changes on the remote network (such as a route going down) are not learned by the exterior router on the other side of the tunnel.

Table 7-16 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-16 : AURP: Routes Not Propagated through AURP Tunnel

Possible Problems Solution

Misconfigured AURP tunnel Step 1 Use the show appletalk interfaces EXEC command to make sure the tunnel interface is up.
Step 2 Use the show running-config privileged EXEC command to view the router configuration. Check the tunnel source and tunnel destination interface configuration command entries.
Step 3 Exterior routers must have their tunnel interface configured with a tunnel source and a tunnel destination command. Make sure that the tunnel destination command on each router points to the IP address of the remote exterior router's tunnel interface.

Missing appletalk route-redistribution command Step 1 If changes on the remote network are not learned through the tunnel, use the show running-config privileged EXEC command to view the router configuration. Check for an appletalk route-redistribution global configuration command entry.
Step 2 If the command is not present, add it to the configuration.

Problem with underlying IP network If there are routing problems in the transit network (the IP network through which the AURP tunnel passes) then AppleTalk traffic might have difficulty traversing the tunnel.
To troubleshoot your TCP/IP network, follow the procedures outlined in the "Troubleshooting TCP/IP" chapter.

Possible Problems	Solution
Misconfigured AURP tunnel	Step 1 Use the show appletalk interfaces EXEC command to make sure the tunnel interface is up. Step 2 Use the show running-config privileged EXEC command to view the router configuration. Check the tunnel source and tunnel destination interface configuration command entries. Step 3 Exterior routers must have their tunnel interface configured with a tunnel source and a tunnel destination command. Make sure that the tunnel destination command on each router points to the IP address of the remote exterior router's tunnel interface.
Missing appletalk route-redistribution command	Step 1 If changes on the remote network are not learned through the tunnel, use the show running-config privileged EXEC command to view the router configuration. Check for an appletalk route-redistribution global configuration command entry. Step 2 If the command is not present, add it to the configuration.
Problem with underlying IP network	If there are routing problems in the transit network (the IP network through which the AURP tunnel passes) then AppleTalk traffic might have difficulty traversing the tunnel. To troubleshoot your TCP/IP network, follow the procedures outlined in the "Troubleshooting TCP/IP" chapter.

FDDITalk: No Zone Associated with Routes

Symptom: Routers on an FDDI ring have routes to networks across the ring but no zones are associated with the routes. The output of the show appletalk route command indicates "no zone set" for those routes.

Note On other media, routes with no zone set are the result of other problems, such as ZIP storms. See the sections "Zones Missing from Chooser" and "Network Services Intermittently Unavailable" in this chapter for more information.

Table 7-17 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-17 : FDDITalk: No Zone Associated with Routes

Possible Problems Solution

FDDITalk version mismatch If any routers in the internetwork are using software releases prior to Cisco IOS Release 10.0, there is a possibility of a FDDITalk version mismatch. Make sure that all routers on the ring are using either pre-FDDITalk or FDDITalk. There should not be a combination of the two.
Following are the FDDITalk implementations for each software release:

In software releases prior to 9.0(2), routers can only use pre-FDDITalk.

In software releases prior to Cisco IOS Release 10.0, routers will use the Apple implementation of FDDITalk by default.

However, if a pre-FDDITalk router exists on the FDDI network, routers will fall back to pre-FDDITalk. A router can be forced to use FDDITalk with the no appletalk pre-fdditalk interface configuration command.

In Cisco IOS Release 10.0 and later, the default is to use the Apple implementation of FDDITalk.

However, you can force a router to use pre-FDDITalk with the appletalk pre-fdditalk interface configuration command.

Possible Problems	Solution
FDDITalk version mismatch	If any routers in the internetwork are using software releases prior to Cisco IOS Release 10.0, there is a possibility of a FDDITalk version mismatch. Make sure that all routers on the ring are using either pre-FDDITalk or FDDITalk. There should not be a combination of the two. Following are the FDDITalk implementations for each software release: In software releases prior to 9.0(2), routers can only use pre-FDDITalk. In software releases prior to Cisco IOS Release 10.0, routers will use the Apple implementation of FDDITalk by default. However, if a pre-FDDITalk router exists on the FDDI network, routers will fall back to pre-FDDITalk. A router can be forced to use FDDITalk with the no appletalk pre-fdditalk interface configuration command. In Cisco IOS Release 10.0 and later, the default is to use the Apple implementation of FDDITalk. However, you can force a router to use pre-FDDITalk with the appletalk pre-fdditalk interface configuration command.

ARA: ARA Client Unable to Connect to ARA Server

Symptom: An ARA client (such as a Macintosh) attempts to connect to an ARA server (such as a Cisco access server) and cannot initiate a remote session. The user might be able to connect briefly but the connection is immediately terminated.

Table 7-18 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-18 : ARA: ARA Client Unable to Connect to ARA Server

Possible Problems Solution

Missing arap network command entry Step 1 Use the show running-config privileged EXEC command to view the router configuration. If you are running Cisco Internetwork Operating System (Cisco IOS) Release 10.2 or later, look for an arap network global configuration command entry.
Step 2 Configure the arap network global configuration command to enable ARA on the router or access server.

AppleTalk routing is not enabled on the appropriate interfaces Step 1 Use the show apple interfaces EXEC command to determine if interfaces are operational and if AppleTalk routing is enabled on the correct interfaces.
Step 2 If AppleTalk routing is not enabled on the proper interfaces, enable it where appropriate. Refer to the Cisco IOS Network Protocols Configuration Guide, Part 1 for detailed information on configuring an interface for AppleTalk routing.

Modem, serial line, or hardware problems For serial line troubleshooting information, see the "Troubleshooting Serial Line Problems" chapter. For modem troubleshooting information, see the "Troubleshooting Dialin Connections" chapter. For hardware troubleshooting information, see the "Troubleshooting Hardware and Booting Problems" chapter.

Possible Problems	Solution
Missing arap network command entry	Step 1 Use the show running-config privileged EXEC command to view the router configuration. If you are running Cisco Internetwork Operating System (Cisco IOS) Release 10.2 or later, look for an arap network global configuration command entry. Step 2 Configure the arap network global configuration command to enable ARA on the router or access server.
AppleTalk routing is not enabled on the appropriate interfaces	Step 1 Use the show apple interfaces EXEC command to determine if interfaces are operational and if AppleTalk routing is enabled on the correct interfaces. Step 2 If AppleTalk routing is not enabled on the proper interfaces, enable it where appropriate. Refer to the Cisco IOS Network Protocols Configuration Guide, Part 1 for detailed information on configuring an interface for AppleTalk routing.
Modem, serial line, or hardware problems	For serial line troubleshooting information, see the "Troubleshooting Serial Line Problems" chapter. For modem troubleshooting information, see the "Troubleshooting Dialin Connections" chapter. For hardware troubleshooting information, see the "Troubleshooting Hardware and Booting Problems" chapter.

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

Symptom: An 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 7-19 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-19 : ARA: Connection Hangs after "Communicating At..." Message

Possible Problems Solution

MNP4 Link Request packets sent by client ARA stack are 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 or Cisco IOS software prior to Release 10.2, 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 you cannot 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¹ pause before exiting. Configure an additional delay that takes into account the behavior of the serving modem.

¹ ms=millisecond

Possible Problems	Solution
MNP4 Link Request packets sent by client ARA stack are 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 or Cisco IOS software prior to Release 10.2, 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 you cannot 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¹ pause before exiting. Configure an additional delay that takes into account the behavior of the serving modem.

ARA: Cannot Send or Receive Data over ARA Dialin Connection

Symptom: ARA connections are established but users cannot send or receive ARA data over the link.

Table 7-20 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-20 : ARA: Cannot Send or Receive Data over ARA Dialin Connection

Possible Causes Suggested Actions

Missing arap network command entry Step 1 Use the show running-config privileged EXEC command to view the router configuration. If you are running Cisco Internetwork Operating System (Cisco IOS) Release 10.2 or later, look for an arap network global configuration command entry.
Step 2 Configure the arap network global configuration command to enable ARA on the router or access server.

Missing autoselect command Step 1 Use the show running-config privileged EXEC command to view the router configuration. Check to see if the autoselect arap line configuration command is configured on the router.
Step 2 If the command is not present, add it to the configuration.

MNP5 enabled on answering modem Step 1 Check to see if the answering modem has MNP5 error correction enabled.
Step 2 If MNP5 is enabled on the answering modem, disable it. For information on checking or changing the modem configuration, refer to the modem documentation.

Zone list is empty Step 1 Use the show appletalk route and show appletalk zones privileged EXEC commands to see if the router can see its ARA routes and zones.
Step 2 Use the show appletalk interface ethernet EXEC command and make sure that the output matches your Apple network parameters.
Step 3 Change the interface configuration as required.

TACACS problem For information on troubleshooting TACACS problems, refer to the "Troubleshooting Security Implementations" chapter.

Possible Causes	Suggested Actions
Missing arap network command entry	Step 1 Use the show running-config privileged EXEC command to view the router configuration. If you are running Cisco Internetwork Operating System (Cisco IOS) Release 10.2 or later, look for an arap network global configuration command entry. Step 2 Configure the arap network global configuration command to enable ARA on the router or access server.
Missing autoselect command	Step 1 Use the show running-config privileged EXEC command to view the router configuration. Check to see if the autoselect arap line configuration command is configured on the router. Step 2 If the command is not present, add it to the configuration.
MNP5 enabled on answering modem	Step 1 Check to see if the answering modem has MNP5 error correction enabled. Step 2 If MNP5 is enabled on the answering modem, disable it. For information on checking or changing the modem configuration, refer to the modem documentation.
Zone list is empty	Step 1 Use the show appletalk route and show appletalk zones privileged EXEC commands to see if the router can see its ARA routes and zones. Step 2 Use the show appletalk interface ethernet EXEC command and make sure that the output matches your Apple network parameters. Step 3 Change the interface configuration as required.
TACACS problem	For information on troubleshooting TACACS problems, refer to the "Troubleshooting Security Implementations" chapter.

ARA: Slow Performance from Dialin Connection

Symptom: Performance on remote dialin Apple Remote Access (ARA) sessions is slow.

Table 7-21 outlines the problems that might cause this symptom and describes solutions to those problems.

Table 7-21 : ARA: Slow Performance from Dialin Connection

Possible Problems Solution

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. Hardware flow control is recommended for access server-to-modem connections.

For example, to configure hardware flow control on line 2 of an access server, enter the following commands:

C2500(config)# line 2

C2500(config-line)# flowcontrol hardware

Note: If you cannot use flow control, limit the line speed to 9600 bps. Faster speeds can 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 instructions on initiating a reverse Telnet session, see the section "Establishing a Reverse Telnet Session to a Modem" in the "Troubleshooting Dialin Connections" chapter.

Step 3 Use 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 about troubleshooting access server-to-modem connections, see the "Troubleshooting Dialin Connections" chapter. For information on troubleshooting hardware problems, see the "Troubleshooting Router Hardware Problems" chapter.

Possible Problem	Solution
AppleTalk Enhanced IGRP and RTMP are running simultaneously on the same interface	Use the show running-config privileged EXEC command on network routers. Check the interface configurations to determine whether AppleTalk Enhanced IGRP and RTMP are both enabled on the same interface. Running both AppleTalk Enhanced IGRP and RTMP on the same interface increases bandwidth and processor overhead. Determine whether both routing protocols need to be running on the interface and disable one or the other if necessary or desired.
Older version of the Cisco IOS software	If problems persist, upgrade to the latest release of the Cisco IOS software.

Table of Contents