North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Zebra/linux device production networking? (summary)

  • From: Jake Khuon
  • Date: Thu Jun 08 00:36:02 2006
  • Action:
  • Dcc:
  • Expires:

### On Wed, 07 Jun 2006 10:34:26 -0700, Nick Burke <[email protected]>
### casually decided to expound upon [email protected] the following thoughts
### about "Re: Zebra/linux device production networking? (summary)":

NB> Finally, it appears as if, contrary to what the articles are saying, not 
NB> many people are actively considering such a move. However, it is more 
NB> common in smaller businesses starting new locations or building out.

It all depends on the role in which you wish to deploy your equipment.  What
are your requirements?  You can sit down and analyse each component for
reliability, each piece of software, throw it all together and test it. 
Then go back and fix the issues, test, rinse, repeat.  Harden what you can,
improve the interface to make things more manageable, etc...  Afterall, the
T3 NSFNET ran on software based routers. |;^)

But, at the end of the day, you need to sit back and ask yourself what the
payoff is.  Is building a router your business' core competency or even its
core focus?  Or do you simply buy one from one of the reputable companies
out there who have already done the above and go about running your network?

Now many people will tell you that doing a home-grown solution can save you
a lot of money and for applications where you can get away with just
interfaces that support T1s and metro-eth, you'll do fine by rolling your
own software-based router.  Afterall, most lower end Ciscos don't provide
hardware accelerated forwarding anyways.  However, when you weigh in the
cost of time, material and labour of building your own T1 router against
that of a comparable 2600/2800 class box, I'm not sure you're saving
yourself a whole lot.

Now FWIW, I've spent some time dealing with generic whitebox unix routers
and scaling.  One thing that's important is not only the number of routes
but also the distribution of the prefixes.  I've found that with a
Pentium-III class machine with 512MB running a linux-2.4 kernel,
Quagga/Zebra tends to deadlock around 80,000 routes of four full BGP peering
sessions.  The test was done by taking a full live Internet BGP feed from a
route-collector, sending it into four linux whiteboxes running GateD where
the aspaths were modified to make the routes distinct and then feeding it
back towards the target.  I performed the same test with GateD (commercial)
on the same hardware and underlying OS and managed to scale to at least the
full table (approx 150,000 routes) from each of the four peers.  I've also
done some more extensive testing with GateD.  On a 1.8GHz Pentium-4 class
machine with 2GB of memory, I was able to scale out to well over a million
total routes (8 x full 150k BGP routing tables).

Now bear in mind that many of these tests were performed without forwarding
at line rates.  That's a whole nother matter entirely and is very dependent
on the OS (if software forwarding) or NP performance if accelerated hardware
forwarding.  Only low-rate pings were used to verify connectivity.  However,
I have been able to get up to DS3-level line-rate (over 100baseT)
performance out of a Soekris Net4801 running FreeBSD-4.10 and commercial
GateD.  If you're looking to build a router on the cheap that's to be used
in a relatively low-key role then those Soekris boxes are hard to beat.  You
can even get T1/E1 and T3/E3 cards for them in multiple configurations
(singles, dual, quads, and even 8-port T1/E1).

Whatever, you do, I would suggest you weigh not just the technical
feasibilities but also do the financial due-diligence for the business case. 
You will also want to factour in things like support/maintenance,
managability, skill-base of your staff, cost of development, cost of
operation, etc...

/*===================[ Jake Khuon <[email protected]> ]======================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | --------------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| N E T W O R K S |