anguish%elma.epfl.ch@VMA.CC.CMU.EDU (DAVID ANGUISH) (12/18/89)
Strange !! We have a large number of Kinetics KFPS-4 (about 60 of them)
and 24 KFPS-2's dirctly connected to 3 1/2 km of Ethernet backbone cable.
Recently we decided to install CISCO AppleTalk routers (10 are installed)
to break with the 254 connections by Ethernet limitation.
Our problem is the following. The Cisco routers are dropping a byte
in their routing tables which has the effect of shifting, up one, the data.
This of course is seen by all routers that route AppleTalk as the creation
of new nets on the network. What is worse is that this can happen repeatedly
in quick succession and inflates the size of the RTMP packets until the Cisco
is overwhelmed and crashes.
This looks like a problem of hardware or timing. What is worying, is
that Cisco Routers use the long RTMP packet style,of which nobody is really sure
(let alone Apple) if this is the correct way of doing it(maintaining Routers).
Any comments or similar experiences ???!!!??
DW.Anguish, EPFL, Lausanne, CH.
email: anguish@sic.epfl.chjosh@cayman.com (12/19/89)
>> Our problem is the following. The Cisco routers are >> dropping a byte in their routing tables which has the effect of >> shifting, up one, the data. I've seen something very similar at one large network. A KFPS (a FP-2 or FP-3, I believe) was occasionally dropping bytes from packets. In this case I am fairly sure the problem was the FastPath, and not a router. In any event, we learned some things about this situation which may help you: One particular packet I observed with dropped bytes was an NBP lookup on EtherTalk (Phase 1), which turned into a pretty wild RTMP packet. The FastPaths on this net were running KIP. The KIP code had a bug in the route table update routine. No test for maximum distance was ever applied to new routes. This allowed the addition of bogus nets with large distances. The distance was incremented when the route was added. Although the routes would eventually expire, there was always one router which still had the routes, so as soon as one box expired the routes, it would pick them up from another router, with the distance incremented further. After a little while some router would advertise a distance of 255, and another router would add the route, incrementing the distance to 0. At this time the route recieves the protection of an algorithm which never expires distance 0 routes. Now even the FastPath believes it is attached to this bogus net. Because the route was learned via EtherTalk, it became an alias for the EtherTalk network. A series of other bugs in other router products turned these bad networks into great network storms. These bugs included performing lookups in the bogus nets, even though they had no zone name; routing broadcast packets; and wrapping the packet hop count back to zero. If there are bogus RTMPs on your net, and you run KIP, you can greatly reduce your trouble by patching your KIP code: *** /tmp/rtmp.c Mon Dec 18 17:25:20 1989 --- /tmp/rtmp.c.new Mon Dec 18 17:24:56 1989 *************** *** 156,161 **** --- 156,166 ---- } } /* add */ + + /* don't add nets which are too far away */ + if (at->hops >= 15) + return; + /* tuple net # wasnt in our table, add it */ if ((ar = arfree) == 0) return; /* oops, out of room */ This patch is untested, but should do the right thing by preventing the addition of obviously bogus routes, and by this also eliminating the possibility of creating new distance 0 routes. Credit for the discovery of this problem (as far as I know) goes to Dan Lanciani at Harvard. Hope this helps. ------------------------------------------------------------------------------ Josh Littlefield Cayman Systems, Inc. University Park at MIT josh@cayman.com 26 Landsdowne Street (617) 494-1999 Cambridge, MA 02139 ------------------------------------------------------------------------------