Previous Table of Contents Next


TABLE 5.2 AppleTalk GetZoneList and NBP Filter Commands
Command Function
appletalk distribute-list in Applied in interface mode, this command filters routing updates coming in on the interface. It is used in concert with an access list.
appletalk distribute-list out The appletalk distribute-list out command is applied on an interface and filters outbound routing updates. Neither the in nor the out version of the command should be used with AT EIGRP.
appletalk getzonelist-filter The GetZoneList filter controls the router’s replies to ZIP GZL requests from the Chooser.
appletalk access-group Like IP access groups, the appletalk access-group command applies an access list to an interface.
appletalk permit-partial-zones AppleTalk zones may span cable ranges. As a result, the router may learn of a zone from one of two or more cable ranges that service that zone, which results in a partial zone. By default, the router will drop the zone completely. The permit-partial-zones command alters this behavior and continues to advertise the zone even if one or more portions of the zone are unavailable. Spanned zones may be accommodated with this command; however, for diagnostic purposes it is better to maintain a one-to-one match whenever possible.

AppleTalk Tunnels with GRE

There are instances where the designer may wish to use a single protocol in the network backbone, and with increasing frequency that protocol is IP. However, if the corporation needs to connect two or more AppleTalk segments using the backbone, this problem is resolved with AppleTalk tunneling, wherein the AppleTalk packets are encapsulated in another protocol.

Tunneling is typically an encapsulation of one protocol inside another—in this specific instance, AppleTalk inside of IP. There are two tunneling encapsulations: Generic Routing Encapsulation (GRE) and Cayman. Cayman is used when connecting a Cisco router to a GatorBox, and GRE is used when connecting two Cisco routers. This section will focus only on GRE.

From a logical perspective, tunnels are point-to-point links. As such, each link requires the creation of a separate tunnel. Note that GRE tunnels are not AURP tunnels (although they are similar). GRE tunnels do not encompass a routing process like AURP, for example.

Designers should consider the negatives of using tunnels versus using two protocols on the backbone and configuring the AppleTalk protocol. The following list should assist in this evaluation:

•  With tunnels, performance is decreased.
•  Tunnels require additional configuration.
•  Tunnels add overhead to both packets and processor utilization.
•  Tunnels permit maintenance of a single protocol in the backbone, which may simplify configuration and troubleshooting within the core.
•  AppleTalk tunnels should be deployed in star topologies to connect isolated LANs.
•  If tunnels are not used, designers should evaluate AT EIGRP in the core along with the deployment of AppleTalk.

Network Design in the Real World: Tunnels

While tunnels are a possible way to solve many design problems, it seems as though most architects are migrating away from this solution. The primary reasons for this involve training and supportability. The installation of a tunnel is fairly straight-forward; however, it becomes substantially more complex as the number of tunnels increases. In addition, diagnostic processes no longer follow the intraprotocol methodologies that many technicians learned and employed. Rather than troubleshooting an AppleTalk problem, the administrator must add a diagnostic step to troubleshoot the IP portion and confirm that fragmentation and routing for the IP protocol is functioning correctly. As a result, it’s best to consider the arguments for and against using tunnels and then establish a policy for your installation if you decide to go ahead with them—like potato chips, you can’t have just one tunnel.

Some of the issues you should consider include:

Documentation—Will your team update and maintain a complete listing of all tunnels and their functions?

Troubleshooting—Does the expertise exist in all layers of the organization to troubleshoot tunnels and their problems? This answer requires knowledge of both protocols in use (the encapsulation and the native) and the hops between the end points of the tunnel.

Solvability—Unrelated to AppleTalk, one environment that I’m familiar with used tunnels to address subnets that are not contiguous with Interior Gateway Routing Protocol (IGRP). The ultimate solution was to migrate to EIGRP and complete an addressing project that seemed to extend forever. Most of the staff contended correctly that tunnels are a dirty patch to a chronic problem and that the company needed to invest in the resources to directly address the root cause. Ultimately, the scope grew to incorporate the original fixes and the removal of over fifty tunnels.

Scalability—This is included here because it is one of the bastions of network design; however, it really reverts back to solvability. Does the use of a tunnel solve a problem that cannot be resolved any other way?

Macintosh IP

Macintosh IP (MacIP) was an interesting protocol, albeit a short-lived one. Rather than providing an IP stack, MacIP acted, more accurately, as a proxy or gateway. While most modern installations use a fully compliant version of the IP stack for the Macintosh, MacIP software allowed IP connectivity over the lower-level DDP protocol and required the command appletalk macip for operability on Cisco routers.

MacIP was most frequently configured to support LocalTalk or Apple-Talk Remote Access (ARA). These installations required MacIP in order to permit clients access to IP resources. LocalTalk was a low-bandwidth networking solution that preceded AppleTalk. ARA is still used in some installations, and it was an efficient means of connecting Macintosh devices to the network via a modem.


Previous Table of Contents Next