New CS 17.15.2 IOS-XE beta firmware: adaptive policy, 802.1x, NM simplification etc. Woo! 😎

[cmr]

CS firmware versions IOS XE 17.15.2 changelog

Important notes

• Please note that downgrading to CS firmware is restricted after upgrading to any Cloud-native IOS XE release. Factory reset may be required, and support assistance will be necessary. Learn more http://cs.co/9002xhAan.
• Attempting to convert unsupported models such as C9200CX may result in an unusable switch. Please review the list of supported models in the release notes below before proceeding with the upgrade.

Cloud-native ios xe beta overview

• The cloud-native IOS XE release introduces a significant architectural shift from the previous container-based design to a cloud-native framework. This simpler architecture unlocks many benefits for your cloud-managed Cisco Catalyst switches, including the C9300-M, C9300L-M, C9300X-M, C9200L and MS390 families. This includes faster boot and initialization performance, especially for stacks, and the start of a new generation of capabilities as we expose more underlying IOS-XE capabilities, including a Cloud CLI Terminal that introduces the ability to perform CLI commands directly from the dashboard!
• CS16 or CS17 are prerequisites before initiating this upgrade. We do not recommend attempting to upgrade to IOS XE from other firmware versions.

Release highlights

• Management Interface Architecture Change: removed the need for a dedicated management interface
• Default Network Module: Simplification and consolidation of all discrete uplink port modules into 8 default ports that get applied dynamically to any inserted Network module.
• Standardized Cisco logging and interface naming
• Configuration Templates (note: see known issues)
• Adaptive Policy
• Intelligent Capture (note: see known issues)
• C9200L Hardware Platform Support (see supported models below)
• Storm Control
• Radius Multi-Auth (dot1X)
• Device Uptime
• 802.1X Control Direction

Before you upgrade or migrate: key considerations

• Downgrading from cloud-native IOS XE firmware is restricted: Please note that after upgrading to any Cloud-native IOS XE release, downgrading to CS firmware is restricted. Factory reset may be required, and support assistance will be necessary. Learn more at http://cs.co/9006xBRxA
• After migrating CLI/DNA managed switches to cloud-managed mode, please note that console and SSH access are no longer available. All management access is only available via the cloud dashboard or the local status page through the rear management port.
• After upgrading from CS to cloud-native IOS XE firmware, port mirroring configurations on module ports will not be retained. Users will need to reconfigure port mirroring on module ports following the upgrade.
• To onboard a CLI/DNA-managed switch to the dashboard in cloud mode, claim the switch into a network already configured for cloud-native IOS XE. Claiming into a network configured for CS firmware may have unexpected results.
• The 30-day grace period applies to Catalyst switches onboarded to Meraki Dashboard, allowing customers to trial cloud mode prior to fully committing. Valid DNA licensing can be converted to a Meraki license through a qualified promotion process. Refer http://cs.co/9005aw6VH for more details.

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 related to 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.
• Fixed an issue related to Management plane connectivity may be interrupted when there are a large number of LLDP announcements.
• Fixed an issue related to stacks of 5 or more switches may experience a configuration mismatch when making multiple consecutive port configuration changes to several interfaces in a row

Known issues

• Installing C9200L firmware on C9200CX switches can cause the device to become unresponsive and will require a RMA.
• RSTP blocking status is not showing up on the dashboard for network modules, but the status can be checked using the Show CLI/Command Runner as a temporary solution.
• C9200Ls are not supported on Configuration Templates
• Unable to use intelligent packet capture on the standby or member devices of a stack for C9300/MS390
• Meraki authentication is not supported on this version.
• Port scheduling is not supported on this version.
• Switches upgraded to IOS XE send DHCP requests with a different identifier than switches running CS firmware. This will result in DHCP reservations not being correctly applied.
• When upgrading from 17.15.1 to 17.15.2, some devices may lose IP and VLAN settings.
• LACP is not functioning on the network module ports of NM-2Y modules.

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

Transitioning from cs to ios xe 17.15: unsupported features

• The following CS features are not supported in this release:
• Sticky MAC
• Encrypted Traffic Analytics (ETA)
• Client Tracking does not work on 10G-MGig, 25G, 40G and 100G C9K ports
• Energy Efficient Ethernet (EEE)
• Meraki Authentication (Meraki Auth)
• Port Schedules
• Alternate Management Interface (AMI)
• Geo-cloud
• SNMPv3
• Certain features will be added to the IOS XE versions in future releases. Refer to the Cloud-native IOS XE documentation for further details: http://cs.co/9001Q4ALF

[thomasthomsen]

So far the only "problem", and I dont really see it as a problem, because, this is how I would like it to work 🙂 - but the dashboard text tells something different.

When you upgrade to a supported 17.15.x release, and you do your "service meraki connect" and "show meraki connect" to get all the into and the switch ready.

When you claim the serial in the dashboard, and add it to a network, the dashboard says this:

"Proceeding will overwrite all existing configuration". But I have never had this happen.

The switch never starts the actual conversion, I have to force it every time with the command:
"test platform software config mode managed".

Personally I think... this is nice, because up until then the switch actually stays in "config mode monitored", so you will actually see the switch be online in the dashboard, but in monitored mode, just the new way, instead of the old way with the onboarding app.

I really hope they keep it this way, so we can avoid using the app, and all the config it applies to the switch.

(Just like the 9800 in monitored mode).

And, of course we would like to be able ourselves to apply the "revert back command" that i guess is :
"test platform software config mode catalyst" 🙂

But as mentioned I have not seen any issues, on C9300 or C9200 with this new way of running native NexTunnel.

And I REALLY look forward to all the, ehhh, "normal" IOS-XE features coming here 🙂 - But I would settle for SmartPorts as the MS -> CS feature I feel I need the most.

[thomasthomsen]

PS: Oh yeah .. be really patient after starting the upgrade ... REALLY REALLY patient.

Go make a cup of coffee, walk the dog, watch some paint dry , or similar activity 🙂

PPS: come to think of it, the only issue I have encountered is that for some reason, my C9300 stack uses the configured vlan (10 in this case) for management on IPv4, but insists on using IPv6 in vlan50 (all vlans have IPv6 available .. I have no idea why, and I cant change it 🙂 )