Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!SUVM.BITNET!JMWOBUS
From: JMWOBUS@SUVM.BITNET ("John M. Wobus")
Newsgroups: comp.sys.proteon
Subject: Problems with P4200s not updating routing tables.
Message-ID: <8906051537.AA28968@devvax.TN.CORNELL.EDU>
Date: 5 Jun 89 15:31:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 77

>We've had trouble with our P4200s dropping routes, presumably because they
>are discarding incoming RIP information.  Proteon suggested we spend more
>money replacing what they just sold us with their newer equipment, which
>we have done to some extent.  We have also eliminated all RIP information
>about networks other than or own subnets from our network (using static
>default routes instead).
>
>Has anyone else had this sort of problem with P4200s?  If so, how did you
>solve it?  It has bothered us to no end that we bought into this stuff,
>then had to spend additional money buying new versions before we got a
>working network (by "working network", I mean a network which would not
>spontaneously disconnect telnet users several times a day).
>
>Also, it strikes me that software can be written to do other things
>besides drop routes when things get busy--we've never had such a problem
>with our non-Proteon routers.  It seems to me that each of our remaining
>P4200-10s is a time-bomb ready to start killing routes again when things
>get busy, and that our P4200-31s would do the same at some busier level,
>given the priorities of the software.

Thanks for all the response and interest in the problem I outlined in the
above quote.  Here are answers to several people's queries and
suggestions:

(1) It happened under 8.0.  Upgrading to 8.1 did NOT solve the problem:
    no noticeable change.
(2) Re serial links: we have only 1 serial link (T1) and though it may have
    suffered from the problem, the problem was hurting us most on other
    gateways with no serial links.
(3) Someone asked about my comment on Proteon's recommendation.  Proteon
    wanted to see our network configuration & map to check them.  They
    recommended upgrading to 8.1.  When that didn't help, all we got
    was suggestions: reduce the load on the gateways (which we did, but
    you can only do so much of this without moving computers from building
    to building, etc); reduce the amount of RIP information by using static
    defaults (which we did); upgrade to faster P4200s (which we did).
(4) Each of our gateways had (and has) a default network route.  Now, we
    depend upon them completely, whereas during the problem, we were also
    trying to use the RIP information which NYSERNet provides us.  Subnets
    were and are handled by RIP.  Subnet routes were clearly getting dropped:
    user complaints were about reaching our own computers; network routes
    were probably getting dropped too, but they are used less and their users
    are more used to occasional failures.   We run NO Gated.  The P4200s
    that lost routes were on an Ethernet with several other (non-Proteon)
    gateways which always had all the routes.  Thus
    I assume the RIP was on the Ethernet, but the P4200s didn't
    always manage to get it in their tables.  We went through the ringer
    and are very likely to have eliminated all simple problems like
    failing to "enable sending subnet routes".
(5) Yes, we run DECnet.  In order to reduce the chances of this problem, we
    have run gateways in parallel, one DECnet only, and one IP only--this
    also strikes me as throwing good money after bad.  We deal with all the
    routes that NYSERNet gives us (which I believe includes all the NSFnet
    regionals, but never included other networks hanging off of ARPAnet)
    which I recall being in excess of 200 networks.  We contribute 30-40 subnet
    routes of our own.  Milo S. Mendin says "As for not deleting routes
    upon the timeout of that route, the RIP spec says you're supposed to
    do that."  In fact, I believe our problem was that RIP-info on the network
    never reached the routing table: this has nothing to do with timeouts
    except that later, it is the timeout that actually erases the route.
(6) I don't know if OSPFIGP would help, but it does us little good
    until our other gateways' manufacturers also support it.  Anyhow,
    I would judge it a RIP implementation problem: who could say whether
    Proteon will do something similar when they implement OSPFIGP?

We started using P4200s largely because we liked the idea of using a
counter-rotating fiber ring to interconnect the buildings: it has no
single point of failure, and all that.  We decided to live with a
proprietary ring architecture while we wait for FDDI.  However, we have
found that the large majority of our problems are gateway problems rather
than network problems: we could have installed an Ethernet backbone using
fiber repeaters, avoided being locked into a single vendor and the users
would hardly notice any difference in performance or reliability.
However, more reliable gateways would easily be noticed.

John Wobus
Syracuse University