[127799] in North American Network Operators' Group
Re: Vyatta as a BRAS
daemon@ATHENA.MIT.EDU (Dobbins, Roland)
Wed Jul 14 16:15:13 2010
From: "Dobbins, Roland" <rdobbins@arbor.net>
To: NANOG list <nanog@nanog.org>
Date: Wed, 14 Jul 2010 20:14:52 +0000
In-Reply-To: <201007141449.48220.lowen@pari.edu>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jul 15, 2010, at 1:49 AM, Lamar Owen wrote:
> CEF is CEF is CEF, whether done on a 2600 or a 7200 or a GSR. Now, don't=
get me wrong; the engineers who make massively parallel forwarding engines=
are creative and smart folks, and have come up with very elegant methods o=
f moving the bits ever faster, but the fundamental forwarding architectures=
, even of these accelerated boxes, can be implemented in pure software, as =
evidenced by the Cisco Nexus 1000V.
This is a *vast* oversimplification of the 'life of a packet' in a box like=
a CRS-1 vs. a 7200, for example. You know this, of course.
> Marketingspeak doesn't necessarily reflect reality. The original draft o=
f one of my replies in this thread said this 'Let's run this rabbit, and d=
ispel some marketing hype while we're at it.'
I wasn't a marketing person during my time at Cisco, and I'm not a marketin=
g person now. Technical people within Cisco and outside Cisco routinely ma=
ke use of the terms 'hardware-based' and 'software-based' to describe these=
fundamental classes of routers, and have for years.
> The reality is that 'hardware-based' routers really are AMP (asymmetrica=
l multiprocessing) software-based routers, with specialized processors runn=
ing specialized software.
Right - the 'hardware-based routers' idiom comes from the 'specialized proc=
essors', known as NPUs, ASICs, TCAMs, and so forth.
> And when implemented properly they are very good at what they do; I have =
GSR's, they work great, and regardless of what engine is on the linecard so=
me software at some level running on some processor is making the forwardin=
g decisions at the data plane,
'Some processor' =3D ASIC or NPU =3D 'hardware-baed'.
> and they can even for certain things require a punt to the MIPS processor=
on the linecard (IPv6 on Engine 1, anyone?).
Yes, this is true - or even to the system RP.
> Knowing the technology and its architecture, without blindly buying into=
marketingspeak, helps operators make better procurement decisions.
Nobody in this conversation so far is 'blindly buying into marketingspeak',=
to my knowledge - certainly not me.
> And Cisco's website has most of the information you need to make that de=
cision, if you use their hardware, which is very good.
The content on Cisco's Web site is confusing, redundant, full of *actual* m=
arketing-speak, and highly confusing in many aspects. This isn't a problem=
unique to Cisco, mind, but afflicts almost all technology companies.
> Dig deeply enough, and past the hardware versus software pseudodichotomy=
, and you can make very informed decisions indeed.
Yes, but you aren't going to do that by looking at product marketing materi=
als on a Web site.
> As a tongue in cheek example, remember the 'switching router' versus 'ro=
uting switch' distinction?
Yes, which was nonsense. OTOH, 'hardware-based' vs. 'software-based' is a =
useful distinction commonly employed by technical, non-marketing people wit=
hin both the vendor and operational communities alike.
> If a specialized network processing engine in an AMP router can protect t=
he control plane CPU, then code running on different processors in an SMP s=
ystem could do the same.
Not on a general-purpose SMP system running commodity processors such as th=
ose found in PCs.
> Perhaps not as efficiently, but the end result can be the same. I mean,=
I wonder if Blue Gene or Jaguar could give a CRS series a run for its mone=
y in terms of routing power (especially on the control plane),
Possibly - certainly not on the forwarding plane.
> and what the price/performance ratio would be to throwing something like =
Jaguar (224K Opteron processors, running Linux) at the relatively mundane t=
ask of throwing precisely metered bits around the wires. :-)
Fruitless speculation, IMHO.
> Regardless of recommendations, people are using commodity server-grade SM=
P hardware to run commodity OS's to get the job done, and given the people =
who have chimed in here, apparently are doing it without lots of problems.
My experience is that folks doing this on the edges of their networks event=
ually end up regretting it, after they get zorched a time or two.
> The increase on this and other lists of questions about Mikrotik, Vyatta=
, and other nontraditional routing platforms is an interesting throwback to=
the days of Proteon routers, the original SUN, and Cisco's multibus roots,=
and it shows that people are deploying these newer and much faster boxen i=
n the real world, bugs and all.
It shows me that a lot of folks, because they haven't been in the industry =
very long and/or don't learn from the mistakes of others in the past, seem =
determined to repeat those same mistakes, ad nauseam, ad infinitum.
> It's not a 'software-based =3D bad; hardware-based =3D good' world, even =
at the edge anymore;
I very strongly disagree with this, based upon my hands-on operational expe=
rience in production networks. Running software-based platforms at the edg=
es of one's network is extraordinarily irresponsible, in operational terms,=
if availability is an important metric for said network.
> a few years ago, sure, I wouldn't dream of doing such a thing. I for one =
love what a good parallel state machine in an FPGA can do to your software'=
s performance (we're doing that here, doing interferometric correlation at =
96Gb/s on a relatively inexpensive FPGA platform based on IBOB); or what GP=
U acceleration can do to graphics performance, but it is a help to realize =
that those activities, accelerated though they may be, are still software-b=
ased.
Again, with the semantics. If you take this hairsplitting to its logical e=
xtension, there's no such thing as 'hardware', because it's all 'software' =
- just some of it is 'hardware' which happens to be instantiated in the for=
m of physical chipsets. =20
While this may be intellectually appealing to some folks at the hand-waving=
, 30,000-foot, pseudo-philosophical level, as a matter of practical reality=
in the real world on real networks using real boxes, the distinction has a=
great deal of import.
> And while it's not a BRAS, one of the most exciting products I've seen in=
a long while from Cisco is the above-mentioned Nexus 1000V. Pure software=
virtual switching for VMware.
The N1KV is interesting primarily because it's Cisco's first retail pure-so=
ftware - i.e., not tied to a box - product intended to move packets around.=
It also highlights the flexibility and portability of NX-OS, which is Cis=
co's best OS to date, IMHO.
At the same time, from a performance perspective, it leaves a lot to be des=
ired. I hardly like to think what will happen when a few dozen VMs sending=
their traffic through an N1KV get botted and start spewing out SYN-floods =
and so forth.
We all know there's a great deal of difference between a box like a CRS-1 a=
nd a box like a 7200, and/or an Intel box running Quagga or what-have-you, =
and it's absurd to pretend otherwise.=20
Bottom line - use a software-based box for a layer-3 edge application like =
a BRAS, and you're asking for trouble. And this time, I'm really done with=
this thread, as semantic arguments quickly grow tiresome.
-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken
