Xref: utzoo comp.dcom.sys.cisco:1269 comp.protocols.appletalk:6001
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!bruce!merlin!ianh
From: ianh@resmel.bhp.com.au (Ian Hoyle)
Newsgroups: comp.dcom.sys.cisco,comp.protocols.appletalk
Subject: Re: Appletalk phase 2, disappearing zones & cisco routers
Message-ID: <ianh.675988855@morgana>
Date: 3 Jun 91 22:40:55 GMT
References: <ianh.675588243@morgana>
Sender: usenet@resmel.bhp.com.au (USEnet nntp account)
Organization: BHP Research - Melbourne Laboratories, AUSTRALIA
Lines: 57

ianh@resmel.bhp.com.au (Ian Hoyle) writes:

>We are having a considerable problem here with zone information dropping out
>of the chooser at random intervals.

[ a brief explanation ]

>Has this problem turned up elsewhere, and if so where should I start 
>looking to track this sucker down ?? I'm _very_ perplexed by what is 
>going on. I don't really want to hang a sniffer on my net and look at all 
>the packets :-) .....

Well we have finally fixed our Appletalk zone dropout problems (a big thankyou
to all those people who responded).

It was a combination of several things, one *big* blooper was our fault the 
other ... well we could have avoided it.

Since the Cisco configuration was done by our head office people who were
loath to let us get into the box we didn't really know how it was configured. 
When we finally did gain password access we discovered much to our chagrin 
that our Appletalk Zone  name had been misspelt. This effectively turns off 
routing in the box and helped to explain the zone on the other side of the 
cisco from not appearing.

However, this did not stop the zone dropouts.

After some judicious use of a packet sniffer looking at the RTMP/AARP packets
as they hit our routers and watching what they responded with the only
conclusion we could come to was:

"Get rid on non-seeding routers and hard wire zone names/address ranges on
ALL routers"

It was the only thing that we could think to try since the configurations
had been working prior to introducing the cisco. A big problem here was
probably power failures which allowed non-seeding routers to come to life
before seeding routers.

As an aside we have found the best diagnostic tool to be having laserwriters
in some of the localtalk zones set up as print queues on DEC Pathworks. The
VAX print subsystem constantly "tickles" the device to make sure that it is 
alive which very quickly shows if any of the zones are disappearing.

All now seems to be well (famous last words :-)

	ian
--
                Ian Hoyle
     /\/\       Image Processing & Data Analysis Group
    / / /\      BHP Research - Melbourne Laboratories
   / / /  \     245 Wellington Rd, Mulgrave, 3170
  / / / /\ \    AUSTRALIA
  \ \/ / / /
   \  / / /     Phone   :  +61-3-560-7066
    \/\/\/      FAX     :  +61-3-561-6709
                E-mail  :  ianh@resmel.bhp.com.au