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.
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 😉
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
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.
I thought the Meraki commands were being added to IOS-XE, are you sure that is not the case?
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.
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!