|Previous||Table of Contents||Next|
|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 routers 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.|
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 anotherin 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:
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, its 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 themlike potato chips, you cant have just one tunnel.
Some of the issues you should consider include:
DocumentationWill your team update and maintain a complete listing of all tunnels and their functions?
TroubleshootingDoes 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.
SolvabilityUnrelated to AppleTalk, one environment that Im 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.
ScalabilityThis 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 (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|