North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Scalability issues in the Internet routing system

  • From: Blaine Christian
  • Date: Wed Oct 26 13:20:19 2005 
On Oct 26, 2005, at 12:12 PM, [email protected] 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