Cisco SD-WAN Getting Started Guide

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco SD-WAN Getting Started Guide

Chapter Title

Install and Upgrade Cisco IOS XE Release 17.2.1r and Later

Results

Updated:
March 29, 2023

Chapter: Install and Upgrade Cisco IOS XE Release 17.2.1r and Later

Install and Upgrade Cisco IOS XE Release 17.2.1r and Later

Table 1. Feature History

Feature Name

Release Information

Description

Install and Upgrade

 Cisco IOS XE Release 17.2.1r

This feature supports the use of a single "universalk9" image to deploy Cisco IOS XE SD-WAN and Cisco IOS XE functionality on all the supported devices. This universalk9 image supports two modes - Autonomous mode (for Cisco IOS XE features) and Controller mode (for Cisco SD-WAN features) .

Cisco Catalyst 8000V Edge SoftwarePlatform

Cisco IOS XE Release 17.4.1a

Support added for the Cisco Catalyst 8000V Edge Software platform. Upgrading Cisco CSR1000V or Cisco ISRv platforms to Cisco IOS XE Release 17.4.1a includes upgrading to the platform type to the Cisco Catalyst 8000V.

Starting with Cisco IOS XE Release 17.2.1r, use the universalk9 image to deploy both Cisco IOS XE SD-WAN and Cisco IOS XE on Cisco IOS XE devices.

Starting Cisco IOS XE Release 17.2.1r, UCMK9 image is not available.

This release helps in seamless upgrades of both the SD-WAN and non SD-WAN features and deployments.

Access the Cisco IOS XE and Cisco IOS XE SD-WAN functionality through Autonomous and Controller execution modes, respectively. The Autonomous mode is the default mode for the routers and includes the Cisco IOS XE functionality. To access Cisco IOS XE SD-WAN functionality, switch to the Controller mode. You can use the existing Plug and Play Workflow to determine the mode of the device.

Platforms Supported in Controller Mode

Platforms Supported in Controller Mode

  • Cisco ASR 1000 Series Aggregation Services Routers

  • Modular Cisco ASR 1006-X with ASR1000-RP3 module (Cisco IOS XE Release 17.5.1a or later, see Cisco ASR 1006-X with an RP3 Module.)

  • Cisco ISR 1000 Series Integrated Services Routers

  • Cisco ISR 4000 Series Integrated Services Routers

  • Cisco 1101 Industrial Integrated Services Router

  • Cisco CSR 1000v Series Cloud Services Routers

  • Cisco Integrated Services Virtual Router (ISRv)

  • Cisco Catalyst 8200 Series Edge Platforms

  • Cisco Catalyst 8300 Series Edge Platforms

  • Cisco Catalyst 8500 Series Edge Platforms

  • Cisco Catalyst 8000V Edge Software (Cisco IOS XE Release 17.4.1a or later)

Platforms Not Supported in Controller Mode

Modular platforms based on the following ASR 1000 Series Routers are not supported in controller mode:

  • ASR1000-RP2

Crypto Modules Supported in Controller Mode

The following crypto modules are required for the ASR 1000 series routers:

  • ASR1001HX-IPSECHW, for the ASR 1001-HX

  • ASR1002HX-IPSECHW, for the ASR 1002-HX

Cisco IOS XE Image Compatibility

Deployment Image Version

SD-WAN

 Non SD-WAN

Cisco IOS XE Releases 16.9.x, 16.10.x, 16.11.x, 16.12.x

ucmk9

universalk9

Cisco IOS XE Release 17.1.x

NA

universalk9
Cisco IOS XE Release 17.2.x and later

universalk9*

universalk9**

  • * For SD-WAN use case, non-LI and non-payload encryption image types are not supported.

  • ** For non SD-WAN use case, non-LI and non-payload encryption image types are supported (universalk9_noli, universalk9_npe, universalk9_npe_noli).

Upgrade Considerations

The following Cisco IOS XE SD-WAN devices support multirate interfaces and support the 1GE SFP (optical and CU) and 10GE SFP+ (optical and CU) modules on their 10G interfaces ports:

  • Cisco ASR 1001-HX Router

  • Cisco Catalyst 8500-12X4QC

  • Cisco Catalyst 8500-12X

These devices support auto-negotiation on 10G interfaces ports with 1GE SFP (optical and CU) modules. The following notes apply to auto-negotiation in both SD-WAN and non-SD-WAN modes:

  • For releases before Cisco IOS XE 17.6.1a, auto-negotiation can be configured using the CLI.

  • For releases before Cisco IOS XE 17.6.1a, if you use the CLI or Cisco vManage to reboot a device with a 10G interface that includes a 10GE SFP+ module, that interface will not come up. In this situation, use Cisco vManage or the CLI to configure no negotiation auto for the interface, then reboot the device.

  • From Cisco IOS XE Release 17.6.3a, auto neg values for auto-negotiation are pushed to 10G interfaces on supported devices through feature templates. Ensure that you know which SFP module is on which 10G interface on a device so that you can properly configure the feature template.

  • From Cisco IOS XE Release 17.6.3a, the negotiation auto command is not supported on a 10G interface that includes a 10GE SFP+ module.

  • From Cisco IOS XE Release 17.6.3a, the no negotiation auto command with the default OFF option must be sent through a feature template to all 10G interfaces that include a 10GE SFP+ module. Otherwise, the template push fails.

  • Before upgrading to Cisco IOS XE Release 17.6.3a, use a feature template, a CLI add-on feature templates, or the CLI to apply no negotiation auto to all 10G interfaces that include a 10GE SFP+ module.

  • If you upgrade to Cisco IOS XE Release 17.6.3a from a release in which auto-negotiation was enabled on a 10G interface that includes a 10GE SFP+ module, that interface will not come up. In this situation, use the CLI to configure no negotiation auto for the interface after the upgrade completes.

Restrictions

Restrictions for single "universalk9" image

  • Dual-IOSd is supported only in autonomous mode.

  • Images without payload encryption and NO-LI (universalk9_npe, universalk9_noli, universalk9_npe_noli) images are not supported in controller mode. Only universalk9 images are supported.

  • After onboarding and determining the mode of operation, changing from Controller mode to Autonomous mode or vice-versa, results in the loss of configuration.

  • Reset button functionality is not supported in controller mode on Cisco ISR 1000 series Integrated Service Routers. The reset button does not function to restore a golden image or configuration in controller mode.

  • Auto-install (Python and TCL scripts) and ZTP—Autoinstall and ZTP are not supported in controller mode. If DHCP discovers an attempt to install using either of these processes, a mode change to Autonomous mode is triggered.

  • WebUI—In controller mode, WebUI is not supported and an error message is displayed, if used.

Self-Signed Trustpoint

A self-signed trustpoint is generated and loaded to a Cisco IOS XE SD-WAN device when the device boots up. If this trustpoint is deleted for any reason, you can generate and load a new trustpoint by rebooting the device. The new key may be different than the deleted one.

Introducing Autonomous and Controller Mode

The Cisco IOS XE Release 17.2.1r release introduces two installation modes – Autonomous and Controller modes. The autonomous mode supports the functionality of Cisco IOS XE non SD-WAN deployment and the controller mode supports the Cisco SD-WAN solution.

The following are the main differences between Autonomous mode and Controller mode:

Table 2.

Feature

Autonomous Mode

Controller Mode

Configuration Method

  • Command Line Interface (CLI)

  • NETCONF

YANG-based configuration

  • Cisco vManage

  • NETCONF

Onboarding Modes

  • Plug and Play

  • Config-Wizard

  • WebUI

  • Bootstrap (USB, bootflash, and so on)

  • Auto-Install (Python Script, TCL Script)

  • ZTP (Using DHCP Option 150 and Option 67)

  • Plug and Play

  • Bootstrap (USB, bootflash, and so on)

Licensing

Cisco Smart Licensing

Cisco High Performance Security (HSEC) software licensing. No device licensing.

Image Type

Universalk9

Universalk9

Dual-IOSd redundancy model

Supported

Not Supported

High Availability

Supported

Not Supported

Global configuration mode

configure terminal

config-transaction

Software Installation for Cisco IOS XE Routers

Download the Software for Cisco IOS XE Release 17.2.1r or Later

Download the router-model-universalk9.​release-number. image for Cisco IOS XE Release 17.2.1r or later software from the Cisco site https://software.cisco.com .

Install Software on Cisco CSR 1000v Platform

Based on the cloud in which you are deploying the CSR 1000v instance, see the following to perform the bootstrap and/or the day 0 configuration:

Install a Cisco Catalyst 8000V Edge Software Platform

Table 3. Feature History

Feature Name

Release Information

Description

Support for the Cisco Catalyst 8000V Edge Software Platform on OpenStack Train

 Cisco IOS XE Release 17.7.1a

This feature introduces support for managing a Cisco Catalyst 8000V Edge software platform hosted in the OpenStack cloud computing platform "Train" release.

Beginning with Cisco IOS XE Release 17.4.1a, Cisco SD-WAN supports the Cisco Catalyst 8000V virtual router platform, which replaces the Cisco CSR1000V and Cisco ISRv. Installing the Cisco Catalyst 8000V in an Cisco SD-WAN environment requires Cisco vManage Release 20.4.1 or later.

Download the Cisco Catalyst 8000V software image that is appropriate for your method of deployment. For example, this can be an OVA file for ESXi, or a QCOW2 image for OpenStack or KVM. Do not choose an ISO image. Have the image ready to upload to the Cisco vManage software image repository. The file name begins with: c8000v-universalk9


Note

To operate with Cisco SD-WAN, the device must be in controller mode. When starting the device in controller mode, boot the device using the bootflash:packages.conf file.

For complete information about the platform, including installation in KVM, ESXi, and OpenStack environments, see the Cisco Catalyst 8000V Edge Software Installation and Configuration Guide. For information about creating a bootstrap file for onboarding the Cisco Catalyst 8000V into Cisco SD-WAN, see Bootstrap Process for Cisco SD-WAN Cloud-Hosted Devices.

Clean Install

We recommend a clean install of the Cisco Catalyst 8000V. This ensures support for all features, provides the most up-to-date licensing, and ensures that devices and the controller stay synchronized. For cases where upgrade is necessary, see the procedure in Upgrade to Cisco IOS XE Release 17.2.1r or Later.


Note

After a clean install of the Cisco Catalyst 8000V, it is not possible to downgrade the device to a release earlier than Cisco IOS XE Release 17.4.1a.

Upgrading a Cisco CSR1000V to a Cisco Catalyst 8000V

Upgrading a Cisco CSR1000V or Cisco ISRv virtual router to Cisco IOS XE Release 17.4.1a includes upgrading to the Cisco Catalyst 8000V. Note the following:

  • The Cisco Catalyst 8000V preserves all of the functionality available on Cisco CSR1000V or Cisco ISRv platforms.

  • Performing the upgrade in Cisco vManage preserves the configuration of the device(s) being upgraded.

OpenStack

Installing a Cisco Catalyst 8000V on the OpenStack Train release requires using a Cisco IOS XE Release 17.7.1a or later image for the Cisco Catalyst 8000V.

Cisco does not support installing a Cisco Catalyst 8000V on OpenStack using an earlier image, or installing on OpenStack using an earlier image and upgrading to Cisco IOS XE Release 17.7.1a.

Plug and Play in Cisco IOS XE Release 17.2.1r and Later Releases

Plug and Play Onboarding Workflow

  1. Place an order for the device in Cisco Commerce with Smart Account and Virtual Account details of the customer.

  2. The device information from Cisco Commerce like Device serial number, Smart Account, and Virtual Account are added to the Plug and Play portal.

  3. Add a vBond controller profile into the Plug and Play (PnP) portal for the same Smart Account and Virtual Accounts.

  4. Associate the new device to the vBond controller profile manually.

  5. PnP sends all relevant information including vBond details, device serial number, organization name, and network ID to Zero Touch Provisioning (ZTP).

  6. Download the device serial number file (provisioning file) from PnP and upload it to Cisco vManage. The devices are now available on Cisco vManage. You can also use the Sync Smart Account option on vManage to sync the device with your virtual account and populate the device in Cisco vManage.


Note

If you created and scheduled a device template on Cisco vManage Release 20.3.x and upgraded Cisco vManage to Cisco vManage Release 20.4.1 or later before onboarding the target device, when you onboard the device using PNP or ZTP, the template push fails. To avoid this failure, reschedule the template after upgrading the Cisco vManage software and then onboard the device.


Note
If the ZTP process for a device is interrupted because the device reloads or power cycles, the ZTP process does not restart and the device comes online with the Cisco vManage image that was in its original configuration. In this situation, upgrade the device to the desired Cisco vManage release manually.

Note

For more information, refer to the Plug and Play Support Guide.

Mode Discovery with Plug and Play Onboarding

The PnP-based discovery process determines the mode in which the device operates, based on the controller discovery and initiates a mode change, if required. The mode change results in a reboot of the device. Once reboot is complete, the device performs appropriate discovery process.

When you upgrade to Cisco IOS XE Release 17.2.1r or later, on a Cisco device that already runs a Cisco IOS XE or Cisco SD-WAN image, the device starts in autonomous mode or controller mode depending on the configured controller.

Plug and Play (PnP) deployment include the following discovery process scenarios:

Table 4.

Boot up Mode

Deployment Mode

On-boarding agent

vBond Orchestrator

 Discovery Process

Mode Change

Autonomous

Cisco Digital Network Architecture (DNA)

Plug and Play

No

Plug and Play Connect Discovery or on-premise plug and play server discovery

No Mode change

Autonomous

Cisco vManage

Plug and Play

Yes

Plug and Play Connect Discovery

Mode change to controller mode

Controller

Cisco DNA

Plug and Play

No

Plug and Play Connect Discovery or on-premise plug and play server discovery

Mode change to autonomous mode

Controller

Cisco vManage

Plug and Play

Yes

Plug and Play Connect Discovery

No mode change

Automatic IP Address Detection

Table 5. Feature History

Feature Name

Release Information

Description

Day 0 WAN Interface Automatic IP Detection using ARP

Cisco IOS XE Release 17.7.1a

Cisco SD-WAN Release 20.7.1

Cisco vManage Release 20.7.1

This feature enables a device to automatically learn about the available IP addresses and default gateway information when a DHCP server is not available. The device assigns an IP address to its WAN interface, and then contacts the PnP server and begins the PnP onboarding process.

Typically, the WAN interface on a Cisco IOS XE SD-WAN device or Cisco vEdge device is configured as a DHCP client, and this interface receives an IP address and gateway server information from the DHCP server during the plug-and-play (PnP) onboarding process.

If the DHCP server is not available, the device automatically learns about the available IP addresses and default gateway information by using Address Resolution Protocol (ARP) packets. If an IP address that the device learns allows a successful connection to the PnP server, the device continues with the PnP onboarding process.


Note

This feature applies only to day zero deployments and is enabled by default.

Prerequisites for Automatic IP Address Detection

  • To trigger ARP, configure the IP address of the device as the BGP neighbor on the provider edge (PE) router.

    This PE router is the first point of contact for the device in the WAN transport network. The PE router then sends ARP packets with this IP address to the device. The device receives the ARP packets, and then the Automatic IP Address Detection feature defines the ARP destination IP address as the device's WAN interface IP address.

  • For Cisco IOS XE SD-WAN devices, the network mask of this IP address must be 30 bits.

  • For automatic IP address detection and redirection through an on-premises ZTP server, the A record of the ZTP server on the DNS server must be set to ztp.cisco.com. In addition, the DNS server must have an ip name-server value of 8.8.8.8 or 8.8.4.4.

For automatic IP address detection, a device uses 8.8.8.8 or 8.8.4.4 as the DNS server to resolve devicehelper.cisco.com or ztp.cisco.com. The PnP process then attempts to reach devicehelper.cisco.com or ztp.cisco.com to continue onboarding.


Note
An IP address that a device automatically detects is not preserved during reboots of the device that occur before the PnP onboarding completes. In such cases, an IP address is assigned automatically when the PE router ARP cache expires.

Limitations and Restrictions for Automatic IP Address Detection

The following limitations and restrictions apply only to Cisco IOS XE SD-WAN devices:

  • This feature is supported only on Cisco 1000 Series Integrated Service Routers, Cisco 4000 Series Integrated Service Router, and Cisco Catalyst 8200 and 8300 Series Edge Platforms. On these devices, this features is supported only for Gigabit Ethernet Interface 0/0/0.

  • The feature is supported only on devices that are in controller (SD-WAN configuration) mode. See https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/install-upgrade-17-2-later.html.

  • This feature is supported only in a simple 30 bit network mask Layer 2 network in which one PE router and one customer edge router are in the same VLAN.

  • This feature does not support VRRP, HSRP, or GLBP on the PE router.

  • An ARP destination IP address is used as the WAN interface IP address on a device only after the device receives the same ARP request eight times within an interval of 150 seconds.

Non-PnP Onboarding

New Installation: Mode Change Device Day Zero Scenario

  1. If the device is running a pre-17.2 universalk9 image on a new box, or for an existing box where you performed write erase and reload and loaded a Cisco IOS XE 17.2 or newer image, the device boots in day zero configuration and in autonomous mode.

  2. The new device determines if a mode change is required based on the bootstrap file.

    • If ciscosdwan.cfg or ciscosdwan_cloud_init.cfg bootstrap file in a plugged in the bootstrap location, mode change to controller mode is initiated. After the device boots up in controller mode, the configuration present in the configuration file is applied.

    • If a ciscortr.cfg bootstrap file or config-wizard is discovered, mode change is not initiated and the boot up continues in the Autonomous mode.


Note

  • The bootstrap file (ciscosdwan.cfg) is generated by Cisco vManage, and has UUID, but no OTP.

  • For software devices (Cisco Catalyst 8000V Edge Software, Cisco Cloud Services Router 1000V Series, and Cisco ISRv), and for OTP-authenticated devices such as the Cisco ASR1002-X, use the bootstrap file ciscosdwan_cloud_init.cfg. This file has OTP but no UUID validation.

Switch Modes Using Cisco CLI

Use the controller-mode command in privileged EXEC mode to switch between controller and autonomous modes.

The controller-mode disable command switches the device to autonomous mode. 

Device# controller-mode disable

The controller-mode enable command switches the device to controller mode. 

Device# controller-mode enable

Note

To switch the device to the controller-mode, boot the system using either the bootflash:/*.bin or bootflash:/packages.conf file.


Note

If device is booted with bundle mode (Super packages), after reboot, the image gets automatically expanded and activated to prepare the router for SDWAN operation. Devices with 4GB RAM may require an additional reboot to free up space in /bootflash. The following devices with 4GB RAM need reload:

  • Cisco ISR 4451

  • Cisco ISR 4431

  • Cisco ISR 4461

  • Cisco ISR 4351

  • Cisco ISR 4331

  • Cisco ISR 4321

Note

You cannot view the contents of the bootflash:/.sdwaninstaller directory of a Cisco IOS XE SD-WAN device in either of the following conditions:

  • The device is in controller mode.

    or

  • The device is in autonomous mode and using Cisco IOS XE Release 17.6.1a or later.

Mode Discovery and Mode Change with Bootstrap Files

On a device that already runs a Cisco IOS XE non SD-WAN image, after upgrading to a Cisco IOS XE Release 17.2.1r or later image, the device boots up in autonomous mode.


Note

If there is a previous SD-WAN configuration file present on the device, the device boots in controller mode. Before performing an upgrade, ensure that you remove any stale SD-WAN configuration files from bootflash.

Detailed steps to delete all SD-WAN artifacts from bootflash:

delete /force bootflash:/ciscosdwan*.cfg

delete /force /recursive bootflash:/.sdwaninstallerfs

delete /force /recursive bootflash:/.sdwaninstaller

delete /force /recursive bootflash:/.sdwaninternal

delete /force /recursive bootflash:/sdwan

delete /force /recursive bootflash:/vmanage-admin

delete /force /recursive bootflash:/.cdb_backup

delete /force /recursive bootflash:/.installer/active

delete /force /recursive bootflash:/.installer

On a device that already runs a Cisco IOS XE SD-WAN image, after upgrading to a Cisco IOS XE Release 17.2.1r or later image, the device boots up in controller mode.


Note

Installing the Cisco Catalyst 8000V on OpenStack requires using the Cisco Catalyst 8000V image for Cisco IOS XE Release 17.7.1a or later.

Use the controller-mode enable command to switch from autonomous to controller mode and the controller-mode disable command to switch from controller mode to autonomous mode.

To switch modes using CLI, ensure that the appropriate configuration files mentioned in the table below are present. After the device boots up, the configuration present in the configuration file is applied. The device reads the configuration file and uses the configuration information to come up on the network.

Table 6. Configuration File Prerequisites for Mode Change

Current Mode

Mode change to

Platforms

Configuration file and location

Controller

Autonomous

All supported platforms

ciscortr.cfg in any file system available to the device

Autonomous

Controller

  • Cisco Cloud Services Router, CSR1000v

  • Cisco Integrated Services Virtual Router, ISRv

  • Cisco Catalyst 8000V

  • Cisco ASR1002-X

ciscosdwan_cloud_init.cfg on bootflash, USB, CDROM0, or CDROM1

Autonomous

Controller

  • Cisco Aggregation Services Router, ASR 1000 Series

  • Cisco Integration Service Routers, ISR 4000 series and ISR 1000 series routers

ciscosdwan.cfg on bootflash or USB

Note

On a Cisco CSR1000v device (for Cisco IOS XE Release 17.2 or later) and a Cisco Catalyst 8000V (for Cisco IOS XE Release 17.4 or later) image deployment, if you want to boot up the device in controller mode, load the bootstrap file generated by Cisco vManage by bootstrap (ESXi, KVM, and OpenStack) or user-data (AWS) or custom-data (Azure and GCP).

The following fields must be present in the ciscosdwan_cloud_init.cfg bootstrap file:

  • otp

  • uuid

  • vbond

  • org

Note

When the device mode is switched from autonomous to controller, the startup configuration and the information in NVRAM (certificates), are erased. This action is equivalent to running the write erase command.


Note

When the device mode is switched from controller to autonomous, all Yang-based configuration is preserved and can be reused if you switch back to controller mode.


Note

When the device is in Day N configuration and is reloaded, the presence of a bootstrap file does not impact the device operating mode.


Note

You cannot view the contents of the bootflash:/.sdwaninstaller directory and .sdwanistallerfs file of a Cisco IOS XE SD-WAN device in either of the following conditions:

  • The device is in controller mode.

    or

  • The device is in autonomous mode and using Cisco IOS XE Release 17.6.1a or later.

Directory, more, copy and delete operations are not allowed when the file and directory are hidden in controller-mode.

Reset Controller Mode Configuration

If you use request platform software sdwan config reset or request platform software sdwan software reset commands to bring the device back to controller-mode day-zero configuration, the device performs one of the following actions:

To erase the SD-WAN configuration of the current active image, use the following CLI:

Device# request platform software sdwan config reset
%WARNING: Bootstrap file doesn't exist and absence of it can cause loss of connectivity to the controller.
For saving bootstrap config, use:
request platform software sdwan bootstrap-config save
Proceed to reset anyway? [confirm]
Backup of running config is saved under /bootflash/sdwan/backup.cfg
WARNING: Reload is required for config-reset to become effective.

Note

The warning listed in the above configuration is visible only on Cisco IOS XE Release 17.3.1a and later images.

For the changes to take effect, you must reload the router after running the CLI. Running this CLI ensures the configuration for the currently installed version is wiped along with crypto keys and the device enters the day zero workflow after the reload.

If the device is not set up to use PnP for onboarding, then it reads the configuration file in the bootflash and uses the configuration information to come up on the network. If the device is setup to use PnP onboarding, then after reload, the PnP discovery will start again.


Note

In the case of public clouds, just like a fresh install, additional bootstrap configuration is provisioned that allows you to login to the instance.


Note

In public cloud and NFVIS environments, ensure that a latest day-zero bootstrap configuration file (exported from Cisco vManage) is available in a supported location and following standard file naming conventions (example: bootflash:/ciscosdwan_cloud_init.cfg file), before the configuration reset operation is performed.


Warning

Failure to follow save the bootstrap file in these environments cause loss of virtual machine connectivity.

Mode Switching: Additional Information

Configuration Persistence During Mode Switch

Table 7.

Current Configuration Mode

Mode Switched to

Behavior

Autonomous

Controller

Contents of NVRAM and the startup configuration are erased. Configuration is not be restored. Device is reverted to Day zero configuration. Previous running configuration is stored in bootflash.

Note 

When you switch from autonomous mode to controller mode, and switch back to autonomous mode, the Cisco IOS XE configuration is not restored because the startup configuration is empty. You have to manually restore configuration from the backup.

Controller

Autonomous

CDB contents are erased (for subsequent mode switches) and Cisco IOS configuration are not restored (as startup configuration is empty). You have to manually restore configuration from the backup.

Verify Controller and Autonomous Modes

Show Command Output for Controller Mode

Device# show logging | include OPMODE_LOG
*Dec  8 16:01:17.339: %BOOT-5-OPMODE_LOG: R0/0: binos: System booted in CONTROLLER mode
Device# show version | inc operating

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

Device-mode bootup status:
-------------------------------------
 Success
Device# show platform software chasfs r0 brief | inc device_managed_mode

/tmp/chassis/local/rp/chasfs/etc/device_managed_mode : [controller]
  /tmp/fp/chasfs/etc/device_managed_mode : [controller]
Device# show version | inc Last reload
Last reload reason: Enabling controller-mode

Show Command Output for Autonomous Mode

Device# show logging | include OPMODE_LOG
*Dec  8 17:01:17.339: %BOOT-5-OPMODE_LOG: R0/0: binos: System booted in AUTONOMOUS mode
Device# show version | inc operating

Router operating mode: Autonomous
Device# show platform software device-mode

Operating device-mode: Autonomous 

Device-mode bootup status:
-------------------------------------
Device# show platform software chasfs r0 brief | inc device_managed_mode

/tmp/chassis/local/rp/chasfs/etc/device_managed_mode : [autonomous]
  /tmp/fp/chasfs/etc/device_managed_mode : [autonomous]
Device# show version | inc Last reload
Last reload reason: Enabling autonomous-mode

Note

If the device is in controller mode, the show sdwan running-config command does not display the following information:

  • All service commands under /native/service except tcp-small-servers, udp-small-servers, tcp-keepalives-in, and tcp-keepalives-out

  • Configurations under line VTY except for transport, access-class, and ipv6 access-class

  • IPv6 unicast routing configuration

  • Commands in /native/enable

To verify these configuration use the show running-config command.

Change the Console Port Access After Installation, in Controller Mode

Before You Begin

Before beginning this procedure, ensure that you have access to the Cisco CSR1000V or Cisco Catalyst 8000V router through the currently configured console access method.

Change the Console Port Access

This procedure changes the method for connecting to the console to access a Cisco CSR1000V or Cisco Catalyst 8000V software device.

The image used for deploying the Cisco CSR1000V or Cisco Catalyst 8000V software determines the default type of console access to use, which can be virtual or serial.

The procedure includes changing the mode from controller to autonomous, and then back to controller, which is required for operation with Cisco SD-WAN. These mode changes cause the device to reload.

Perform the following steps to change the console port access.

  1. In EXEC mode, enter enable to enter privileged EXEC mode. 

    Router> enable

  2. Disable controller mode. Enter the following command and follow the prompts to complete the command.

    Device# controller-mode disable

    Note

    This reboots the device in autonomous mode.

  3. After the device restarts, enter enable to enter privileged EXEC mode. 

    Router> enable

  4. Enter global configuration mode.

    Device# configure terminal

  5. Use one of the following options to configure the type of access:

    • virtual: This option specifies that the device is accessed through the hypervisor virtual VGA console.

      Device(config)# platform console virtual

    • serial: This option specifies that the device is accessed through the serial port on the virtual machine (VM).


      Note

      • Use this option only if your hypervisor supports serial port console access.

      • If the device configuration is stored as a Cisco vManage device template and is attached to the device using Cisco vManage, enter the command 
        Device(config)# platform console serial
        to the CLI add-on feature template. For more information on CLI Add-On Feature Templates see, Cisco SD-WAN Systems and Interfaces Configuration Guide. This helps in avoiding Cisco vManage removing the serial port when the device template is attached to the device. 
      Device(config)# platform console serial

    • auto: (This option has been deprecated and is not recommended.) This option specifies that the device console is detected automatically. This is the default setting during the initial installation boot process. For additional information, see Booting the Cisco CSR 1000v as the VM.

  6. Exit configuration mode.

    Device(config)# end

  7. Save the configuration.

    Device# write memory

  8. Copy the running configuration to the startup configuration.

    Device# copy system:running-config nvram:startup-config

  9. Change the device back to controller mode. Enter the following command and follow the prompts to complete the command.

    Device# controller-mode enable

    Note

    This step reboots the device in controller mode.

Upgrade to Cisco IOS XE Release 17.2.1r or Later

Supported Upgrades

Table 8. Cisco CSR1000V and Cisco ISRv Routers

You Can Upgrade to...

From these Releases

Cisco IOS XE Release 17.4.1a

Cisco IOS XE SD-WAN 17.3.1a or later

Cisco IOS XE SD-WAN 17.2.2 or later

Cisco IOS XE SD-WAN 16.12.4a or later

Note 

  • To upgrade a Cisco CSR1000V or Cisco ISRv router to Cisco IOS XE Release 17.4.1a from a release not listed here requires first upgrading to one of these releases.

  • Upgrading a Cisco CSR1000V or Cisco ISRv router to Cisco IOS XE Release 17.4.1a includes upgrading to the Cisco Catalyst 8000V.

Cisco IOS XE 17.3.x

Cisco IOS XE Release 17.2.1r

Cisco IOS XE Release 17.2.1v

Cisco IOS XE SD-WAN 16.12.x

Cisco IOS XE SD-WAN 16.11.x

Cisco IOS XE SD-WAN 16.10.x

Cisco IOS XE SD-WAN 16.9.x

Cisco IOS XE Release 17.2.1r

Cisco IOS XE SD-WAN 16.12.x

Cisco IOS XE SD-WAN 16.11.x

Cisco IOS XE SD-WAN 16.10.x

Cisco IOS XE SD-WAN 16.9.x
Table 9. All Routers Supported by Cisco SD-WAN Except Cisco CSR1000V, Cisco ISRv, and Cisco Catalyst 8000V

You Can Upgrade to...

From these Releases

Cisco IOS XE Release 17.4.1a

Cisco IOS XE SD-WAN 17.3.1a or later

Cisco IOS XE SD-WAN 17.2.1 or later

Cisco IOS XE SD-WAN 16.12.4a or later

Cisco IOS XE 17.3.x

Cisco IOS XE Release 17.2.1r

Cisco IOS XE SD-WAN 16.12.x

Cisco IOS XE SD-WAN 16.11.x

Cisco IOS XE SD-WAN 16.10.x

Cisco IOS XE SD-WAN 16.9.x

Use the following procedures to upgrade your device to Cisco IOS XE Release 17.2.1r or later images.


Note

Do not delete the existing image to ensure that you have a rollback option.

Note
If an upgrade fails, do not attempt to reactivate the new software image. Instead, remove the new software image, identify and correct any configuration settings that might have caused the failure, and try the upgrade procedure again. If the issue persists, contact Cisco for assistance.

Note

When upgrading to Cisco IOS XE Release 17.4.1a from Cisco IOS XE Releases 17.3.1a or earlier, we recommend that you do not make any changes to the device configuration using CLI, while a feature template is detached. Starting Cisco IOS XE Release 17.4.1a, we use Cisco vManage assisted upgrades. In this upgrade procedure, Cisco vManage saves the device configuration before the upgrade. If the configuration on the device, that is modified using CLI is not same as on Cisco vManage, then the device has inconsistent configuration after the upgrade.

For example, if you configure the BGP AS number of a device to a different value using CLI, the device can have inconsistent configuration and the upgrade fails. If the upgrade is performed when the device is in CLI mode, then you must revert the BGP AS number to the original value and then upgrade the device. Therefore, we recommend that you upgrade the device using Cisco vManage.


Note

Beginning with Cisco IOS XE Release 17.5.1a, if you are upgrading the firmware for a device on which the primary tunnel interface is a cellular interface and the backup tunnel interface is a gigabit interface, use the gigabit interface as the primary interface for the firmware upgrade.

For information about configuring the priority of a tunnel interface, see the vmanage-connection-preference command in Cisco SD-WAN Command Reference. An interface that is configured with a higher preference value has a higher priority.

Upgrade Using Cisco vManage

We recommend using Cisco vManage to upgrade. This keeps devices and the controller synchronized.

  1. Use the Cisco vManage upgrade and activate procedure described in the Cisco SD-WAN Monitor and Maintain guide.

Upgrade Using CLI

We recommend using Cisco vManage to upgrade. This keeps devices and the controller synchronized. If it is necessary to upgrade using the CLI, use the following steps.

Back Up Configuration Files

Use these following steps to make configuration file copies before performing the manual upgrade process. Without these steps, the router will lose its configuration during the upgrade.


Note

If the deployment is on a public cloud service, such as Amazon Web Services (AWS), failure to save the configuration before upgrading manually can cause an unrecoverable loss of connectivity with the device. In contrast to a hardware device, there may be no way to gain any type of console access to the virtual router.

  1. Use the following command to make a backup copy of the Cisco IOS XE SD-WAN configuration: 

    show running-config | redirect bootflash:/sdwan/ios.cli

  2. Use the following command to make a backup copy of the Cisco SD-WAN running configuration: 

    show sdwan running-config | redirect bootflash:/sdwan/sdwan.cli

Upgrade Procedure

  1. Download the Cisco IOS XE Release 17.2 image for your device from https://software.cisco.com

  2. Upload the image to the device.

  3. Install the new software. Example:

    Device# request platform software sdwan software install bootflash:/isr4300-universalk9.17.2.1.SPA.bin

  4. Activate the software. The device reloads when the activation is complete. Example:

    Device# request platform software sdwan software activate 17.2.01r.9.3

  5. Verify that the software is activated.

    Device# show sdwan software

VERSION      ACTIVE DEFAULT PREVIOUS CONFIRMED TIMESTAMP
--------------------------------------------------------------------------------
16.12.1d.0.48 false  true   true     auto     2020-03-04T10:43:45-00:00
17.2.01r.9.3   true  false  false    user     2020-03-04T11:15:20-00:00

Total Space:388M Used Space:100M Available Space:285M
  6. (Optional) To ensure that the new version is preserved if software reset required, use the following command. Example:
    Device# request platform software sdwan software set-default 17.2.01r.9.3

  7. Verify the upgrade using request platform software sdwan software upgrade-confirm . 

    Device# request platform software sdwan software upgrade-confirm

    Note

    From 17.6.1 release, you cannot perform another install, activate or deactivate operation for an image or a Software Maintenance Update (SMU), when the upgrade-confirm function is pending for an existing operation.


Note

In controller mode, use the config-transaction command to enter global configuration mode. The configuration terminal command is not supported in Controller mode.

Table 10. Configuration Persistence in Upgrade Scenarios

Existing Installation (image)

Upgraded to (image)

Behavior

Cisco IOS XE SD-WAN Release 16.12 and earlier (ucmk9)

Cisco IOS XE Release 17.2.1r (universalk9)

Device boots up in controller mode and configuration is preserved.

Cisco IOS XE Release 16.12 and earlier (universalk9)

Cisco IOS XE Release 17.2.1r (universalk9)

Device boots up in autonomous mode and configuration is preserved (via startup configuration).

Downgrade from Cisco IOS XE Release 17.2.1r or Later Releases

Downgrade a Cisco IOS XE SD-WAN Device to a Previously Installed Software Image

To downgrade a Cisco IOS XE SD-WAN device to an earlier software image that is currently installed on the device using the CLI, perform the following steps:

  1. Display the currently installed images.

    Device# show sdwan software
 
Example:
VERSION          ACTIVE  DEFAULT  PREVIOUS  CONFIRMED  TIMESTAMP                 
----------------------------------------------------------------------------------
16.10.400.0.0    false   true     true      auto       2019-11-20T04:40:05-00:00 
17.3.1.0.102822  true    false    false     auto       2020-07-31T11:01:22-00:00

  2. Activate the image. This resets the device, deleting any existing configuration. The device starts in day zero configuration.

    Device# request platform software software activate desired-build

    Example:

    Device# request platform software software activate 16.10.400.0.0

Downgrade a Cisco IOS XE SD-WAN Device to an Older Software Image

To download an earlier software image and downgrade a Cisco IOS XE SD-WAN device to an earlier software image using the CLI, perform the following steps:

  1. Display the currently installed images.

    Device# show sdwan software
 
Example:
VERSION          ACTIVE  DEFAULT  PREVIOUS  CONFIRMED  TIMESTAMP                 
----------------------------------------------------------------------------------
16.10.400.0.0    false   true     true      auto       2019-11-20T04:40:05-00:00 
17.3.1.0.102822  true    false    false     auto       2020-07-31T11:01:22-00:00

  2. If necessary, remove an existing software image to provide space for loading a new software image.

    Device# request platform software sdwan software remove previous-installed-build

    Example:

    Device# request platform software sdwan software remove 16.10.400.0.0

  3. Download the software image for the downgrade and copy it to the device bootflash.

  4. Install the downloaded image.

    Device# request platform software sdwan software install bootflash:/desired-build

    Example:

    Device# request platform software sdwan software install bootflash:/isr1100be-universalk9.17.02.01a.SPA.bin

  5. Display the currently installed images, which now include the new image.

    Device# show sdwan software
VERSION          ACTIVE  DEFAULT  PREVIOUS  CONFIRMED  TIMESTAMP                 
----------------------------------------------------------------------------------
17.02.01a.0.211  false    true     true      auto       2020-03-30T09:34:04-00:00

  6. Activate the new image. This resets the device, deleting any existing configuration. The device starts in day zero configuration.

    Device# request platform software sdwan software activate desired-build clean

    Example:

    Device# request platform software sdwan software 17.02.01a.0.211 clean

Downgrade Scenarios for Cisco IOS XE Release 17.2.x

Table 11. Configuration Persistence in Downgrade Scenarios

Existing Installation (image)

Downgrade to (image)

Behavior

Cisco IOS XE Release 17.2.1r(universalk9) in controller mode

Cisco IOS XE SD-WAN Release 16.12 and earlier (ucmk9)

Device boots up with ucmk9 image and configuration is restored if the uckm9 image was previously installed on the device.

Downgrading to a fresh install of old image versions brings the device to Day 0 configuration. To proceed, use the clean option at activation.

Cisco IOS XE Release 17.2.1r (universalk9) in autonomous mode

Cisco IOS XE Release 17.1.1 and earlier (universalk9)

Device boots up with universalk9 image and configuration is restored.

Note

  • Downgrading directly from controller mode to Cisco IOS XE Amsterdam Release 17.1.x or earlier universalk9 or other non SD-WAN images is not supported. To downgrade from controller mode to earlier IOS XE images, switch to autonomous mode and follow the downgrade process.

  • Downgrading directly from autonomous mode to Cisco IOS XE SD-WAN 16.12 or earlier ucmk9 SD-WAN images is not supported. To downgrade from autonomous mode to earlier IOS XE SD-WAN images, switch to controller mode and follow the downgrade process.

Restore Smart Licensing and Smart License Reservation

The smart licensing authorization is lost when a device switches from autonomous to controller mode and back to autonomous mode again.

For more information about Smart Licensing, refer to Smart Licensing Guide for Access and Edge Routers.

Restore Smart Licensing

  1. Reconfigure device to reach Cisco Smart Software Manager (CSSM).

  2. Register the device using license smart register idtoken token force command in privileged EXEC mode.

  3. Set the required crypto throughput using platform hardware throughput crypto crypto-value .

  4. Save the configuration using write memory in privileged EXEC mode.

  5. Reload the device and verify that the new crypto throughput value is applied using the show platform hardware throughput crypto command.

Restore Smart License Reservation

  1. Enable the reservation mode using the license smart reservation command in global configuration mode.

  2. Set the required crypto throughput using platform hardware throughput crypto crypto-value .

  3. Save the configuration using write memory .

  4. Reload the device and verify that the new crypto throughput value is applied using the show platform hardware throughput crypto command.

Onboard Cisco Catalyst 8000V Edge Software Hosted by a Cloud Service, Using PAYG Licensing

To onboard a Cisco Catalyst 8000V platform hosted by a cloud service, using pay as you go (PAYG) licensing, perform these steps.

You can also use Cisco Cloud onRamp for Multi-Cloud to onboard a Cisco Catalyst 8000V platform using PAYG licensing. For information to integrate public cloud infrastructure into the Cisco SD-WAN fabric, see Cloud OnRamp Configuration Guide, Cisco IOS XE Release 17.x.


Note

This procedure is applicable to Cisco Catalyst 8000V hosted by Amazon Web Services (AWS).

  1. From the Cisco vManage menu, choose Configuration > Devices, and click Add PAYG WAN Edges.

  2. In the Add PAYG WAN Edges dialog box, enter the number of PAYG devices to onboard into Cisco SD-WAN, select the Validate check box, and click Add.

    The Task View page opens, showing the progress as Cisco vManage creates logical devices.


    Note

    Validating causes Cisco vManage to publish the list of devices to the Cisco vBond Orchestrator and Cisco vSmart Controller controllers in the network.

  3. After the Task View page shows the logical devices have been created successfully, choose Configuration > Devices to view the new logical devices on the Devices page.


    Note

    The Chassis Number column shows the unique identifier for each logical device.

  4. For the logical devices that you have created, click … and choose Generate Bootstrap Configuration.

  5. (Optional) Attach a device template to the logical devices that you have created.

  6. In the Generate Bootstrap Configuration dialog box, click Cloud-Init and then click OK.

    The Generate Bootstrap Configuration dialog box shows the content of the bootstrap configuration, which includes the UUID of the logical device, and includes the configuration details provided by the device template if you have attached one.


    Note

    The UUID corresponds to the identifier in the Chassis Number column in the Devices table.

  7. There are different methods for loading the bootstrap configuration onto a C8000V instance on a cloud service. The method you use depends on the cloud service. We recommend to click Download in the Generate Bootstrap Configuration dialog box to save a copy of the bootstrap configuration.

  8. In the cloud services portal, create a PAYG instance of the Cisco Catalyst 8000V. When configuring the instance, use the bootstrap configuration that you created in Cisco vManage. The details of how to load the Cisco SD-WAN bootstrap configuration onto the instance are specific to the cloud services provider.


    Note

    On AWS, the workflow for bringing up an instance includes a user data step that enables loading the bootstrap configuration.

  9. On the cloud service platform, start the Cisco Catalyst 8000V instance using the bootstrap configuration from an earlier step.

    When the Cisco Catalyst 8000V instance boots up, it joins the Cisco SD-WAN overlay automatically. In Cisco vManage, on the Devices page, this Cisco Catalyst 8000V instance shows a green medal icon in the State column and In Sync in the Device Status column.


    Note

    On the Devices page, for logical devices that have not joined the Cisco SD-WAN overlay, the State column shows a dotted-circle icon.

Bootstrap Process for Cisco SD-WAN Cloud-Hosted Devices

Before You Begin

The device template provides the configuration details that enable the device to connect to Cisco vManage.

If you create a logical device and then generate a bootstrap configuration without first attaching a device template, the resulting file will include a minimal configuration. If you attach a device template to the logical device before generating the bootstrap configuration, the resulting file will include a more complete configuration, which can be helpful in enabling the device to connect to the Cisco SD-WAN overlay. We recommend that you attach a device template to the logical device before creating the bootstrap configuration.

This procedure is useful when onboarding a software device, such as the Cisco Catalyst 8000V, to a private cloud, such as KVM, ESXi, or OpenStack.

Bootstrap Process for Cisco SD-WAN Cloud-Hosted Devices

  1. From the Cisco vManage menu, choose Configuration > Devices.

  2. For the logical device (includes the UUID) that you are using for a new cloud-hosted instance, click … and choose Generate Bootstrap Configuration.

  3. In the Generate Bootstrap Configuration dialog box, choose Cloud-Init and click OK. The Generate Bootstrap Configuration dialog box displays the bootstrap configuration, including the OTP token for the license, vBond address, UUID, and organization information.


    Note

    The UUID corresponds to the identifier in the Chassis Number column in the Devices table.


    Note

    Ensure that the bootstrap configuration does not include more interfaces than the virtual device instance has in the cloud environment.

  4. There are different methods for loading the bootstrap configuration onto a device instance on a cloud service. The method you use depends on the cloud service. We recommend that you click Download in the Generate Bootstrap Configuration dialog box to save a copy of the bootstrap configuration.

    You can use the bootstrap configuration when setting up a device instance in the cloud service. The configuration enables the device instance to connect to Cisco SD-WAN.

For information about onboarding a Cisco Catalyst 8000V in a private cloud, see the following:

For example bootstrap configuration files for the Cisco Catalyst 8000V, see Cisco Catalyst 8000V Cloud Initialization Files.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco