John Albritton, CCIE
$55.00 0-07-134743-7
|
Cisco IOS Essentials
John Albritton, CCIE $55.00 0-07-134743-7 |
|
| Reserve your copy at a Bet@ Bookstore near you! |
Contact Bet@ Books © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use. |
AppleTalk is a layer-3 network protocol developed by Apple. AppleTalk is a protocol suite for peer-to-peer communication, which allows any host to share its files, devices, and services. AppleTalk has two versions – Phase 1 and Phase 2. All references to AppleTalk in this chapter are to Phase 2.
As with the other network protocols, our coverage of AppleTalk will begin with a brief overview of host addressing and protocol operation. We will then cover the IOS commands for the basic configuration of AppleTalk as we make modifications to our three-router internetwork.
An AppleTalk layer-3 address is 24 bits long, and, just as with any other layer-3 address, has a network part and a node part. The network part of the address is 16 bits long and is written in decimal form. The node part is the last 8 bits and is written also written in decimal. The full address is written with the network part and the node part separated by a period (.).
A range of network numbers identifies an AppleTalk networks. We call this range of network numbers a cable range. A host on the network has a network address within the cable range; a cable range is normally written as two decimal numbers separated by a hyphen. A host’s node address must be between 1 and 254. For example, a host on a network with the cable range 300-309 could have an address of 304.219 or 300.1; AppleTalk identifies both addresses as being on the same network.
AppleTalk uses the AppleTalk Address Resolution Protocol (AARP) to map AppleTalk addresses to MAC addresses on LAN’s. When an AppleTalk host needs to send a packet, it sends an AARP request packet to the broadcast address of its network. The AARP request packet contains the AppleTalk address of a desired destination host. When the destination host receives the AARP broadcast and finds its address, the host sends an AARP reply to the source host. The AARP reply contains the MAC address that is placed into the frame header during the encapsulation process on the source host. The source host also caches the information in the reply for later use. This entire process is practically the same one that is performed by IP ARP.
We assign AppleTalk addresses to AppleTalk routers. Other AppleTalk hosts dynamically acquire an address when they start. An AppleTalk host, like a Macintosh computer, determines the cable range of the network to which it is attached by asking the local routers for it. The host then randomly picks a network number from within the cable range and a node number from 1 to 254. The address must be verified to be unique on the network; therefore, the host uses AARP to see if another host on the network has the same address. The host sends AARP request packets onto the network asking for the MAC address corresponding to its own randomly selected AppleTalk address. If no other host responds, the host is assured of having a unique address. If the host receives an AARP reply to its requests, the address is not unique, and another address is randomly selected. The process repeats until a unique address is acquired.
In an AppleTalk internetwork, each network has a cable range, and networks are logically grouped into zones. A zone is a collection of networks that can be searched for services. Zones have alphanumeric, text names that we make up when we build an AppleTalk internetwork. Normally, zone names are descriptive of the services offered by the hosts on its networks. For example, Headquarters and Dallas Sales Office are both valid zone names. An AppleTalk network must be a part of at least one zone. If a network is in multiple zones, the first zone defined for the network is its primary zone.
All of the routers connected to a network must agree on the cable range and zone name(s) for the network. When AppleTalk packet processing is started on a router interface, the AppleTalk routing process checks for other AppleTalk routers on the interface’s network, and, if it finds any, it verifies that the other routers have the same cable range and zone(s) defined. If a discrepancy is found, AppleTalk processing stops on the interface until the discrepancy is corrected.
We are going to use the OSI Reference Model to help discuss the components that make up AppleTalk protocol suite. Figure 9-1 shows the AppleTalk stack as compared to the seven layers of the OSI Reference Model.
<<<J126 – Figure 9-1 AppleTalk Stack Compared to OSI Reference Model>>>
This chapter’s goal is to show the commands for configuring AppleTalk on an IOS-based router; therefore, this overview is meant only to provide enough background information for us to understand what is happening when we configure AppleTalk on a router.
An AppleTalk hosts access to the network medium happens at layers 1 and 2 with link access protocols such as EtherTalk, TokenTalk, and LocalTalk. LocalTalk is an Apple-developed LAN type; EtherTalk is used for AppleTalk over Ethernet, and TokenTalk is used for AppleTalk over TokenRing.
AppleTalk hosts on Ethernet or TokenRing networks always use a SubNetwork Access Protocol (SNAP) encapsulated frame header.
Layer 3 has the Datagram Delivery Protocol (DDP). DDP provides connectionless, end-to-end connectivity between two hosts. The DDP header of packet contains the source and destination AppleTalk addresses. Upper layer protocols and applications are identified by a socket number within the DDP header.
Figure 9-1 shows RTMP (Routing Table Maintenance Protocol), NBP (Name Binding Protocol), and AEP (AppleTalk Echo Protocol).
RTMP is the default AppleTalk routing protocol. RTMP is a distance vector routing protocol that uses hop count as its metric and does periodic updates every 10 seconds. As with IPX, IOS also supports the use of EIGRP to share route information among routers. NBP provides a form of AppleTalk host name to address resolution. It allows AppleTalk host to locate services by their name, type, or zone. AppleTalk hosts use AEP for connectivity testing.
ZIP allows routers to discover the zones defined in an internetwork. All routers maintain a Zone Information Table (ZIT) which contains the names of the zones and the cable ranges of the networks in each zone.
Layers 6 and 7 contain the AppleTalk Filing Protocol (AFP) and the AppleTalk printing protocol. AFP is used for host file sharing, and Postscript is used for printing.
When IOS receives a frame containing an AppleTalk packet, IOS strips the frame header and trailer from around the packet and sends the packet to the AppleTalk routing process. The routing process searches the AppleTalk routing table for an entry matching the network part of the destination AppleTalk address in the DDP header.
During our initial configuration in Chapter 3, we enabled AppleTalk on two of our routers, Dallas and FortWorth. Figure 9-2 shows the existing internetwork with the already-configured AppleTalk cable ranges and zones.
<<<J127 – Figure 9-2 Current AppleTalk Internetwork>>>
AppleTalk is running on Dallas’s Ethernet0 and Serial1 interfaces and on FortWorth’s Ethernet0 and Serial0 interfaces. Figure 9-2 shows the AppleTalk addresses for the active interfaces. AppleTalk connectivity has not been established to Austin, yet. Figure 9-3 shows the current AppleTalk routing table on Dallas as displayed with the show appletalk route command.
<<<Figure 9-3 Show AppleTalk Route Output on Dallas>>>
The routing table display tells that there are three entries (Line 4). Dallas has two directly-connected AppleTalk networks; each is identified with the letter C in left column of the entry (Lines 8 and 10). The letter R in the left column of an entry signifies an RTMP-learned route (Line 9). The network with cable range 200-209 is the Ethernet LAN on FortWorth. Dallas’s next hop gateway to reach FortWorth’s Ethernet is 1001.200, which is the AppleTalk address of FortWorth’s Serial0 interface. The values shown in the brackets indicate the route’s hop count and status, respectively. For the entry on Line 9 the contents of the brackets are 1/G. The network is 1 hop away, and its status is Good. That is correct; G stands for Good. Other status possibilities are B for Bad and S for Suspect (maybe bad). Each entry in the AppleTalk routing table includes the name of the primary zone for the network described.
Since we have seen the routing table, we should take a look at the ZIT (zone information table). Figure 9-4 shows the output of the show appletalk zone command on Dallas.
<<<Figure 9-4 Show AppleTalk Zone Output on Dallas>>>
Dallas’s ZIT has three zones (Line 6). Each zone contains one network. In the next section we will be building onto our AppleTalk internetwork by configuring AppleTalk on Austin and the links that connect it.
The only protocol whose traffic IOS routes by default is IP; therefore, therefore, we must first turn on the routing of AppleTalk traffic. We use the global configuration command appletalk routing to do that. We then configure the assigned AppleTalk cable range and zone(s) to each interface that is to transmit and receive AppleTalk packets. The interface configuration command appletalk cable-range is used to configure the network number, and the interface configuration command appletalk zone is used to configure the zone name.
The AppleTalk cable range must be entered as two decimal numbers separated by a hyphen; the first number must be less than the second number. Cable ranges are not allowed to overlap in the internetwork. We can specify a specific AppleTalk address to be assigned to an interface, or we can allow IOS to find a unique address on its own.
If an interface’s network is in more than one zone, multiple appletalk zone commands can be entered. The zone specified in the first command becomes the primary zone.
As soon as we enter a valid cable range and zone on an interface, IOS attempts to locate other routers on the interface’s network and verify the information. If there is no other router on the network or the information from other routers matches the local router, AppleTalk is enabled on the interface.
<<<J128 – Figure 9-5 Internetwork Diagram Showing Austin AppleTalk Cable Ranges and Zones>>>
Figure 9-5 shows an updated internetwork diagram with the cable ranges and zones to be used for Austin AppleTalk connectivity. We will reference this information in the configuration below.
AppleTalk is already enabled on Dallas and FortWorth so we will start our configuration example on Austin then move to the Dallas and FortWorth interfaces that are connected to Austin. The commands for configuring AppleTalk on Austin, based on the Figure 9-5 information, are shown in Figure 9-6.
<<<Figure 9-6 AppleTalk Configuration on Austin>>>
The routing of AppleTalk packets is enabled on Austin (Line 3). We have three interfaces on which we want to process AppleTalk traffic; the first on is Ethernet0 (Line 4). The cable range for Austin’s Ethernet LAN is 300-309 (Line 5). Since we did not include a specific AppleTalk address, IOS will locate a unique address in the cable range with the selection process that uses AARP as was described in Section 9.1. Once IOS acquires a unique address, it will include the address on the appletalk cable-range command that becomes part of the running configuration. The Ethernet LAN is in the zone named Strike (Line 6). On Serial0 (Line 7), we have assigned a specific AppleTalk address, 1003.2 (Line 8). Since Serial0 is connected to a point-to-point WAN and point-to-point WAN’s have only two hosts, the cable range is a range of one, 1003-1003. Austin’s two serial interfaces are part of the same AppleTalk zone, WAN, that the serial link between Dallas and FortWorth is. The WAN zone will contain three networks, all WAN’s.
We now need to do the configuration on Dallas and FortWorth that will provide AppleTalk connectivity to Austin. Figure 9-7 shows the completion of AppleTalk configuration on the Dallas Serial0 interface that will be used for Austin connectivity, and Figure 9-8 shows the completion of AppleTalk configuration on the FortWorth Serial1 interface.
<<<Figure 9-7 AppleTalk Configuration on Dallas Serial0>>>
<<<Figure 9-8 AppleTalk Configuration on FortWorth Serial1>>>
Both of the WAN’s that connect to Austin have been defined to be part of the WAN zone, and we have specified the AppleTalk addresses on the Dallas and FortWorth interfaces.
RTMP is the default routing protocol for AppleTalk. If we are going to use it, there is no routing protocol configuration necessary. As soon as AppleTalk processing is enabled on an interface, RTMP is enabled on the interface.
AppleTalk has been configured on all of the routers in our internetwork. Now we will use some of the commands that show us the status of AppleTalk. The output of the following commands will be shown in this section:
The show protocols command shows us the protocols that IOS is configured to route, the status of each interface, and the primary characteristic(s) of each protocol on each interface. For AppleTalk, the primary characteristics are the cable range and the primary zone. Figure 9-9 shows the output of the show protocols command on Austin after AppleTalk addresses have been verified by the neighbor routers.
<<<Figure 9-9 Show Protocols Output on Austin After AppleTalk Configuration>>>
The routing of AppleTalk packets is enabled on Austin (Line 4). IOS has acquired the AppleTalk address 304.219 for use on Ethernet0 (Line 11). We see also that IOS has accepted the AppleTalk address that we specified for Serial0 and Serial1 (Lines 18 and 22).
The show appletalk route command shows the contents of the AppleTalk routing table. We first covered this command in Figure 9-3. The new AppleTalk routing table on Dallas is shown in Figure 9-10.
<<<Figure 9-10 AppleTalk Routing Table on Dallas After AppleTalk Configuration>>>
<<<Figure 9-11 AppleTalk Routing Table on Austin After AppleTalk Configuration>>>
The routing tables now show six routes each – three that are directly connected and three that are learned from RTMP. Dallas’ AppleTalk path to reach Austin’s Ethernet LAN is via Austin Serial1 interface, which is out its own Serial0 interface (Line 10, Figure 9-10). The routing tables show the primary zone for each cable range. To view the cable ranges that are a part of each zone, we use the show appletalk zone command, which we first showed in Figure 9-4. The new ZIT on Dallas is shown in Figure 9-12.
<<<Figure 9-12 AppleTalk Zone Information Table on Dallas After AppleTalk Configuration>>>
The WAN zone now contains three networks, all of the WAN’s (Line 4), and the Strike zone has been added to the table (Line 5).
<<<Figure 9-13 Show AppleTalk Interface Output on Dallas>>>
The show appletalk interface command returns information about the AppleTalk configuration of each interface. The output of the command on Dallas is in Figure 9-13. The output contains the AppleTalk cable range, address, and zone for each interface that has AppleTalk enabled. For Ethernet0 (Line 8), the cable range is the one we configured (Line 9). The AppleTalk address is 100.10, and it is valid (Line 10). IOS considers an AppleTalk address to be valid once it has been verified to be unique and the cable range and zone(s) assigned to the interface have been verified to be the same as any other routers connected to the same network. In the case of Ethernet0, there are no other routers on the same network. AppleTalk gleaning (Line 12) is the process by which IOS processes all of the AppleTalk traffic being received by an interface and dynamically builds an AARP cache based on the information in the frames. The gleaning process is disabled by default.
There are two routers on each of the serial links; therefore, each of the routers must go through the verification process once the neighbor router on the other end of the serial link is discovered. On the Serial0 interface (Line 14), the address we entered has been validated (Line 16), and it was verified by the other host on the network, 1002.2 (Line 18).
The show commands described above are good ways of verifying the configuration of AppleTalk; however, they do very little for making sure that AppleTalk connectivity has been established. For that we need to use the AppleTalk ping application. The AppleTalk ping application uses AEP to transmit AppleTalk echo request packets to an AppleTalk destination address and receive AppleTalk echo replies. Three ways of doing an AppleTalk ping in IOS are as follows:
Figure 9-14 shows examples of all three options. The AppleTalk pings are being done from Dallas, and the destination address is that of Austin’s Ethernet0 interface as obtained with the show protocols command in Figure 9-9.
<<<Figure 9-14 AppleTalk Ping Examples>>>
When the normal ping is used to performing the AppleTalk ping (Line 1), we depend on IOS recognizing that the address we have typed is an AppleTalk address. IOS correctly interprets the addresses an AppleTalk based on its format, and then IOS does the AppleTalk IPX ping by sending five AppleTalk echoes to Austin’s Ethernet0 interface and receiving five replies. An exclamation point (!) indicates the successful reception of a ping reply from the target host (Line 5); if no reply were received, IOS would display a period (.) instead. The success rate and response time information is given on the last line (Line 6).
Using the ping appletalk command (Line 7) tells IOS that the address in the command is an AppleTalk address so that IOS does not have to figure it out. The result is the same as that of the normal ping.
We invoke an extended ping by typing the ping command without an address (Line 13), and then IOS prompts us for the protocol (Line 14). Entering appletalk at the protocol prompt will cause IOS to ask for an AppleTalk destination address (Line 15). The extended ping gives us the opportunity to change the number of echoes sent, the size of the echoes, and the reply timeout before actually performing the ping operation. With the default parameters, the extended ping process is the same as the one for the first two pings.
AppleTalk EIGRP has the same basic operation as IP EIGRP, which we described in Section 7.7.3.2. AppleTalk EIGRP is Cisco-proprietary. It is supported only on Cisco routers for the sharing of AppleTalk routes. AppleTalk EIGRP can replace RTMP on networks that have only Cisco AppleTalk routers; these networks are usually WAN’s.
The implementation of AppleTalk EIGRP can save WAN bandwidth since EIGRP performs incremental updates for routes. This means that updates are transmitted only when a change occurs, not at the usual 10-second interval of RTMP
We will configure AppleTalk EIGRP on the WAN’s of our internetwork and leave RTMP on the LAN’s. The configuration of AppleTalk EIGRP is different from the configuration of other routing protocols we have seen; the enabling and disabling of an AppleTalk routing protocol are done in interface configuration mode rather than a routing process configuration mode.
Before we can enable AppleTalk EIGRP on an interface, we must enable it in global configuration mode. The appletalk routing eigrp command along with a router identification number will enable us to start AppleTalk EIGRP on an interface. Unlike IP EIGRP and IPX EIGRP, which require a common ASN on all of the routers running them, AppleTalk EIGRP requires a unique router identification number on each of the routers using it to exchange routes.
We enable AppleTalk EIGRP on an interface by using the interface configuration mode command appletalk protocol eigrp. Turning on AppleTalk EIGRP on an interface does not automatically turn off RTMP on the interface; therefore, we should disable RTMP on the interface to avoid running two AppleTalk routing protocols and using network bandwidth needlessly. RTMP is disabled on an interface with the no appletalk protocol rtmp.
To configure the redistribution routes between RTMP and AppleTalk EIGRP, we use the global configuration command appletalk route-redistribution. Issuing this command will allow the AppleTalk EIGRP process to send RTMP-learned networks in its updates, and it will allow RTMP to send EIGRP-learned networks in its updates. In some older versions of IOS, this command appeared in the running configuration automatically when AppleTalk EIGRP was enabled. We will enter it manually just in case IOS does not do it automatically.
Figure 9-15 shows the implementation of AppleTalk EIGRP on Dallas. Figure 9-16 shows the configuration of AppleTalk EIGRP on FortWorth. Figure 9-17 has the configuration commands on Austin.
<<<Figure 9-15 AppleTalk EIGRP Configuration on Dallas>>>
<<<Figure 9-16 AppleTalk EIGRP Configuration on FortWorth>>>
<<<Figure 9-17 AppleTalk EIGRP Configuration on Austin>>>
We selected the followed router ID’s: 100 for Dallas (Figure 9-15, Line 3), 200 for FortWorth (Figure 9-16, Line 3), and 300 for Austin (Figure 9-17, Line 3). We have enable AppleTalk EIGRP on the Serial0 and Serial1 interfaces of all three routers. For each WAN interface we entered two commands: appletalk protocol eigrp to enable AppleTalk EIGRP and no appletalk protocol rtmp to disable RTMP since it was enabled by default. As an example, these two commands are shown on Lines 5 and 6 of Figure 9-17.
Just as with the other versions of EIGRP, IOS maintains a neighbor table and a topology table for AppleTalk EIGRP. These can be displayed with the show appletalk eigrp neighbors and show appletalk eigrp topology commands, respectively. The structure of the AppleTalk versions of the tables is similar to that of the IP versions we described in Section 7.7.3.4.
AppleTalk configuration requires that the IOS AppleTalk routing process be started with the appletalk routing command. Then we must go to each interface that is to be involved in routing AppleTalk packets and assign it an AppleTalk cable range and at least one AppleTalk zone. The appletalk cable-range command is used to assign and AppleTalk cable range to an interface, and the appletalk zone command is used place an interface into an AppleTalk zone.
The internetwork that we now have for AppleTalk connectivity is shown in Figure 9-18. The final internetwork diagram shows all of the cable ranges, zones, and interface addresses. The boundary of AppleTalk EIGRP processing is the same as that of the WAN zone.
<<<J129 - Figure 9-18 Final AppleTalk Internetwork Diagram>>>
Figure 9-19 shows the AppleTalk-specific commands from Dallas’ running configuration. Figure 9-20 shows FortWorth’s AppleTalk-specific commands taken from the running configuration. Figure 9-21 shows the AppleTalk-specific commands from Austin’s running configuration.
<<<Figure 9-19 Dallas AppleTalk Configuration Commands>>>
<<<Figure 9-20 FortWorth AppleTalk Configuration Commands>>>
<<<Figure 9-21 Austin AppleTalk Configuration Commands>>>
We have enabled AppleTalk routing on the three active interfaces of each router in the internetwork. We also enabled AppleTalk EIGRP and disabled RTMP on the WAN interfaces while leaving RTMP on the LAN interfaces. If we have a mixed-vendor router environment, we probably would have left RTMP without EIGRP on all interfaces.
We are going to leave AppleTalk running on our test internetwork; however if we wanted to stop the AppleTalk routing process on a router, we can enter the following global configuration command.
no appletalk routing
The no appletalk routing command will remove, from the running configuration, the commands dealing with AppleTalk routing. These commands include those that define AppleTalk cable ranges, zones, and routing protocols.
| Chapter: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| Reserve your copy at a Bet@ Bookstore near you! |
Contact Bet@ Books © 1999 The McGraw-Hill Companies, Inc. All rights reserved. Any use of this Bet@ Book(TM) is subject to the rules stated in the Terms of Use. |
