[86206] in North American Network Operators' Group
Re: Scalability issues in the Internet routing system
daemon@ATHENA.MIT.EDU (Blaine Christian)
Wed Oct 26 13:19:31 2005
In-Reply-To: <200510261612.j9QGCi6C017592@turing-police.cc.vt.edu>
Cc: Alexei Roudnev <alex@relcom.net>,
Lincoln Dale <ltd@interlink.com.au>, nanog@nanog.org,
Daniel Senie <dts@senie.com>
From: Blaine Christian <blaine@blaines.net>
Date: Wed, 26 Oct 2005 13:18:55 -0400
To: Valdis.Kletnieks@vt.edu
Errors-To: owner-nanog@merit.edu
On Oct 26, 2005, at 12:12 PM, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 26 Oct 2005 08:53:50 PDT, Alexei Roudnev said:
>
>
>> Anyway, as I said - it is only small, minor engineering question -
>> how to
>> forward having 2,000,000 routes. If internet will require such
>> router - it
>> will be crearted easily. Today we eed 160,000 routes - and it
>> works (line
>> cards,m software, etc - it DO WORK).
>>
>
> Forwarding packets is only half the story. Building a routing
> table is
> the other half.
>
> Route flaps. Even if you have an algorithm that's O(n), 2M routes
> will take
> 12.5 times as long to crunch as 160K. If your routing protocol is O
> (n**2) on
> number of routes, that's about 150 times as much.
>
> Such a router is probably buildable. I'm not at all convinced that
> it's "easy"
> to do so at a price point acceptable for most sites that currently
> have full
> routing tables.
>
There are definitely performance challenges to overcome. Of course,
most route processors are underpowered compared to the existing state
of the art for processors so there is some wiggle room.
With both Cisco and Juniper we have a nice period of hang time as
"brand new" new routes get installed. Both vendors are playing with
layers of abstraction to improve things once up and operational but
increasing the amount of time to bring a device "online" is factor
which influences purchasing decisions as well.
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).
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.
Regards,
Blaine
