IOS
The classical IOS is a monolithic kernel that runs all of the necessary modules in the same memory space. This means that if something happens to the routing engine or the LED indicator, it can cause the whole IOS kernel to crash if it runs out of memory. That may have been okay years ago but todayās mission critical networks canāt afford to have a rogue process bringing down an entire chassis switch.
To resolve above issue Ciscoās software engineers, rebuild the IOS CLI on a more robust platform known as IOS-XE
IOS-XE
IOS XE runs as a system daemon on a āmodern Linux platform.ā Cisco also abstracted the system functions out of the main kernel and into separate processes. That means that if one of them goes belly up it wonāt take the core kernel with it. One of the other benefits of running the kernel as a system daemon is that you can now balance the workload of the processes across multiple processor cores.
IOS-XR
IOS XR is what the Mirror Universe version of IOS would look like. Much like IOS XE, IOS XR does away with the monolithic kernel and shared memory space of IOS Classic. XR uses an OS from QNX to serve as the base for the IOS functions. XR also segments the ancillary process in IOS into separate memory spaces to prevent system crashes from an errant bug. XR is aimed at the larger service provider platforms like the ASR and CRS series of routers. You can see that in the way that XR can allow multiple routing protocol processes to be executed at the same time in different memory spaces. Thatās a big key to the service provider.
What makes IOS XR so different from IOS Classic? That lies in the configuration method. While the CLI may resemble the IOS that youāre used to, Instead of making live config changes on a live system, the running configuration is forked into a separate memory space. Once you have created all the changes that you need to make, you have to perform a sanity check on the config before it can be moved into live production.
