ISSU for MR

rhbirkelund
Kind of a big deal
Kind of a big deal

ISSU for MR

Apparently the release notes for MR 26.8 has been updated.

 

rbnielsen_0-1589185534946.png

 

 Is it just me, or has this not got any attention?

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
5 Replies 5
PhilipDAth
Kind of a big deal
Kind of a big deal

I didn't know about that feature.  Good tip.

rhbirkelund
Kind of a big deal
Kind of a big deal

Me neither, just noticed it. 🙂

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
rhbirkelund
Kind of a big deal
Kind of a big deal

If only there were a treaure hunt, finding features that are sneaked in by Meraki. 😉

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
cmr
Kind of a big deal
Kind of a big deal

Yes it wasn't in the original 26.8, it was added later on...

If my answer solves your problem please click Accept as Solution so others can benefit from it.
MerakiDave
Meraki Employee
Meraki Employee

Not a bad idea @rhbirkelund maybe offer Meraki swag for when you find features that haven't been announced yet, but might have been leaked in the release notes apparently.  😁  @PhilipDAth @cmr this was a wish for a long time. In a similar fashion that Meraki allows staged upgrades in Meraki switch networks, there can be seamless AP firmware upgrades. 

 

Dashboard will determine how to best break up the APs into two groups and run an algorithm that examines connected clients, AP load, neighbor tables, and dynamically select two AP groups to upgrade firmware one group at a time, such that it minimizes the downtime for all clients overall.  Very handy for critical wireless networks where they're in constant operation and it's difficult or impossible to get a change window.

 

So with standard roaming behavior you can create a very seamless firmware upgrade without badly disrupting client connectivity from a mass-reboot of APs. So in theory, with good RF coverage and roaming behavior, you now have a hitless ISSU mechanism for MR wireless.  And it's Meraki simple. 😀

 

And I know what you might be thinking, what about having more control over the process, via AP tagging to create your own groups for example, and I've raised that suggestion already.  We'll see I suppose.

 

https://documentation.meraki.com/MR/Other_Topics/Access_Point_Firmware_Upgrade_Strategy

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels