Questions & Answers Collected from Partners@Lists
Mac
Index
| Apple Printer Mysteriously Switches AppleTalk Zones 11/96 |
Question:
At random times, [a Laserwriter] will move itself out of the designated zone (Forsythe-Eng), which is the default zone for the router, to another zone within our router (Spruce). Hmmmm...what do you think is causing this to happen?
Answer:
I think that coordinating the activity of the four Fastpaths on Steve's network will probably solve the problem of the printer occasionally jumping to another zone. (A lengthy explanation follows, useful only to people who manage their department's Appletalk services).
Lengthy Explanation...
Printers, like all Appletalk devices, will adopt the default zone for the local network unless told otherwise. Apple Laserwriters and HP Laserjets come with a utility program that you can use to assign the printer to a zone from the list of zone names registered for the local network. This same utility lets you give the printer a name that's meaningful to you.
It turns out that the default zone for the network is "Spruce." So the printer in question is losing its zone assignment, and adopting the default zone instead.
The information about what the default zone name is, and what other optional zone names are, comes from the Appletalk router on the network, almost always a Shiva Fastpath. The Fastpath broadcasts its information about zones and how to get to them roughly once every 10 seconds. Other devices, notably Novell Netware servers configured to offer Appletalk file and print services, also act as Appletalk routers. In Steve's case, using Neon Software's RouterCheck program I see only Shiva Fastpaths providing router information.
Devices on the network like Laserwriter printers can become confused if a network has multiple Appletalk routers that broadcast different zone information. These "zone wars" can result when one router's zone list becomes corrupted.
In the case of the network Steve McGriff takes care of, there are four Shiva Fastpaths. Using software from Shiva called Net Manager, I can see that these four devices have different sets of zone information, so this may be the cause of the disappearing printer.
One solution would be to reconfigure these four Fastpaths so only one of them talks to the ethernet side. This is accomplished by setting "Ethertalk Phase 2" on in the NetDB entry for only one Fastpath instead of all four as they are today. This reduces the likelihood that there wil be any zone list confusion on this network. The other three Fastpaths may be providing Appletalk gateway services to Localtalk (Phonenet) networks. If not, they should be shut down.
Appletalk routing information (a list of Appletalk zones and Fastpath IP addresses used to get to the zone) is generated from information recorded in NetDB by the department's LNAs. Each Fastpath is configured to listen for a message that says, in effect, "A new routing table is available -- come and get it!" This message is sent from argus.stanford.edu, the computer whose address is the familiar 36.56.0.151.
Each Fastpath should be configured to recognize argus as a trusted source for the message to reconfigure. If the Fastpath doesn't know to listen to argus, then the message goes unheeded. The result is that, over time, a Fastpath's routing table doesn't get updated, and the likelihood of corrupted data increases.
If the Fastpath doesn't know where to go for the routing table, then it can't download (using TFTP) the latest information. In addition to argus, two more computers, 36.56.0.150 and 36.56.0.152, can act as the source of the routing info file. The Fastpath's local configuration should be set to use one of these three addresses.
Again using Shiva Net Manager, I can see that the four Fastpaths have differing information about where to look for the routing table. Net Manager doesn't always report this information properly, so a closer inspection using Shiva Fastpath Manager is necessary.
A report that summarizes Appletalk zone information can be found at URL:
http://www/group/networking/sunet.reports/atalkatab/stanford.atalkatab.2
This is the Appletalk Administrative Table ("atalkatab" for short) that coordinates how the Fastpaths on the Stanford Appletalk network talk to each other.
For Steve's area, the relevant line in the Atalkatab is:
171.3 - 171.3 E 36.171.0.130 Spruce Puichon Forsythe-Eng Forsythe-SCC \ Forsythe-Services # Comm-Srvs-Net (43779)
Here's how to decode the above information:
| 171.3 - 171.3 | The Appletalk Phase 2 network number. Since the two values are the same, this is a network with 256 or fewer Appletalk addresses assigned to it. There are a few dorm nets that use a bigger range. This number is displayed in "dotted hexcidecimal form." |
| E | This is an ethertalk network. |
| 36.171.0.130 | The address of the Shiva Fastpath that acts as gateway to this Appletalk network. This is kfps-forsythe-eng, a Fastpath in Forsythe Hall. |
| Spruce | The default zone for this Appletalk net. This is the zone that devices will join if they are not configured otherwise Puichon, etc other zone names registered in NetDB for this network segment. |
| # | Comm-Srvs-Net a comment describing in English who uses the network. |
| (43779) | The Appletalk number in decimal form, calculated as follows from the hexcidecimal Appletalk number 171.3 (171*256) + 3 = 43,779. |
So now we know that "Spruce" is the default zone name and 36.171.0.130 is the Fastpath NetDB is telling others to use to reach this network. Therefore, we should shut down the other three Fastpaths, properly configure and re-start the 36.171.0.130 Fastpath. Once it's going properly, the other three Fastpaths can be reconfigured and restarted. This might take 60 minutes to accomplish because the four Fastpaths are in three different buildings.
One last comment -- if the above steps don't solve the problem, an additional cause might be the battery in the Fastpath that maintains its configuration in memory. There are many Fastpaths on campus that are 4 or 5 years old, and they're reaching the end of their battery life. A battery that doesn't maintain proper voltage can be the source of the problem. Unfortuantely, the battery in a Fastpath is soldered in place, so it's not a do-it-yourself replacement.
Local Network Administrators who would like advice and guidance with Appletalk problems should contact their Networking Systems consultant. If you don't know who that is, send email to help@networking.
Question: Steven McGriff, Dist Computing & Comm Systems
Answer: Chip Haven, Networking Services
11/96
| Stanford
| ITSS
| EP
Home | Info/App
| Events
|
Resources: | ListQnA |
Doc's
| Quick
Guide | Campus
Sites | Other
Sites | Vendor
Sites |
Please feel free
to submit any suggestions
or relevant web links
This page modified April 1997.