CS Firmware Version IOS XE 17.15.1.9 - First IOS-XE Native Release, Caveats Galore, Read Carefully

[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!

[cmr]

Updated release notes, key points are:

Known issues

• NOTE: ATTEMPTING TO CONVERT UNSUPPORTED MODELS SUCH AS C9200CX MAY RESULT IN A UNUSABLE SWITCH. PLEASE REVIEW THE LIST OF SUPPORTED MODELS BEFORE PROCEEDING WITH THE UPGRADE.
• Installing C9200L firmware on C9200CX switches can cause the device to become unresponsive and will require a RMA.

• Adaptive Policy and SGT configurations are not currently supported

Supported models

• NOTE: ATTEMPTING TO CONVERT UNSUPPORTED MODELS SUCH AS C9200CX MAY RESULT IN A UNUSABLE SWITCH. PLEASE REVIEW THE LIST OF SUPPORTED MODELS BEFORE PROCEEDING WITH THE UPGRADE.
• 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, C9300L-24P-4X-M, C9300L-24T-4X-M, C9300L-24UXG-4X-M, C9300L-48P-4X-M, C9300L-48PF-4X-M, C9300L-48T-4X-M, C9300L-48UXG-4X-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

[AugustoSNunes]

Is there any ETA for the support of 9200 non L?

[cmr]

I know there is another version due before the end of the year, but it could be sooner.  Anything I see will be posted in the community. 

[ScottMcD]

Do you know if the 9500s will be moving to the 17.15.1 code base at some point as well?

Currently have them in monitor mode but they have a bug in 17.12.3 where they constantly go offline from the Dashboard and the only way to return them is to run a telnet command to the us.tlsgw.meraki.com to restart the tunnel.

[JeroenVercoulen]

Do you know more about the new version that is coming?

[cmr]

Apologies, I was just told that there would be one, hopefully shortly!

[JeroenVercoulen]

Do you know when the new version is coming?
Also when does this version for example goes to Release Candidate?

[cmr]

@JeroenVercoulen beta 2 is coming soon, I don't have an exact date, but am hoping in the next 1-2 weeks as it is nearly ready. 🤞

[ScottMcD]

Hi @cmr @is there any word on the 9500s getting in the beta list? There current code base has major disconnect bug from the Meraki dashboard.

[cmr]

@ScottMcD by current code, do you mean the stable version?  I'll see if I can find out.

[ScottMcD]

The only code support for 9500 series is 17.12.3.  Even then it keeps dropping the connection to the dashboard, which I have an open ticket with support. was hoping this is getting  resolved in the next beta . Or an update on when the 9500 will be able to upgrade their IOS to a higher level supported by Meraki Dashboard would be nice. 

[JeroenVercoulen]

There is now an Early trial active for connecting with 17.15.2 as a firmware in the new way. Maybe worth looking at.

https://community.meraki.com/t5/Switching/EARLY-TRIAL-NOW-Cloud-Monitoring-for-Catalyst-Switch-with-...

[Mloraditch]

I can't answer that question but for the next year plus a few months, if you need 9200s to be Meraki Managed I'd be getting the Ls...

[JeroenVercoulen]

When reverting back from the Beta to the Stable it failes to update. Anybody else experiencing this?

[cmr]

I think that is what @PhilipDAth had.

[JeroenVercoulen]

It's not booting in rommon mode or so. I get the following message.

Switch 1 R0/0: install_mgr: Failed to install download package , Error: Invalid installation package. Name cs-17-1-202410212002-Geb13a3247771-rel-grief does not match with cs-17-1-202410212002-Geb13a3247771-rel-grief.

[JeroenVercoulen]

Had a case with support.

They can downgrade it for you to 17.1.3 then it works the downgrade and then you can upgrade to 17.1.4

[Prestont]

Hello,

i have a couple of C9300X that also struggle to downgrade. but if i leave them on for a day or two they do downgrade. just take a very long time. i also am working with support on the issue,

[Wayne-T]

Does anyone know where to find the newly added CLI access via the Dashboard?? I have looked thru the old and new dashboard versions and are unable to locate it!?

TY in advance

[GIdenJoe]

I had my first issues with this, which is a bit of an install problem.

So imagine this:
You want to use a switch management VLAN which is different than VLAN 1.

However your switch first came online with all ports in trunk native VLAN 1 and it received an IP in that this switch thinks is VLAN 1, however the trunk leading to the upstream devices has the switch management VLAN as native (think the MX downlink).

So to fix this you want to change the uplink ports so it takes VLAN 2001 in my case as native VLAN and then apply a fixed IP address inside that range.

Now here comes the problem:

The switch will deny the config since it now has to apply the IP from VLAN 2001 which is in the same subnet like the switch now has DHCP in VLAN 1.  This will cause the netconf call to fail and leave an error xml file on the flash of the switch.

RPC Error occured during SET: /flash/meraki/config_updater/monitor/dwnld_running.config
Info: <?xml version="1.0" encoding="UTF-8"?><error-info xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"><severity xmlns="http://cisco.com/yang/cisco-ia">error_cli</severity>
<detail xmlns="http://cisco.com/yang/cisco-ia">
<bad-cli>
<bad-command> ip address 10.10.1.11 255.255.255.0</bad-command>
<error-location>36</error-location>
<parser-response>&#13;
% 10.10.1.0 overlaps with Vlan1</parser-response>
<parser-context> description Uplink_VLAN
mac-address 0018.0a4f.0001
no shutdown
ip access-group l3-v4-acl in
ip address 10.10.1.11 255.255.255.0</parser-context>
</bad-cli>
</detail>

So the switch gets stuck in the VLAN 1 config and does not allow any other configs for some reason.

I was able to console into the switch and manually remove VLAN 1 IP address and apply fixed to VLAN 2001.  The switch then came back online with the correct VLAN and now I can no longer access the CLI via console cable.  There are still some other issues like no longer being able to console from dashboard (internal error).  So it would seem we are having a bit of an issue with the configs.

[DevOps_RC]

For info, I've been notified of a bug with long allowed Vlan statements which IOS breaks into multiple lines. So if you have an allowed vlan over ~39 characters (including ,-) it will fail configuration validation. I hope this is fixed soon, so I can get IOS-XE onto the last few of our MS390s..I feel  IOS-XE beta is a more stable/robust firmware than the MS/CW fudges to get the MS390s (C9300 HW) into the dashboard. 

[jamess03]

Can someone advise me on the Spanning Tree changes with this? I'm looking to purchase some C9300L-M switches and use this new feature.

Previous Meraki guidance for MST configuration was for a root Cisco switch to match this config:

spanning-tree mode mst
spanning-tree mst configuration
name region1
revision 1
spanning-tree mst 0 priority 4096

This makes sense because I can assign the same name across all switches. This ensures that all the switches are in the same MST region.

But with this new Cloud-Native IOS-XE feature, the MST recommendation changed. According to the overview document, the Spanning Tree configuration name changes to the MAC address of the switch. And so if each Meraki switch has a unique MST name, this would essentially put all of your Meraki switches outside of the MST region of your root switch, no matter what.  I'm pretty sure the MST revision number, VLAN assignments and configuration name must match to ensure each switch is in the same MST region.

spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name 00180a4f0001
revision 1

Cisco covers this here: Understand the Multiple Spanning Tree Protocol (802.1s) - Cisco

Note: If for any reason two switches differ on one or more configuration attribute, the switches are part of different regions. For more information refer to the next section, Region Boundary.

So what MST configuration should my traditional IOS-XE root switch (C9500) use to ensure Meraki edge switches are in the same region as my root?

[jamess03]

I think I answered my own question by labbing this out with some Catalyst switches. There are also some Meraki community conversations around this: Re: Mekari / Cisco - MSTP and RSTP Configuration Questions - The Meraki Community

What Meraki is essentially doing with the configuration is emulating RSTP. I don't think you can actually establish the same MST region between every Meraki switch. Instead, you communicate with an RSTP boundary and the behavior is the same.

When I configured the exact same Meraki MST configuration used with this new feature - and then connected it to an MST0 instance with a different name and revision number - the "Meraki" switch observed the root switch properly and this was the output:

Catalyst-Switch#show spanning-tree mst interface gigabitEthernet 0/1

GigabitEthernet0/1 of MST0 is root forwarding
Edge port: no (default) port guard : none (default)
Link type: point-to-point (auto) bpdu filter: disable (default)
Boundary : boundary (RSTP) bpdu guard : disable (default)
Bpdus sent 5, received 225

Instance Role Sts Cost Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0 Root FWD 20000 128.1 1-4094

Catalyst-Switch#show spanning-tree

MST0
Spanning tree enabled protocol mstp
Root ID Priority 32768
Address 6899.cdc2.a680
Cost 20000
Port 1 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32768 (priority 32768 sys-id-ext 0)
Address ac7e.8abd.4c80
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/1 Root FWD 20000 128.1 P2p Bound(RSTP)