Chapter 5
Designing Apple Talk Networks

CISCO INTERNETWORK DESIGN EXAM OBJECTIVES COVERED IN THIS CHAPTER:

ü Use Enhanced IGRP for path determination in internetworks that support IP, IPX, and AppleTalk.

ü Examine a client’s requirements and construct an appropriate AppleTalk design solution.

ü Choose addressing and naming conventions to build manageable and scalable AppleTalk internetworks.

ü Use Cisco IOS ™ features to design scalable AppleTalk internetworks.

The explosive growth of the Internet and the scalability of the Internet Protocol (IP) have greatly impacted current network designs. More specifically, their growth and popularity have affected deployments of most other network protocols, including easy-to-configure AppleTalk. In fact, the days of AppleTalk-only networks are virtually non-existent.

AppleTalk became popular because of the many benefits its design afforded. It was designed to negate the need to configure addresses, network masks, and default gateways on individual workstations and to handle naming and service updates automatically. These features greatly reduced the number of administrative errors that could be introduced, and along with the early successes of the Macintosh, provided networks with many other advantages. Nonetheless, AppleTalk has become less popular because of its relatively poor scalability, which is due in large part to its reliance on broadcasts.

Recently, a number of relatively new services have been added to Apple-Talk to counteract some of the scalability problems found in the original protocol. These new services, plus the many benefits of AppleTalk and the resurgence of the Macintosh platform in recent years, make it important to address the issues that frequently confront network designers working with the protocol.

Designing for AppleTalk Networks

The design goal of any network is typically the same: provide a scalable, logical platform from which users may complete tasks and other functions with a high degree of performance and reliability.

AppleTalk, as a protocol, can address many aspects of this goal in its native form. However, it falls short when it comes to scalability. This shortcoming combined with the rise in popularity of IP-only segments in lieu of multiprotocol networks has made AppleTalk fall out of favor. While some older applications may still rely on traditional AppleTalk services, the most recent versions of AppleTalk and MacOS do support the exclusive use of IP. It is important to note, though, that AppleTalk is a separate protocol from IP, and there are no dependencies between them. The current CID examination continues to focus on AppleTalk, and so readers preparing for the examination should focus on this chapter in that context. With the release of System 8 and later, however, more and more production networks that use Macintosh systems are forgoing the AppleTalk protocol completely. This chapter is irrelevant to those installations and will only be of interest from a historical perspective or for those designers migrating from AppleTalk to IP.

Before beginning to design an AppleTalk network, it is important to evaluate the validity of using AppleTalk in a new network installation. While the rest of this chapter is dedicated to designing and installing AppleTalk networks, a designer must first address the conventional wisdom in modern network design, which, as was just mentioned, is to use a single protocol on the network where possible. While not without its shortcomings, that protocol is IP.

Once an AppleTalk network design is chosen, the designer will wish to focus on creating a design that is easy to use and maintain. This is especially true when deploying a network in an environment without a full-time technical staff, such as would be found in smaller schools, for example. However, these objectives are always a good idea regardless of venue—remember the adage, “Keep it simple.”

In addition, the designer will want to create an AppleTalk design that accomplishes as many of the following goals as possible:

•  Reduce broadcast traffic.

•  Maintain scalability.

•  Make configuration easy, where possible.

•  Use policy routing, where appropriate.

•  Incorporate with non-AppleTalk protocols, where appropriate. This might include the use of AppleTalk tunnels or a numerically significant addressing scheme that conforms to IP, IPX, and AppleTalk.

The designer should also keep in mind that AppleTalk is not a single protocol, but rather a family of protocols that interoperate. These protocols include:

•  AppleTalk Address Resolution Protocol (AARP)

•  Routing Table Maintenance Protocol (RTMP)

•  AppleTalk Echo Protocol (AEP)

•  Name-Binding Protocol (NBP)

•  AppleTalk Transaction Protocol (ATP)

•  Zone Information Protocol (ZIP)

•  Datagram Delivery Protocol (DDP)

•  AppleTalk Data Stream Protocol (ADSP)

	According to convention, this chapter will use the term AppleTalk. However, a protocol’s definition is actually based on its underlying physical media. Thus, the correct terms are EtherTalk, FDDITalk, and so forth.

The most important protocols will be presented in subsequent sections, but the remainder will only be discussed here briefly and will not be referred to again in this chapter. These less important protocols include AEP and ADSP. AEP is useful in troubleshooting and operates similarly to IP Ping. ADSP is a connection-oriented protocol that provides reliable full-duplex byte-stream services.

Figure 5.1 illustrates the relationship between AppleTalk and the OSI model. As with most protocols, there are no direct mappings between the theoretical OSI model and the actual divisions of the protocols themselves. However, based on the function each protocol serves, it is appropriate to place DDP and AARP into the network layer (Layer 3) and ZIP and NBP into the session and transport layers, respectively.

FIGURE 5.1  AppleTalk and the OSI model