Oct/094
ISR G2 – what I wish it was…
Cisco ISR G2 - the best a branch can get?
Cisco announced the new ISR line recently, a 3x performance improvement for the high-end moving up to ~150Mbps. But the question I have that has been lingering with me for a while is, "Why not use an x86 processor and a decent hypervisor with that?"
Crazy, I know, right? But with the current set of Intel Nehalem cores I can get several Gb/s of sustained throughput at varying packet sizes. So it's not like I have a data plane performance issue. You can even schedule the cores to provide additional protection for mission-critical control plane processes.
Regrettably, to me, this was not the direction taken with this line. Why do I think it would be cool? For several main reasons:
One thing you could do is run several VMs for integrating neat things like Call Managers and Network Analysis. Who needs a separate co-processor when you can cost-effectively get a CPU with more than enough horsepower and DRAM to run a variety of concurrent branch office workloads.
Control Plane Performance would be through the roof - so you can actually support the market that fiber to the home is creating for Gigabit Ethernet handoffs to the home and business. This is rapidly expanding and becoming a more and more popular handoff in dense urban environments.
Killer integration - run branch office apps, rin your own apps, run the routing protocol stacks, and have enough process and VM separation to guarantee performance and stability. But also you wouldn't have to do special versions of IP-PBX call management for the router- you could run the full-blown image right on it. Want WAN Optimization, load a VM. Same with Network Analysis, etc. At some point performance will peter out, but not too soon.
Sadly for me, this feels like an opportunity lost. But who knows - maybe they will pull a rabbit out of the hat with something like this someday.
dg
Author: Douglas Gourlay
high-tech executive with interests in networking, virtualization, cloud computing, and IT/Tech government policy. VP of Marketing at Arista Networks - this blog reflects Doug's personal views and opinions and not necessarily those of Arista Networks.Additional comments powered by BackType
default gateway
- Vendor Math September 18, 2009
- Implications of Virtualization and Cloud August 19, 2009
- Virtualization's Impact on Networks August 6, 2009
- Brad Reese, PR's Worst Nightmare August 5, 2009
- Hello World, and Random Career Thoughts August 4, 2009
October 22nd, 2009
I hear ya loud and clear!
Apt metaphor at the end there.
October 23rd, 2009
The question is “why should they do it” ? They would lose money. Cheaper boxes would perform better then current ones.
October 24th, 2009
Adrian, I disagree a bit. An Intel Nehalem with a decent bit of RAM may actually be a bit more expensive than the current cost-optimized ISR platforms. On any product with that much volume you spend a lot of time and energy ensuring component selection keeps COGS low and that volumes can bring further cost reductions.
But the real shifts it would enable are:
– decouple memory density from price and get rid of perception of price-gouging while enabling core-value to be delivered through VM based plugins.
– another delivery platform for the Nexus 1000v technology
– quick time-to-market and time-to-integration of any acquisition with a VM-based offering
Thus net-net would be a higher performance, and as technologies integrate, high margin offer with a more extensible hardware platform. That is, if you really wanted the network to be a platform.
dg
October 28th, 2009
This concept of a virtualized services router (VSR?) popped into my head a couple of years ago. There are issues with the concept (too many network interrupts on a single host OS/hypervisor and processor degrading network performance), but there exist methods and software today which could overcome those issues. Two ideas Sun Microsystems proposed, “Throughput Networking” where a single core of a multicore processor is used as a packet processor for all applications on a box, and “Project Crossbow”, which allows a single host OS to support multiple TCP/IP stacks on one kernel, which again eliminates a network bottleneck in a virtualized environment, would make such a platform viable. Throughput networking would work on a multicore x86 processor, and a multiple TCP/IP stack kernel could be adapted to Linux or *BSD OSs.