Vyatta as a BRAS

Joe Greco jgreco at ns.sol.net
Wed Jul 14 15:17:48 UTC 2010


> On Jul 14, 2010, at 5:45 AM, Joe Greco wrote:
> > That's just a completely ignorant statement to make.
> 
> It's based on a great deal of real-world experience; I'm sorry you consider=
>  that to be 'ignorant'.

You're speaking to someone who has extensive experience with "software"
based routers, and you're failing to acknowledge the upsides of such an
architecture, when I've already conceded the upsides of a hardware
architecture.

> >  I notice in particular how carefully you qualify that with "[w]hen BCPs =
> are=20
> > followed"; the fact that hardware router manufacturers have declared
> > everything and anything that derails their bullet trains as "not a
> > BCP" is a perfect example of this deceptive sort of misinformation.
> 
> Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. =
> al. aren't 'misinformation'.  They're useful, proven techniques/features wh=
> ich any operator ought to implement.

The things that any given use scenario ought to implement are highly
dependent on the actual application.

> > There are plenty of FreeBSD based devices out there that are passing
> > tons of traffic; almost any of them are more competent than any Cisco
> > router I'm aware of when hitting them directly with traffic
> 
> Then your experience of Cisco routers (and/or those from other vendors) mus=
> t be limited to the lower-end platforms; I can assure you that faster Cisco=
>  boxes such as ASRs, GSRs, CRSes, and so forth are in another league entire=
> ly, and can handle mpps of to-us traffic, when properly configured.  Softwa=
> re-based routers simply can't do that; it's not an indictment of them, it's=
>  just that they aren't suited to purpose, just as station wagons generally =
> aren't to be found in the Indy 500.

So your solution is to keep throwing heavier hardware at the problem until
it works.  Okay, I see that.  Now, let me quote from a different message:

> If maintaining availability is important, then hardware-based (semantic
> hairsplitting aside) devices are a requirement.

The truth is that you can keep throwing CPU at a problem as well.  I can
size a software based router such that it can remain available.

This is neither new nor exciting technology.  Luigi Rizzo was doing
extensive work on this about a decade ago: he took an Athlon 750 platform
with 4 100Mbit ethernet interfaces in it (Athlon 750 = 1999 tech) and was
able to exceed 100Mbps levels without a problem.  The UNIX based platforms
have extensive capabilities to defend against attack, even without a
firewall.  As with a hardware based platform, there are both good things
and bad things you can do that will impact availability.

Software based platforms have an incredible edge in areas that hardware
based platforms don't, including capex and the ability to find replacement
parts after a disaster.  I spent some time after the Haiti quake getting
FreeBSD-based routers up and running, a task made easier because it's a
lot easier to find a working PC and scavenge some network cards than it is
to find a working Cisco router in a city where all inbound and outbound
transportation is paralyzed.

You can continue to defend your position, of course, but it's just looking
a bit silly.  A wise engineer knows that there are several ways to tackle
any task, and "one tool for every job" is not a sound policy.

If you'd like to revise your position to "Cisco and Juniper software based
solutions are underpowered PoS", that's probably a defensible position,
and you won't get any argument from me.  Please don't generalize such a
position into all software based devices, though.  Overall, there are a
lot more software based routers out there than hardware based devices.
Your cablemodem, your ADSL modem, your wifi access point, all these are
probably software based devices.  Some of them will melt under a too-great
load.  Some won't.  This is a function of many different factors.  There
is nothing inherent in a software-based device that's going to make it
fail under load - just as there's nothing inherent in a hardware-based
device that's going to make it succeed (which is why you have to qualify
your defense of these with "must follow BCP").  It's the related
engineering that ultimately determines whether or not it all works out.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"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.




More information about the NANOG mailing list