Cisco’s trying to put more emphasis in the intelligence in their software by breaking it up in different modules and offering it a la carte. You only install the functionality that you need. This is opposed to an IOS with a suite of services for each level of IOS, where you would determine which services you wanted to enable and which services you wanted to disable. It saves a little space on the router, and instead of having disabled code on the router, I’m installing only what I want. At one extreme I could customize each router to do its job in the best way. That sounds great, but how would I manage customizing every router to have a different image? Testing every configuration and maintaining them would be a bear. Personally I would assemble the set of features that are needed in my enterprise (probably a few configurations based on deployment) and standardize on that.

If I were an IT manager, the questions I would look at are: Does this have an impact when you get ready to roll out a new service? Say, if I wanted to turn on access control, I am now adding a new module to my router, as opposed to turn on a feature in the IOS. Either way, you really should test any configuration change, but in the past, we’ve seen some people not paying attention to that – they just thought of it as flicking a switch on an installed IOS. With separate modules it is obvious that there is more going on here. Since the upgrade requires new software on the router, hopefully everyone will go through a good checklist: Is this feature compatible with the other modules? Does it add too much load for the RAM or CPU? Have we tested this configuration? There is nothing new here, but hopefully the act of installing software will encourage people not to bypass these checks. This extra discipline alone would make the effort a success.

In many ways the modular design is similar to the way Linux allows me to install just the services I want. In some cases the services are interchangeable. Do I want a user interface or just a command line? If I take a UI, do I want KDE or Gnome? What shell do I want? As long as the interface between modules is maintained, the parts are interchangeable. The modules can be developed and tested independently. This greatly simplifies development by letting each module focus on a single function. Simple development usually means faster progress, fewer bugs and often gives better performance. The trick is coming up with a good architecture to efficiently analyze the traffic and take advantage of hardware assistance. If each module has to do much analysis then scalability will suffer.

The open-source XORP project, which allows you to turn a standard PC into a router, also has a modular design and is seeking to go a step further by creating a market for router applications - third-party plug-ins to enhance the basic operation. It will be interesting to see whether new companies pop up to exploit that niche. The biggest limitation for a PC-based router is the lack of hardware acceleration – there’s no straight-through path for the packets. Every packet that comes in has to be analyzed by the PC and passed through another port. Commercial routers have specialized hardware that directs that traffic very quickly. I wonder what a PC could do with some specialized hardware and a plug-in to control it. It's doubtful there would be enough market to make this worthwhile, but I would love to see the types of applications developed if Cisco decided to provide an API to its processing pipeline.

XORP is an interesting platform except for the NIC performance. That is limited by the number of interrupts the CPU can handle and the PCI bandwidth. If someone had a NIC that fed more directly to the CPU then Opterons would be incredible for routing. I believe the current NICs use PCI slots limited to 133 MHz while the Opterons have something like separate 2GHz buses for each core. All data would run through the module pipeline so you could write a module to prioritize, buffer, monitor... Whatever module you want to add could be plugged in. I think whichever major player develops a plug-in architecture first could have a big head start on this market and be hard to keep up with by leveraging the energies of other vendors.

But I digress. Providing an API to third parties would be very attractive in terms of functionality. It is difficult in terms of support. If a third party product takes down the router, do you call Cisco or the third party vendor? Do you need a big compatibility lab with a "Cisco Certified" sticker? PCs have a lot of built-in support now for tracking down application bugs. I don't know how much support is built into the IOS.

A few are concerned, (correctly, in my opinion,) that breaking up the IOS into modules is an attempt by Cisco to get greater revenue from software. But, it makes sense that if they add features like NAC, WAN optimization, etc., that Cisco should be able to charge more. Otherwise it gets hard to compete by offering more features in the IOS. One way around this is to put the power in a blade like with WAAS. The disadvantage is they then have to redirect traffic to the blade instead of instead of handling the operations in the main data path. If the CPU has the power then the feature should really be implemented in IOS. The restraint on increasing prices is competition. The price of the sale includes hardware and software. Cisco will not be able to charge more for the combination of hardware and software than customers believe is an appropriate value compared to other vendors.

Besides, I have always heard in the rumor mills that “nobody really buys the IOS,” and that salespeople often give away whatever is required to get the hardware orders in order to meet quota. If so, the salespeople might throw in a couple of IOS modules to get deals in the future. This is probably even truer for big companies, which makes it even harder to justify designing products for the major enterprises where the product will likely be given away. The justification would be if the software is required in order to get the big hardware orders.

Ben Haley is Senior Product Architect in the Software Engineering Department at NetQoS.

Technorati Tags: Cisco Routers IOS Modular+IOS IT Networking