Downloads |
 Feedback
|
Table Of Contents
AppleTalk Configuration and Troubleshooting Tips
Using the test appletalk and ping appletalk Commands
Preventing Internetwork Reconfiguration Problems
AppleTalk: Users Cannot Access Zones or Services
AppleTalk Configuration Mismatches
Phase 1 and Phase 2 Rule Violations
AppleTalk: Zones Missing from Chooser
AppleTalk: No Devices in Chooser
AppleTalk: Network Services Intermittently Unavailable
AppleTalk: Old Zone Names Appear in Chooser (Phantom Zones)
AppleTalk: Connections to Services Drop
AppleTalk: Interface Fails to Initialize AppleTalk
AppleTalk: Port Stuck in Restarting or Acquiring Mode
AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers
AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors
AppleTalk Enhanced IGRP: Routes Missing from Routing Table
AppleTalk Enhanced IGRP: Poor Performance
AppleTalk Enhanced IGRP: Router Stuck in Active Mode
Enhanced IGRP Active/Passive Modes
AURP: Routes Not Propagated Through AURP Tunnel
FDDITalk: No Zone Associated with Routes
ARA: ARA Client Unable to Connect to ARA Server
ARA: Connection Hangs After "Communicating At..." Message
ARA: Cannot Send or Receive Data over ARA Dialin Connection
ARA: Slow Performance from Dialin Connection
Troubleshooting AppleTalk
In the early 1980s, as Apple Computer, Inc., was preparing to introduce the Macintosh computer, Apple engineers knew that networks would become a critical need. They wanted to ensure that a Macintosh-based network was a seamless extension of the revolutionary Macintosh user interface. With these two goals in mind, Apple decided to build a network interface into every Macintosh and to integrate that interface into the desktop environment. Apple's new network architecture was called 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 original implementation of AppleTalk, which was designed for local workgroups, is now commonly referred to as AppleTalk Phase 1. With the installation of more than 1.5 million Macintosh computers in the first five years of the product's life, however, Apple found that some large corporations were exceeding the built-in limits of AppleTalk Phase 1, so they enhanced the protocol. The enhanced protocol, known as AppleTalk Phase 2, improved the routing capabilities of AppleTalk and allowed AppleTalk to run successfully in larger networks.
AppleTalk Technology Basics
AppleTalk was designed as a client/server distributed network system. In other words, users share network resources (such as files and printers) with other users. Computers supplying these network resources are called servers; computers using a server's network resources are called clients. Interaction with servers is essentially transparent to the user because the computer itself determines the location of the requested material and accesses it without further information from the user. In addition to their ease of use, distributed systems also enjoy an economic advantage over peer-to-peer systems because important materials can be located in a few, rather than many, locations.
In Figure 9-1, AppleTalk protocols are shown adjacent to the Open System Interconnection (OSI) reference model layers to which they map.
Figure 9-1 AppleTalk and the OSI Reference Model
Media Access
Apple designed AppleTalk to be link-layer independent. In other words, it can theoretically run on top of any link-layer implementation. Apple supports a variety of link-layer implementations, including Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and LocalTalk. Apple refers to AppleTalk over Ethernet as EtherTalk, to AppleTalk over Token Ring as TokenTalk, and to AppleTalk over FDDI as FDDITalk. The link-layer protocols that support AppleTalk over these media are EtherTalk Link Access Protocol (ELAP), LocalTalk Link Access Protocol (LLAP), TokenTalk Link Access Protocol (TLAP), and FDDITalk Link Access Protocol (FLAP). LocalTalk is Apple's proprietary media-access system. It is based on contention access, bus topology, and baseband signaling, and runs on shielded twisted-pair media at 230.4 kbps. The physical interface is EIA/TIA-422 (formerly RS-422), a balanced electrical interface supported by EIA/TIA-449 (formerly RS-449). LocalTalk segments can span up to 300 meters and support a maximum of 32 nodes.
The Network Layer
This section describes AppleTalk network-layer concepts and protocols. It includes discussion of protocol address assignment, network entities, and AppleTalk protocols that provide OSI reference model Layer 3 functionality.
Protocol Address Assignment
To ensure minimal network administrator overhead, AppleTalk node addresses are assigned dynamically. When a Macintosh running AppleTalk starts up, it chooses a protocol (network-layer) address and checks whether that address is currently in use. If it is not, the new node has successfully assigned itself an address. If the address is currently in use, the node with the conflicting address sends a message indicating a problem, and the new node chooses another address and repeats the process. Figure 9-2 shows the AppleTalk address selection process.
The mechanics of AppleTalk address selection are media dependent. The AppleTalk Address Resolution Protocol (AARP) is used to associate AppleTalk addresses with particular media addresses. AARP also associates other protocol addresses with hardware addresses. When either AppleTalk or any other protocol stack must send a packet to another network node, the protocol address is passed to AARP. AARP first checks an address cache to see whether the relationship between the protocol and the hardware address is already known. If it is, that relationship is passed up to the inquiring protocol stack. If it is not, AARP initiates a broadcast or multicast message inquiring about the hardware address for the protocol address in question. If the broadcast reaches a node with the specified protocol address, that node replies with its hardware address. This information is passed up to the inquiring protocol stack, which uses the hardware address in communications with that node.
Figure 9-2 The AppleTalk Address Selection Process
Network Entities
AppleTalk identifies several network entities. The most elemental is a node, which is simply any device connected to an AppleTalk network. The most common nodes are Macintosh computers and laser printers, but many other types of computers are also capable of AppleTalk communication, including IBM PCs, Digital Equipment Corporation VAX computers, and a variety of workstations. The next entity defined by AppleTalk is the network. An AppleTalk network is simply a single logical cable. Although the logical cable is frequently a single physical cable, some sites use bridges to interconnect several physical cables. Finally, an AppleTalk zone is a logical group of (possibly noncontiguous) networks. These AppleTalk entities are shown in Figure 9-3.
Figure 9-3 AppleTalk Entities
Datagram Delivery Protocol
AppleTalk's primary network-layer protocol is the Datagram Delivery Protocol (DDP). DDP provides connectionless service between network sockets. Sockets can be assigned either statically or dynamically.
AppleTalk addresses, which are administered by the DDP, consist of two components: a 16-bit network number and an 8-bit node number. The two components are usually written as decimal numbers, separated by a period (for example, 10.1 means network 10, node 1). When an 8-bit socket identifying a particular process is added to the network number and node number, a unique process on a network is specified.
AppleTalk Phase 2 distinguishes between nonextended and extended networks. In a nonextended network such as LocalTalk, each AppleTalk node number is unique. Nonextended networks were the sole network type defined in AppleTalk Phase 1. In an extended network such as EtherTalk and TokenTalk, each network number/node number combination is unique.
Zones are defined by the AppleTalk network manager during the router configuration process. Each node in an AppleTalk network belongs to a single specific zone. Extended networks can have multiple zones associated with them. Nodes on extended networks can belong to any single zone associated with the extended network.
The Transport Layer
AppleTalk's transport layer is implemented by several protocols: Routing Table Maintenance Protocol (RTMP), AppleTalk Update Routing Protocol (AURP), AppleTalk Echo Protocol (AEP), AppleTalk Transaction Protocol (ATP), and Name Binding Protocol (NBP).
RTMP
The protocol that establishes and maintains AppleTalk routing tables is RTMP. RTMP routing tables contain an entry for each network that a datagram can reach. Each entry includes the router port that leads to the destination network, the node ID of the next router to receive the packet, the distance in hops to the destination network, and the current state of the entry (good, suspect, or bad). Periodic exchange of routing tables allows the routers in an internetwork to ensure that they supply current and consistent information. Figure 9-4 shows a sample RTMP table and the corresponding network architecture.
Figure 9-4 A Sample AppleTalk Routing Table
AppleTalk's NBP associates AppleTalk names (expressed as network-visible entities, or NVEs) with addresses. An NVE is an AppleTalk network-addressable service, such as a socket. NVEs are associated with one or more entity names and attribute lists. Entity names are character strings such as printer@net1, whereas attribute lists specify NVE characteristics.
Named NVEs are associated with network addresses through the process of name binding. Name binding can be done when the user node is first started up, or dynamically, immediately before first use. NBP orchestrates the name binding process, which includes name registration, name confirmation, name deletion, and name lookup.
Zones allow name lookup in a group of logically related nodes. To look up names within a zone, an NBP lookup request is sent to a local router, which sends a broadcast request to all networks that have nodes belonging to the target zone. The Zone Information Protocol (ZIP) coordinates this effort.
ZIP maintains network number-to-zone name mappings in zone information tables (ZITs). ZITs are stored in routers, which are the primary users of ZIP, but end nodes use ZIP during the startup process to choose their zone and to acquire internetwork zone information. ZIP uses RTMP routing tables to keep up with network topology changes. When ZIP finds a routing table entry that is not in the ZIT, it creates a new ZIT entry. Figure 9-5 shows a sample ZIT.
Figure 9-5 A Sample AppleTalk ZIT
AURP
AURP allows a network administrator to connect two or more AppleTalk internetworks through a foreign network (such as Transmission Control Protocol/Internet Protocol [TCP/IP]) to form an AppleTalk wide-area network (WAN). The connection is called a tunnel, which functions as a single, virtual data link between the AppleTalk internetworks, as shown in Figure 9-6.
Figure 9-6 An AppleTalk Tunnel
A router that connects an AppleTalk internetwork to a tunnel (that is, a router that runs AURP) is called an exterior router. The exterior router sends AppleTalk data packets and routing information through the foreign network by encapsulating the packets with the header information required by the foreign network system. The receiving exterior router removes the foreign header information and sends the packets out the appropriate interface. Packets are encapsulated in User Datagram Protocol (UDP) headers in the initial implementation of AURP.
When only two exterior routers are connected to a tunnel, that tunnel is called a point-to-point tunnel. When more than two exterior routers are connected to the tunnel, that tunnel is called a multipoint tunnel. If all exterior routers connected to a multipoint tunnel can send packets to each other, the tunnel is said to be fully connected. If one or more exterior routers are not aware of other exterior routers, the tunnel is said to be partially connected. Each exterior router functions both as an AppleTalk router within its local internetwork and as an end node in the foreign network that connects the AppleTalk internetworks.
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.
AURP uses the principle of split horizons (which states that it is never useful to send information about a route back in the direction from which the information came) to limit the propagation of routing updates. For that reason, an exterior router sends routing information about only the networks that comprise its local internetwork to other exterior routers connected to the tunnel.
When an exterior router becomes aware of another exterior router on the tunnel, the two exterior routers exchange their lists of network numbers and associated zone information. Thereafter, an exterior router sends routing information only when the following events occur:
•
A network is added to the routing table.
•
•
•
When an exterior router receives AppleTalk data packets or routing information that needs to be forwarded over the tunnel, the AURP module converts that information to AURP packets. The AURP packets are encapsulated in the header information required by the foreign network and sent over the tunnel to the destination exterior router, as shown in Figure 9-7.
Figure 9-7 The AURP Architectural Model
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.
Note
AEP
AEP is an extremely simple protocol which generates packets that can be used to test the reachability of various network nodes.
ATP
ATP is suitable for transaction-based applications such as those found in banks or retail stores. ATP transactions consist of requests (from clients) and replies (from servers). Each request/reply pair has a particular transaction ID. Transactions occur between two socket clients. ATP uses exactly once (XO) and at-least-once (ALO) transactions. XO transactions are used in situations where performing the transaction more than once would be unacceptable. Banking transactions are examples of transactions that, if performed more than once, result in invalid data.
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.
Upper-Layer Protocols
AppleTalk supports several upper-layer protocols:
•
•
•
•
Troubleshooting AppleTalk
This section presents protocol-related troubleshooting information for AppleTalk connectivity and performance problems. In addition to general AppleTalk problems, this chapter also covers AppleTalk Enhanced IGRP, AppleTalk Remote Access (ARA), AURP, and FDDITalk problems.
The section "AppleTalk Configuration and Troubleshooting Tips" discusses preventive measures and tips to help you configure and troubleshoot your AppleTalk internetwork. The remaining sections describe specific AppleTalk symptoms, the problems that are likely to cause each symptom, and the solutions to those problems.
The following sections cover the most common network issues in AppleTalk environments:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
AppleTalk Configuration and Troubleshooting Tips
This section offers configuration and troubleshooting tips that can help you prevent or more easily repair problems in AppleTalk internetworks.
It consists of 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.
Preventing AppleTalk Problems
Table 9-1 lists suggestions to help you avoid problems when configuring a router for AppleTalk.
Table 9-1 AppleTalk Problem-Prevention Techniques
Every router connected to a network must agree on the configuration of that network
Every router on an AppleTalk network (that is, on a single cable segment) must agree on the configuration of the network. Therefore, network numbers, cable ranges, timer values, zone names, and other parameters should be the same for every router on the segment.
Every network number in an internetwork must be unique
Network numbers must be unique throughout the entire AppleTalk network. Duplicate network numbers can cause connectivity- and performance-related problems.
Upgrade to AppleTalk Phase 2 wherever possible
To minimize interoperability problems, upgrade all router Ethernet interfaces to Phase 2. Phase 1/Phase 2 networks can be problematic, as can nonextended AppleTalk networks.
When you change a router or interface configuration, enable the debug apple error privileged exec command to log errors
The debug apple error privileged exec command tracks the progress and status of changes in the internetwork and alerts you to any errors. You can also run this command periodically when you suspect network problems. In a stable network, this command returns no output.
You can establish a syslog server at your site and add the configuration command appletalk event-logging to the router. This keeps a running log, with timestamps, of significant events on your network.
Disable this command with the no debug apple error command when you have completed diagnostic activities.
Design your network with attention to the direction in which traffic will flow and minimize the number of different zones in the internetwork
Careful zone mapping can minimize unnecessary NBP1 traffic. Planning is particularly important in WANs where traffic traversing WAN links (such as X.25) can be quite expensive.
In System 6, if a user opens the Chooser, the Macintosh continually sends NBP BrReq packets. In System 7, a logarithmic backoff minimizes the amount of traffic generated.
Give all the backbone/WAN connections the same zone name rather than put them in a zone with a LAN.
In most internetworks, it is not desirable to have the zone names for all backbone or WAN connections appear in the Chooser list. If you make the zone name of all the WAN links the same (for example, ZZSerial), only that entry appears in the Chooser menu.
Set AppleTalk timers to the default values throughout the internetwork
A stable network almost never has nondefault timer values configured. Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork. Check with a qualified technical support representative before changing AppleTalk default timer values.
1 NBP = Name Binding Protocol
Using the test appletalk and ping appletalk Commands
In Cisco IOS Release 11.1 and later, use the test appletalk privileged exec command to help identify problem nodes. Use the nbp (Name Binding Protocol) options of the command to perform informational lookups of NBP-registered entities. The information returned when using the nbp options is useful when AppleTalk zones are listed in the Chooser but services in those zones are unavailable.
When running the test appletalk facility, use the confirm option to check that a name of a specified type is registered on a device. For example, nbp confirm 24279.173 my-mac:AFPServer@engineering confirms that the name my-mac is registered on the device 24279.173 in the engineering zone. The object type is AFPServer. The syntax for the nbp confirm command is as follows:
nbp confirm appletalk-address [:skt] object:type@zone
The syntax description is as follows:
•
•
•
•
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.24Type 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 msThe 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.
Preventing Internetwork Reconfiguration Problems
Configuration conflicts can occur when zone names or cable range numbers are changed. In particular, problems arise when routing devices about which you are not administratively aware exist on the internetwork.
Many devices can act as routers (for example, Novell servers, Pathworks servers, or UNIX workstations running CAP to do print and file sharing). In general, if you are changing zone names or cable range numbers in your internetwork, shut down all routers so that a Cisco router does not see a conflict and prevent AppleTalk from initializing on the interface.
Before changing the configuration, use the show appletalk neighbors exec command to determine 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.
Changing Zone Names
When changing a zone name on an existing network, perform the following actions:
Step 1
Step 2
Step 3
These actions are required because AppleTalk makes no provisions for informing neighbors in the internetwork about a changed zone list. Routers make ZIP queries only when a new (or previously aged-out) network appears on the internetwork.
Adding a new zone to an extended cable configuration prevents the router from bringing up an AppleTalk interface after the interface has been reset. This is because its configuration no longer matches that of its neighbors (that is, it detects a configuration mismatch error).
AppleTalk Discovery Mode
When bringing up an interface on an existing cable where a long zone list is defined, using AppleTalk discovery mode helps you save effort and avoid mistakes.
The following steps outline bringing up an interface in discovery mode:
Step 1
Step 2
The router should not be in discovery mode for normal operation (it is recommended that discovery mode be used only when initially configuring networks). After the initial configuration, configure all routers for seed, or nondiscovery, mode. If you enable AppleTalk discovery and the interface is restarted, you must have another operational communication server or router on the directly connected network or the interface will not start up. It is not advisable to have all communication servers and routers on a network configured with discovery mode enabled. If all communication servers were to restart simultaneously (for instance, after a power failure), the network would become inaccessible until at least one communication server or router were restarted with discovery mode disabled.
Step 3
Step 4
Forcing an Interface Up
In certain situations, you might need to force an interface to come up even though its zone list conflicts with that of another router on the network. You can do this by using the appletalk ignore-verify-errors global configuration command. Usually the other router is one over which you have no administrative control but which you know has an incorrect zone list.
The appletalk ignore-verify-errors command allows you to bypass the default behavior of an AppleTalk interface. By default, the AppleTalk interface 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.
AppleTalk: Users Cannot Access Zones or Services
Symptom: Users cannot access zones or services that appear in the Chooser. Users might or might not be able to access services on their own network.
Table 9-2 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-2 AppleTalk: Users Cannot Access Zones or Services
Configuration mismatch
1.
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.
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.
2.
3.
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.
1.
2.
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.
3.
Phase 1 and Phase 2 rule violations
1.
2.
3.
•
•
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
1.
2.
3.
4.
5.
6.
1 NBP = Name Binding Protocol
AppleTalk Configuration Mismatches
A configuration mismatch occurs if all the AppleTalk routers on a given cable do not agree on the configuration of that cable. This means that all routers must have matching network numbers, a matching default zone, and a matching zone list.
To protect against configuration errors that violate this rule, Cisco AppleTalk routers block activation of any port on which a violation of this rule exists. At interface initialization, if other routers on the network do not agree with the way a router is configured, the router 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 upAppleTalk routing disabled, Port configuration mismatchAppleTalk cable range is 4-5AppleTalk address is 4.252, ValidAppleTalk zone is "Maison Vauquer"AppleTalk port configuration conflicts with 4.156AppleTalk discarded 8 packets due to input errorsAppleTalk discarded 2 packets due to output errorsAppleTalk route cache is disabled, port initializingLine 2 of the command output shows that routing has been disabled due to a port configuration mismatch. Line 6 indicates the AppleTalk address of the conflicting router.
You can also display the NBP registered name of the conflicting router, which can simplify resolution of a port mismatch problem. To see registered NBP names, enable the appletalk name-lookup-interval global configuration command. This causes the show appletalk interface exec command output to display nodes by NBP registration name.
Phase 1 and Phase 2 Rule Violations
When Phase 1 and Phase 2 routers are connected to the same internetwork, the internetwork specifications must conform to two rules:
•
•
If these rules are not followed, connectivity between the nonextended and extended portions of an internetwork becomes degraded and might be lost. In particular, services located on nonextended networks using Phase 1 routers will not be visible on the other side of the Phase 1 router.
Note
Another Phase 1 and Phase 2 issue is the handling of NBP packets. Phase 1 AppleTalk has three types of NBP packets, and Phase 2 AppleTalk has four types of NBP packets. This difference can lead to communication problems between Phase 1 and Phase 2 routers. Table 9-3 lists the NBP packet types for AppleTalk Phase 1 and Phase 2.
As shown in Table 9-3, Forward Request packets do not exist in Phase 1. Only Phase 2 routers know what to do with them. Phase 1 routers that receive Forward Request packets simply drop them.
AppleTalk: Zones Missing from Chooser
Symptom: Certain zones do not appear in the Chooser. The zones are not visible from multiple networks. In some cases, when the Chooser is opened, the zone list changes.
Table 9-4 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-4 AppleTalk: Zones Missing from Chooser
Configuration mismatch
1.
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.
2.
3.
Configuration mismatch (continued)
4.
For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.
Misconfigured access lists or other filters
1.
2.
3.
4.
5.
6.
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.
1.
The following example is output from the show interfaces command:
Ethernet0 is up, line protocol is upHardware is Lance, address is 0000.0c32.49b1 (bia 0000.0c32.49b1)Internet address is 192.168.52.26/24MTU 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.
2.
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.
3.
Router#debug apple eventsAppleTalk Events debugging is onRouter#%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 250-250 down; reported bad by 200.41Caution: 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.
4.
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.
1.
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.
2.
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.
3.
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.
4.
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.
1 RTMP = Routing Table Maintenance Protocol
AppleTalk: No Devices in Chooser
Symptom: Zones appear in the Chooser, but when a service (such as AppleShare) and a zone are selected, no devices appear in the device list.
Table 9-5 outlines the problem that might cause this symptom and describes solutions to that problem.
AppleTalk: Network Services Intermittently Unavailable
Symptom: Network services are intermittently unavailable. Services come and go without warning.
Table 9-6 outlines the problems that might cause this symptom and describes solutions to those problems.
AppleTalk: Old Zone Names Appear in Chooser (Phantom Zones)
Symptom: Old AppleTalk zone names continue to appear in the Chooser. Even after zone names are removed from the configuration, "phantom" zones continue to appear in the Chooser.
Table 9-7 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-7 AppleTalk: Old Zone Names Appear in Chooser (Phantom Zones)
Configuration mismatch
1.
Configuration mismatch (continued)
1.
2.
3.
4.
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.
1.
Invalid zone names in routing table (continued)
2.
3.
AppleTalk: Connections to Services Drop
Symptom: Users complain that their AppleTalk sessions suddenly drop for no apparent reason.
Table 9-8 outlines the problem that might cause this symptom and describes solutions to that problem.
AppleTalk: Interface Fails to Initialize AppleTalk
Symptom: Router interface connected to a network will not initialize AppleTalk.
Table 9-9 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-9 AppleTalk: Interface Fails to Initialize AppleTalk
Configuration mismatch
1.
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.
2.
3.
4.
For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.
Phase 1 and Phase 2 rule violations
1.
2.
3.
•
•
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.
AppleTalk: Port Stuck in Restarting or Acquiring Mode
Symptom: A router port is stuck in restarting or acquiring mode (as shown in the output of the show apple interface privileged exec command). The router cannot discover routes or poll neighbors on an attached cable.
Table 9-10 outlines the problems that might cause this symptom and describes solutions to those problems.
AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers
Symptom: Macintosh clients cannot connect to servers in an AppleTalk Enhanced IGRP network environment.
Table 9-8 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-8 AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers
Routers not establishing neighbors properly
For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" next.
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.
1.
2.
3.
AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors
Symptom: AppleTalk Enhanced IGRP routers do not establish neighbors properly. Routers that are connected do not appear in the neighbor table.
Table 9-1 outlines the problems that might cause this symptom and describes solutions to those problems.
AppleTalk Enhanced IGRP: Routes Missing from Routing Table
Symptom: Routes are missing from the routing table of routers running AppleTalk Enhanced IGRP. Clients (Macintosh computers) on one network cannot access servers on a different network. Clients might or might not be able to connect to servers on the same network. The problem might occur in internetworks running only Enhanced IGRP or in an internetwork running Enhanced IGRP and RTMP.
Table 9-2 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-2 AppleTalk Enhanced IGRP: Routes Missing from Routing Table
Routers not establishing neighbors properly
For information on troubleshooting this problem, see the section "AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors" earlier in this chapter.
AppleTalk Enhanced IGRP is not enabled on interfaces
Use the show running-config privileged exec command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries.
This command must be present in order for an interface to generate AppleTalk Enhanced IGRP hello messages and routing updates.
Older version of the Cisco IOS software
If problems persist, upgrade to the latest release of the Cisco IOS software.
AppleTalk Enhanced IGRP: Poor Performance
Symptom: Network performance in an AppleTalk Enhanced IGRP environment is poor. Connections between clients and servers are slow or unreliable.
Table 9-3 outlines the problems that might cause this symptom and describes solutions to those problems.
AppleTalk Enhanced IGRP: Router Stuck in Active Mode
Symptom: An AppleTalk Enhanced IGRP router is stuck in Active mode. The router repeatedly sends error messages similar to the following to the console:
%DUAL-3-SIA: Route 2.24 Stuck-in-Active
Note
For a more detailed explanation of Enhanced IGRP Active mode, see the section "Enhanced IGRP Active/Passive Modes" later in this chapter.
Table 9-4 outlines the problems that might cause this symptom and describes solutions to those problems.
Enhanced IGRP Active/Passive Modes
An Enhanced IGRP router can be in either Passive or Active mode. A router is said to be passive for a network when it has an established path to that network in its routing table. The route is in Active state when a router is undergoing a route recomputation. If there are always feasible successors, a route never has to go into Active state and avoids a route recomputation.
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.
AURP: Routes Not Propagated Through AURP Tunnel
Symptom: AppleTalk routes are not propagated through an AURP tunnel. Routes that are known to exist on one side of the tunnel do not appear in the routing tables of the exterior router on the other side of the tunnel. Changes on the remote network (such as a route going down) are not learned by the exterior router on the other side of the tunnel.
Table 9-5 outlines the problems that might cause this symptom and describes solutions to those problems.
FDDITalk: No Zone Associated with Routes
Symptom: Routers on an FDDI ring have routes to networks across the ring, but no zones are associated with the routes. The output of the show appletalk route command indicates "no zone set" for those routes.
Note
Table 9-6 outlines the problem that might cause this symptom and describes solutions to that problem.
ARA: ARA Client Unable to Connect to ARA Server
Symptom: An ARA client (such as a Macintosh) attempts to connect to an ARA server (such as a Cisco access server) and cannot initiate a remote session. The user might be able to connect briefly, but the connection is immediately terminated.
Table 9-7 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-7 ARA: ARA Client Unable to Connect to ARA Server
Missing arap network command entry
1.
2.
arap network [network-number] [zone-name]
Missing arap network command entry (continued)
Syntax Description:
•
•
AppleTalk routing is not enabled on the appropriate interfaces
1.
2.
Modem, serial line, or hardware problems
For serial line troubleshooting information, see Chapter 15, "Troubleshooting Serial Lines." For modem troubleshooting information, see Chapter 16, "Troubleshooting Dialup Connections." For hardware troubleshooting information, see Chapter 3, "Troubleshooting Hardware and Booting Problems."
1 ARAP = AppleTalk Remote Access Protocol
ARA: Connection Hangs After "Communicating At..." Message
Symptom: An ARA client (for example, a Macintosh) tries to connect to an ARA server (such as a Cisco access server) over client and server modems. The client receives a connect message such as "Communicating at 14.4 Kbps" but then hangs for 10-30 seconds and finally shows a "connection failed" message.
Table 9-8 outlines the problem that might cause this symptom and describes solutions to that problem.
ARA: Cannot Send or Receive Data over ARA Dialin Connection
Symptom: ARA connections are established, but users cannot send or receive ARA data over the link.
Table 9-9 outlines the problems that might cause this symptom and describes solutions to those problems.
Table 9-9 ARA: Cannot Send or Receive Data over ARA Dialin Connection
Missing arap network command entry
1.
2.
arap network [network-number] [zone-name]
Syntax Description:
•
•
Missing autoselect command
1.
2.
MNP5 enabled on answering modem
1.
2.
Zone list is empty
1.
2.
3.
TACACS1 problem
For information on troubleshooting TACACS problems, refer to Chapter 24, "Troubleshooting CiscoWorks 2000."
1 TACACS = Terminal Access Controller Access Control System
ARA: Slow Performance from Dialin Connection
Symptom: Performance on remote dialin ARA sessions is slow.
Table 9-10 outlines the problem that might cause this symptom and describes solutions to that problem.
