Meraki Community

Mloraditch

Please read carefully and refer to the referenced documentation article. This reads like a true beta that you may only want on lab switches given all the caveats.

Overview

With the release of IOS XE 17.15.1 to the Meraki Dashboard, we are beginning an exciting transition from a container-based architecture to one that is based on native IOS XE, with support for Meraki cloud management. With this first beta release, your switch(es) will upgrade and transition from CS firmware to cloud-native IOS XE 17.15.1, managed by Meraki Cloud.
This simpler architecture unlocks many benefits for your cloud-managed Cisco Catalyst switches, including the 9300-M, 9300X-M, and MS390 families. This includes faster boot and initialization performance, especially for stacks, and the start of a new generation of capabilities we will deliver with faster speed. It also introduces the ability to perform CLI show commands directly from Dashboard!
Please note, CS16 or CS17 is a prerequisite before initiating this upgrade.
For details on behavior changes related to L3 Switch Virtual Interface (SVI), LED Behavior, and STP behaviors, please refer to the cloud-native IOS XE Overview (https://documentation.meraki.com/MS/Cloud-Native_IOS_XE/Cloud-Native_IOS_XE_Overview).

New feature highlights

Introducing cloud-native IOS XE.
Improved boot time for your Cisco Catalyst cloud-managed switches, especially for stacks.
CLI access through the dashboard to run show commands for troubleshooting.
Support for Intelligent Capture.
Support for C9200L hardware platform. (See Supported Models below)
Enhanced logging capabilities with native Catalyst logging support.
Share Your Post-upgrade Feedback!
We value your feedback on our latest release! Please take a moment to complete this brief 5-minute survey (https://forms.office.com/r/gHuK4bJRZ5) and share your experience with us.

Fixed issues

Fixed an issue that caused incorrect PoE usage data to be shown in the dashboard on MS390.
Fixed an issue that prevented the application of fixed IP assignments if the IP being assigned had an active DHCP lease on MS390.
Fixed a problem that allowed MS425 devices to perform client sampling on ports directly connected to downstream MS390 switches.
Fixed an issue causing switches to restart after stack failovers.

Known issues

L3 Features: Management interface replaced by L3 SVI in IOS XE. If the switch management address belongs to the same subnet as an L3 SVI present in the configuration before upgrading from a CS to IOS XE release, the upgrade may fail and revert to the CS release, especially if the management address is statically assigned.
RADIUS authentication may not work when the RADIUS server is in the same subnet as the switch management interface.
Encrypted Traffic Analytics (ETA) is not currently supported. Please disable ETA/Netflow on a network before upgrading to Cloud-Native IOS-XE. If ETA is enabled, it will prevent configuration changes to the network until it is disabled again.
C9300L is not currently supported. We recommend moving C9300L devices to a separate network that will not be upgraded before attempting to upgrade to this release. If you upgrade C9300L devices, please note that the uplink ports will not function. As a workaround, use the copper ports instead.
Downstream clients may experience packet loss for 60-200 seconds in stacks while the standby switch takes over the active stack member role when the active stack member is powered off.
Management plane connectivity may be interrupted when there are a large number of LLDP announcements.
Meraki native MS switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to a Catalyst-based switch unless the bundles are configured on the Catalyst side first. All Meraki native MS switch ports are configured in passive LACP mode so that loops do not occur between Meraki native switches (always present)
Stacks of 5 or more switches may experience a configuration mismatch when making multiple consecutive port configuration changes to several interfaces in a row

Temporary feature gaps: cs/ms17 vs ios xe 17.15.1

We are actively working to bridge the feature gap between CS/MS17 and IOS XE versions. Please note that the following features are not yet available in cloud-native IOS XE but will be addressed in subsequent releases.
SmartPorts
MAC Blocklist / Allowlist
Digital Optical Monitoring
RSPAN / VLAN SPAN
IPv6 RA Guard / DHCP Guard
WarmSpare / VRRP
FIPS / Gov Cloud
HTTP Proxy for NextTunnel
Storm control
SNMP v3
Sticky MAC
Encrypted Traffic Analytics (ETA)
Dynamic ARP Inspection (DAI) Auto-Uplink

Supported models

C9200L-24T-4X , C9200L-24P-4X, C9200L-48T-4X , C9200L-48P-4X , C9200L-48PL-4X , C9200L-24PXG-4X , C9200L-48PXG-4X , C9200L-24PXG-2Y , C9200L-48PXG-2Y , C9200L-24T-4G , C9200L-24P-4G , C9200L-48T-4G , C9200L-48P-4G , C9200L-48 PL-4G
C9300-24T-M, C9300-24P-M, C9300-24U-M , C9300-24UX-M , C9300-48T-M , C9300-48P-M , C9300-48U-M , C9300-48UXM-M , C9300-48UN-M , C9300-24S-M, C9300-48S-M , C9300X-12Y-M, C9300X-24Y-M, C9300X-48HXN-M, C9300X-24HX-M, C9300X-48HX-M, C9300X-48TX-M,  and its corresponding Catalyst switch SKUs for migration
MS390-24-HW, MS390-24P-HW, MS390-24U-HW, MS390-24UX-HW, MS390-48-HW, MS390-48P-HW, MS390-48U-HW, MS390-48UX-HW, MS390-48UX2-HW

cmr

This is the release I was waiting for! Apparently the DHCP option issues with the container C9x00 switches is fixed in this release. Unfortunately I don't have them any more as we replaced them with MS355s. Hopefully someone is brave enough to try it out 😉

cmr

Hopefully an upgrade from earlier IOS-XE (non Meraki managed) will come, that would be a great benefit 😎

Note that this is not what I mean, there should be no need to lose all the config... Migration from CLI-managed Catalyst Switches to Meraki-managed Mode - Cisco Meraki Documentation

Mloraditch

Whatever the issue with 9300Ls was, has been fixed as RN have been updated to remove that caveat. Another note has been added about 9200CXs not being supported and "Meraki Auth is unsupported" as well.

Will be curious how they fix things going forward as the new architecture is the dashboard sending regular IOS commands via the tunnel. There is no longer an abstraction layer on top of things so there should be less to fix in the actual device firmware and more backend work to just make sure commands and output are sent back and forth in the correct format.

cmr

I thought the Meraki commands were being added to IOS-XE, are you sure that is not the case?

Mloraditch

Here is a good explainer: https://techfieldday.com/video/next-generation-cloud-management-for-cisco-catalyst/

The way I understand it is they use the built in YANG/NETCONF support to do all config and the main thing added to the IOS-XE code is the management tunnel vs the previous container that had to run on top and interpret meraki config. Now most of the coding is in the meraki backend as far as doing new features.

Some of the reporting appears to be somewhat customized and I'm not sure I quite understand how that works but it's still simpler.

cmr

Thanks @Mloraditch that is a very interesting video. Looks like they added a load of processes to IOS-XE and then moved the translation of commands from the container to the cloud as you said. Much better. Boot times for a stack from ~10 mins to 4 mins and config changes taking half the time are all welcome improvements!