Upgrading SD-WAN Controllers and WAN Edges

An SD-WAN overlay is several pieces of software that have to stay compatible with each other: Manager, Validator, Controller, and every WAN edge. Upgrading them in the wrong order, or mixing trains Cisco does not list as compatible, is a reliable way to lose control connections.

This post is the lifecycle, not a live upgrade. The lab runs Cisco Catalyst SD-WAN 20.18.2.1 on the controllers and IOS XE 17.18.02 on the C8000v edges, built in my home lab. I read the running images and I did not upload a new package, activate one, or reboot anything.

This is part of the Cisco SD-WAN series. Previous: SD-WAN segmentation end to end.

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

The problem: four planes, one compatibility rule

Manager is the orchestrator. The Validator introduces new devices. The Controller runs OMP. The edges forward packets. Each one has its own image, and the edge image train (17.x) is paired with the controller train (20.x, then 26.x).

If you upgrade edges first, they may reject the older Controller. If you upgrade the Controller before Manager, Manager may not understand the new device. If you upgrade Manager last, you are driving the process from the box that is furthest behind.

Cisco's documented order is:

1. Manager, by itself
2. Validator
3. Controller
4. WAN edges

Cisco also says you cannot put Manager in a group software-upgrade operation with the others. Upgrade and reboot Manager on its own, then use it to upgrade the rest. The recommendation is to perform upgrades from Manager rather than from the CLI.

Think of it as remodeling a control tower before the runways. The people who will coordinate the rest of the work need the new playbook first.

What this lab is running today

I checked each role with show software (Viptela OS) or show sdwan software (IOS XE). Each box has one image, and that image is active and default. There is no previous image to roll back to.

manager# show software
VERSION    ACTIVE  DEFAULT  PREVIOUS  CONFIRMED  TIMESTAMP
20.18.2.1  true    true     -         -          2025-11-18T05:06:40-00:00

The Controller and the Validator print the same 20.18.2.1 line, same timestamp.

edge1#show sdwan software
VERSION            ACTIVE  DEFAULT  PREVIOUS  CONFIRMED  TIMESTAMP
17.18.02.0.4112    true    true     false     user       2026-11-05T04:14:33-00:00

edge2 matches, with a timestamp three seconds later. show version on the edges reports Cisco IOS XE Software, Version 17.18.02. show sdwan system status reports Controller Compatibility 20.18 and vManaged: false. The edges are still CLI-managed, which means a Manager-driven upgrade workflow would be the same software-install path but without a device template in the way.

The overlay itself is healthy on these images: control connections up, two BFD sessions up, and a VRF 10 ping to 192.168.20.10 at 5/5. That is the baseline I would record again after any real upgrade.

I did not open a software-repository upload, and I did not start an install task. There is nothing useful about watching a lab reboot off a second image I do not intend to keep.

Compatibility and the path into 20.18

Cisco moved the old static compatibility tables into two tools:

• The Compatibility Matrix Tool, for which edge versions a given Manager/Controller release will support.
• The Upgrade Matrix Tool, for which Manager versions you can jump between.

Check both before you download anything. The 17.18.x device release notes say Manager 20.18.1 supports devices up to N-2 long-lived releases and does not keep older overlay devices. After a Manager upgrade to 20.18.1, Manager flags incompatible devices with compliance banners and alarms. That is the warning I would expect if an older edge stayed behind.

Cisco's upgrade journey note (document 225515, updated 20 February 2026) is the map I would follow for a production Manager:

• Gather five facts first: standalone Manager or a cluster, disaster recovery on or off, current Manager version, target Manager version, and current router versions.
• Pause disaster recovery before you upgrade, if you use it, and do not continue until that pause is clean.
• Cluster upgrades, and some older trains such as 20.9, have extra CLI and statistics-database steps. A standalone 20.15.x or 20.18.x Manager upgrade can use the GUI.
• Validator and Controller upgrades are a separate procedure, from the Manager GUI or the CLI, after Manager itself is done.

The next controller train after 20.18 is 26.1.x. That jump is a planned migration, not something I am running here.

The order, and why it is that order

Manager first. It holds the software repository, the upgrade workflow, and the view of device compatibility. Cisco upgraded the group workflow so that when you do upgrade a mixed set of Validators, Controllers, and edges, the backend still sequences Validator, then Controller, then edges (up to 40 edges in parallel, depending on CPU). Manager stays out of that group.

Validator second. New or reconnecting devices have to find the overlay through the Validator. An upgraded Validator understands the certificates and serials the rest of the overlay will use.

Controller third. OMP peers are sensitive to version skew. Once Manager can manage the new Controller code, the Controller can serve edges that are about to move.

Edges last. They forward user traffic. Upgrade them in waves, site by site, and keep a path through the sites you have not touched. Confirm control connections and BFD after each wave.

Cisco publishes a software-upgrade workflow (from Manager 20.8.1) that walks you through edge upgrades and shows status. I did not run that workflow.

Verify before anyone clicks Upgrade

If you do upgrade later, repeat that table after Manager, after the Validator and Controller, and after each edge wave. Keep the old image until you confirm the new one, then mark it default only when you are willing to lose the previous slot.

What breaks

• Edges first. The new edge code may not form control connections to an older Controller.
• Skipping the compatibility tools. 20.18 is explicit about dropping older than N-2 long-lived device trains.
• Upgrading Manager while disaster recovery is still replicating. Cisco wants DR paused and clean.
• Including Manager in a group install with Validators and Controllers. That operation is not supported.
• Running an image install on this lab to "see the prompts." There is no second image, and a reboot would take down the overlay this series is using.

Key takeaways

• Upgrade Manager by itself, then the Validator, then the Controller, then the edges. Check Cisco's compatibility and upgrade-matrix tools for the exact trains you have.
• This lab is already aligned on 20.18.2.1 and 17.18.02, one image per box, with a healthy overlay. I recorded those versions and stopped.
• I did not upload, activate, or reboot any image.
• Treat a real upgrade as a change window with a recorded baseline, not as a lab experiment on the only fabric you have.