Failover how much complexity will it add?

Holmes,David A dholmes at
Mon Nov 9 17:58:47 UTC 2009

Most purpose-built routing "appliances" use ternary content addressable memory (TCAM) in order to accomplish deterministic, hardware-based, longest-prefix lookups in large routing tables, such as a full Internet BGP feed. TCAM is used to replace software-based table lookup algorithms which have been empirically shown to lack scalability as the number of routes in the routing table increases, and as the line rate in/out of the routers increases. Current TCAM hardware-based routing engines scale to 10 Gbps, and beyond. Much research has been done in this area in the last 15 years. 

I don't think general purpose BSD/Linux systems meet the scalability requirement for deterministic network design. Nothing political about that. 

-----Original Message-----
From: adel at [mailto:adel at] 
Sent: Monday, November 09, 2009 8:36 AM
To: nanog at
Subject: Re: Failover how much complexity will it add?

Hi Joe,

I agree with most of what you say below regarding linux sysadmin, BSD etc.  I'm quite happy and actually would prefer building a linux solution on our own hardware.  However, politically I think this is going to be difficult.  I just feel that they will be more comfortable with embedded network boxes as a pose to a linux solution.  I guess what I'm saying is this is partially a political thing.


On Mon   3:20 PM , Joe Greco <jgreco at> wrote:

> > 
> > Thanks,
> > 
> > I've taken your advice and decided to reconsider my requirement for a
> full 
> > routing table. I believe I'm being greedy and a partial table will be 
> > sufficient. With regards to Linux/BSD, its not the CLI of quagga that
> will 
> > be an issue, rather the sysadmin and lack of supporting infrastructure
> for 
> > Linux boxes within the organisation. So things like package management,
> You don't need to run Apache on your router.
> > syslog servers, 
> If you didn't have syslog servers for the Cisco, you don't need one for 
> the Quagga.
> > monitoring,
> If you didn't monitor the Cisco, you don't need to monitor the Quagga.
> > understanding of security issues etc.
> What security issues?
> The thing is, people get all tied up over this idea that it is some major
> ongoing burden to support a Linux based device.
> I have a shocker for you. The CPE your residential broadband relies on
> may
> well run Linux, and you didn't even know it. The wifi router you use may
> run
> Linux. There are thousands of embedded uses for Linux. I highly doubt
> that
> the average TiVo user has a degree in Linux. Many different things you
> use
> in day-to-day life run Linux, BSD, VxWorks, or whatever ... mostly
> without any
> need of someone to handhold them on security issues.
> Of course, security issues do come up. But they do with Cisco as well. 
> A proper Linux router doesn't have ports open, aside from bgp and ssh,
> and
> those can be firewalled appropriately. This makes it very difficult to
> have
> any meaningful "security problems" relating to the platform...
> You can expect the occasional issue. Just like anything else. But trying
> to
> compare it to security issues on a general Linux platform is only
> meaningful
> if you're trying to argue against the solution.
> (I'm a BSD guy myself, but I don't see any reason for undue Linux
> paranoia)
> > I don't want to leave them with a linux/bsd solution that they won't be
> > able to maintain/manage effectively when I am gone.
> If they're unable to maintain something as straightforward as BSD or
> Linux 
> when you're gone, this raises alarm bells as to whether or not BGP is 
> really suited for them. BGP is *much* more arcane, relatively speaking.
> You can go to your local bookstore and pick up a ton of Linux or BSD
> sysadm
> books, but you'll be lucky to find a book on BGP.
> > Thanks for your comments. Look forward to hearing which solutions come 
> > back into the mix having dropped the full routing table requirement.
> There's a whole plethora of BGP-capable gear that becomes possible once 
> you make that call. Cisco and Juniper both make good gear. A variety
> of other mfrs do as well. Something as old as an Ascend GRF 400 (fast
> ethernet, line speed, 150K routes, ~1998?) is perfectly capable of
> dealing
> with the load, though I mention this primarily to make the point that
> there
> is a lot of equipment within the last decade that can support this.
> ... JG
> -- 
> Joe Greco - Network Services - Milwaukee, WI -
> [1]
> "We call it the 'one bite at the apple' rule. Give me one chance [and]
> then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many
> apples.
> Links:
> ------
> [1]

More information about the NANOG mailing list