With the announcement by Mike Volpi, Cisco Senior Vice President, Routing Technology Group (so he should know what he’s talking about) of a new ‘modular IOS’ about to appear, what are the implications for the IOS we’ve come to know, love, and despair of, for the past couple of decades? Does this new approach herald a significant change to the way we’re going to have to live with routing from now on?

Why change?
When Cisco’s Internetwork Operating System appeared on the first IGS, MGS and AGS platforms, in the days when you shifted jumper block selectors to do a password reset, routing was pretty simple. But as new routing protocol support, DLSw, MPLS, security, QoS features and the rest have been added, the code has grown in complexity and size—as the amount of memory we now have to buy attests to.

IOS developers tend to work on one area of code development—BGP, multicast, whatever. Which makes sense. But because the code was originally developed as a whole, it’s not always easy to make changes to one part without the risk of something else being affected. Hence the weeks of regression testing required before every major or maintenance code release. And that can’t be cheap.

So although huge chunks of code are currently developed in a sort of isolation—a pseudo-modularity—it’s not as clean cut as might be liked. In theory, anyway, allowing developers to work on their particular piece, with a known method of interconnecting all the pieces to minimise problems, makes for a more efficient way of building code.

Why now?
That in itself might not have been enough to make a change though. What’s more likely is indicated by the fact that this new code is being developed for Cisco’s currently best-kept secret, the so-called HFR (Huge Fast Router, although there have been alternative suggestions). No one in Cisco will publicly admit it exists, although it’s been seen, and rumour has it that a few are in beta trials with major carriers and that it will make its debut later this year.

Now the HFR is going to be a service provider box. It will come in various sizes (both throughput-wise and physically) from huge to ginormous. In its smallest version it may be an option for a large enterprise, in the future, but it’s aimed at capturing the SP market. And the one thing that providers do not like is an outage. So the HFR, presumably, will have redundant everything, both for performance and resilience. And that includes the operating system. Taking a router out of service, to do code upgrades that fail and have to be backed out, isn’t an option. Even though Cisco IOS today can support High Availability features to varying degrees in the different platforms with the aim to have full Non-Stop Forwarding, even if a processor fails or during a code change, wouldn’t it be good if, say, you had to do a code upgrade for a new QoS feature, you could just upgrade that part and the rest of the routing functionality continued to work? It would also mean that your testing process would be minimised, since you wouldn’t have to spend weeks, or even months as some carriers presently do, making sure that a change to one part of the code, or network, doesn’t screw up something completely unrelated somewhere else—by which time there’s another version out anyway.

Enterprise impact
It then makes sense to utilise all this development effort into other routing platforms too - Cisco has always pushed the idea of one IOS for all boxes (even though you’re probably having to run different versions of it to support the different hardware and software features you need). By breaking off chunks of code, it would seem plausible that you could buy the modules you want (though they may well be marketed as grouped feature sets, as they are today) for the processes you need for your environment. If you need, you can add, remove and upgrade them independently.

Which all sounds remarkably good, to be honest. Of course, nobody’s seen this code yet to see if that is how it will work. If it only appears for the high end platforms this year, it’s likely that it may take rather a long time to filter down to your 831 SoHo routers. That will depend on how big a push Cisco puts on it, though, and what other development work takes priority.

In other words, don’t hold your breath. It will more than likely impact the SPs first and be a long time before it makes it to a real live network. Ironically, some of the smaller, more innovative providers that would be more willing to deploy new systems quicker are probably the ones that don’t need the vast amounts of throughput needed by an HFR, although their techies are probably busily making up reasons why they need a couple to play with—sorry, test. But this type of code development does offer great flexibility and improved service, and might be the greatest improvement to IOS since version 9 let you use the ? within the config prompt.