[ppml] too many variables

Bruce M Simpson bms at incunabulum.net
Sat Aug 25 00:41:51 UTC 2007


I am the chap who did the port of XORP to Microsoft Windows; normally on 
the Internet I play a FreeBSD committer role.

Leo Bicknell wrote:
> 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).
As far as I am aware, zebra/quagga uses a table scanning design for BGP.

This is where XORP comes in:

Figure 13, BGP route flow, may be of particular interest here. XORP 
defers the pushdown of routes in its RIB to the kernel.

The current model is to explicitly coroutine on a per-process basis, 
within a message-passing architecture. This is lockless at process level 
- the kernel handles synchronization based on the I/O primitives upon 
which the XRL message passing between XORP routing processes is based, 
so it does rely on the atomicity of these operations. Normally on a BSD 
or Linux machine, a local stream socket (TCP or UNIX) is used for such 

XORP's design could potentially be improved further for multi-core CPUs, 
by the use of continuations and CPU affinity. The use of a 
soft-real-time scheduler might also be worth investigation, although 
XORP is built around cooperative multi-tasking, so that would require 
explicitly re-entering the scheduler.

As regards the latency of route propagation to the kernel: I'd be 
interested to hear in technical detail problems which people may be 
experiencing here, e.g. on Linux or BSD platforms.

I have on-and-off been researching a new routing implementation for 
FreeBSD which would draw inspiration from the recent work in Linux and 
other operating systems, so I want to get as much input from people's 
experiences as possible.


More information about the NANOG mailing list