Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!McRCIM.McGill.EDU!peta From: peta@McRCIM.McGill.EDU (Peter Whaite) Newsgroups: comp.protocols.appletalk Subject: uab+ problem. Message-ID: <1991Mar6.234858.25707@thunder.mcrcim.mcgill.edu> Date: 6 Mar 91 23:48:58 GMT Sender: news@thunder.mcrcim.mcgill.edu Reply-To: peta@McRCIM.McGill.EDU (Peter Whaite) Organization: McRCIM, McGill University Lines: 93 Nntp-Posting-Host: thunder.mcrcim.mcgill.edu We have uab+ running on a SUN3/80 (SUNOS4.0.3 -- dont ask), two Shiva boxes, kip on a SUN3 machine, and 3 ethertalked Macs. All of these are on the same subnet. uab+ (zone=Sol) kip (zone=Apollo) | | | | ----+-+--------------------------+-+------------- Ethertalk Macs | Ethernet | | | Shiva Shiva | | | | -----+----------------- -----+------------------- Phonenet (zone=Clouds) Phonenet (zone=Flurries) atalkad configures both Shiva boxes. Anyway, after a while the net starts getting really bogged down, and the problem is that when uab+ comes up it gets told (by one or both of the shivas) that there is a net 0.0. It seems like the distance (number of hops?) is 132!! I`m not sure if this problem happened recently or if it has always been around as our network has been in a state of flux for some time now. New macs have been added recently. Could this be a Phase II incompatibiliy? How are Phonenetted macs configured for Phase I or Phase II atp? Here is the uab output... sol# ./uab -D 8 uab: 18:34:37 03/06/91 Port description match on sol uab: 18:34:37 03/06/91 interface le0 uab: 18:34:37 03/06/91 local delivery is modified KIP forwarding uab: 18:34:37 03/06/91 network 0.41 uab: 18:34:37 03/06/91 zone 3-'Sol' uab: 18:34:37 03/06/91 Ethernet address for le0 is 08:00:20:07:18:54 uab: 18:34:39 03/06/91 new route for net 0.41 at hash [bkt 7, d 0] uab: 18:34:39 03/06/91 port 161412 host route added for network 0.41 uab: 18:34:39 03/06/91 host port: net 0.41, bridge self, dist 0, port 161412, s tate good uab: 18:34:39 03/06/91 insert for Sol [14,0] uab: 18:34:39 03/06/91 port 161412 zone name Sol inserted uab: 18:34:39 03/06/91 port 161412 acquired node 24 on interface le0 uab: 18:34:40 03/06/91 BRIDGE NODE CREATE uab: 18:34:40 03/06/91 PORT 161412 uab: 18:34:40 03/06/91 ID len 8, byte 0 191 look bridge node 191 at hash [bkt 54, d 0] uab: 18:34:40 03/06/91 NEW RTMP: port 161412, source 191 uab: 18:34:40 03/06/91 new route for net 0.0 at hash [bkt 0, d 0] uab: 18:34:40 03/06/91 create_entry: net 0.0 uab: 18:34:40 03/06/91 new: net 0.0, bridge 191, dist 131, port 161412, state g ood uab: 18:34:40 03/06/91 new route for net 3.1 at hash [bkt 63, d 0] uab: 18:34:40 03/06/91 create_entry: net 3.1 uab: 18:34:40 03/06/91 new: net 3.1, bridge 191, dist 2, port 161412, state goo d uab: 18:34:40 03/06/91 new route for net 3.2 at hash [bkt 38, d 0] uab: 18:34:40 03/06/91 create_entry: net 3.2 uab: 18:34:40 03/06/91 new: net 3.2, bridge 191, dist 1, port 161412, state goo d uab: 18:34:40 03/06/91 new route for net 2.41 at hash [bkt 44, d 0] uab: 18:34:40 03/06/91 create_entry: net 2.41 uab: 18:34:40 03/06/91 new: net 2.41, bridge 191, dist 1, port 161412, state go od uab: 18:34:42 03/06/91 will zip 191 for 2.41 uab: 18:34:42 03/06/91 will zip 191 for 3.2 uab: 18:34:42 03/06/91 will zip 191 for 3.1 uab: 18:34:42 03/06/91 will zip 191 for 0.0 uab: 18:34:42 03/06/91 zipping 191 for 4 networks uab: 18:34:42 03/06/91 insert for Apollo [13,0] uab: 18:34:42 03/06/91 ZIPPED: from 0.41.191 network 2.41 for zone Apollo uab: 18:34:42 03/06/91 insert for Clouds [2,0] uab: 18:34:42 03/06/91 ZIPPED: from 0.41.191 network 3.2 for zone Clouds uab: 18:34:42 03/06/91 insert for Flurries [23,0] uab: 18:34:42 03/06/91 ZIPPED: from 0.41.191 network 3.1 for zone Flurries There is more when the other bridge info comes in, but after that is just keeps trying to find a good route for net0.0 again and again, but there are too many hops. Any ideas. Please mail direct if this is a frequently asked question that everyone except me knows the answer too.