[ppml] too many variables

Leo Bicknell bicknell at ufp.org
Mon Aug 13 14:25:32 UTC 2007

In a message written on Mon, Aug 13, 2007 at 02:29:14PM +0200, Eliot Lear wrote:
> This assumes "the real problem" is CPU performance, where many have 
> argued that the real problem is memory bandwidth.  Memory doesn't track 
> Moore's Law.  Besides, Moore's Law isn't a law.  What's your Plan B?  
> This is where a lot of RRG/RAM work is going on right now.

I think there are multiple problems with core routers.  However,
the discussion here was about BGP being able to converge.  For that,
the FIB is not important, there need be no routing plane.

What sort of computer does it take to get 200 sessions at an exchange
point and compute a FIB in a "reasonable" amount of time?  That's
determined first by the implementation (algorithm) and second by
the processor speed.  It may also be impacted due to the bandwidth
between routers, although I'm skeptical that's an issue.

[Why?  Let's say 10,000 routes per peer, and 50 peers all on a single
giabit ethernet exchange.  Let's also put an upper bound of 512 bytes
per route.  That's ~250Mbytes, or what, maybe 30 seconds?]

It seems to me an off the shelf PC with a Core 2 Duo processor, 4
gig of memory, and a gigabit ethernet port would be 1-2 orders of
magnitude faster than what's currently in the routers.  Optimize
for a multithreaded CPU, add a second and it would converge really
fast.  My own experience is that zebra / quagga blow away the
performance of any router out there as long as you don't ask them
to install the routes in the kernel (which is really slow in a
general purpose OS).

Now, once the FIB is computed, can we push it into line cards, is
there enough memory on them, can they do wire rate lookups, etc are
all good questions and all quickly drift into specialized hardware.
There are no easy answers at that step...

       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070813/334d88e2/attachment.sig>

More information about the NANOG mailing list