IOS Vs IOS XE
My first truly technical post – I’m excited to jump into the meat and potatoes of these posts!
I’ll be staring with the very first exam objective:
1.1 Network theory
1.1.a Describe basic software architecture differences between IOS and IOS XE
1.1.a (i) Control plane and Forwarding plane
1.1.a (ii) Impact to troubleshooting and performances
1.1.a (iii) Excluding specific platform’s architecture
It’s hard to say exactly when it will happen, but given Cisco’s current direction in moving all of their new platforms from IOS to IOS XE, it probably won’t be long before we see the last new release of IOS as we know it.
If you’re like me, you always get a little apprehensive every time Cisco has another new operating system. ASAs run ASA OS, Nexus and MDS platforms run NX-OS. There’s an IOS XR OS out there, but unless you work for a service provider, you’ve probably never actually touched it. One of the big “strengths” of these Cisco operating systems is also one if their biggest weaknesses: They’re a lot like IOS. The big problem with being similar to IOS is that Engineers often end up responsible for designing, deploying, maintaining and troubleshooting these systems without any specific training for them, and without really knowing the differences from IOS. Even worse, Engineers often get bit by these lessons in the middle of an implementation.
For example, I know someone that planned on replacing an IOS router with an ASA failover pair at their Internet edge. The IOS router was performing BGP peering with their service provider. The unfortunate Engineer planned an outage window and had everything their new ASA wired up, only to find out that ASAs couldn’t do BGP peering. They essentially had to completely redesign their Internet edge that day on a white board in a conference room, and ended up having to use the IOS router as an edge device to do the BGP peering. After finally getting connectivity to their service provider up and running, they came back to the ASAs to start configuring them as the hub of their DMVPN network, as the IOS device had been… and then discovered that DMVPN is an “IOS only” feature. Let’s just say that that was a rough weekend. The Engineer was sure they would get fired. They weren’t. Rather, upon explaining everything to their manager, the manager was disappointed in the product and its limitations. And while it’s great that their manager was understanding and didn’t blame the Engineer, it’s really too bad that they came away from the experience with a negative opinion of the ASA, because aside from a few limitations like those, the ASA product line is great to work with. In many cases, it surpasses the IOS feature set. But that story is a prime example of just why the different operating systems can leave Engineers so hesitant. It’s not always easy to “know what you don’t know” about the differences between these operating systems.
Anecdotes aside, the point is that some of these differences can be huge, and it’s often difficult for an Engineer to know what to expect with an OS that is like the one they’ve been using. With IOS XE, one of the best bits of news is that it’s still the IOS that you know and have come to love all these years, at least as far as features and CLI administration. The biggest difference is that IOS XE runs IOS as a process on top of an underlying Linux OS, rather than running IOS as the basic operating system. It’s similar to the idea of having IOS running as a VM on your router/switch now.
This abstraction from the hardware opens up quite a few possibilities, not the least of which is multi-core processing. The fact that IOS isn’t the entire OS actually allows separate parts of the hardware to be controlled by separate processes, allowing IOS to be developed in a far more modular approach. No longer do IOS developers have to worry about writing different sets of code for every different platform and feature set because the drivers for the hardware are no longer needed as a part of the IOS. Those hardware drivers are separate, while still being upgradable.
Another benefit of IOS XE, is that it has additional functions and programmability, as it was created with APIs that give Engineers and Developers new ways of programming these devices, which is especially being targeted for “Network Aware Applications” and “Software Defined Networking.” Trying to explain what those things are could be a blog in and of itself. Since those aren’t covered on the CCIE test, I’m not going to go into further detail, but if you want to dive in, there’s some fascinating information out there on the Googles.
Control Plane And Forwarding Plane Operations on the IOS XE Platform
The control plane and the forwarding plane (or data plane, as it often called) have always been tightly integrated. Trying to explain the difference between the two can make your head spin. One of the best and simplest explanations I’ve come across is this one: http://sdntutorials.com/difference-between-control-plane-and-data-plane/ where the difference is broken down as:
“Control Plane => Learning what we will do
Data Plane => Actually moving the packets based on what we learned.”
Another explanation that I heard many years ago, but am unable to find the reference, is that Control Plane information is going to be contained in packets that are actually destined to a router or switch, such as a routing protocol, and the Data Plane is what moves packets going through the switch, and is mostly made to handle the traffic of other hosts.
What is the big deal about the forwarding plane and control plane in IOS XE? Well, IOS “classic” is a singular Operating System that runs on hardware dedicated to the IOS, and therefore, a single IOS process is responsible for both of these planes. Because of it’s modular design however, IOS XE allows the different planes to be run as their own individual processes, and even allows these processes to be run on different pieces of hardware. This also enhances redundancy and high availability, as newer routers have redundant hardware built in, for instance, redundant route processors.
One final benefit of this modularity and separation of the control and data planes is the fact that individual components can be upgraded, as opposed to the traditional IOS upgrade methods, which usually require having to upgrade the entire operating system for new feature sets or bug fixes. These individual “packages” allow you to upgrade just what you need. If a bug is found, for instance, in the SSH handler that allowed hackers to PWN your router, you can upgrade with the latest “RPAccess” package on your router. This allows you to upgrade just the remote management part of your router and fix up the one needed funtion. No more having to read through the entire release notes for a new IOS, accept an entirely new set of caveats, and risk discovering any unknown bugs when moving to a new IOS version, just for a simple big fix!
In the CBTNuggets video about IOS XE, Anthony Sequeira gives a great closing note about IOS XE: “Think modularity and high availability.” That’s a great way to sum up the benefits of the new evolution of Cisco’s IOS.
For anyone interested in further reading, Cisco has a great write-up here: http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xe-3sg/QA_C67-622903.html
On a personal note, I really enjoyed writing this post, because it’s about something that I knew absolutely nothing about before I started working on my CCIE. It’s fun to take topics like this and force yourself to get to a point where you can explain it. It surprised me to realize that, even after going over the information from multiple sources and feeling “ok” about my understanding, I had a really hard time explaining some of the details. It was only after forcing myself to go back and really pay attention to some details that I missed the first couple of times through that I really felt comfortable enough to start writing. This is one of those topics that is easy to blow off a bit, because of the fact that there aren’t any commands to memorize, and with it being a written-only topic, it’s easy to assume you won’t really need to know it, that it’s just one of those things that Cisco is excited about, so they had to put it on a test somewhere as a topic. Just the same, I’m glad to have spent the time learning it a little better, and I really do feel a lot more comfortable with the topic, in case I do come upon a question about IOS XE on the written. I also feel far more prepared to talk about this with customers that might be considering buying some of the gear that Cisco is shipping with this code, like the Catalyst 3850, ISR 4000 routers, or the ASR1000 series routers, and for a consultant, being prepared for customer questions is always a good thing!