)
FIGURE 5.2 The Macintosh Chooser
| Previous | Table of Contents | Next |
It is important for designers to compose naming conventions that provide unambiguous names for nodes. In AppleTalk, names are ultimately presented in the format Node Name: Device Type@Zone. This format relates directly to the address information of the node, i.e., the zone name is the logical grouping of devices and the node name relates to a specific machine. The device type provides the socket information referenced earlier in this chapter. The device type might appear as Server:AFPServer@Sybex Sales. Cisco recommends that user nodes be named for their user and that they be listed last name first to facilitate searching. Unlike some other platforms, Macintosh resources frequently serve as both client and server; therefore, there may be numerous device types for a particular resource.
The Chooser in Macintosh systems is similar to the Network Neighborhood in Windows networks. See Figure 5.2. Apple users utilize the Chooser to select files, print, and perform other services.
FIGURE 5.2 The Macintosh Chooser
Under any version of MacOS, a Macintosh will send a GetZoneList (GZL) query to populate the resource list in the Chooser. This message is sent to every router that services a zone and to every server node in that zone. Each will then respond to the requester. Therefore, designers should limit the number of resources per zone so that each request returns a small number of responses. This rule is particularly important for zones that are frequently accessed, such as a server zone.
Most Macintosh computers have been upgraded to System 7 or greater. (System is the name of the Macintosh operating system.) When such is not the case, designers should stress the importance of this deployment. The AppleTalk Chooser uses NBP to locate resources on the network, resources that are organized based on the objects’ type, zone, and name. Before System 7, the Chooser would send a broadcast every three seconds while the user had the Chooser window open, which obviously generated a great deal of traffic. And, because the message was transmitted as a broadcast, the network’s performance could suffer. With the release of System 7, the Chooser began to use a delay between broadcasts that increases exponentially, which has reduced the rate at which broadcasts are sent.
Dynamic routing within the AppleTalk environment may use a number of protocols, which include AppleTalk RTMP, AppleTalk EIGRP (Enhanced Interior Gateway Routing Protocol), and AURP (AppleTalk Update-Based Routing Protocol). This section will introduce each of these along with information for designers to consider when selecting the appropriate protocol for their environment.
While floating static routes are typically not incorporated into most AppleTalk designs, Cisco introduced the concept of floating static routes for AppleTalk in IOS version 11. This feature may be useful for designers when incorporating backup routes into the network.
The default AppleTalk routing protocol is RTMP, which is very similar to the Routing Information Protocol (RIP) found in IP. Both protocols are limited to a hop count of 15, and AppleTalk always incorporates a split-horizon update mechanism. Unlike IP RIP, though, RTMP sends updates every 10 seconds. Updating so frequently significantly adds to the chatty reputation of the overall protocol. Updates appear in the form of “tuples,” which contain the cable range and hop count values.
The designer must consider a number of factors with RTMP. First, networks are limited to 15 hops due to the requirements of the routing protocol. This limitation may not be a large concern, as a well-designed network should rarely need 15 hops between networks, but the limitation remains and is a factor in the design. Second, RTMP is very chatty, as noted before, and so the designer may wish to use another protocol to conserve bandwidth and resources. However, this option is not always available because workstations and servers need to hear updates in order to operate on the network. Consequently, populated segments do not have RTMP disabled.
The designer should also consider the following with regard to AppleTalk RTMP packets:
By using this information, the designer may calculate the impact that routing updates have on the network. This impact is especially important on low-speed WAN links, where bandwidth may be severely limited. It is clear that a large routing table, transmitted every 10 seconds in its entirety, would quickly consume a substantial percentage of the bandwidth on a 56Kbps circuit.
Partial-mesh networks are also thwarted by the demands of split-horizon updates in RTMP. As a result, designers will need to use full-mesh topologies or consider the other two routing protocols, AT EIGRP or AURP. The EIGRP version of AppleTalk is perhaps best suited to address this problem.
As with all of the EIGRP routing protocols, the AppleTalk EIGRP (AT EIGRP) is proprietary to Cisco and requires the administrator to commit to an all-Cisco solution. For some environments, this restriction does not pose a significant shortcoming, and the use of AT EIGRP can greatly enhance the scalability of the AppleTalk protocol.
 | Unlike EIGRP for the IP and IPX protocols, AT EIGRP does not use the same autonomous system (AS) or process identifier for all routers in the network. In fact, the AT EIGRP identifier must be different for each router in the network that will participate in AT EIGRP. This requirement is an important design and documentation consideration that should be incorporated into the addressing and naming convention. In addition, the number following the AT EIGRP command, appletalk routing eigrp router-number, is not an AS number but a router-number, as shown. |
As noted in the previous section, the default AppleTalk routing protocol, RTMP, does not scale well. This is due to its 15-hop-count limitation and its frequent broadcasts of the entire routing table. In addition, the required use of split-horizon updates can limit designs that use partial-mesh configurations. This limitation is negated with the use of AT EIGRP.
The exclusive use of AT EIGRP is most appropriate on WAN links. Nonetheless, it may also be used in the backbone and other transit segments that do not require RTMP updates. When enabling AT EIGRP, the router will automatically redistribute route information between AT EIGRP and RTMP. The most significant benefits to AT EIGRP are its conservation of bandwidth (updates occur only following a network change) and rapid convergence (under one second following a link failure). Of course, convergence times within the RTMP environment will be limited by that protocol.
| Previous | Table of Contents | Next |
){kind=link}