Cloud Operating Mode for Catalyst Cloud-Managed Switches Overview

Downgrading from Cloud-Native IOS XE is restricted

Due to complexities in restoring the container-based architecture, downgrades from cloud-native IOS XE to any prior CS firmware via the dashboard is restricted. A factory reset may be required and support assistance will be necessary. Please consider this before upgrading your production network to the cloud-native IOS XE version. 

Onboarding your CLI/DNA-managed Catalyst

After migrating to cloud management, please note that remote access (serial console and SSH) are no longer available. All management access can now be accessed through the cloud dashboard or the local status page via the rear management port.

Migrating a Layer 3 (L3) Switch 

Prior to cloud-native IOS XE, L3 switches required at least two IP addresses, one for the management IP and a second for the L3 Switch Virtual Interface (SVI). You cannot route traffic through the management-IP, it essentially worked as an out-of-band management interface. In cloud-native IOS XE, the Meraki management interface is now combined with a Layer 3 uplink SVI, using one single IP address, rather than two.

To use Layer3 SVI's with cloud-native IOS XE, the following requirements/conditions apply:

• Static IP on management/uplink SVI. It's highly recommended to configure your management interface to use a static IP address prior to upgrading. If your L3 SVIs default-route and management interface gateways are NOT the same, then all switch traffic will use the management interfaces DHCP acquired gateway as a next hop.

• If you upgrade from Container-based (CS) firmware to Cloud-Native IOS-XE be aware of the following:

  • If you have the management interface on the same VLAN as a configured L3 SVI, the SVI IP address will override the management interface address, and the management interface IP address will be erased. This is done to attempt to preserve L3 routability in the network, but may result in the loss of management traffic such as SNMP or RADIUS when the management IP address changes. For example:

    • Management interface has a static IP of 10.10.10.130 on vlan 10

    • There is also an SVI on VLAN 10 configured for 10.10.10.254 with a default route of 10.10.10.1

    • After the upgrade, the switch will use 10.10.10.254

  • If you have the management interface on a unique VLAN with no overlapping SVI, then the management interface will become a new uplink SVI.

• L3 SVI's configured as a client DHCPv4 server cannot also be configured as a preferred uplink. Configuring an interface as an uplink that is already configured as a DHCP server will have the DHCP server configuration removed.

• Alternate Management Interface (AMI) configuration now requires a dedicated L3 SVI interface to be created on the switch. It is no longer configured from the switches side-bar. If you have configured the network to support AMI on a VLAN (ex. VLAN10), then every switch in that network must have a L3 SVI on the specified VLAN in order to use that interface as an AMI. If there is no L3 SVI interface on a switch that matches the AMI VLAN, then the management/uplink interface will be used as default. 

Configure your network to cloud-native IOS XE firmware before adding your Catalyst switch operating in cloud mode to the network.

To onboard a DNA/CLI-managed switch to the dashboard in cloud mode, ensure you add the switch into a network already configured for cloud-native IOS XE firmware. Adding a switch into a network configured for CS firmware may have unexpected results.

Licensing

The same 30-day grace period is available for Catalyst switches onboarded to the Cloud Dashboard, enabling customers to trial cloud mode before making a full commitment. A valid DNA license can be converted to a Meraki cloud license through a qualified promotion process. Refer to the quick start guide page 4 for more details. http://cs.co/9005aw6VH

Management Interface Architecture

The management interface is now a Layer 3 (L3) interface. Previously, switches running CS firmware needed a specific management IP address. Now, management is handled by any L3 interface. All settings related to management connectivity and L3 interfaces can now be found on the Routing & DHCP page. For switches that only support Layer 2 (L2), DHCP functionality is available, but enabling L3 functionality requires setting a static management IP address first.

Watch this video to learn more about this change.

L3 Migration – with unique VLANs

When the Management IP VLAN is different from the L3 interface VLANs, both VLANs are migrated. This results in two default routes:

• Management traffic uses one route, determined by the UAC (use the command sh uac uplink)
• User traffic is load balanced

You will need to decide which route to retain.

Default Port Modules

Upgrading to the cloud-native IOS XE 17.15 firmware simplifies the network module configuration. When a module is not installed, the configuration is consolidated into eight default ports. Once a network module is installed, these ports are automatically mapped to the appropriate interfaces. Previously, each potential network module required its own unique configuration. For instance, configuring a 48-port switch required configuring 98 ports to accommodate every possible module. Now, there are only 56 ports (48+8) needed to support both current and future modules.

Watch this video to learn more about this change.

Safe-Config and Rollback

When upgrading to the cloud-native IOS XE firmware, if your switch fails to come online after transitioning from CS firmware, it will automatically revert to the CS/Container firmware after a period of 2 hours.

It is important not to reboot or factory reset the switch during this 2-hour window, as this may corrupt the rollback configuration and hinder the switch's recovery and will ultimately corrupt the rollback configuration. If, after 2 hours, the switch has not recovered or connected to the dashboard, please contact support. Once the switch has successfully recovered, it will not attempt the upgrade again for another 2 hours.

Additionally, if the switch successfully upgrades to the cloud-native firmware, ensure it remains online and connected for 30 minutes following the upgrade. This duration allows the configuration to be marked as safe and committed.

Layer 3 SVI Behavior

Prior to cloud-native IOS XE, Layer3 Meraki switches required at least two IP addresses, one for the management IP and a second for the Layer3 Switch Virtual Interface (SVI). You cannot route traffic through the management-IP, it essentially worked as an out-of-band management interface. In cloud-native IOS XE, the Meraki management interface is now combined with a Layer 3 uplink SVI, using one single IP address, rather than two.

To use Layer3 SVI's with cloud-native IOS XE, the following requirements/conditions apply:

• The management/uplink SVI must be configured for a static IP address. It's highly recommended to configure your management interface to use a static IP address prior to upgrading.
• If you upgrade from Container-based (CS) firmware to Cloud-Native IOS-XE be aware of the following:
  • If you have the management interface on the same VLAN as a configured L3 SVI, the SVI IP address will override the management interface address, and the management interface IP address will be erased. This is done to attempt to preserve L3 routability in the network, but may result in the loss of management traffic such as SNMP or RADIUS when the management IP address changes. For example:
    • Management interface has a static IP of 10.10.10.100 on vlan 10
    • There is also an SVI on VLAN 10 configured for 10.10.10.200.
    • After the upgrade, the switch will use 10.10.10.200.
  • If you have the management interface on a unique VLAN with no overlapping SVI, then the management interface will become a new uplink SVI.
  • If your management IP is configured for DHCP, you be required to assign a static IP address to the uplink SVI before other L3 SVIs can be created. Static addressing is considered a Cisco best practice for Layer 3 switch deployments.

Spanning Tree Changes

Spanning-Tree Protocol (STP) behaves differently in cloud-native IOS XE 17.15.1 onwards.

• CS17 and cloud-native IOS XE 17.15.1+ exhibit different behaviors in their handling of Spanning Tree Protocol (STP).
• Cloud-native IOS XE runs Multiple Spanning Tree Protocol (MSTP) with PVST simulation enabled and changes the MSTP region identifier to the switch's MAC ID. 

• For spanning-tree root bridges, MSTP is preferred and remains compatible with Rapid-PVST+ as long as VLAN 1 is allowed on the trunk. If VLAN 1 is not configured on the uplink, the downstream Cloud-Native IOS XE/MSTP switch will become the root for all VLANs.

LED Behavior

The system LED on the switch indicates the system status, including the progress of booting and connecting to the Meraki dashboard without logging in into the system or Dashboard. The MS390 switch has a rainbow system LED to indicate the system state. This rainbow LED is not available on Catalyst 9000 hardware. Blue Beacon LED button and the System LED are instead used on Catalyst 9000 hardware to indicate the system status.

• Cloud Native IOS XE firmware continues to use the rainbow LED in the MS390 and Blue Beacon and system LEDs in Catalyst 9000 to provide system status.

  • For the LED behaviour of cloud-managed Catalyst 9000 switches please refer to the table in our Catalyst 9300/X/L-M Series Installation Guide. It stays the same in the cloud-native IOS XE firmware.

  • For the LED behaviour of MS390 please refer to our documentation on MS390 Series Installation Guide. However, cloud-native IOS XE with MS390 adds two additional stages (taken from Catalyst 9000), described below: