If you have spent any amount of time working with Cisco gear, you have almost certainly typed commands into something called IOS. But here is the thing that trips up a surprising number of people, even experienced network engineers: not all IOS is the same. There are three distinct operating systems that carry the Cisco IOS name, and they differ in architecture, capability, platform support, and day-to-day behavior. Confusing them can lead to real headaches when you are troubleshooting, studying for a certification, or planning a deployment.

I have worked with all three across lab and production networks, and I want to give you the clear breakdown I wish someone had given me years ago. I am going to cover the history of each Cisco operating system, their architectural differences, which platforms run which OS, CLI variations, and practical guidance on when you will encounter each in the real world.

A Brief History of the Three Operating Systems

Classic IOS: The One That Started It All

Cisco IOS, which stands for Internetwork Operating System, first appeared in the mid-1980s. It was the software that powered the routers and switches that built the modern internet. For over two decades, classic IOS was synonymous with Cisco networking. The platform matured through hundreds of releases, gaining features like OSPF, BGP, MPLS (see our VLANs and segmentation) (see our BGP protocol deep dive), and QoS along the way.

Classic IOS is a monolithic operating system. Every process runs in a single, shared memory space with no memory protection between them. That design made sense in the 1980s when router hardware had limited resources, but it also meant that a single misbehaving process could crash the entire system. By the early 2000s, Cisco recognized that the monolithic architecture was becoming a liability. That recognition led to two separate development efforts that produced IOS-XE and IOS-XR.

IOS-XE: The Modern Enterprise Workhorse

IOS-XE made its debut around 2008 with the ASR 1000 series routers. The goal was straightforward: take the familiar IOS CLI and rebuild the underlying architecture to be modular and resilient. Cisco achieved this by running a Linux kernel underneath and executing IOS as a daemon on top of that kernel. You get the same CLI you are used to, but with proper process separation, memory protection (see our ASR9000 password recovery), and in-service software upgrade capability.

Today IOS-XE runs on the Catalyst 9000 switches, ISR 1000/4000 routers, ASR 1000 series (see our Catalyst vs Meraki hardware), and Catalyst 8000 edge platforms. If you are deploying new Cisco enterprise gear in 2026, you are almost certainly running IOS-XE.

IOS-XR: Built for Service Providers

IOS-XR arrived around 2004 on the CRS-1 carrier routing system, designed from day one for service provider requirements: full internet routing tables, multi-year uptime, and the ability to patch software while forwarding traffic at hundreds of gigabits per second.

IOS-XR is based on a microkernel architecture, originally QNX and more recently migrating to a 64-bit Linux foundation. It uses a fully distributed processing model where software components run as independent, protected processes that can be restarted individually. The CLI looks similar to IOS at a glance, but the operational model is fundamentally different.

Architecture: Monolithic vs Modular vs Distributed

The architectural differences drive everything else: stability, upgrade procedures, failure domains, and scalability.

Classic IOS: One Big Binary

Classic IOS runs as a single executable image. All features, protocols, and management processes share the same memory space. When you load an IOS image onto a router, you are loading one monolithic binary.

• No memory protection: A bug in the SNMP process can corrupt memory used by BGP, causing a full system crash.
• Single point of failure: Any unhandled exception brings down the entire router.
• Upgrades require a reload: There is no way to upgrade software without taking the device offline.
• Simple and predictable: Fewer moving parts means easier troubleshooting when things go right.

IOS-XE: Linux Under the Hood

IOS-XE introduces a layered architecture. At the bottom sits a standard Linux kernel. On top of that, Cisco runs the IOSd process (IOS daemon), which provides the familiar CLI and control plane. Other infrastructure services, such as the platform manager and forwarding manager, run as separate Linux processes.

• Process isolation: A crash in one component does not necessarily take down the entire system.
• In-service software upgrades (ISSU): Supported on platforms with redundant supervisors, allowing hitless upgrades.
• Linux access: Engineers can drop into a Linux shell for advanced diagnostics, packet captures, and scripting using tools like tcpdump and Python.
• Programmability: Native support for NETCONF, RESTCONF, YANG models, and guest shell containers for automation.
• Familiar CLI: The command syntax is nearly identical to classic IOS, so the learning curve is minimal.

IOS-XR: Distributed Microkernel Design

IOS-XR takes modularity to its logical extreme. Every major subsystem runs as an independent, restartable process with its own protected memory space.

• Per-process restart: You can restart the BGP process without affecting OSPF or the forwarding plane. On a service provider backbone, this is invaluable.
• Package-based upgrades: Software is delivered as individual packages (called SMUs, or Software Maintenance Updates) that can be installed without a full reload.
• Multi-chassis clustering: The distributed architecture natively supports control plane redundancy across multiple chassis, critical for carrier-grade deployments.
• Commit-based configuration: Configuration changes are staged and then committed as a transaction, similar to Junos. More on this below.

Which Platforms Run Which OS?

Here is the definitive breakdown as of early 2026.

Classic IOS Platforms

Classic IOS is effectively end-of-life for new deployments, but you will still encounter it on older hardware in production:

• ISR G1 and G2 routers: Cisco 1800, 2800, 3800, 1900, 2900, 3900 series
• Catalyst 2960, 3560, 3750 switches: The workhorses of enterprise access and distribution layers for over a decade
• Catalyst 4500 (Supervisor 6 and earlier): Older modular campus switches
• Catalyst 6500 (Supervisor 720 and earlier): Classic core switches running IOS in hybrid or native mode

IOS-XE Platforms

IOS-XE is where Cisco concentrates its enterprise development. The platform list continues to grow:

• Catalyst 9200, 9300, 9400, 9500, 9600 series: The entire modern Catalyst switching portfolio
• ISR 1000 and ISR 4000 series routers: Current-generation branch and WAN routers
• ASR 1000 series: Edge and WAN aggregation routers
• Catalyst 8200, 8300, 8500 edge platforms: The newest SD-WAN and edge routing hardware
• CSR 1000v and Catalyst 8000v: Virtual router instances for cloud and lab deployments

IOS-XR Platforms

IOS-XR is reserved for Cisco’s highest-end routing platforms designed for service provider and hyperscale environments:

• ASR 9000 series: Service provider edge and aggregation routers
• NCS 540, 560, 5500, 5700 series: Network Convergence System platforms for provider networks
• Cisco 8000 series: Silicon One-based routers for web-scale and provider core networks
• CRS series: The original carrier routing system (largely superseded by NCS and 8000 series)
• XRv 9000: Virtual IOS-XR instance for lab and testing

CLI Differences That Will Trip You Up

Sitting down in front of an IOS-XR device for the first time can be disorienting. The commands look familiar, but the operational model is different enough to cause real confusion. Here are the key differences to watch for.

Configuration Commits

In classic IOS and IOS-XE, configuration commands take effect immediately. If you accidentally paste a bad ACL into a production router, those rules are live the instant you hit Enter.

IOS-XR uses a commit-based model. You enter configuration mode, make changes, and nothing takes effect until you type commit. You can review pending changes with show configuration changes, bail out with abort (see our network security best practices), or use commit confirmed to auto-rollback if you do not confirm within a time window. This is one of IOS-XR’s best features, and I genuinely wish IOS-XE would adopt it universally.

Show Commands and Syntax Variations

Many show commands differ subtly between the platforms. Here are some examples that catch people off guard:

Interface Naming

IOS-XR uses a four-tuple interface naming convention: type rack/slot/module/port. Instead of GigabitEthernet0/0, you see GigabitEthernet0/0/0/0. This reflects the distributed, multi-chassis architecture of IOS-XR platforms.

Administrative Differences

• No enable mode in IOS-XR: Access control is handled through user roles and task-based authorization (AAA). You log in and are either authorized for a command or you are not.
• Linux shell access in IOS-XE: You can access the underlying Linux shell using guestshell or iox services, gaining access to Python, pip, and standard Linux utilities. Classic IOS does not offer this.

Feature Comparison: What Each OS Does Best

Each operating system has a sweet spot, and understanding these strengths will help you make sense of why Cisco maintains three separate codebases.

Classic IOS: Simplicity and Legacy Support

Classic IOS excels at being simple and well-understood. Decades of documentation and training materials cover virtually every scenario. Its main limitations are the lack of modern programmability, the inability to perform hitless upgrades, and no process-level fault isolation.

IOS-XE: The Best of Both Worlds

IOS-XE retains CLI compatibility with classic IOS while adding modern capabilities:

• SD-WAN integration: Cisco’s SD-WAN controllers manage IOS-XE devices natively. Catalyst 8000 and ISR 4000 platforms function as SD-WAN edge devices.
• Catalyst Center compatibility: Full support for Cisco’s intent-based networking controller.
• Streaming telemetry: Model-driven telemetry using YANG models with periodic and on-change subscriptions.
• Container hosting: Run Docker containers in the guest shell environment directly on network devices.

IOS-XR: Scale and Resilience

IOS-XR is engineered for environments where downtime is measured in dollars per second:

• Segment Routing: The most mature implementation of SR-MPLS and SRv6, the emerging standard for provider traffic engineering.
• Streaming telemetry at scale: gRPC-based telemetry with high-frequency collection, purpose-built for large-scale monitoring.
• Non-stop routing and forwarding: True hitless failover between redundant route processors.
• High-density line cards: Support for 400G and beyond on the Cisco 8000 series with Silicon One ASICs.

When You Will Encounter Each OS in the Real World

Let me give you some practical scenarios so you can calibrate your expectations.

Enterprise Campus and Branch Networks

If you are managing campus switches and branch routers, you will primarily deal with IOS-XE. New deployments use Catalyst 9000 switches and ISR 4000 or Catalyst 8000 routers. You may also encounter classic IOS on older Catalyst 2960 and 3750 switches that have not yet been replaced.

Service Provider and ISP Networks

Service providers run IOS-XR on their core and edge routers. If you take a job at an ISP or managed services provider, you will spend your days on ASR 9000s, NCS platforms, and the Cisco 8000 series.

Homelabs and Study Environments

For lab work, classic IOS is still widely used because older hardware is cheap. A used Cisco 2911 can be had for under $50. For IOS-XE, the Catalyst 8000v runs as a virtual machine in Cisco Modeling Labs (CML) or EVE-NG. For IOS-XR, the XRv 9000 virtual appliance works in the same tools, but be aware it requires at least 16 GB of RAM for a reasonable lab topology.

Data Centers

Cisco’s primary data center switching platform, the Nexus series, runs NX-OS, a separate OS not covered here. However, data center interconnect and backbone roles often use IOS-XR platforms like the NCS 5500 and Cisco 8000 series.

Certifications: Which Exams Cover Which OS?

Understanding the certification landscape helps you focus your study time on the right platform.

CCNA (200-301)

The CCNA primarily covers classic IOS and IOS-XE CLI syntax. Since they are CLI-compatible at this level, you do not need to distinguish between them during the exam. IOS-XR is not tested on the CCNA.

CCNP Enterprise

The CCNP Enterprise track focuses heavily on IOS-XE, including DNA Center integration, SD-WAN, and programmability features like RESTCONF and YANG models.

CCNP and CCIE Service Provider

The Service Provider track is where IOS-XR takes center stage. The SPCOR and CCIE SP exams require deep knowledge of IOS-XR’s commit-based model, Segment Routing, and MPLS. If you are pursuing the SP track, you need dedicated IOS-XR lab time. The workflow is different enough from IOS-XE that you will struggle without hands-on practice.

DevNet Certifications

Cisco’s DevNet certifications cover programmability across IOS-XE, IOS-XR, and NX-OS. The exams expect you to understand the automation capabilities of each platform family, with practical skills in at least one.

Choosing the Right OS for Your Situation

If you are still wondering which of these operating systems matters most to you, here is my straightforward advice:

1. Starting your career or studying for the CCNA: Focus on classic IOS and IOS-XE. They share the same CLI, and most enterprise jobs will have you on IOS-XE devices.
2. Targeting enterprise networking: Invest in IOS-XE. Learn NETCONF, RESTCONF, and Catalyst 9000 administration. This is where the industry is heading.
3. Pursuing a service provider career: You need IOS-XR proficiency. Build a lab with XRv 9000 images and practice the commit-based workflow with Segment Routing.
4. Working in network automation: You will need working knowledge of all three. Each platform exposes different APIs, and a well-rounded engineer should handle IOS-XE RESTCONF and IOS-XR gRPC with equal confidence.

Final Thoughts

The Cisco IOS family is not a single thing. It is three distinct platforms with shared heritage but divergent architectures and use cases. Classic IOS is the legacy foundation aging out. IOS-XE is the modern enterprise standard that keeps the familiar CLI while delivering modularity and programmability. IOS-XR is the service provider powerhouse built for scale and continuous operation.

Understanding these differences affects how you troubleshoot, automate, upgrade, and plan your career. The next time someone casually says “it is just IOS,” you will know better.

If you found this breakdown useful, keep an eye on IGNA Online. I will be publishing a hands-on IOS-XE tutorial next, walking through NETCONF configuration on a Catalyst 9300. Until then, happy labbing.