[86208] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Scalability issues in the Internet routing system

daemon@ATHENA.MIT.EDU (Andre Oppermann)
Wed Oct 26 14:06:28 2005

Date: Wed, 26 Oct 2005 20:05:52 +0200
From: Andre Oppermann <nanog-list@nrg4u.com>
To: Blaine Christian <blaine@blaines.net>
Cc: nanog@nanog.org
In-Reply-To: <54A606A2-7C5E-42A7-9876-3C13C7C40BA8@blaines.net>
Errors-To: owner-nanog@merit.edu


Blaine Christian wrote:
> It does seem appropriate to consider Gigabit sized routing/forwarding  
> table interconnects and working on TCP performance optimization for  BGP 
> specifically, if any improvement remains.  Combine those things  with a 
> chunky CPU and you are left with pushing data as fast as  possible into 
> the forwarding plane (need speedy ASIC table updates  here).

I guess you got something wrong here.  Neither BGP nor TCP (never has been)
are a bottleneck regarding the subject of this discussion.

> Another thing, it would be interesting to hear of any work on  breaking 
> the "router code" into multiple threads.  Being able to  truly take 
> advantage of multiple processors when receiving 2M updates  would be the 
> cats pajamas.  Has anyone seen this?  I suppose MBGP  could be rather 
> straightforward, as opposed to one big table, in a  multi-processor 
> implementation.

You may want to read this thread from the beginning.  The problem is not
the routing plane or routing protocol but the forwarding plane or ASIC's
or whatever.  Both have very different scaling properties.  The forwarding
plane is at an disadvantage here because at the same time it faces growth
in table size and less time to perform a lookup .  With current CPU's you
can handle a 2M prefix DFZ quite well without killing the budget.  For the
forwarding hardware this ain't the case unfortunatly.

-- 
Andre

home help back first fref pref prev next nref lref last post