ianh@resmel.bhp.com.au (Ian Hoyle) (05/30/91)
We are having a considerable problem here with zone information dropping out
of the chooser at random intervals.
The scenario:
a) Two Webster multiport gateways, one running transition ethertalk routing
(hence our phase 2 network has a single net number range)
b) Two Kinetics fastpaths - phase 2 only
c) DEC VAX running LANworks (phase 2) and acting as the seeder
d) a cisco with phase 2 routing turned on. (an IGS running 8.2 rel 3)
I know I can't exhaustively provide the whole scoop here as to our network
setup, but ever since phase 2 routing was turned on in the cisco, problems
have turned up with *all* zones disappearing from the chooser on ethernet
connected macs (sometimes only a few disappear - this occurs if the Mac is
on phase 1 or 2).
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 :-) .....
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.audees@sid.sps.mot.com (Randy Dees) (05/31/91)
In article <ianh.675588243@morgana>, ianh@resmel.bhp.com.au (Ian Hoyle) writes: > d) a cisco with phase 2 routing turned on. (an IGS running 8.2 rel 3) > > I know I can't exhaustively provide the whole scoop here as to our network > setup, but ever since phase 2 routing was turned on in the cisco, problems > have turned up with *all* zones disappearing from the chooser on ethernet > connected macs (sometimes only a few disappear - this occurs if the Mac is > on phase 1 or 2). > > 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 :-) ..... > when we enabled phase II appletalk with the 8.2 roms, we began experiencing problems with data corruption of appletalk packets through the cisco. it was obvious in ascii files that were copied from macs on one side of the cisco to a remote appleshare server. binary files (applications) would not work. it was real obvious using apple's disk maker program that does a cecksum of the file. ___________ T1 ___________ | cisco |--------------| cisco | |_________| |_________| | | mac--------| |-----appleshare server randy dees dees@sid.sps.mot.com uunet!motsps!sid.sps.mot.com!dees
ianh@resmel.bhp.com.au (Ian Hoyle) (06/04/91)
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
tom@wcc.oz.au (Tom Evans) (06/06/91)
In article <ianh.675988855@morgana>, ianh@resmel.bhp.com.au (Ian Hoyle) writes: > 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 ] > > 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 ... 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" That is _A_ "solution" but doesn't describe the real cause of the problem, which was: 1. The CISCO had a mis-spelt zone name configured into it. 2. The CISCO recognised this condition and supposedly disabled its EtherTalk Phase 2 interface as a result. At least it said it did. 3. Disabled or not, the CISCO was still sending AppleTalk RTMP (Routing Table Maintenance Packets) out the "disabled" interface. 4. Other routers on the network, receiving these RTMP packets and learning of "new" network numbers were trying (continuously - every 10 seconds or so) to find out the zone names by sending ZIP packets to the CISCO. 5. The CISCO had disabled the AARP protocol on EtherTalk, so it refused to respond to any AARP requests to resolve its address. All the other routers were stable, but "unsatisfied". 6. Every time a Mac on EtherTalk received an RTMP packet from the CISCO it would switch its "A-Router" pointer to point to the Cisco. It would then try to send "off-net" packets there, but then couldn't get the AARP requests resolved, and so the packets got dropped. 7. With 6 (or so) routers on Ethernet, this means that every time you open the Chooser there is a 15% chance of "A-Router" pointing to the CISCO, which would then refuse to answer the Chooser's request for a Zone List. So no zones visible in Mac Choosers (sometimes). Talk about "calling attention to a configuration problem" :-) :-). ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 A.C.N. 004 818 455