Troubleshooting AppleTalk

Although AppleTalk is a proprietary network, Apple has published AppleTalk specifications in an attempt to encourage third-party development. Today, many companies---including Novell, Inc., and Microsoft Corporation---are successfully marketing AppleTalk-based products.

The main function of AURP is to maintain accurate routing tables for the entire AppleTalk WAN by the exchange of routing information between exterior routers. In addition, AURP encapsulates AppleTalk data packets with the headers required by the foreign network.

At the destination exterior router, the AURP module removes the headers required by the foreign system from the AURP packets and sends AppleTalk data packets to their final destination. The exterior router uses the AURP packets that contain routing information to update its routing information tables but does not propagate that information to any other exterior router.

ATP is capable of most important transport-layer functions, including data acknowledgment and retransmission, packet sequencing, and fragmentation and reassembly. ATP limits message segmentation to eight packets, and ATP packets cannot contain more than 578 data bytes.

It consists of information on preventing AppleTalk problems, preventing internetwork reconfiguration problems, changing zone names, using AppleTalk Discovery Mode, and forcing an interface up to allow a router to start functioning if the network is misconfigured.

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. The syntax for the nbp confirm command is as follows:

The syntax description is as follows:

• appletalk-address---AppleTalk network address in the form network.node. The argument network is the 16-bit network number in the range 1 to 65279. The argument node is the 8-bit node number in the range 0 to 254. Both numbers are decimal.

• :skt---(Optional) Name of socket.

• object:type---Name of device and the type of service. The colon (:) between object and type is required.

• @zone---Name of the AppleTalk zone where the entity object:type resides.

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 following display shows input to and output from the user ping command:

Router> ping appletalk 2.24
Type escape sequence to abort.
Sending 5, 100-byte AppleTalk Echoes to 2.24, timeout is 2 seconds:
!!!!!
Success rate is 100 percent, round-trip min/avg/max = 4/4/8 ms

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

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

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.

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

The following steps outline bringing up an interface in discovery mode:

Step 1 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 lets you know when the discovery process is complete by displaying an "operational" message.

Step 2 After discovery is complete, and while in interface configuration mode, enter the no appletalk discovery interface configuration command for the specific AppleTalk interface being initialized. This saves the acquired information and forces the configuration to be validated at port startup.

Step 3 Use the copy running-config startup-config privileged exec command to save the acquired information to nonvolatile RAM (NVRAM).

Step 4 Verify the configuration with the show running-config privileged exec command.

The appletalk ignore-verify-errors command allows you to bypass the default behavior of an AppleTalk interface. By default, the AppleTalk interface does 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.

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 "mismatch" 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 whether 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 cable-range 0-0 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 destinations. 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 NBP1 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.

1NBP = Name Binding Protocol

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 does not allow AppleTalk to become operational on that interface. Cisco routers attempt to restart such an interface every two 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 continues to operate on that interface until the interface is reset. At that point, the interface fails to become active. When the show appletalk interface exec command is issued, the router indicates a port configuration mismatch.

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

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

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 "mismatch" 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 whether 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 cable-range 0-0 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 RTMP1 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. The following example is output from the show interfaces command: 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 [...]
Route flapping (unstable route)	The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. Step 2 If the load is less than 50%, 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%, 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 Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. 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. The following example is output from the show appletalk traffic command: Router#sh apple traffic [...] ZIP: 44 received, 35 sent, 6 netinfo [...] Router# Compare this output with the output 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 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.
ZIP storm	For example, you can use the show appletalk route exec command to view the AppleTalk routing table. Check whether 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.

1RTMP = Routing Table Maintenance Protocol

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
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 destinations. 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. The following example is output from the show interfaces command: 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 [...] The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. Step 2 If the load is less than 50%, 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%, 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 The debug apple events command is useful for solving AppleTalk network problems because it provides an overall picture of the stability of the network. In a stable network, the debug apple events command does not return any information. If, however, the command generates numerous messages, the messages can indicate where the problems might lie.
Route flapping (unstable route)	Turning on debug apple events will not cause apple event-logging to be maintained in nonvolatile memory. Only turning on apple event-logging explicitly will store it in nonvolatile memory. Furthermore, if apple event-logging is already enabled, turning on or off debug apple events will not affect apple event-logging. Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. 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.
ZIP storm	Step 1 Use the show appletalk traffic command to check the field showing the number of ZIP requests: Router#sh apple traffic [...] ZIP: 44 received, 35 sent, 6 netinfo [...] Router# Compare this output with the output 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 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 whether 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
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 "mismatch" 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 whether all router configurations agree on 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 cable-range 0-0 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.

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. The following example is output from the show interfaces command: 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 [...] The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes. Step 2 If the load is less than 50%, 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%, 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
Route flapping (unstable route)	Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. 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
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 "mismatch" 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 whether all router configurations agree on 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 con- figuration command appletalk address 0.0 on a nonextended network or the appletalk cable-range 0-0 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.

Possible Problems	Solution
Router is in discovery mode, and no seed router exists on the network	Step 1 Put the router in nondiscovery 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 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. By default, AppleTalk RTMP routes are automatically redistributed into enhanced IGRP, and AppleTalk enhanced IGRP routes are automatically redistributed into RTMP. 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
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 whether the interface and line protocol are up. Look for high numbers in the queue fields and excessive drop counts. The queue fields displays the maximum size of the queue and the number of packets dropped due to a full queue. If there are many drops, if the queue count is high, or if the interface or line protocol is down, there is probably something wrong with the interface or other hardware. For more information on troubleshooting hardware, see Chapter 3,"Troubleshooting Hardware and Booting Problems," and Chapter 15, "Troubleshooting Serial Line Problems." 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
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
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.

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

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 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 times out and causes 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. The following example is output from the show appletalk eigrp neighbor command: 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. The uptime counter is the elapsed time, in hours, minutes, and seconds, since the local router first heard from this neighbor. Step 2 Determine where the problem is by looking at the output of the "Stuck-in-Active" error message, which indicates 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 Chapter 3, "Troubleshooting Hardware and Booting Problems."
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.

If the Enhanced IGRP router loses the connection to a network, it becomes active for that network. The router sends out queries to all 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 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.

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 Chapter 7, "Troubleshooting TCP/IP."

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 and 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 use only pre-FDDITalk. In software releases prior to Cisco IOS Release 10.0, routers use the Apple implementation of FDDITalk by default. However, if a pre-FDDITalk router exists on the FDDI network, routers 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
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 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. The syntax for the arap network command is as follows: arap network [network-number] [zone-name] Syntax Description: network-number---(Optional) The AppleTalk network number. The network number must be unique on your AppleTalk network. This network is where all ARAP1 users appear when they dial in to the network. zone-name---(Optional) The AppleTalk zone name.
AppleTalk routing is not enabled on the appropriate interfaces	Step 1 Use the show apple interfaces exec command to determine whether interfaces are operational and whether AppleTalk routing is enabled on the correct interfaces. Step 2 If AppleTalk routing is not enabled on the proper interfaces, 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 Chapter 15, "Troubleshooting Serial Line Problems." For modem troubleshooting information, see Chapter 16, "Troubleshooting Dialin Connections." For hardware troubleshooting information, see Chapter 3, "Troubleshooting Hardware and Booting Problems."

1ARAP = AppleTalk Remote Access Protocol

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 no longer listens 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.

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 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. The syntax for the arap network command is as follows: arap network [network-number] [zone-name] Syntax Description: network-number---(Optional) The AppleTalk network number. The network number must be unique on your AppleTalk network. This network is where all ARAP users appear when they dial in to the network. zone-name---(Optional) The AppleTalk zone name.
Missing autoselect command	Step 1 Use the show running-config privileged exec command to view the router configuration. Check to see whether 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 whether 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 determine whether 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.
TACACS1 problem	For information on troubleshooting TACACS problems, refer to Chapter 24, "Troubleshooting Security Implementations."

1TACACS = Terminal Access Controller Access Control System

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 Chapter 16, "Troubleshooting Dialin Connections." 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 Chapter 16, "Troubleshooting Dialin Connections." For information on troubleshooting hardware problems, see Chapter 3, "Troubleshooting Hardware and Booting Problems."