peta@McRCIM.McGill.EDU (Peter Whaite) (03/07/91)
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. bschmidt@bnr.ca (Ben Schmidt (BNR)) (03/07/91)
In article <1991Mar6.234858.25707@thunder.mcrcim.mcgill.edu> peta@McRCIM.McGill.EDU (Peter Whaite) writes: > 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? Peter, Apple retro-actively changed the ATP1 RTMP spec, when they introduced ATP2/Internet Router, so that the first routing tuple in an ATP1 RTMP packet is an RTMP version number. To an ATP1 router, this tuple looks like net 0 at 132 hops or some such nonsense. Sources of these "modified" ATP1 RTMP packets could be any Apple Internet Router s/w, or possibly any other ATP1/P2 transition gateway on your net - the Shiva's?) In an *ideal* world, this retro-active change to the ATP1 spec would have caused no problems: any other ATP1 router should just drop that tuple since: a) net 0 is an invalid net number. (well actually, an "unknown" net) b) 130 exceeds the 15 hop count limit and the net associated with it should be not be further propogated. Guess you don't work in an *ideal* world either? :-) Retroactively changing existing protocol specs (as opposed to introducing new ones, like ATP2) is never nice. Not advertising it, is even less nice. Ben Schmidt Bell-Northern Research, Ltd. Ph: (613) 763-3906 Information P.O. Box 3511, Station C FAX:(613) 763-3283 Technology Ottawa Canada K1Y 4H7 bschmidt@bnr.ca