Firmware Updates

[YBerllan]

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

[ww]

you have a lot more control now then back in the days.  

https://documentation.meraki.com/zGeneral_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ

[whistleblower]

what does the keyword option ‘ignore‘ mean in detail?

• Ignore: This option will appear as selected if there is a newer firmware version available but nothing is currently scheduled. If an upgrade was scheduled but was subsequently cancelled (either from the Organization > Firmware Upgrades page or by Support), the Ignore option will be selected.

does this mean that all updates are ignored or only a specific one?!

[cmr]

@whistleblower the specific update is being referred to

[DeanDunlop]

Not True:

You can cancel all updates and schedule them as you see fit.  

1. Navigate to Organization > Monitor > Firmware upgrades. 
2. From the Overview tab, view the Scheduled changes section, and find the applicable scheduled upgrade. 
3. Scheduled upgrades will be grouped by their respective products and scheduled upgrade time. 
4. For any given scheduled product upgrade, Click either the Reschedule or Cancel button. If selecting Reschedule, choose either Perform the upgrade now or Schedule upgrade for, specifying a date and time for the upgrade to take place. 
5. By selecting Cancel for a given scheduled upgrade, the upgrade will be canceled for all networks listed for that upgrade. 

[PhilipDAth]

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.

[YBerllan]

Hi
Many thanks for taking the time to share this with me. Very useful. The environment we have is the same 24/7 manufacture. These switches look to be very helpful and I feel they are the right option for supporting remotely around the world.

Kind regards

John