Hi Guys,
I have been told that it is not possible to delay or have control on firmware updates to Meraki switches. Is this Ture?
We need to be able to control the push of firmware updates to switches in order that we do not affect production.
We also need to be able to roll back in the event of an issue.
The Meraki products are attractive to us for us to be able to control LAN environments far away in the world.
Cheers
you have a lot more control now then back in the days.
https://documentation.meraki.com/zGeneral_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ
what does the keyword option ‘ignore‘ mean in detail?
does this mean that all updates are ignored or only a specific one?!
Not True:
You can cancel all updates and schedule them as you see fit.
Hi @YBerllan. I have Meraki switches deployed in 24x7 factory environments. Before I put it into such an environment I tell the customer they must agreement to giving me one outage window every year - which they usually can do (most have some kind of maintenance shutdown).
To make this workable you must stick to "stable" code. Even if you strike a bug. This is because the "stable" train for switches is usually only updated once a year or so (this is not a policy, just an observation). Also Meraki does not make people move from one stable release to another very aggressively - so you usually have quite a time window.
So the "stable" train has a relatively long life in Meraki terms.
Next comes the "Stable release candidate" train. You will be forced to upgrade to newer "stable release trains" as they become available. From my experience, you might be forced to deployed a newer version within 3 months. Maybe 6 months if you are lucky.
I often use this train for "office" environments, where the office can have an outage every night.
Lastly their is the "beta" release train. These have the shortest release cycle. Meraki will force you to upgrade and get off older beta code frequently (maybe within 2 months). Obviously Meraki do not want to keep having to support older beta code.
I only tend to use this code when I have a critical bug that is fixed in the beta code, or their is a new feature that the customer really really wants.
So basically you need to select a "train" based on how tolerant you are to having down time.