Scalability issues in the Internet routing system

Blaine Christian blaine at blaines.net
Wed Oct 26 17:18:55 UTC 2005


On Oct 26, 2005, at 12:12 PM, Valdis.Kletnieks at 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









More information about the NANOG mailing list