At first glance I might think this is just another incremental update to the same set of devices we’ve had for the last 10 years. Going back to the ISR G1’s we see that at face value we have largely the same set of models. The 4321 is a 2811 or 2911. The 4351 a 2951 replacement. And the 4431 bumps up to two power supplies just like the 3825 and 3925 before it. But there are some significant differences with these new ISR 4000s.

1. NIM or Network Interface Module. This is the HWIC replacement. It is not backwards compatible and is a completely new form factor. I know there are some folks out there groaning about having to buy all new modules, but for us in the voice world this new NIM solves a major problem for us. The voice module NIMs have a PVDM slot on the NIM itself, enabled by a PVDM4 that also comes in a new form factor. This allowed Cisco’s engineers to create a separate clocking domain per NIM. With the EOS dates for NM-HDV modules earlier this year if a customer needed multiple clocking domains (e.g. They needed to support a local PRI from carrier A and an LD PRI from carrier B) they would have to buy a second router! Quite expensive for one PRI port. Now we can have up to 3 clocking domains in a single chassis on even the 4321. One other welcome update here is support for online insertion & removal (aka hot swap).
   

   NIM T1 Modules – Cisco.com

2. PVDM4. Cisco launches their 4th generation DSP. As mentioned it comes in a new form factor th
   

   PVDM4 Module – Cisco.com

   at is not backwards compatible with the PVDM2 or PVDM3 that preceded it. Cisco has not turned on video conferencing as the PVDM3 did although the hardware can support it, but let’s be honest with ourselves; the PVDM3 was a really terrible video bridge that was quite expensive for the poor performance and user experience provided. It’s clear that products like Cisco’s TelePresence Server and Conductor are the future here.

3. The other big change for us voice folks is the move away from “IOS Classic” to IOS XE. Outside of some corner case very large projects involving CUBE on an ASR a typical voice engineer has probably never run across IOS XE. Here’s a great article that sums up IOS XE, but if I can paraphrase the key update here is that IOS XE uses separate processes for the various tasks and systems running on a router. This means that if you run into a bug that causes the SNMP service to blow up the entire router doesn’t become unresponsive. Your voice processes like CUBE could continue to function unimpaired.

This might also help to explain why our friends in the CUBE product management team have so consistently pointed out to us over the last year that all the features they were developing in IOS Classic for the ISR G2 were launching at the same time in IOS XE for the ASR. Of course, now all that hard work pays off double when the newest additions to the ISR line running on Cisco’s latest IOS architecture come to market on a level playing field against their predecessors.

Let’s take a look at some performance comparisons. In the chart below we see throughput with services listed. Cisco claims that throughput with multiple services will not suffer nearly as much as they did on previous generation routers due to the multicore processor and IOS XE’s multi-threaded approach.

That is especially intriguing to me as a voice engineer because it means I have hardware where I can turn on all of the fun MediaNet features like Performance Monitor and AVC. Which in turn means that I can get some really incredible data out of tools like LiveAction. If you haven’t looked at LiveAction take 10 min to browse through their website and watch a few demo videos. It is hands down the most powerful QoS management and monitoring tool I’ve seen and well worth the time.

These new models also have a “Performance License” that enables additional processing power to support a higher throughput. The idea from Cisco being that you buy the router today and in three years when your WAN circuit gets an upgrade you simply buy a license rather than replace the router in order to support the higher throughput requirements. Personally, I’m not so hot on that idea and would have preferred each platform release without any sort of rate limiting or policing due to a license. You’ll see two numbers then in the chart below for performance of the ISR 4000s, the first is the default and the second is the throughput after applying the Performance License.

The new ISR 4000 line might be enough change for voice engineers to handle at the moment, but there’s more. Our venerable VG224 analog gateway has long been in need of an update. Handicapped by non-field replaceable memory limitations it cannot make the jump past IOS 15.1 and thus lacks the enhancements of 15.2 and 15.4. Enter the VG310 (24-port) and VG320 (48-port). Yes, finally the 48-port 1RU analog gateway has returned (RIP VG248).

There is one surprising disappointment for the new VG310 and VG320 and that is the lack of IOS XE. These appear to be based on ISR G2 architecture and IOS Classic. While there are no plans to EOL the ISR G2 at the moment, history tells us it’s not that far down the road. When that happens these will be one of a very few gateway/router products still using IOS Classic.

These new platforms seem to have slipped by many of us, but a few months down the road all voice engineers will feel the impact as they trade in their 2900s and VG224s for 4300s and VG310s. While I don’t love everything about the new platforms (e.g. the additional performance license and the lack of IOS XE on the VG310/320), there’s enough good here to outweigh the shortcomings. Multiple clocking domains and the performance benefits with IOS XE’s architecture have me itching to deploy a few and put them to the test.