On Wednesday, July 14, 2010 08:39:50 am Dobbins, Roland wrote:
> And it's not *my* definition - 'hardware-based' vs. 'software-based' are the 
> terms to describe these two fundamental architectural classes of router 
> *within Cisco itself*.

[snip]

> There's a world of difference in packet-handling mechanisms and sheer 
> performance between a 7200 and a CRS-1, or a GSR, or a CRS-3, or Juniper 
> T-series - and not just one of 'more, faster processors', but of fundamental 
> architecture. 

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 why 'hardware-based' vs. 'software-based' is a useful distinction; 
> again, note that within Cisco, these are the common terms used to describe 
> these general classes of device, with 7200s and ISRs being termed 
> 'software-based', and the other models mentioned above described as 
> 'hardware-based'.

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.'  

The reality is that 'hardware-based' routers really are AMP (asymmetrical 
multiprocessing) software-based routers, with specialized processors running 
specialized software. 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, and they can even for certain things 
require a punt to the MIPS processor on the linecard (IPv6 on Engine 1, 
anyone?).  

Knowing the technology and its architecture, without blindly buying into 
marketingspeak, helps operators make better procurement decisions.  And Cisco's 
website has most of the information you need to make that decision, if you use 
their hardware, which is very good.  Dig deeply enough, and past the hardware 
versus software pseudodichotomy, and you can make very informed decisions 
indeed.  As a tongue in cheek example, remember the 'switching router' versus 
'routing switch' distinction?

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.  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), 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. :-)

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.  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's not a 'software-based = bad; hardware-based = good' world, even at the 
edge anymore; 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.

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.

Reply via email to