From: "Mathieu Giguere" <Mathieu.Giguere@ericsson.ca>
To: <Valdis.Kletnieks@vt.edu>,
"Mathieu Giguere \(QB/EMC\)" <mathieu.giguere@ericsson.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries.
Date: Thu, 8 Apr 2004 14:35:31 -0400 [thread overview]
Message-ID: <014701c41d98$45e6bac0$0348858e@D4SF2B21> (raw)
In-Reply-To: 200404081558.i38Fw2SU014685@turing-police.cc.vt.edu
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@vt.edu
To: Mathieu Giguere (QB/EMC)
Cc: linux-kernel@vger.kernel.org
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.....
next prev parent reply other threads:[~2004-04-08 18:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-08 14:40 IPv4 and IPv6 stack multi-FIB, scalable in the million of entries Mathieu Giguere
2004-04-08 15:58 ` Valdis.Kletnieks
2004-04-08 18:35 ` Mathieu Giguere [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-08 15:22 Mathieu Giguere
[not found] <1IJuR-8qH-39@gated-at.bofh.it>
2004-04-08 17:18 ` Andi Kleen
2004-04-08 18:10 ` Mathieu Giguere
2004-04-08 18:33 ` David S. Miller
2004-04-08 18:34 ` alex
2004-04-08 19:53 Mathieu Giguere
2004-04-09 1:05 ` jamal
2004-04-08 21:16 Krishna Kumar
2004-04-09 13:16 Ronnie Sahlberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='014701c41d98$45e6bac0$0348858e@D4SF2B21' \
--to=mathieu.giguere@ericsson.ca \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.giguere@ericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.