Now in the worst case you have 300 host routes in all your portmasters.
One may say it's rather unusual case (300 line in one location). Maybe.
But if the PMs don't scale... we'd better look for something else.
So, the question remains: Can anyone confirm or deny the performance
degradation when a PM has some substantial amount of rip routes?
If so, what can be done about it? You can't filter some rip routes -
in cases like the one above you need all the routes (btw, PMs can't
selectively filter RIP updates).
It is possible to split up the PMs into groups of 2-3-4 units
(depending on where the degradation starts). One can put the groups
on the separate network segments and pass only 255.255.255.0 routes
between them (in fact it's how RIP does it, and you can't change
it with RIPv1). Thus every box in the group will have at maximum
30*N host routes + M prefix /24 routes, where N is the number of boxes
in the group and M is the number of the groups. So far I see this as the
only solution.
Also a related question - what is the memory requirements for routing
table in PM? How many routes can the standard box bear?
>
> On Fri, 24 Nov 1995, Alex Rubenstein wrote:
>
> > > >I hear that performance drops severaly on the PM2eR when they are filled
> > > >with several hundred RIP routes. I've only heard this from one person, but
> > > >the numbers were down in the 100's of Kbps area.
> > >
> > > Anyone confirm or deny this?
> >
> > I got an answer: Who cares?
> >
> > If your network is configured with 'several hundred rip routes', you
> > should be more concerned on how inefficient your network is and not the
> > PM's abailty to store routes.
>
> I'd be interested to know what, besides a complete lack of networking
> knowledge, makes you believe that a network with several hundred
> routes distributed via RIP is inefficient.
>
> There is no reason for a network with "several hundred RIP routes"
> to be inefficient. I've worked on quite large (50-60 sites world-wide,
> hundreds of networks) internetworks that used RIP for routing, and
> worked just fine. And the ciscos we used had no trouble with such
> large routing tables, probably because they tiny in comparison to
> your average Internet border router.
>
> In many networks like this, it would be nice to switch to OSPF.
> However, many vendors (such as Livingston, Telebit, Ascend, etc.)
> don't support OSPF, making migration just a bit of a hassle.
>
> If Livingston wants to sell to large companies with large networks,
> as well as small companies, using a fast algorithm for routing
> table lookups so the machine can deal with hundreds of routes is
> only sensible.
>
> cjs
>
> Curt Sampson curt@portal.ca Info at http://www.portal.ca/
> Internet Portal Services, Inc.
> Vancouver, BC (604) 257-9400 De gustibus, aut bene aut nihil.
>
-- Igor V. Semenyuk Internet: iga@sovam.com SOVAM Teleport Phone: +7 095 258 4170 Moscow, Russia Fax: +7 095 258 4133