Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries.

From: Mathieu Giguere
Date: Thu Apr 08 2004 - 13:36:40 EST


Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries.Hi,

We working on a edge application for aggregateing a lots of mobile (up
to 100k), then go on the backbone. We are talking about an access
application not a core. Each mobile can than have to talk with services we
want to provide to them.

Our need for now, is around 100k. But why not try to have a solution
future proof, where can scale up to a memory footprint dedicated for it.
Not limited by the architecture himself.

Like I said before, it's not a home linux box. It's a commercial server
serving a lots of users. But, nothing can prevent home user to benefit from
a more scalable stack.

/mathieu

----- Original Message -----
From: Valdis.Kletnieks@xxxxxx
To: Mathieu Giguere (QB/EMC)
Cc: linux-kernel@xxxxxxxxxxxxxxx
Sent: Thursday, April 08, 2004 11:58 AM
Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of
entries.


On Thu, 08 Apr 2004 10:40:46 EDT, Mathieu Giguere said:
> We currently looking for a multi-FIB, scalable routing table in the
> million of entries, no routing cache for IPv4 and IPv6. We want a IP
stack
> that can have a log(n) (or better) insertion/deletion and lookup
> performance. Predictable performance, even in the million of entries.
Gaak.
The guys at http://www.cidr-report.org are only showing 130K or so prefixes
in
the global routing table (and estimate that it could be kicked down to 90K
or
so with better CIDR aggregation.
I won't ask what sort of totally martian network design is leading to a
routing
table of millions of entries - even the "stick PMTU info into a host route"
trick
should expire routes to hosts you're not talking to, and you're probably
going
to be wanting a load balancer if you're talking to hundreds of thousands of
machines at the same time.....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/