|Previous||Table of Contents||Next|
|Its important to keep in mind that Apple devices cannot be placed in AT EIGRP-only segments because they must receive RTMP updates.|
To calculate the metric in AT EIGRP, the router employs a simple formula that makes each hop appear as a 9,600bps link. The RTMP hop count information is preserved.
The formula used is as follows:
AT EIGRP metric = number of hops x 25652400
As noted in the AppleTalk RTMP section, RTMP is limited in partial-mesh network designs because of the requirement that split-horizon must always be used. In AT EIGRP, this requirement no longer exists, and so RTMP may, therefore, be better suited for such designs as these. The command to remove split-horizon from AT EIGRP networks is no appletalk eigrp-splithorizon.
No, someone didnt just lose their lunch. AURP specifies a standard way of connecting AppleTalk networks over point-to-point lines, including dial-up modems and T1 lines. More importantly, it provides a specification for tunneling AppleTalk through foreign network systems, such as TCP/IP, X.25, OSI, and DECnet.
AURP also reduces routing update traffic. As opposed to the default 10-second update interval of RTMP, AURP updates routing tables only when a network change occurs. These updates include changes only to the topology and not the entire routing table, which further reduces the volume of traffic on the WAN link. Another benefit to the protocol is that it is an open standard under the Internet Engineering Task Force (IETF), which makes it well suited to multivendor environments. The same is not true with AT EIGRP.
Designers should remember the following when considering AURP:
Figure 5.3 illustrates the AURP tunnel configuration.
FIGURE 5.3 The AURP tunnel over an IP-only WAN
As found in most protocols, Cisco has incorporated a number of platform-specific features that can enhance the functionality of the overall system. In AppleTalk, these features include the aforementioned AppleTalk EIGRP routing protocol and the AppleTalk access lists. In addition to the typical Cisco access list, a number of protocol-specific access lists are available to the designer, including ZIP filters and NBP filters. These will be presented in this section.
AppleTalk access lists operate in much the same way as they do in IP or other routing protocols. Therefore, the administrator or designer may use them to create distribute lists that control RTMP packets and block cable ranges. They may also be used as part of a security model.
It is important to note that there are additional filters in AppleTalk that are specifically designed to handle certain restrictions in AppleTalk networks. These are presented in this section, and the designer should use them when appropriate. For example, you should not use distribute lists to block zone information. Doing so may cause problems within the network. It is best to use the ZIP reply filter or the GetZoneList filter. All of these filters are based on AppleTalk access lists.
Zone Information Protocol (ZIP) packets advertise zone information to the network. This information must relate to the route, or routes, that corresponds to a particular zone. When ZIP advertises information about a route that does not have a corresponding zone, it can cause a ZIP storm. Cisco routers prevent ZIP storms by holding routing updates for networks that have not sent corresponding zone information. In so doing, the potential for ZIP storms is greatly reduced. Note that this feature greatly increases the stability of the network, but it may slow the propagation of route information.
Available since Cisco IOS 10.2, AppleTalk ZIP reply filters can be an effective mechanism for blocking zone information at the router. This action may be warranted at a border router between two organizations, but AppleTalk is typically not shared between organizations. Rather, the function is used to control zone information between different divisions within the companyeither on departmental or geographical boundaries. In all cases, this function is employed between administrative domains.
The ZIP reply filter does not affect RTMP updates between routers but does squelch the ZIP reply to the corresponding ZIP request, effectively hiding the zones from the opposing network. The network, or cable range, associated with that zone will also be removed from the routing table, since there is no associated zone name.
A separate function available to AppleTalk designers is the free-trade zone. This zone may be created between two organizations or two parts of the same domain. In both cases, networks on either side of the free-trade zone are blocked from the other.
The command that applies the ZIP reply filter is appletalk zip-reply-filter.
It is possible to limit the zone information presented to a group of users with GetZoneList filters. This mechanism may be used to provide limited security or to simplify a portion of the network.
The administrator places the GetZoneList filter on the router that services the users. The filter must be placed on every cable range that user nodes use to access the network. This placement requirement limits the scalability of this function. The filter operates by responding to GetZoneList queries with a parsed version of the network zone list.
The NBP filters were introduced with version 11 of the IOS and are used to block specific services from hosts.
The commands that relate to GetZoneList and NBP filters as shown in Table 5.2.
|Previous||Table of Contents||Next|