Managed topology and IOS-XE software campaigns
Managed topology connects administrator-declared device locations to two separate workflows: placing application Pods and coordinating IOS-XE operating-system changes. Start with the task you need; enabling placement does not authorize an OS upgrade.
---
config:
layout: dagre
look: classic
---
flowchart LR
I["Declared device topology"] --> N["Manager-owned Node labels"]
N --> S["Kubernetes scheduler"]
S --> P["Application Pod placement"]
I --> R["Reviewed IOS-XE campaign"]
R --> A["CVK admission and reservations"]
A --> O["Gated device OS change"]Scroll the diagram horizontally on smaller screens.
Choose a task
| I want to… | Start here |
|---|---|
| Enable the managed boundary and enroll devices | Enable and enroll |
| Place applications by site, rack or failure domain | Schedule application workloads |
| Plan, approve and run an IOS-XE upgrade or downgrade | Run software campaigns |
| Evaluate voluntary workload evacuation before a campaign | PDB-aware drain preview |
| Understand blocked work and inspect current evidence | Observe and troubleshoot |
| Recover work, retire topology or transfer device ownership | Recovery and retirement |
| Inspect authority, protocol and qualification contracts | Design and authorization reference |
Before you begin
Managed topology is disabled by default. It requires Kubernetes 1.35+, native admission, administrator-controlled device namespaces, leader election and matching chart/CRDs/manager/workers. Complete the setup prerequisites before enrollment; a ready Pod alone does not prove that boundary.
Application hosting can use the initial network-observer profile. OS campaigns additionally require network read-write authority and explicit upgrade gates. Follow the campaign procedure, not unmarked per-device upgrade leaves, for enrolled devices.
Scope and qualification
These pages target v2026.11.1. October v2026.10.0 contains the foundation;
November introduces the staged activation, recovery and network-evidence
extensions described here. Upgrade the matching CRDs, admission policies,
chart, manager and workers together. Check release records
for publication status and feature status for qualification limits.
Campaigns are IOS-XE-specific. Default BlockIfRunning blocks on live workloads;
optional drain has a narrow cohort and incomplete service-through-reload
qualification. A heartbeat, graph or successful lab run does not prove production
forwarding health. Keep guards until the relevant cluster, device and application
checks pass.
Recorded scope and evidence identifies the tested boundaries. The roadmap and execution plan retain development history, not authority to bypass a blocked operation.
Links from earlier versions of this guide
Older links remain valid below. Each opens the corresponding task or reference section; update bookmarks to its canonical page when convenient.
| Previous section | Continue to |
|---|---|
| Architecture and ownership | Open section |
| Prerequisites | Open section |
| Configure and enable | Open section |
| Label vocabulary | Open section |
| Enroll devices safely | Open section |
| Workload scheduling | Open section |
| Experimental in-tree Workload/PodGroup/TAS | Open section |
| Topology-aware IOS-XE software campaigns | Open section |
| Secure gNOI and image-source prerequisites | Open section |
| Opt-in PDB-aware drain (development preview) | Open section |
| Submit, review, and approve | Open section |
| Admission and execution behavior | Open section |
| Pause, resume, and cancel | Open section |
| Observe and troubleshoot | Open section |
| Delegated authorization | Open section |
| Rollback and retirement | Open section |
| Abandoning an unused preparation | Open section |
| Offline transfer to another cluster | Open section |
| Qualification checks | Open section |
| Read-only accepted topology graph | Open section |
| Deferred roadmap and limitations | Open section |