Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!cayman.com!josh
From: josh@cayman.com
Newsgroups: comp.protocols.appletalk
Subject: Re: Cisco AppleTalk Router overflow
Message-ID: <8912182240.AA03565@cuba.Cayman.COM>
Date: 18 Dec 89 22:40:11 GMT
References: <891218144047.20c0209e@SIC.Epfl.CH>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 69

>>         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
------------------------------------------------------------------------------