Guest

Support

Troubleshooting AppleTalk

 Feedback

Table Of Contents

Troubleshooting AppleTalk

AppleTalk Technology Basics

Media Access

The Network Layer

Protocol Address Assignment

Network Entities

Datagram Delivery Protocol

The Transport Layer

RTMP

AURP

AEP

ATP

Upper-Layer Protocols

Troubleshooting AppleTalk

AppleTalk Configuration and Troubleshooting Tips

Preventing AppleTalk Problems

Using the test appletalk and ping appletalk Commands

Preventing Internetwork Reconfiguration Problems

Changing Zone Names

AppleTalk Discovery Mode

Forcing an Interface Up

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.

A change in the path to a network causes the exterior router to access that network through its local internetwork rather than through the tunnel or to access that network through the tunnel rather than through the local internetwork.

A network is removed from the routing table.

The distance to a network is changed.

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 As defined by Apple Computer, AURP converts RTMP and ZIP packets into AURP packets and vice versa. As implemented by Cisco, AURP converts Enhanced IGRP packets as well as RTMP and ZIP packets.


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:

AppleTalk Data Stream Protocol (ADSP) establishes and maintains full-duplex data streams between two sockets in an AppleTalk internetwork. ADSP is a reliable protocol in that it guarantees that data bytes are delivered in the same order as sent and that they are not duplicated. ADSP numbers each data byte to keep track of the individual elements of the data stream. ADSP also specifies a flow-control mechanism. The destination can essentially slow source transmissions by reducing the size of its advertised receive window. ADSP also provides an out-of-band control message mechanism. Attention packets are used as the vehicle for moving out-of-band control messages between two AppleTalk entities. These packets use a separate sequence number stream to differentiate them from normal ADSP data packets.

The AppleTalk Session Protocol (ASP) establishes and maintains sessions (logical conversations) between an AppleTalk client and a server.

AppleTalk's Printer Access Protocol (PAP) is a connection-oriented protocol that establishes and maintains connections between clients and servers. (Use of the term printer in this protocol's title is purely historical.)

The AppleTalk Filing Protocol (AFP) helps clients share server files across a network.

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: Users Cannot Access Zones or Services

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

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

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 

Preventive Action
Description

Every router connected to a network must agree on the configuration of that network

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

Every network number in an internetwork must be unique

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

Upgrade to AppleTalk Phase 2 wherever possible

To minimize interoperability problems, upgrade all router Ethernet interfaces to Phase 2. Phase 1/Phase 2 networks can be problematic, as can 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:

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

:skt—(Optional) Name of socket.

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

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

In software releases prior to Cisco IOS Release 11.0, the ping appletalk exec command serves a similar function. Use this command to verify that a node is reachable from the router (for example, ping appletalk 2.24 pings AppleTalk node 2.24).

The following display shows input to and output from the user ping command:

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

The ping privileged exec command also supports several AppleTalk parameters that provide additional troubleshooting capabilities. In particular, use the NBP option when AppleTalk zones are listed in the Chooser but services are not available. If a configuration contains the appletalk name-lookup-interval global configuration command, the NBP option of the AppleTalk ping function displays nodes by their NBP registration names.

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 Disable AppleTalk on all router interfaces on the cable for approximately 10 minutes. This allows all routers in the internetwork to age out the network number from their routing tables.

Step 2 Configure the new zone list.

Step 3 Re-enable AppleTalk on all interfaces.

These actions are required because AppleTalk makes no provisions for informing neighbors in the internetwork about a changed zone list. Routers make ZIP queries only when a new (or previously aged-out) network appears on the internetwork.

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

AppleTalk Discovery Mode

When bringing 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 Bring up the interface in discovery mode (using the appletalk cable-range 0-0 interface configuration command). When a router is in discovery mode, the router changes its configuration to match the advertised cable range if the advertised cable range is different from that configured on the router. The debug apple events privileged exec command lets you know when the discovery process is complete by displaying an "operational" message.

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

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 Use the copy running-config startup-config privileged exec command to save the acquired information to nonvolatile RAM (NVRAM).

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

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 

Possible Problems
Solution

Configuration mismatch

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

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

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

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. If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment.

3. If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cable-range 0-0 command on an extended network. This causes the router to get its configuration information from the network.

For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" later in this chapter.

Duplicate network numbers or overlapping cable-range

In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, packets might not be routed to their intended destinations.

If AppleTalk services do not appear in the Chooser for particular networks, those networks probably have duplicate network numbers.

1. Change the network number or cable-range of the suspect network to a unique value using the appletalk cable-range interface configuration command.

2. Use the show appletalk route privileged exec command to view the routing table. If the network number or cable-range continues to appear in routing tables, you have found the duplicate (because the other network using that number will continue to send routing updates).

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

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

Phase 1 and Phase 2 rule violations

1. Use the show appletalk globals exec command to determine whether the internetwork is in compatibility mode.

2. Enable the appletalk name-lookup-interval global configuration command and use the show appletalk neighbors exec command to determine which specific neighbor (by NBP1 name) is in compatibility mode.

3. To resolve the problem, you can perform one of the following actions:

Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 and reconfigure the internetwork

Ensure that all routers are in compliance with the two Phase 1 and Phase 2 rules

For more information on Phase 1 and Phase 2 rule violations, see the section "Phase 1 and Phase 2 Rule Violations" later in this chapter.

Misconfigured access lists or other filters

1. Use the show appletalk access-list exec command on routers in the path from source to destination.

2. Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. If there are distribution lists or other filters configured, disable them.

3. After disabling access lists, check whether remote zones and services become accessible.

4. If zones and services are now available, a misconfigured access list is the likely problem. To isolate the problem access list, enable lists one at a time until connectivity fails.

5. Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally.

6. If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.

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 up
AppleTalk routing disabled, Port configuration mismatch
AppleTalk cable range is 4-5
AppleTalk address is 4.252, Valid
AppleTalk zone is "Maison Vauquer"
AppleTalk port configuration conflicts with 4.156
AppleTalk discarded 8 packets due to input errors
AppleTalk discarded 2 packets due to output errors
AppleTalk route cache is disabled, port initializing

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

You can also display the NBP registered name of the conflicting router, which can simplify resolution of a port mismatch problem. To see registered NBP names, enable the appletalk name-lookup-interval global configuration command. This causes the show appletalk interface exec command output to display nodes by NBP registration name.

Phase 1 and Phase 2 Rule Violations

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

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

Multiple zones cannot be assigned to unary cable ranges.

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


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


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.

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

Phase 1 NBP Packet
Phase 2 NBP Packet

BrRq (Broadcast Request)

BrRq (Broadcast Request)

FwdReq (Forward Request)

LkUp (Lookup)

LkUp (Lookup)

LkUp-Reply (Lookup Reply)

LkUp-Reply (Lookup Reply)


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 

Possible Problems
Solution

Configuration mismatch

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

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

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

2. Enter the show appletalk interface exec command again. If its output still contains a "port configuration mismatch" message, check whether all router configurations agree on the network number or cable range and the zone or zone list.

3. If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment.

Configuration mismatch (continued)

4. If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cable-range 0-0 command on an extended network. This causes the router to get its configuration information from the network.

For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.

Misconfigured access lists or other filters

1. Use the show appletalk access-list exec command on routers in the path from source to destination.

2. Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command. If there are distribution lists or other filters configured, disable them.

3. After disabling access lists, check whether remote zones and services become accessible.

4. If zones and services are now available, a misconfigured access list is the likely problem. To isolate the problem access list, enable lists one at a time until connectivity fails.

5. Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally.

6. If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.

Route flapping (unstable route)

Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP1 updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.

1. Use the show interfaces exec command to check the traffic load. Check the load for each interface.

The following example is output from the show interfaces command:

Ethernet0 is up, line protocol is up
 Hardware is Lance, address is 0000.0c32.49b1 (bia  
  0000.0c32.49b1)
 Internet address is 192.168.52.26/24
 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 
255/255,  
  load 1/255
[...]

Route flapping (unstable route)

The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes.

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

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

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

Router#debug apple events 
AppleTalk Events debugging is on
Router#
%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 
250-250 down; reported bad by 200.41

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

4. If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.

You can return the timers to their defaults (10, 20, 60) by using the no appletalk timers global configuration command.

Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork.

ZIP storm

A ZIP storm occurs when a router propagates a route for which it currently has no corresponding zone name; the route is then propagated by downstream routers.

Note: Cisco routers provide a firewall against ZIP storms in the internetwork. If a Cisco router receives a routing update from a neighbor, it does not propagate that new route until it receives the accompanying zone name.

1. Use the show appletalk traffic command and check the field showing the number of ZIP requests.

The following example is output from the show appletalk traffic command:

Router#sh apple traffic
[...]
ZIP:   44 received, 35 sent, 6 netinfo
[...]
Router#

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

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

Use the debug apple zip privileged exec command to identify the network for which the zone is being requested by neighboring routers. You can also use the show apple private exec command to check the number of pending ZIP requests.

3. Identify the router that injected the network number into the internetwork (and that is causing the excessive ZIP traffic). The show appletalk traffic and show appletalk route exec commands provide information that can help you find the suspect router.

For example, you can use the show appletalk route exec command to view the AppleTalk routing table. Check whether a network shows up in the routing table, even though the display indicates that no zone is set.

If you find a network for which no zone is set, a node on that network is probably not responding to ZIP requests, resulting in the ZIP storm.

4. Determine why the node is not responding to ZIP requests. Access lists or other filters might be the cause. ZIP storms can also result from a defect in the software running on the node. Contact the vendor to determine whether there is a known problem.

Too many zones in internetwork

The Chooser in System 6 can display only a limited number of zones, which presents problems in large internetworks that have many zones.

If the Macintosh is running a version of System 6, upgrade it to System 7 or System 7.5.

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.

Table 9-5 AppleTalk: No Devices in Choose

Possible Problems
Solution

Misconfigured access lists

1. Use the show appletalk access-list exec command on routers in the path from source to destination.

2. Disable any access lists (or just those on a particularly suspect router) using the no appletalk access-group interface configuration command.

3. After disabling access lists, check whether devices appear in the Chooser.

4. If devices now appear in the Chooser, a misconfigured access list is probably filtering NBP traffic. To isolate the problem access list, enable lists one at a time until devices no longer appear.

5. Check the access lists and associated configuration commands for errors. Configure explicit permit statements for traffic that you want to pass through the router normally.

6. If problems persist, there might be more than one misconfigured access list. Continue enabling access lists one at a time and fixing misconfigured access lists until the problem is solved.

For detailed information about filtering NBP traffic using access lists, refer to the Cisco IOS Network Protocols Configuration Guide, Part 1.


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.

Table 9-6 AppleTalk: Network Services Intermittently Unavailable 

Possible Problems
Solution

Duplicate network numbers or overlapping cable-range

In AppleTalk, network numbers must be unique within an internetwork. If duplicate network numbers exist, packets might not be routed to their intended destinations.

If AppleTalk services do not appear in the Chooser for particular networks, those networks probably have duplicate network numbers.

1. Change the network number or cable-range of the suspect network to a unique value using the appletalk cable-range interface configuration command.

2. Use the show appletalk route privileged exec command to view the routing table. If the network number or cable-range continues to appear in routing tables, you have found the duplicate (because the other network using that number will continue to send routing updates).

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

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

Route flapping (unstable route)

Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.

1. Use the show interfaces exec command to check the traffic load. Check the load for each interface.

Route flapping (unstable route) (continued)

The following example is output from the show interfaces command:

Ethernet0 is up, line protocol is up
  Hardware is Lance, address is 0000.0c32.49b1 (bia 
0000.0c32.49b1)
  Internet address is 192.168.52.26/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
rely 255/255, load 1/255
[...]

The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes.

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

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

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

Router#debug apple events 
AppleTalk Events debugging is on
Router#
%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 
250-250 down; reported bad by 200.41

The debug apple events command is useful for solving AppleTalk network problems because it provides an overall picture of the stability of the network. In a stable network, the debug apple events command does not return any information. If, however, the command generates numerous messages, the messages can indicate where the problems might lie.

Turning on debug apple events will not cause apple event-logging to be maintained in nonvolatile memory. Only turning on apple event-logging explicitly will store it in nonvolatile memory. Furthermore, if apple event-logging is already enabled, turning on or off debug apple events will not affect apple event-logging.

Route flapping (unstable route) (continued)

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

4. If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.

You can return the timers to their defaults (10, 20, 60) by using the no appletalk timers global configuration command.

Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork.

ZIP storm

A ZIP storm occurs when a router propagates a route for which it currently has no corresponding zone name; the route is then propagated by downstream routers.

Note: Cisco routers provide a firewall against ZIP storms in the internetwork. If a Cisco router receives a routing update from a neighbor, it does not propagate that new route until it receives the accompanying zone name.

1. Use the show appletalk traffic command to check the field showing the number of ZIP requests:

Router#sh apple traffic
[...]
ZIP:   44 received, 35 sent, 6 netinfo
[...]
Router#

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

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

ZIP storm (continued)

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. Identify the router that injected the network number into the internetwork (and that is causing the excessive ZIP traffic). The show appletalk traffic and show appletalk route exec commands provide information that can help you find the suspect router.

For example, you can use the show appletalk route exec command to view the AppleTalk routing table. Check whether a network shows up in the routing table, even though the display indicates that no zone is set.

If you find a network for which no zone is set, a node on that network is probably not responding to ZIP requests, resulting in the ZIP storm.

4. Determine why the node is not responding to ZIP requests. Access lists or other filters might be the cause.

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


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) 

Possible Problems
Solution

Configuration mismatch

1. Use the show appletalk interface exec command. Check the output for a "port configuration mismatch" message.If the command output contains a"mismatch" message, the router configuration disagrees with that of the listed neighbor.If the command output does not include the "mismatch" message, use the clear apple interface privileged exec command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist.

Configuration mismatch (continued)

1. Use the show appletalk interface exec command. Check the output for a "port configuration mismatch" message.If the command output contains a"mismatch" message, the router configuration disagrees with that of the listed neighbor.If the command output does not include the "mismatch" message, use the clear apple interface privileged exec command on the interface in question. If the interface becomes operational after clearing, a configuration mismatch does not exist.

2. Enter the show appletalk interface exec command again. If its output still contains a "port configuration mismatch" message, check whether all router configurations agree on network number or cable range and the zone or zone list.

3. If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment.

4. If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cable-range 0-0 command on an extended network. This causes the router to get its configuration information from the network.

For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.

Invalid zone names in routing table

AppleTalk does not provide a way to update ZIP tables when changing the mapping of zone names to networks or cable ranges.

For example, if the zone name for network number 200 is Twilight Zone, but you decide to change the zone to No Parking Zone, the zone name on the interface can be changed, and the new zone name takes effect locally.

However, unless you keep network 200 off the internetwork long enough for it to be completely aged out of the routing tables, some routers will continue to use the old zone name (this is called a phantom zone). Alternatively, if you cannot keep the network off the internetwork that long, change the underlying network number when you change the zone name of a cable.

1. Use the show running-config privileged exec command to view the router configuration. Check the network numbers configured for each AppleTalk interface.

Invalid zone names in routing table (continued)

2. Make sure that there are no network numbers configured that were previously assigned to a zone that has been deleted. Change the cable-range using the appletalk cable-range interface configuration command or disable the network until it is aged out of routing tables.

3. Use the show appletalk zones command to verify that the zone no longer appears in the zone list.


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.

Table 9-8 AppleTalk: Connections to Services Drop 

Possible Problems
Solution

Route flapping (unstable route)

Excessive traffic load on internetworks with many routers can prevent some routers from sending RTMP updates every 10 seconds as they should. Because routers begin to age out routes after missing two consecutive RTMP updates, the inconsistent arrival of RTMP updates can result in constant route changes.

1. Use the show interfaces exec command to check the traffic load. Check the load for each interface.

The following example is output from the show interfaces command:

Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c32.49b1 (bia   
  0000.0c32.49b1)
Internet address is 192.168.52.26/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 
255/ 
  255, load 1/255
[...]

The load field displayed in the show interfaces command is the load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over five minutes.

Route flapping (unstable route) (continued)

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

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

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

Router#debug apple events 
AppleTalk Events debugging is on
Router#
%AT-6-PATHNOTIFY: Ethernet0: AppleTalk RTMP path to 
250-250 down; reported bad by 200.41

Caution: Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use.

4. If routes are being aged incorrectly, use the appletalk timers global configuration command to correct the problem. Suggested timer values are 10, 30, and 90 to start, but do not exceed 10, 40, and 120. The first number must always be 10, and the third value should be three times the second.

You can return the timers to their defaults (10, 20, 60) by using the no appletalk timers global configuration command.

Timers should be consistently set to the same value throughout the internetwork, or at a minimum, throughout the backbone of the internetwork.


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 

Possible Problems
Solution

Configuration mismatch

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

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

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

2. Enter the show appletalk interface exec command again. If its output still contains a "port configuration mismatch" message, check to see whether all router configurations agree on network number or cable range and the zone or zone list.

3. If router configurations disagree on these parameters, alter router configurations to bring all routers into alignment.

4. If problems persist, put the problem router in discovery mode by specifying the interface configuration command appletalk address 0.0 on a nonextended network or the appletalk cable-range 0-0 command on an extended network. This causes the router to get its configuration information from the network.

For more information about configuration mismatches, see the section "AppleTalk Configuration Mismatches" earlier in this chapter.

Phase 1 and Phase 2 rule violations

1. Use the show appletalk globals exec command to determine whether the internetwork is in compatibility mode.

2. Enable the appletalk name-lookup-interval global configuration command and use the show appletalk neighbors exec command to determine which specific neighbor (by NBP name) is in compatibility mode.

3. To resolve the problem, you can perform one of the following actions:

Upgrade AppleTalk Phase 1 routers to AppleTalk Phase 2 and reconfigure the internetwork

Ensure that all routers are in compliance with the two Phase 1 and Phase 2 rules

For more information on Phase 1 and Phase 2 rule violations, see the section "Phase 1 and Phase 2 Rule Violations" earlier in this chapter.


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.

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

Possible Problems
Solution

Router is in discovery mode, and no seed router exists on the network

1. Put the router in nondiscovery mode by assigning a network number or cable range to the problem interface using the appletalk address or appletalk cable-range interface configuration command.

2. If the problem persists, consult your technical support representative for more assistance.

Crossed serial circuits with multiple lines between two
routers

1. Check the physical attachment of serial lines to ensure that they are correctly wired.

2. If necessary, rewire the lines and check the output of the show interfaces and show appletalk interface commands to confirm that the interface and line protocol are up.

3. If the router still cannot find routes, consult your technical support representative for more assistance.

Software problem

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


AppleTalk Enhanced IGRP: Clients Cannot Connect to Servers

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

Table 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

Possible Problem
Solution

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. Use the show running-config privileged exec command on routers to make sure that RTMP is enabled on interfaces connected to LAN segments with connected Macintosh computers.

2. If RTMP is not enabled, enable it using the appletalk protocol rtmp interface configuration command.

3. If desired, disable AppleTalk Enhanced IGRP on the interface using the no appletalk protocol eigrp interface configuration command.


AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors

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

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

Table 9-1 AppleTalk Enhanced IGRP: Routers Not Establishing Neighbors 

Possible Problem
Solution

AppleTalk Enhanced IGRP is not globally configured on the appropriate routers

1. Use the show running-config privileged exec command to check the configuration of routers that should be running Enhanced IGRP. Look for appletalk routing eigrp global configuration command entries. This command enables AppleTalk Enhanced IGRP routing on the router.

2. If AppleTalk Enhanced IGRP routing is not enabled on the router, use the appletalk routing eigrp router-id global configuration command to enable it.

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

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

AppleTalk Enhanced IGRP is not enabled on interfaces

Use the show running-config privileged exec command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries.

This command must be present in order for an interface to generate AppleTalk Enhanced IGRP hello messages and routing updates.

Timer values are mismatched

1. Use the show appletalk eigrp neighbors exec command. Make sure that all directly connected AppleTalk Enhanced IGRP routers appear in the output.

2. Examine the uptime field in the show appletalk eigrp neighbors output. A continuously resetting uptime counter indicates that hello packets from the neighboring router are arriving sporadically. This might be caused by a timer value mismatch or by hardware problems.

3. Use the show interface exec command to determine whether the interface and line protocol are up. Look for high numbers in the queue fields and excessive drop counts. The queue fields displays the maximum size of the queue and the number of packets dropped due to a full queue.

If there are many drops, if the queue count is high, or if the interface or line protocol is down, there is probably something wrong with the interface or other hardware. For more information on troubleshooting hardware, see Chapter 3,"Troubleshooting Hardware and Booting Problems," and Chapter 15, "Troubleshooting Serial Line Problems."

4. Use the show running-config privileged exec command on all AppleTalk Enhanced IGRP routers in the network. Look for appletalk eigrp-timers interface configuration command entries. The values configured by this command must be the same for all AppleTalk Enhanced IGRP routers on the network.

Timer values are mismatched (continued)

5. If any routers have conflicting timer values, reconfigure them to conform with the rest of the routers on the network. These values can be returned to their defaults with the no appletalk eigrp-timers interface configuration command.

Older version of the Cisco IOS software

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


AppleTalk Enhanced IGRP: Routes Missing from Routing Table

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

Table 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

Possible Problem
Solution

Routers not establishing neighbors properly

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

AppleTalk Enhanced IGRP is not enabled on interfaces

Use the show running-config privileged exec command on routers that are running Enhanced IGRP. Check the interface configurations for appletalk protocol eigrp interface configuration command entries.

This command must be present in order for an interface to generate AppleTalk Enhanced IGRP hello messages and routing updates.

Older version of the Cisco IOS software

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


AppleTalk Enhanced IGRP: Poor Performance

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

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

Table 9-3 AppleTalk Enhanced IGRP: Poor Performance

Possible Problem
Solution

AppleTalk Enhanced IGRP and RTMP are running simultaneously on the same interface

Use the show running-config privileged exec command on network routers. Check the interface configurations to determine whether AppleTalk Enhanced IGRP and RTMP are both enabled on the same interface.

Running both AppleTalk Enhanced IGRP and RTMP on the same interface increases bandwidth and processor overhead. Determine whether both routing protocols need to be running on the interface and disable one or the other if necessary or desired.

Older version of the Cisco IOS software

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


AppleTalk Enhanced IGRP: Router Stuck in Active Mode

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

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


Note Occasional messages of this type are not a cause for concern. This is how an Enhanced IGRP router recovers if it does not receive replies to its queries from all its neighbors. However, if these error messages occur frequently, you should investigate the problem.


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

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

Table 9-4 AppleTalk Enhanced IGRP: Router Stuck in Active Mode 

Possible Problems
Solution

Active timer value is misconfigured

The active timer determines the maximum period of time that an Enhanced IGRP router will wait for replies to its queries. If the active timer value is set too low, there might not be enough time for all the neighboring routers to send their replies to the Active router.

1. Check the configuration of each Enhanced IGRP router using the show running-config privileged exec command. Look for the timers active-time router configuration command entry associated with the appletalk routing eigrp global configuration command entry.

2. The value set by the timers active-time command should be consistent among routers in the same autonomous system. A value of 3 (3 minutes, the default value) is strongly recommended to allow all Enhanced IGRP neighbors to reply to queries.

Interface or other hardware problem

1. If queries and replies are not sent and received properly, the active timer times out and causes the router to issue an error message. Use the show appletalk eigrp neighbors exec command and examine the uptime and Q Cnt (queue count) fields in the output.

The following example is output from the show 
appletalk eigrp neighbor command:
Router#show appletalk eigrp neighbor
AT/EIGRP Neighbors for process 1, router id 1
H   Address        Interface   Hold Uptime   SRTT   
RTO  Q  Seq
                               (sec)         (ms)       
Cnt Num
0   200.41          Et0           10 0:00:37     0  
3000  0  2

If the uptime counter is continually resetting or if the queue count is consistently high, there might be a hardware problem. The uptime counter is the elapsed time, in hours, minutes, and seconds, since the local router first heard from this neighbor.

2. Determine where the problem is by looking at the output of the "Stuck-in-Active" error message, which indicates the AppleTalk address of the problematic node.

3. Make sure the suspect router is still functional. Check the interfaces on the suspect router. Make sure the interface and line protocol are up and determine whether the interface is dropping packets.

For more information on troubleshooting hardware, see Chapter 3, "Troubleshooting Hardware and Booting Problems."

Flapping route

If there is a flapping serial route (caused by heavy traffic load), queries and replies might not be forwarded reliably. Route flapping caused by heavy traffic on a serial link can cause queries and replies to be lost, resulting in the active timer timing out.

Take steps to reduce traffic on the link, or increase the bandwidth of the link.

Older version of the Cisco IOS software

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


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.

Table 9-5 AURP: Routes Not Propagated Through AURP Tunnel 

Possible Problems
Solution

Misconfigured AURP tunnel

1. Use the show appletalk interfaces exec command to make sure the tunnel interface is up.

2. Use the show running-config privileged exec command to view the router configuration. Check the tunnel source and tunnel destination interface configuration command entries.

3. Exterior routers must have their tunnel interface configured with a tunnel source and a tunnel destination command. Make sure that the tunnel destination command on each router points to the IP address of the remote exterior router's tunnel interface.

Missing appletalk route-redistribution command

1. If changes on the remote network are not learned through the tunnel, use the show running-config privileged exec command to view the router configuration. Check for an appletalk route-redistribution global configuration command entry.

2. If the command is not present, add it to the configuration.

Problem with underlying IP network

If there are routing problems in the transit network (the IP network through which the AURP tunnel passes), then AppleTalk traffic might have difficulty traversing the tunnel.

To troubleshoot your TCP/IP network, follow the procedures outlined in Chapter 7, "Troubleshooting TCP/IP."


FDDITalk: No Zone Associated with Routes

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


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


Table 9-6 outlines the problem that might cause this symptom and describes solutions to that problem.

Table 9-6 FDDITalk: No Zone Associated with Routes

Possible Problems
Solution

FDDITalk version mismatch

If any routers in the internetwork are using software releases prior to Cisco IOS Release 10.0, there is a possibility of a FDDITalk version mismatch. Make sure that all routers on the ring are using either pre-FDDITalk or FDDITalk and are not a combination of the two.

Following are the FDDITalk implementations for each software release:

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

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

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

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

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


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 

Possible Problems
Solution

Missing arap network command entry

1. Use the show running-config privileged exec command to view the router configuration. If you are running Cisco IOS Release 10.2 or later, look for an arap network global configuration command entry.

2. Configure the arap network global configuration command to enable ARA on the router or access server. The syntax for the arap network command is as follows:

arap network [network-number] [zone-name]

Missing arap network command entry (continued)

Syntax Description:

network-number(Optional) The AppleTalk network number. The network number must be unique on your AppleTalk network. This network is where all ARAP1 users appear when they dial in to the network.

zone-name(Optional) The AppleTalk zone name.

AppleTalk routing is not enabled on the appropriate interfaces

1. Use the show apple interfaces exec command to determine whether interfaces are operational and whether AppleTalk routing is enabled on the correct interfaces.

2. If AppleTalk routing is not enabled on the proper interfaces, enable it where appropriate. Refer to the Cisco IOS Network Protocols Configuration Guide, Part 1 for detailed information on configuring an interface for AppleTalk routing.

Modem, serial line, or hardware problems

For serial line troubleshooting information, see Chapter 15, "Troubleshooting Serial 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.

Table 9-8 ARA: Connection Hangs After "Communicating At..." Message 

Possible Problems
Solution

MNP4 Link Request packets sent by client ARA stack are responded to by the serving modem instead of the ARA server

1. Check the version numbers of the ARA software on the client and the Cisco IOS software on the access server.

If you are using ARA version 1.0 or Cisco IOS software prior to Release 10.2, it is advisable to upgrade to ARA 2.0 and Cisco IOS Release 10.2 or later. ARA 2.0 modifies the framing of MNP4 Link Request packets, allowing them to be passed to the access server rather than responded to by the serving modem.

MNP4 Link Request packets sent by client ARA stack are responded to by the serving modem instead of the ARA server (continued)

2. If you cannot upgrade your software, try modifying the behavior of the modem to use a LAPM-to-No Error Correction fallback instead of a LAPM-to-MNP4-to-No Error Correction fallback. The modem no longer listens for and respond to MNP4 messages, allowing MNP4 packets to reach the access server.

Note: Many modems cannot be configured in this manner.

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


ARA: Cannot Send or Receive Data over ARA Dialin Connection

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

Table 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

Possible Causes
Suggested Actions

Missing arap network command entry

1. Use the show running-config privileged exec command to view the router configuration. If you are running Cisco IOS Release 10.2 or later, look for an arap network global configuration command entry.

2. Configure the arap network global configuration command to enable ARA on the router or access server. The syntax for the arap network command is as follows:

arap network [network-number] [zone-name]

Syntax Description:

network-number(Optional) The AppleTalk network number. The network number must be unique on your AppleTalk network. This network is where all ARAP users appear when they dial in to the network.

zone-name(Optional) The AppleTalk zone name.

Missing autoselect command

1. Use the show running-config privileged exec command to view the router configuration. Check to see whether the autoselect arap line configuration command is configured on the router.

2. If the command is not present, add it to the configuration.

MNP5 enabled on answering modem

1. Check to see whether the answering modem has MNP5 error correction enabled.

2. If MNP5 is enabled on the answering modem, disable it. For information on checking or changing the modem configuration, refer to the modem documentation.

Zone list is empty

1. Use the show appletalk route and show appletalk zones privileged exec commands to determine whether the router can see its ARA routes and zones.

2. Use the show appletalk interface ethernet exec command and make sure that the output matches your Apple network parameters.

3. Change the interface configuration as required.

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.

Table 9-10 ARA: Slow Performance from Dialin Connection 

Possible Problems
Solution

Flow control is not enabled, is enabled only on one device (either DTE or DCE), or is misconfigured

1. Configure hardware flow control on the line using the flowcontrol hardware line configuration command. Hardware flow control is recommended for access server-to-modem connections.

Flow control is not enabled, is enabled only on one device (either DTE or DCE), or is misconfigured (continued)

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

C2500(config)#line 2
C2500(config-line)#flowcontrol hardware

Note: If you cannot use flow control, limit the line speed to 9600 bps. Faster speeds can result in lost data.

2. After enabling hardware flow control on the access server or router line, initiate a reverse Telnet session to the modem via that line.

For instructions on initiating a reverse Telnet session, see the section "Establishing a Reverse Telnet Session to a Modem" in Chapter 16, "Troubleshooting Dialup Connections."

3. Use a modem command string that includes the RTS/CTS flow command for your modem. This command ensures that the modem is using the same method of flow control (that is, hardware flow control) as the Cisco access server or router. See your modem documentation for exact configuration command syntax.

For more information about troubleshooting access server- to-modem connections, see Chapter 16, "Troubleshooting Dialup Connections." For information on troubleshooting hardware problems, see Chapter 3, "Troubleshooting Hardware and Booting Problems."