This chapter presents protocol-related troubleshooting information for AppleTalk connectivity problems. The emphasis here is on symptoms and problems associated with AppleTalk network connectivity.
This chapter consists of the following sections:
- Introductory troubleshooting information, including brief definitions of key AppleTalk terms, several diagnostic hints, and summary of the most common AppleTalk internet problems
- An overview of problem prevention techniques
- Summary of AppleTalk symptoms
- Symptom/problem/action modules
The symptom/problem/action modules consist of the following sections:
- Symptom statement--A specific symptom associated with the technology/media/protocol in which this module appears.
- Possible causes and suggested actions--For each symptom, a table containing possible causes for the symptom and suggested actions for resolving each cause.
The following discussion establishes a framework for discussing AppleTalk internetworking problems. For the purposes of this document, subsequent descriptions adhere to these general rules.
It is difficult to distinguish problems that occur on a single cable segment versus those on an entire enterprise network without making an explicit distinction between networks and internets. For this discussion, an internet refers to the entire collection of networks connected via internet routers. Networks are individual networks as defined by their associated, unique Appletalk network numbers or cable ranges.
There is often confusion over the use of the terms Phase 1 and Phase 2 in Appletalk. Cisco refers to routers as being Phase 1 or Phase 2 with respect to their ability to support the Appletalk Phase 2 enhancements. Cisco routers dynamically determine whether their neighbors are Phase 2 compliant or not, and operate in Phase 1 compatibility mode if necessary. Most routers currently offered are Phase 2 routers. Older routers that have not been upgraded may be Phase 1 routers.
Note Some routers can be configured for Phase 1, Phase 2, or
transition support. Cisco recommends that routers be configured for Phase 2 at the earliest opportunity, subject to limitations in software (such as routers not allowing nonextended Ethernet configurations for Phase 2). Cisco recommends against the use of
transition mode, which is an interim solution at best. Transition mode implementations can be avoided by using enhancements available in Cisco routers.
To describe a network or interface, Cisco uses the terms nonextended and extended. An extended network is one that can contain multiple consecutive network numbers (in other words, a cable range). A nonextended network is one that contains a single network number (such as network 2). Nonextended networks use ARPA (Ethernet Type II) encapsulation on Ethernet. Extended networks use SNAP encapsulation. In addition, FDDI, Token Ring, and most other new media use SNAP encapsulation. An extended network does not require use of multiple network numbers (in other words, 3-3 is a valid extended cable range).
Note As a further point of clarification, there are no inherent problems in transporting traffic from extended networks across nonextended networks (a common misconception). However, there are certain implementation
rules that apply to internets featuring both Phase 1 and Phase 2 routers. These rules are discussed later in this chapter.
Internetworks based on the AppleTalk networking protocol suite can encompass complex environments. The fact that they have been designed to make life easier for users does not necessarily make them easier to administer. Before exploring specific symptoms, the following discussions outline some hints and suggestions for AppleTalk internet troubleshooters.
There are two general rules to remember when setting up an AppleTalk internetwork:
- Every router connected to a specific network must agree on that network's configuration (here, network refers to a single cable segment).
- Every network number on an internetwork must be unique.
This chapter is primarily organized around symptoms. In subsequent symptom modules, a list of known possible causes and suggested actions is provided based on a identifiable symptoms. However, many of the most common problems can result in a variety of symptoms. The following discussion covers some the most common problems associated with AppleTalk internets.
The problems summarized here include the following:
- Configuration mismatch
- Duplicate network numbers
- Phase 1/Phase 2 rule violations
- ZIP storms
- Access list errors
- Unstable routes
- Unexpected back doors
These descriptions outline the general nature of each problem and provide some diagnostic notes. Specific actions associated with each problem are detailed in the symptom modules that include these problems as likely causes.
Note The problems that follow certainly do not represent all known AppleTalk internetworking problems. Indeed, this is only a small subset of potential pitfalls. However, they do represent many of the problems most commonly encountered when creating, upgrading, or modifying AppleTalk internets.
A configuration mismatch occurs when the following golden rule of Appletalk is violated:
- All routers on a given cable must agree on the configuration of that cable (meaning that all must have matching network numbers, cable ranges, zone names, and/or zone lists).
To protect against configuration errors in which this rule is violated, many vendors (including Cisco) block activation of any port on which a violation of this rule exists. At interface initialization, if other routers on the network are not in agreement with the way a Cisco router is configured, the Cisco router will not allow AppleTalk to become operational on the interface where a disagreement exists. Cisco routers attempt to restart such an interface every two minutes to avoid outages resulting from transient conditions.
However, if the router is already operational, and another router becomes active whose configuration does not match, the router will continue to operate on that interface until it is restarted. At that point, the interface will fail to become active, and the router will declare a port configuration mismatch in show appletalk interface.
Figure 3-1 illustrates a typical example of the show appletalk interface display showing the net.node address of the device with which the router disagrees.
Figure 3-1: Example Show AppleTalk Interface Display Illustrating Port Mismatch
In Software Release 9.0 and higher, an option is available to display the Name Binding Protocol (NBP) registered name of the conflicting router. This can simplify resolution of a port mismatch problem.
To obtain registered NBP names,enable the appletalk name-lookup-interval global configuration command. If enabled, the show appletalk interfaces command will display nodes by NBP registration name if available. Refer to your Router Products Configuration and Reference publication for more information.
A very important rule in Appletalk is that network numbers must be unique within an internet, because they comprise the postal-code used to route packets. If duplicate network numbers exist, some packets will not be routed to their intended destinations and will be lost or misdirected. In addition, duplicate network numbers can cause connectivity and performance problems.
When Phase 1 and Phase 2 routers are in the same internet, the internet specifications must conform with two mandatory rules:
- There can be no "wide" cable range specifications in the Phase 2 extended portion of the internet. In other words, all cable ranges must span no more than one network number. Examples of acceptable cable ranges in this situation are 9-9, 20-20, and 2-2.
- Multiple zones cannot be assigned to cable ranges.
If these internet compatibility rules are not followed, connectivity between the nonextended and extended portions of an internetwork will be degraded or even lost. In particular, services located on nonextended networks serviced by Phase 1 routers will not be visible on the other side of the Phase 1 router.
A key difference between Phase 1 and Phase 2 is the way the Name Binding Protocol (NBP) works. This difference can lead to communication problems between Phase 1 and Phase 2 routers. There are four different types of NBP packets in Phase 2 AppleTalk and three in Phase 1. This difference is a point of much confusion in AppleTalk internetworks that support both Phase 1 and Phase 2. Table 3-1 lists the NBP packet types for AppleTalk Phase 1 and Phase 2.
Comparison of Phase 1 and Phase 2 NBP Packet Types
| Phase 1 NBP Packet
| Phase 2 NBP Packet
|
|---|
| BrRq (Broadcast Request)
| BrRq (Broadcast Request)
|
| LkUp (Lookup)
| LkUp (Lookup)
|
|
| FwdReq (Forward Request)
|
| LkUp-Reply (Lookup Reply)
| LkUp-Reply (Lookup Reply)
|
As shown in Table 3-1, Forward Request (FwdReq) packets do not exist in Phase 1. Only Phase 2 routers will know what to do with them. Phase 1 routers that receive FwdReq packets quietly drop them.
Note It is important to remember that just because a router is configured for nonextended networks
does not mean it is a Phase 1 router. A Cisco router running 8.2 software or higher is a Phase 2-compliant router
regardless of how the interfaces are configured.
Routers use the Zone Information Protocol (ZIP) to exchange zone information, and end systems use it to acquire zone lists. Note that there is no mechanism in AppleTalk to force routers to update zone lists. Once a zone has been acquired, routers do not make a ZIP request again unless the network has aged out of the routing table for some reason. As a result, you must use care when adding or removing zone names from an active network.
A ZIP storm occurs when a router has propagated a route for which it currently has no corresponding zone name. When the downstream routers also propagate this route, a ZIP storm will ensue.
Question: How do you know when you have a ZIP storm in progress?
Answer: You will see the AppleTalk traffic counters for the ZIP requests increment very rapidly (show appletalk traffic). Use the debug apple-zip command to identify the network for which the zone is being requested by neighboring routers.
 | Caution Throughout this publication, the use of debug commands is suggested for obtaining information about network traffic and router status. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internets are experiencing high load conditions. In addition, when you have finished using a debug command, remember to disable it with the specific undebug command or the undebug all command. |
Question: How can you correct a ZIP storm?
Answer: The best plan is to configure your internetwork so that you prevent ZIP storms. Use of Software Release 9.0(1) or later on Cisco routers will help provide a firewall against ZIP storms in your internetwork. A ZIP storm will not propagate beyond a Cisco router running Software Release 9.0(1) or later. If a Cisco router receives a routing update from a neighbor, it does not propagate that new route any further until it has received the zone name for it.
However, if you determine that a ZIP storm is occurring, you must search for the router that injected the network number into the internetwork (and that is causing the excessive ZIP traffic). The router commands show appletalk traffic and show appletalk route provide information that can help you find suspect nodes. Once you have found an offending node, you must stop it from propagating invalid routes. This may require you to upgrade the node's software.
If properly used, access lists can provide a powerful way to control traffic and limit access to resources on an AppleTalk network. However, if not properly implemented, access lists can lead to a number of failures on your internet. Typical problem symptoms associated with incorrectly specified access lists include services for a particular network not being visible to other networks, zones missing from users' Choosers, and services being visible on Choosers but not being accessible.
On very busy internetworks with many routers, it is possible that some routers will fail to send RTMP updates every 10 seconds as they should (due to the excessive load). This results in unnecessary route changes because routes begin to be aged out once two successive RTMP updates have been lost. If severe enough, zones may fade in and out of the Chooser or exhibit other unpredictable behavior. Route instability associated with load problems is known as flapping.
Unexpected Back Door
A back door is any unexpected path or route through an internetwork. The existence of a back door can result from a number of different events: IP gateways establishing a DDP/IP link unexpectedly; bridges being installed without notice; or even users connecting networks with dial-up connections. Back doors typically cause a change in performance over the internetwork and/or connectivity problems. Performance problems usually occur because all traffic between two sites is going through a lower-bandwidth circuit, or because all traffic is being sent through a single gateway. Connectivity problems can result when routing loops form, or duplicate network numbers are introduced.
Table 3-2 provides a list of suggestions intended to help reduce problems when configuring a router for AppleTalk.
AppleTalk Problem Prevention Suggestions
| Preventive Action
| Comments
|
|---|
| Upgrade to Phase 2 wherever possible.
| This is not a simple task (as it is often described), but is well worth the effort. Pay special attention to upgrading all routers to the same (and most recent default) software version. This will minimize interoperability problems.
|
| When configuring (or making changes to) a router or interface for AppleTalk, enable the command debug apple-events.
| This command tracks the progress and status of changes in the internet and alerts you to any errors. You also should run this debug periodically when you suspect network problems.However, in a stable network, this command does not return any information. Remember to disable this debug command with the undebug apple-events command when you have completed diagnostic activities.
You may want to consider adding the configuration command appletalk event-logging and establishing a syslog server at your site. This will keep a running log, with timestamps, of significant events on your network.
|
| When changing a zone name to an existing network:
Step 1: Take all routers for that cable off line for at least 10 minutes. This allows all routers in the internet to age out the network number from their routing tables.
Step 2: Configure the new zone list
Step 3: Bring the routers back on line.
| These actions are recommended because AppleTalk makes no provisions for informing neighbors in the internetwork about a new zone name. Routers only make ZIP queries when a new or previously aged-out network appears on the internet.
Adding a new zone to an extended cable configuration will normally result in the router shutting down its interface for Appletalk; its configuration no longer matches that of its neighbors, resulting in a configuration mismatch error.
|
| Use the appletalk timers global configuration command in busy networks with large numbers of internet routers on a single network.
| On very busy networks with many LocalTalk-to-EtherTalk routers, the LocalTalk Link Access Protocol (LLAP) routers may not send RTMP updates every 10 seconds as they should. This results in unnecessary route flapping. Suggested value to start: apple timers 10 30 90. The first number should always be 10, and the third number should always be three times the second value. However, setting the second and third numbers to excessively high values can result in slow routing convergence when network topology changes.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
| Minimize the number of different zones in the internet.
| Give all of the backbone/WAN connections the same zone name (such as WanZone) or have WAN connections share the zone name of the smaller of the two sites that it connects.
In most internetworks, it is not desirable to have the zone names for all backbone or WAN connections appear in the Chooser list. If you make the zone name of all the WAN links the same (WanZone), only that entry appears in the Chooser menu.
|
| Design your network with special attention to the direction in which user/application traffic will flow.
| Careful design of the zone mapping can minimize unnecessary NBP traffic. Note that in System 6, if a user opens the Chooser, the Macintosh continually sends NBP BrReq packets. In System 7, Apple has modified this behavior with a logarithmic backoff to minimize the amount of traffic generated.
Taking this action can be particularly important in wide area networks (WANs) where traffic traversing WAN links (such as X.25) can be quite expensive.
|
| Zones should be named for the convenience of end users and not for diagnostic purposes.
| Zones should not be used as cable labels (in other words, do not identify one zone per cable with names like "Bld2 S/W Serial T1"). In general, a mixture of location and departmental naming conventions works best (for example, "Bldg 13 Engineering").
|
| Control the number of zones used.
| Many routers have specific limits on the number of routes and zones they can handle. These limits usually result from memory constraints, but are sometimes fixed limits. If you exceed such a limit on a cable connected to one of these devices, zones may come and go unpredictably. Cisco routers do not impose fixed limits.
|
When bringing a router up on an existing cable where a long zone list is defined, the following actions will help you avoid mistakes and save effort.
- Bring the interface up in discovery mode--debug apple-events will let you know when the process is complete. At that time, you will see the following message:
operational.
- After discovery is completed, and while in configuration mode, enter the no appletalk discovery command for the specific AppleTalk interface being initialized. This action allows the acquired information to be saved and requires that the configuration be validated at port startup. The router exits out of discovery mode for normal operation (it is recommended that discovery mode only be used when initially configuring networks). Thereafter, all routers should be configured for seed, or nondiscovery, mode.
- Issue a write memory to save the acquired information to nonvolatile RAM.
- Verify the configuration with show configuration.
It is common to create configuration conflicts when changing zone names or cable range numbers. In particular, problems arise when routers exist on the internet about which you are not (administratively) aware.
Remember that many devices can act as routers (for example, Pathworks servers or UNIX workstations running CAP to do print sharing and/or file sharing). In general, if you are changing zone names or cable range numbers in your internetwork, all routers should be shut down or a Cisco router will see a conflict and prevent AppleTalk from initializing on the interface.
Use a network analyzer to listen for router traffic, shut down all routers, wait 10 minutes, and bring up the master seed router.
The following suggestions from router technical support representatives are offered to help speed problem diagnosis and ensure efficient data gathering in the event of failures.
- The diagnostic command debug apple-events is completely silent in a stable network. If it results in any output, unnecessary changes are occurring on the internetwork. You can continuously log the output from this command to a syslog daemon on a UNIX host to monitor the internetwork for configuration and status changes.
| Caution Throughout this publication, the use of debug commands is suggested for obtaining information about network traffic and router status. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internets are experiencing high load conditions. In addition, when you have finished using a debug command, remember to disable it with the specific undebug command or the undebug all command. |
- To identify problem nodes, you can run ping tests with a one-line command. For example, ping 2.24 will ping AppleTalk node 2.24. Use this command to verify that the node is reachable from the router. The ping command also supports a number of AppleTalk variable parameters.
The NBP option of the AppleTalk ping function provides additional troubleshooting capabilities. In particular, use the NBP option when you find that AppleTalk zones are listed in the Chooser, but services are not available. In addition the NBP features (implemented as of Software Release 9.0) display nodes by NBP registration name, if enabled using the appletalk name-lookup-interval command. Refer to your Router Products Configuration and Reference publication for more information.
The symptom modules that follow pertain to AppleTalk internetwork problems. Unless otherwise indicated, each module is presented as a set of general problems. Where there are special considerations associated with a situation, notes are included.
AppleTalk connectivity symptoms discussed in this section include the following:
- Users cannot see zones or services on remote networks
- Services in a network are not visible outside that network
- Users cannot access services on remote networks
- Zones are missing from Choosers of Macs
- Services not always available; fade in and out
- Services visible, but users cannot connect
- Zone list changes each time Chooser is opened
- Connection to services drop
- Port seems stuck in acquiring mode
- Old zone names still appear in Chooser
Symptom: Although users are able to access services on their own network, offnet zones and services expected to be available from their Chooser lists are not accessible.
Table 3-3 outlines possible causes of blocked access to offnet zones and network resources.
Causes and Actions for Blocked Access to Offnet Resources
| Possible Cause
| Suggested Actions
|
|---|
| Configuration mismatch
| Step 1: From the router, perform show appletalk interface.
|
|
| Step 2: Look for "port configuration mismatch" message; indicates that the configuration disagrees with listed neighbor.
|
|
| Step 3: If no error is displayed, execute the clear interface command for the interface in question. If it becomes operational after clearing, a configuration mismatch does not exist. If it declares "port configuration mismatch," continue with the steps that follow.
|
|
| Step 4: Verify that configuration for each router agrees regarding network number or cable range and the zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its seed information from the network (put the router in discovery mode by specifying appletalk address 0.0).
|
|
| Step 5: If they do not agree, modify configurations of the other routers as necessary.
|
|
| Step 6: If the problem persists, try to determine which router is at fault.
|
|
| The show appletalk interface command will generate the network and node address of the conflicting router.
|
|
| If appletalk name-lookup-interval is enabled, the NBP registration name will be displayed.
|
|
| If you are unable to identify the misconfigured router using the node address, determine the hardware address of the conflicting router with show appletalk arp. This also allows you to determine the vendor code (vendor codes are available in RFC 1340).
|
|
| Step 7: As an alternative, all routers but one can be configured for nonseed or discovery mode, then routers can be restarted.
|
Symptom: Users find that the AppleTalk services for a particular network do not appear in their Choosers.
Table 3-4 outlines possible causes of missing network services.
Causes and Actions for Missing Services
| Possible Cause
| Suggested Actions
|
|---|
| Configuration mismatch
| Step 1: From the router, perform show appletalk interface.
|
|
| Step 2: Look for "port configuration mismatch" message; indicates that the configuration disagrees with listed neighbor.
|
|
| Step 3: If no error is displayed, execute the command clear interface for the interface in question. If it becomes operational after clearing, a configuration mismatch does not exist. If it declares "port configuration mismatch," continue with the steps that follow.
|
|
| Step 4: Verify that configuration for each router agrees regarding network number or cable range and the zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its seed information from the network (put the router in discovery mode by specifying appletalk address 0.0).
|
|
| Step 5: If they do not agree, modify configurations of the other routers as necessary.
|
|
| Step 6: If the problem persists, try to determine which router is at fault.
|
|
| The show appletalk interface command will generate the network and node address of the conflicting router.
|
|
| If appletalk name-lookup-interval is enabled, the NBP registration name will be displayed.
|
|
| If you are unable to identify the misconfigured router using the node address, determine the hardware address of the conflicting router with show appletalk arp. This also allows you to determine the vendor code (vendor codes are available in RFC 1340).
|
|
| Step 7: As an alternative, all routers but one can be configured for nonseed or discovery mode, then the routers can be restarted.
|
| Duplicate network numbers
| Step 1: The network where these symptoms are noticeable is likely to contain a duplicate network number.
|
|
| Either change the network number of the afflicted network or remove Appletalk from the suspect/problem interface. In either case, the interface's original network number should disappear from the internet within a few minutes. If it persists, you probably have found the duplicate network.
|
|
| Step 2: If you changed the network number on the interface, no further action is required. If not, change it now (make sure it is unique). Remember to reenter the zone name and any other interface configurations for Appletalk on that interface.
|
| Phase 1/Phase 2 rule violations
| Step 1: Use show appletalk global to determine whether or not the internet is in compatibility mode.
|
|
| Step 2: Use show appletalk neighbor to determine which specific neighbor is in compatibility mode (if appletalk name-lookup-interval is enabled, shown by NBP name).
|
|
| Step 3: Select one of three solutions:
|
|
|
- Ensure that all routers are in compliance with the two Phase 1/Phase 2 rules.
|
|
|
- Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 compliance and reconfigure the internet.
|
|
|
- Use appletalk proxy-nbp feature.
|
|
| To use appletalk proxy-nbp, you must create at least one virtual network on the router that has the same zone name as the network where the unreachable services exist. This forces the router to use Phase 1-type NBP lookups (in addition to Phase 2-style FwdRequests) when sending NBP requests through the network. Since the Lookup is defined for Phase 1 routers, the Phase 1 router will properly route the request on to the service and a reply should be received. Refer to the Router Products Configuration and Reference publication for a more information.
|
| Access list errors
| Step 1: Carefully disable access lists on suspect routers and see whether connectivity returns.
|
|
| Step 2: If connectivity returns, access list error is likely suspect. Check access lists and associated configuration commands for errors.
|
|
| Step 3: Modify any access lists as necessary.
|
|
| Step 4: If connection problems persist, consult with your router technical support representative for more assistance.
|
Symptom: Users on a particular network find that they cannot access services off their network, and network administrators discover that the router interface connected to their network will not initialize AppleTalk operation.
Table 3-5 outlines possible causes of an AppleTalk interface failing to initialize.
Causes and Actions for Interface Failing to Start AppleTalk
| Possible Cause
| Suggested Actions
|
|---|
| Configuration mismatch
| Step 1: From the router, perform show appletalk interface.
|
|
| Step 2: Look for "port configuration mismatch" message; indicates that the configuration disagrees with listed neighbor.
|
|
| Step 3: If no error is displayed, execute the command clear interface for the interface in question. If it becomes operational after clearing, a configuration mismatch does not exist. If it declares "port configuration mismatch," continue with the steps that follow.
|
|
| Step 4: Verify that configuration for each router agrees regarding network number or cable range and the zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its seed information from the network (put the router in discovery mode by specifying appletalk address 0.0).
|
|
| Step 5: If they do not agree, modify configurations of the other routers as necessary.
|
|
| Step 6: If the problem persists, try to determine which router is at fault.
|
|
| The show appletalk interfaces command will generate the network and node address of the conflicting router.
|
|
| If apple name-lookup-interval is enabled, the NBP registration name will be displayed.
|
|
| If you are unable to identify the misconfigured router using the node address, look up the hardware address of the conflicting router with show appletalk arp. This display also provides the node's vendor code (vendor codes are available in RFC 1340).
|
|
| Step 7: As an alternative, all routers but one can be configured for nonseed or discovery mode, then the routers can be restarted.
|
| Phase 1/Phase 2 rule violations
| Step 1: Use show appletalk global to determine whether or not the internet is in compatibility mode.
|
|
| Step 2: Use show appletalk neighbor to determine which specific neighbor is in compatibility mode (if appletalk name-lookup-interval is enabled, shown by NBP name).
|
|
| Step 3: Select one of three solutions:
|
|
|
- Ensure that all routers are in compliance with the two Phase 1/Phase 2 rules.
|
|
|
- Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 compliance and reconfigure the internet.
|
|
|
- Use appletalk proxy-nbp feature.
|
|
| To use appletalk proxy-nbp, you must create at least one virtual network on the router that has the same zone name as the network where the unreachable services exist. This forces the router to use Phase 1-type NBP lookups (in addition to Phase 2-style FwdRequests) when sending NBP requests through the network. Since the Lookup is defined for Phase 1 routers, the Phase 1 router will properly route the request on to the service and a reply should be received. Refer to the Router Products Configuration and Reference publication for a more information.
|
Symptom: Mac users on different networks report that zones associated with a particular network do not appear in their Chooser listings.
Table 3-6 outlines possible causes of zones not appearing in the Chooser on networks separated by a router.
Causes and Actions for Zones Not Appearing
| Possible Cause
| Suggested Actions
|
|---|
| Configuration mismatch
| Step 1: From the router, perform show appletalk interface.
|
|
| Step 2: Look for "port configuration mismatch" message; indicates that the configuration disagrees with listed neighbor.
|
|
| Step 3: If no error is displayed, execute the command clear interface for the interface in question. If it becomes operational after clearing, a configuration mismatch does not exist. If it declares "port configuration mismatch," continue with the steps that follow.
|
|
| Step 4: Verify that configuration for each router agrees regarding network number or cable range and the zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its seed information from the network (put the router in discovery mode by specifying appletalk address 0.0).
|
|
| Step 5: If they do not agree, modify configurations of the other routers as necessary.
|
|
| Step 6: If the problem persists, try to determine which router is at fault.
|
|
| The show appletalk interface command will generate the network and node address of the conflicting router.
|
|
| If apple name-lookup-interval is enabled, the NBP registration name will be displayed.
|
|
| If you are unable to identify the misconfigured router using the node address, look up the hardware address of the conflicting router with show appletalk arp. This display also provides the node's vendor code (vendor codes are available in RFC 1340).
|
|
| Step 7: Alternately, all routers but one can be configured for nonseed or discovery mode, then the routers can be restarted.
|
| ZIP storm
| Step 1: Use show appletalk traffic to look for the number of ZIP Requests displayed; repeat after about 30 seconds.
|
|
| Step 2: Compare resulting display output. If number is greater than 10 and increasing, a ZIP storm probably is occurring.
|
|
| Step 3: Use show appletalk route to see whether a network shows up in the table, even though the zone indicates no zone set in the display.
|
|
| Step 4: If you find a network with this zone specification, the node in that network is probably not responding to ZIP requests, resulting in the ZIP storm.
|
|
| Step 5: Determine why the node is not responding to ZIP requests.
|
|
| Step 6: ZIP storms may result from a defect in the problem node's software. Contact the vendor to determine whether there is a known problem.
|
| Access list errors
| Step 1: Carefully disable access lists on suspect routers and see whether connectivity returns.
|
|
| Step 2: If connectivity returns, access list error is likely suspect. Check access lists and associated configuration commands for errors.
|
|
| Step 3: Modify any access lists as necessary.
|
|
| Step 4: If connection problems persist, consult with your router technical support representative for more assistance.
|
| Unstable routes
| Step 1: Check traffic load with show interface. For interfaces with more than 50 percent load, you may need to further segment network to limit traffic.
|
|
| Step 2: Issue the command debug apple-events to determine whether routes are being aged incorrectly.
|
|
| Step 3: Use the appletalk timers command to correct the problem. Suggested parameter values for the command are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
|
| This type of problem often can be alleviated by simply segmenting the network to limit the number of routers on a segment.
|
Symptom: Mac users report that services are intermittently unavailable. Services come and go without warning.
Table 3-7 outlines possible causes of intermittent loss of AppleTalk services.
Causes and Actions for Intermittent AppleTalk Service Loss
| Possible Cause
| Suggested Actions
|
|---|
| Duplicate network numbers
| Step 1: Any network where these symptoms are noticeable is likely to be one where a duplicate network number exists.
|
|
| Either change the network number of the afflicted network or remove Appletalk from the suspect/problem interface. In either case, the interface's original network number should disappear from the internet within a few minutes. If it persists, you have likely found the duplicate network.
|
|
| Step 2: If you changed your network number on the interface, no further action is required. If not, change it now (make sure it is unique). Remember to reenter the zone name and any other interface configurations for Appletalk on that interface.
|
| ZIP storm
| Step 1: Use show appletalk traffic to look for the number of ZIP Requests displayed; repeat after about 30 seconds.
|
|
| Step 2: Compare resulting display output. If number is greater than 10 and increasing, a ZIP storm is probably occurring.
|
|
| Step 3: Use show appletalk route to see whether a network shows up in the table, even though the zone indicates no zone set in the display.
|
|
| Step 4: If you find a network with this zone specification, the node in that network is probably not responding to ZIP requests, resulting in the ZIP storm.
|
|
| Step 5: Determine why the node is not responding to ZIP requests.
|
|
| Step 6: ZIP storms may result from a defect in the problem node's software. Contact the vendor to determine whether there is a known problem.
|
| Unstable routes
| Step 1: Check traffic load with show interface. For interfaces with more than 50 percent load, you may need to further segment network to limit traffic.
|
|
| Step 2: Issue the command debug apple-events to determine whether routes are being aged incorrectly.
|
|
| Step 3: Use the appletalk timers command to correct the problem. Suggested parameter values for the command are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
|
| This type of problem often can be alleviated by simply segmenting the network to limit the number of routers on a segment.
|
| Overloaded network, where routes are being aged out
| Step 1: Check traffic load with show interface.
Step 2: For interfaces with more than 50 percent load, you may need to further segment network to limit traffic.
|
|
| Step 3: Issue the command debug apple-events to determine whether routes are being aged incorrectly. Then use the appletalk timers command to correct the problem.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
Symptom: Users report that Apple services appear in their Chooser lists, but they are unable to access the services.
Table 3-8 outlines possible causes of services appearing in Choosers but not being available.
Causes and Actions for Blocked Service Access
| Possible Cause
| Suggested Actions
|
|---|
| Duplicate network numbers
| Step 1: Any network where these symptoms are noticeable is likely to be one where a duplicate network number exists.
|
|
| Either change the network number of the afflicted network or remove Appletalk from the suspect/problem interface. In either case, the interface's original network number should disappear from the internet within a few minutes. If it persists, you have likely found the duplicate network.
|
|
| Step 2: If you changed your network number on the interface, no further action is required. If not, change it now (make sure it is unique). Remember to reenter the zone name and any other interface configurations for Appletalk on that interface.
|
| ZIP storm
| Step 1: Use show appletalk traffic to look for the number of ZIP Requests displayed; repeat after about 30 seconds.
|
|
| Step 2: Compare resulting display output. If number is greater than 10 and increasing, a ZIP storm is probably occurring.
|
|
| Step 3: Use show appletalk route to see whether a network shows up in the table, even though the zone indicates no zone set in the display.
|
|
| Step 4: If you find a network with this zone specification, the node in that network is probably not responding to ZIP requests, resulting in the ZIP storm.
|
|
| Step 5: Determine why the node is not responding to ZIP requests.
|
|
| Step 6: ZIP storms may result from a defect in the problem node's software. Contact the vendor to determine whether there is a known problem.
|
| Access list errors
| Step 1: Carefully disable access lists on suspect routers and see whether connectivity returns.
|
|
| Step 2: If connectivity returns, access list error is likely suspect. Check access lists and associated configuration commands for errors.
|
|
| Step 3: Modify any access lists as necessary.
|
|
| Step 4: If connection problems persist, consult with your router technical support representative for more assistance.
|
Symptom: Puzzled users report that whenever their Chooser windows are opened, the zone list appears to change.
Table 3-9 outlines possible causes of zones changing whenever the Chooser window is opened.
Causes and Actions for Zone List Constantly Changing
| Possible Cause
| Suggested Actions
|
|---|
| Unstable routes
| Step 1: Check traffic load with show interface. For interfaces with more than 50 percent load, you may need to further segment network to limit traffic.
|
|
| Step 2: Issue the command debug apple-events to determine whether routes are being aged incorrectly.
|
|
| Step 3: Use the appletalk timers command to correct the problem. Suggested parameter values for the command are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
|
| This type of problem often can be alleviated by simply segmenting the network to limit the number of routers on a segment.
|
| Routers on network have different zone lists
| Step 1: Verify that the configuration of zone lists for all routers are in agreement.
|
|
| Step 2: If they do not agree, reconfigure thre routers so that all have matching zone lists for relevant networks.
|
Symptom: Users complain that their sessions with Apple services suddenly drop for no apparent reason.
Table 3-10 outlines possible causes of unexpected loss of Apple network services.
Causes and Actions for Services Being Dropped
| Possible Cause
| Suggested Actions
|
|---|
| Unstable routes
| Step 1: Check traffic load with show interface. For interfaces with more than 50 percent load, you may need to further segment network to limit traffic.
|
|
| Step 2: Issue the command debug apple-events to determine whether routes are being aged incorrectly.
|
|
| Step 3: Use the appletalk timers command to correct the problem. Suggested parameter values for the command are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.
Timers should be consistently set to the same value throughout the internet, or at a minimum, throughout the internet's backbone.
|
|
| This type of problem often can be alleviated by simply segmenting the network to limit the number of routers on a segment.
|
Symptom: Router is unable to discover routes or poll neighbors on attached cable.
Table 3-11 outlines possible causes for a stuck port problem in a router.
Causes and Actions for Stuck Port Problem
| Possible Cause
| Suggested Actions
|
|---|
| Inadvertently crossed (serial) circuits with multiple lines between two routers
| Step 1: Check physical attachment of serial lines to ensure that they are correctly wired.
Step 2: If needed, rewire and check show interface and show appletalk interface output to confirm that traffic is getting through and that the protocol is operating correctly.
|
|
| Step 3: If router is still unable to find routes, consult your router technical support representative for more assistance.
|
| Router is in discovery mode and no seed router exists on network
| Step 1: If there is no seed router on the network, put the router in nondiscovery mode and restart the interface (exit configuration mode). Remember to assign a zone and network number or cable range (assign network number or cable range using the appletalk address or appletalk cable-range interface subcommands).
|
|
| Step 2: Use the no appletalk discovery interface command to allow the specific interface(s) to be seed ports.
|
Symptom: Users report that they are seeing zones that have been deleted from the network.
Note Appletalk does not incorporate any provisions to update routing tables when zone names are changed. 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 internet long enough for it to be aged out of the internet's routing tables completely, some routers will continue to use the old zone name.
Table 3-12 outlines possible causes of unnumbered zones in AppleTalk interconnection environments.
Causes and Actions for Zones with Missing Network Numbers
| Possible Cause
| Suggested Actions
|
|---|
| Configuration mismatch
| Step 1: From the router, perform show appletalk interface.
|
|
| Step 2: Look for "port configuration mismatch" message; indicates that configuration disagrees with indicated neighbor.
|
|
| Step 3: If no error is displayed, execute the command clear interface for the interface in question. If it becomes operational after clearing, a configuration mismatch does not exist. If it declares "port configuration mismatch," continue with the steps that follow.
|
|
| Step 4: Verify that configuration for each router agrees regarding network number or cable range and the zone or zone list. In some cases, the configuration shown is not the configuration being used, so if problems persist, set the problem router to get its seed information from the network (put the router in discovery mode by specifying appletalk address 0.0).
|
|
| Step 5: If they do not agree, modify configurations of the other routers as necessary.
|
|
| Step 6: If the problem persists, try to determine which router is at fault.
|
|
| The show appletalk interfaces command will generate the network and node address of the conflicting router.
|
|
| If apple name-lookup-interval is enabled, the NBP registration name will be displayed.
|
|
| If you are unable to determine which router is misconfigured by the node address, looking up the hardware address of the conflicting router with show appletalk arp allows you to determine the vendor to help narrow the search (vendor codes are available in RFC 1340).
|
|
| Step 7: As an alternative, all routers but one can be configured for nonseed or discovery mode, then the routers can be restarted.
|
| Ghost zone created when a zone name is changed without changing the associated network number
| Step 1: Check the network numbers for each AppleTalk interface in the router configuration.
Step 2: Ensure that any network numbers associated with an old zone name are removed.
|
|
| Step 3: Check show appletalk zones display output to be sure that the ghost zone no longer appears in the list.
|
Note Since AppleTalk has no provision for flushing zones that are not valid, always change the underlying network number when changing the zone name for a cable.
