IOS XE Software and Operating Modes

IOS XE Architecture

A Catalyst 8000 router is not a single monolithic program running on bare metal. Modern Cisco IOS XE is a layered operating system: a Linux kernel and platform services at the bottom, the familiar IOS control plane running as a process on top, and a hardware-accelerated forwarding plane underneath it all. Understanding this layering is the key to understanding everything else in this chapter — because autonomous mode, controller mode, and SD-Routing are all just different personalities of the same software stack.

Think of it like a modern smartphone. The phone's operating system (the equivalent of the Linux platform OS) is always the same. What changes is which apps are running and how the device is being managed — locally by you, or centrally by a mobile-device-management server at your company. The hardware and the OS don't change; the management model does.

Linux Kernel and IOSd

At the foundation of IOS XE is a Linux-based platform operating system, often referred to internally as binos (the Linux-based platform OS that provides hardware abstraction, process isolation, and base services on IOS XE). The Linux layer handles low-level concerns: scheduling, memory protection, device drivers, and keeping individual processes isolated from one another so that a fault in one does not crash the entire router.

Running on top of that Linux layer is IOSd (IOS daemon) — the process that runs the classic Cisco IOS control plane, including the CLI, routing protocols, and feature logic you already know. When you type configure terminal or show ip route, you are talking to IOSd. The important conceptual shift from older monolithic IOS is this: IOSd is now just a process, scheduled and protected by Linux like any other process.

This modular design is what makes the dual-personality model possible. When the router runs as a Cisco SD-WAN node, additional processes and agents — the Overlay Management Protocol (OMP) engine, secure control-connection daemons, and management agents — run alongside IOSd on the same Linux platform. The underlying OS, the hardware abstraction, and the forwarding plane never change.

Below the control plane sits the data plane: packet forwarding handled by dedicated hardware acceleration (the NPUs/ASICs on physical Catalyst 8000 platforms). IOSd programs the forwarding tables into this hardware regardless of which mode the router is running in. A critical implication follows: choosing autonomous versus controller mode does not change the raw forwarding performance of the box. It only changes how the control and management planes are orchestrated and how configuration is represented.

Figure 3.1: IOS XE layered architecture on Catalyst 8000

Software Packaging and SMUs

Cisco consolidated IOS XE for Catalyst 8000/cEdge routers into a single unified image that contains both the autonomous router personality and the SD-WAN cEdge personality. In the older world, autonomous IOS XE and SD-WAN (then called "IOS XE SD-WAN") were separate images and you had to physically replace one with the other to switch. With the unified image, a single setting — the controller-mode flag — tells IOS XE which personality to boot. This is why a mode switch is a reboot, not a software reinstall.

Patching also benefits from the modular architecture. A SMU (Software Maintenance Upgrade) is a targeted, often hot-installable patch that fixes a specific defect or security issue without requiring a full image upgrade and the associated downtime. Because IOS XE components are packaged and isolated, a SMU can deliver a fix to a specific component, letting you address a critical bug quickly while deferring a full version upgrade to your normal maintenance schedule.

Day-0 Boot Process

Day-0 configuration is the initial, one-time setup that brings a brand-new (or freshly erased) device from "out of the box" to "reachable and ready for further configuration." It is the networking equivalent of the first-boot setup wizard on a new laptop: you provide just enough information — a name, an address, credentials — to take over from there.

A Catalyst 8000 ships in autonomous mode by default, so the out-of-box Day-0 experience is the classic one. You can deliver Day-0 configuration through several mechanisms:

• The interactive setup dialog at the console.
• A USB file or bootflash config file applied automatically at boot.
• Plug-and-Play (PnP/ZTP), where the device phones home to a provisioning server.
• For the virtual Catalyst 8000V, cloud-init / custom-data supplied by the hypervisor or cloud platform, which can even install Python packages and run scripts in Guestshell for richer automation.

Figure 3.2: Day-0 boot and provisioning flow

The content of Day-0 differs dramatically by personality, and we will return to this when we contrast the modes. In autonomous mode, Day-0 is about basic connectivity (a management IP, a default route, login credentials). In controller mode, Day-0 is about onboarding into the SD-WAN fabric (system IP, site ID, organization name, and controller addresses). After Day-0, you move on to Day-1 (core service configuration) and Day-2 (optimization, telemetry, ongoing changes).

Key Takeaway: IOS XE is a layered OS — a Linux platform (binos) hosting the IOSd control-plane process over a hardware-accelerated data plane — shipped as a single unified image whose controller-mode flag selects which personality boots. SMUs allow targeted patching, and Day-0 configuration gets a fresh device to a manageable state.

Autonomous vs Controller Mode

The same Catalyst 8000 hardware and the same unified IOS XE image can present two completely different operational personalities. They are mutually exclusive — the router boots into one or the other — and they differ in how the device is configured, managed, and integrated into the network.

Autonomous (Traditional) Mode

Autonomous mode is the default, out-of-box personality: the Catalyst 8000 behaves like a traditional standalone IOS XE router with no SD-WAN overlay running. If you have configured any Cisco router in the last two decades, this will feel familiar.

Its key characteristics:

1. Local CLI is primary. You configure the device with configure terminal, interface and routing stanzas, and so on. You can also use NETCONF/RESTCONF, Ansible, or a controller like Cisco DNA Center for automation.
2. Classic routing and services. You run OSPF, BGP, EIGRP, RIP, and static routes, plus features such as IPsec VPNs (DMVPN, GETVPN, FlexVPN), NAT, QoS, and VRFs — all configured and stored locally. There is no OMP control plane.
3. Config lives on the box. Configuration is held in running-config and startup-config. You make changes locally and save them with copy running-config startup-config (or write memory).

Here is a representative autonomous-mode configuration — exactly the kind you would type into any classic Cisco router:

! Autonomous mode – classic router
hostname BRANCH-RTR1
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 no shut
!
router ospf 10
 network 10.10.10.0 0.0.0.255 area 0
!
router bgp 65010
 neighbor 192.0.2.1 remote-as 65000

Everything here is configured and stored on the device itself. No SD-WAN controller is involved.

Controller (SD-WAN) Mode

Controller mode turns the same device into a cEdge (a Cisco SD-WAN edge router) that participates in an SD-WAN overlay fabric and is managed centrally by Cisco Catalyst SD-WAN Manager (the product formerly known as vManage).

Its key characteristics:

1. Centralized, template-driven management. SD-WAN Manager is a single dashboard from which you define device templates, feature templates, segmentation, QoS, application-aware routing, and security policies — then push them to many cEdges at once. The CLI is still IOS XE-style, but it is transactional (config-transaction), and most configuration is generated from templates rather than typed by hand.
2. Secure control connections. The cEdge forms encrypted (DTLS/TLS) control connections to the SD-WAN controllers — the SD-WAN Validator and SD-WAN Controller (formerly vBond and vSmart) and SD-WAN Manager — validated by certificates.
3. OMP-based overlay. The Overlay Management Protocol (OMP) — the SD-WAN control protocol that distributes routes, TLOCs (transport locators), and policies across the overlay — runs alongside the traditional protocols. BGP/OSPF are still supported, but they typically handle local LAN/WAN adjacency while OMP carries reachability across the fabric.
4. Manager is the source of truth. The device's configuration is effectively shadowed by SD-WAN Manager. Local CLI changes that conflict with templates are overwritten or flagged as out-of-sync.

A minimal SD-WAN Day-0 bootstrap looks very different from the autonomous snippet above — notice it is about joining the fabric, not about routing:

! Minimal SD-WAN bootstrap
system
 host-name BRANCH-EDGE1
 system-ip 10.255.255.11
 site-id 101
 organization-name "MyOrg"
 vbond 203.0.113.10
!
interface GigabitEthernet0/0
 ip dhcp client
 tunnel-interface
  allow-service all
  color biz-internet
  nat

This bootstrap only gets the device into the SD-WAN fabric; the full configuration — VPNs, policies, routing — is pushed afterward from SD-WAN Manager.

There is also a middle ground worth knowing about. SD-Routing is an operational capability where the router stays in autonomous mode and forwards traffic with traditional routing, but is fully managed and monitored by Catalyst SD-WAN Manager — without joining a full SD-WAN overlay or building SD-WAN data-plane tunnels. It is not a third boot mode; it is an add-on to autonomous mode. The router establishes DTLS/TLS control connections to the SD-WAN Validator and Manager (just like an SD-WAN device does for management) so that one Manager can act as a single pane of glass across both your overlay devices and your traditional routers. SD-Routing was introduced in Cisco IOS XE 17.12.1 on routers paired with controllers at release 20.12.1, and it is supported on Catalyst 8000 platforms. We will look at how it is onboarded in the next section.

Feature Differences Between Modes

The clearest way to internalize the contrast is side by side. The triangle of autonomous, SD-Routing, and SD-WAN sorts out a question students often confuse: all three can be managed by SD-WAN Manager, but only one builds an overlay.

Figure 3.3: Autonomous, SD-Routing, and SD-WAN compared

And comparing the two true boot modes head to head:

Key Takeaway: Autonomous mode is the default, CLI-driven standalone router; controller mode makes the device an SD-WAN cEdge managed centrally through SD-WAN Manager with OMP-based overlay; and SD-Routing is a middle option that keeps the router autonomous while still managing it from SD-WAN Manager — without building an overlay.

Switching Modes

Because autonomous and controller mode are two personalities of one image, switching between them is a software operation rather than a reimage. But it is far from a trivial toggle: every mode switch erases the configuration and reboots the router. Treat it as a migration with a maintenance window, not a feature flag.

Figure 3.4: Mode switching as a destructive state machine

request platform / controller-mode Commands

All mode commands run from privileged EXEC (the Router# prompt) — not from configuration mode. Start by confirming which personality you are in:

Router# show platform software device-mode
System mode: Autonomous

The output reports either System mode: Autonomous or System mode: Controller-Managed (exact wording can vary slightly by release).

Worked example A — Catalyst 8300: autonomous → SD-WAN. To convert an autonomous router into a cEdge, use controller-mode enable. The router warns you that it will erase the startup-config, asks you to confirm the reload, then wipes its configuration and reboots into the SD-WAN personality:

C8300# show platform software device-mode
System mode: Autonomous

C8300# controller-mode enable
Enabling controller mode will erase the startup-config. Continue? [y/n]: y
This action will reload the system. Do you want to continue? [y/n]: y

! after reload
C8300# show platform software device-mode
System mode: Controller-Managed

Worked example B — Catalyst 8000V: SD-WAN → autonomous. The reverse operation turns a cEdge back into a classic IOS XE router with controller-mode autonomous. Note that on the virtual 8000V, the hypervisor/VM settings (vNICs, vCPU, memory) are untouched — only the IOS XE configuration is reset:

C8000V# show platform software device-mode
System mode: Controller-Managed

C8000V# controller-mode autonomous
Converting to autonomous mode will erase the startup-config. Continue? [y/n]: y
This action will reload the system. Do you want to continue? [y/n]: y

! after reload
C8000V# show platform software device-mode
System mode: Autonomous

Once in controller mode and onboarded, a new family of SD-WAN operational commands becomes available for verification and troubleshooting:

Router# show sdwan system status
Router# show sdwan control connections
Router# show sdwan omp peers
Router# show sdwan bfd sessions

For SD-Routing, the workflow is different because the device stays autonomous. You generate a bootstrap file (ciscosdwan.cfg) in SD-WAN Manager, copy it to bootflash, ensure the device is in a clean Day-0 state (using controller-mode reset if it was in controller mode, or write erase plus a reload to clear an existing autonomous config), and then bring it up with:

Router# sd-routing bootstrap load bootflash:ciscosdwan.cfg

This command establishes the control connections to the Validator and Manager and registers the device as an SD-Routing (autonomous) device. An alternative is activation by chassis number and Token ID (UUID) obtained from SD-WAN Manager.

Troubleshooting tip: If controller-mode ? shows no options, the image or platform may not support SD-WAN mode switching. Verify you are running a Catalyst 8000 SD-WAN-capable IOS XE image (typically 17.3.x or later for SD-WAN; 17.12.1+ for SD-Routing) and that your release/SKU supports the feature.

Configuration Persistence and Erase

This is the single most important operational fact in the chapter: mode switching is destructive. Both controller-mode enable and controller-mode autonomous are one-way, destructive operations each time they run — they wipe the current configuration and reload.

Specifically, when you switch modes:

• The startup-config is deleted from NVRAM.
• The running configuration is lost on reload; the device comes up with only a minimal, factory-like base config appropriate to the new personality.
• Legacy features (VRFs, DMVPN, classic crypto) must be re-created afterward — either through SD-WAN templates (controller mode) or by reconfiguring from CLI (autonomous mode).

The reason is architectural: SD-WAN's configuration model and data store do not map one-to-one onto classic IOS XE startup-config, so there is no clean way to translate one into the other. The system simply resets to a known-good baseline for the target personality.

The practical discipline that follows:

1. Back up first. Capture show running-config and copy it to TFTP/FTP/flash before any switch.
2. Model the target state ahead of time. If migrating autonomous → SD-WAN, build the equivalent routing, QoS, and VPN behavior as SD-WAN templates and policies before the cutover, so the cEdge can be onboarded immediately after it reboots.
3. Schedule downtime. The reload interrupts traffic. Capturing console output during the first conversion is valuable for change records and rollback planning.

A useful real-world analogy: switching modes is like converting a building from offices to apartments. The structure (hardware) and the plot of land (the Linux OS) stay the same, but you gut the interior and rebuild it to a new floor plan. You would never do it without blueprints (templates/backups) ready and the tenants temporarily moved out (a maintenance window).

When to Use Each Mode

The choice comes down to your operational model, feature needs, and team skill set.

• Choose autonomous mode when you need "just a router" — standard protocols and localized services — in smaller environments or where the team is comfortable with per-device CLI and generic automation (Ansible, RESTCONF). It carries the least architectural overhead.
• Choose controller (SD-WAN) mode when you want centralized policy, application-aware routing, integrated segmentation, overlay security, and template-based rollout across many sites. The Catalyst 8000 becomes a cEdge with SD-WAN Manager as the source of truth.
• Choose SD-Routing when you want unified management — a single SD-WAN Manager pane of glass over both overlay and traditional routers — without forcing every site into an overlay. It is especially valuable for phased migration.

A few illustrative scenarios make the decision concrete:

• Scenario A — Simple dual-homed branch. A site that just needs MPLS + Internet routing with a few VPNs, operated mostly via CLI, is simplest in autonomous mode.
• Scenario B — Large enterprise WAN. Many sites needing centralized policy, per-application dynamic path selection, and template-driven rollout call for controller mode.
• Scenario C — Gradual transition. An estate of 200 classic BGP/MPLS routers can be upgraded to IOS XE 17.12.x+, brought up in SD-Routing to onboard them all into SD-WAN Manager for inventory and monitoring, and then migrated site-by-site to full SD-WAN with controller-mode enable during individual change windows.

Because flipping modes is destructive, many teams in production avoid repeated switching altogether: they dedicate specific hardware or 8000V instances to SD-WAN and others to autonomous routing, maintain golden bootstrap configs for each personality, and lean on PnP/ZTP automation to minimize manual steps after any conversion.

Key Takeaway: Switch modes from privileged EXEC with controller-mode enable (to SD-WAN) or controller-mode autonomous (back to classic), verifying with show platform software device-mode; onboard SD-Routing with sd-routing bootstrap load. Every switch erases the config and reboots, so back up first, model the target state ahead of time, and choose the mode that matches your scale, feature needs, and operating model.