Autonomous vs Controller Mode on IOS XE

You have one IOS XE image and two different routers inside it. Paste a classic configure terminal snippet onto an SD-WAN branch and the change may never become the overlay config. Convert a live SD-WAN edge the other way and you drop it out of the fabric.

This post explains the two modes on Cisco IOS XE 17.18.02, how to see which one you are in, and what Cisco says happens when you switch. I checked the running mode on a Catalyst 8000v in my home lab, on Cisco Catalyst SD-WAN 20.18.2.1. I did not switch either working edge.

This is part of the Cisco SD-WAN series. Previous: Onboard a Catalyst 8000v 17.18 in controller mode. Next: vEdge in 2026: Onboarding and Why It's End-of-Life. The file-transfer sibling is “tclsh not supported in Controller mode”.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

The problem: same image, two control systems

Since IOS XE 17.2, the universalk9 image carries both ordinary IOS XE and Catalyst SD-WAN. You no longer pick a separate "SD-WAN image" at install time. You pick a mode.

That choice decides who the router answers to:

• Autonomous mode is conventional IOS XE. You configure it with configure terminal, Smart Licensing, and the usual on-box tools.
• Controller mode is the SD-WAN personality. The router joins SD-WAN Manager, the Controller, and the Validator, and you change its config with config-transaction and commit.

Think of Autonomous mode as the router running its own CLI, and Controller mode as the router joining the overlay and taking identity, policy, and many operational commands from the control components.

The parts Cisco documents

Cisco's comparison for IOS XE 17.2.1r and later is the source for this table. I did not run each row as a separate experiment.

NETCONF is the XML management protocol the Manager uses to talk to the device. YANG is the data model behind config-transaction.

Cisco's table also lists different licensing models for the two modes. Our Controller-Managed C8000v still printed Smart Licensing Using Policy and a throughput of 20000 kbps, so treat the licensing row as Cisco's documented comparison rather than something I re-tested here.

What the lab actually shows

edge1 is a C8000v on IOS XE 17.18.02. A trimmed show version reads:

edge1#show version | include IOS XE|operating
Cisco IOS XE Software, Version 17.18.02
Router operating mode: Controller-Managed

The same fact appears in a dedicated command:

edge1#show platform software device-mode
Device Operating-mode: Controller-Managed

Device-mode bootup status:
  Bootup Success

show sdwan version returned 17.18.02.0.4112. The control-plane compatibility line in show sdwan system status was Controller Compatibility: 20.18.

A few everyday IOS tools simply refuse to run. The Tool Command Language shell is one of them:

edge1#tclsh
This command is not supported in Controller mode.

That refusal is why the certificate file-transfer post exists. It is a mode restriction, not a syntax error in the certificate.

The SD-WAN configuration on this router uses a transaction, not configure terminal. The identity block from the successful onboard is:

edge1#show sdwan running-config system
system
 system-ip             10.0.0.1
 site-id               100
 organization-name     pinglabz-lab
 vbond 172.16.30.30 port 12346
!

YANG-related processes were running (confd, nesd, syncfd, ncsshd and the rest of show platform software yang-management process). That matches a Controller-Managed box, not an empty Autonomous router.

Help for the mode command is available without changing anything:

edge1#controller-mode ?
  disable  controller-mode disable
  enable   controller-mode enable
  reset    controller-mode reset

I stopped there. controller-mode enable, disable, and reset all reload the router. On a working edge they would take the site out of the overlay. show controller-mode is not a valid command on this image. The mode is in show version and show platform software device-mode.

Switching modes, according to Cisco

I did not run the next three commands on the lab edges. The behavior below comes from Cisco's onboarding and software-installation guides for IOS XE 17.2.1r and later.

To move a router into Controller mode:

Device# controller-mode enable

Cisco documents that this reloads the device. Going from Autonomous to Controller erases the startup configuration and the certificates in NVRAM, the same class of wipe as write erase. The router also expands the running image, so you need free space on bootflash equal to the image .bin size plus 100 MB. Recent 17.12, 17.15, and 17.16 trains check that space before they change mode. Earlier trains could change mode first and then fail the expand.

To move a router back to Autonomous mode:

Device# controller-mode disable

Cisco documents that this also reloads the device. YANG-based configuration is preserved and can be reused if you later return to Controller mode. Cisco describes disable as a temporary move: use the same image to go back.

There is a third option:

Device# controller-mode reset

Cisco documents this as a return to the day-zero configuration.

A factory or bootstrap file can choose the mode for you. If the router finds ciscosdwan.cfg or ciscosdwan_cloud_init.cfg, Cisco says it boots in Controller mode and applies that file. A ciscortr.cfg file or the config-wizard path keeps it Autonomous. Plug and Play can also trigger a mode change. That path is in the Zero-Touch / PnP post.

After a switch into Controller mode you still need an organization name, a Validator address, trust, and an authorized serial list. The onboarding post is the procedure I actually ran.

Verify the mode on your own router

What breaks

• Switching a live SD-WAN edge to Autonomous mode. Control connections drop. The site leaves the overlay until you enable Controller mode again and onboard it.
• Enabling Controller mode on a production Autonomous router without a backup. Cisco says the startup config and NVRAM certificates are erased.
• Not enough bootflash. The expand step can fail, or on older trains it can leave you mid-conversion. Check free space first.
• Using Autonomous habits in Controller mode. configure terminal is the wrong config mode. tclsh and some other on-box tools are blocked. Use config-transaction and commit, or push from SD-WAN Manager.
• Assuming `show controller-mode` exists. On this 17.18.02 image it does not. Read show version or show platform software device-mode.

Key takeaways

• One universalk9 image holds both personalities. Autonomous mode is ordinary IOS XE. Controller mode is the SD-WAN overlay persona.
• Our C8000v 17.18.02 reports Router operating mode: Controller-Managed. I confirmed that with show version and show platform software device-mode, and I left the mode unchanged.
• tclsh is refused in Controller mode. That is expected.
• Cisco documents controller-mode enable, disable, and reset. Enable wipes startup config and certificates. Disable keeps YANG config. All three reload the router. I did not run them on the working edges.
• After you land in Controller mode, you still have to give the router identity, trust, and an authorized serial. That work is in the earlier onboarding posts, not in the mode command itself.