Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!UCBCMSA.BITNET!CLIFF
From: CLIFF@UCBCMSA.BITNET (Cliff Frost {415} 642-5360)
Newsgroups: comp.sys.proteon
Subject: Problems with P4200s not updating routing tables.
Message-ID: <8906051737.AA29493@devvax.TN.CORNELL.EDU>
Date: 5 Jun 89 17:37:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 48

John,
You may be right that this is a Proteon flaw, but I'm not sure based
on the evidence you give.  I suspect you would see the same thing if you
had the same number of routers on an ethernet, all shoving these hundreds
of routes at eachother at exactly the same time.

Think about it.  Say you have 9 p4200s on your p80.  Every 30 seconds
each and every one of them broadcasts their entire routing table.  At
the precise same moment all the ethernet routers (p4200 and others)
broadcast all their routes.  I'd be willing to bet that your non-Proteon
hosts don't have anything like this amount of simultaneous packet
traffic to deal with.  This is why they don't lose routes, it isn't
because they aren't made by Proteon.

In my experience with this (with 350-400 routes in our tables), the
routes coming from ethernets would occasionally lose.  Since we've
reduced our routing tables to less than 100 routes we haven't seen
any of these problems at all.

I think there are two problems here, neither of which are unique to
Proteon:

1)  The RIP spec.  It says you *have* to poison all your routes.  I can
    think of no reason you should have to do this.  If you learn a
    route to net X on interface A, why bother poisoning route X to net A
    ALL the time?  Why not simply poison it for a few minutes after
    you time it out?  This would cut down *enormously* on the number of
    simultaneous packets routers have to process.

    Proteon has no choice here--they have to follow the spec.

2)  The fact that things "synch up".  As Van Jacobson has demonstrated,
    RIP processes will end up in sync, even if they
    start out at random times.  This is why all these packets flood
    the routers all at once.

    Proteon could do something about this, there have been several
    suggested techniques (although I don't know of any proven in practice).

Actually, OSPFIGP may help with your problems.  You don't have to run it
everywhere, just run it on your p80 backbone.  It *should* (if all the
hype comes true) generate much less traffic on the ring and therefore
not clog up your routers.

        Cliff Frost                   (415) 642-5360
        Central Computing Services    <cliff@berkeley.edu>
        University of California      CLIFF AT UCBCMSA
        Berkeley, CA 94720