Vyatta as a BRAS

Dobbins, Roland rdobbins at arbor.net
Wed Jul 14 20:14:52 UTC 2010


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 of 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 of one of my replies in this thread  said this 'Let's run this rabbit, and dispel some marketing hype while we're at it.'

I wasn't a marketing person during my time at Cisco, and I'm not a marketing person now.  Technical people within Cisco and outside Cisco routinely make 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 (asymmetrical multiprocessing) software-based routers, with specialized processors running specialized software.

Right - the 'hardware-based routers' idiom comes from the 'specialized processors', 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 some software at some level running on some processor is making the forwarding decisions at the data plane,

'Some processor' = ASIC or NPU = '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 decision, if you use their hardware, which is very good.

The content on Cisco's Web site is confusing, redundant, full of *actual* marketing-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 materials on a Web site.

>  As a tongue in cheek example, remember the 'switching router' versus 'routing switch' distinction?

Yes, which was nonsense.  OTOH, 'hardware-based' vs. 'software-based' is a useful distinction commonly employed by technical, non-marketing people within both the vendor and operational communities alike.

> If a specialized network processing engine in an AMP router can protect the control plane CPU, then code running on different processors in an SMP system could do the same.

Not on a general-purpose SMP system running commodity processors such as those 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 money 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 task of throwing precisely metered bits around the wires. :-)

Fruitless speculation, IMHO.

> Regardless of recommendations, people are using commodity server-grade SMP 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 eventually 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 in 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 = bad; hardware-based = good' world, even at the edge anymore;

I very strongly disagree with this, based upon my hands-on operational experience in production networks.  Running software-based platforms at the edges 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 GPU acceleration can do to graphics performance, but it is a help to realize that those activities, accelerated though they may be, are still software-based.

Again, with the semantics.  If you take this hairsplitting to its logical extension, 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 form of physical chipsets.  

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-software - 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 Cisco's best OS to date, IMHO.

At the same time, from a performance perspective, it leaves a lot to be desired.  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 and a box like a 7200, and/or an Intel box running Quagga or what-have-you, and it's absurd to pretend otherwise. 

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 at arbor.net> // <http://www.arbornetworks.com>

    Injustice is relatively easy to bear; what stings is justice.

                        -- H.L. Mencken







More information about the NANOG mailing list