Wish: Actual scheduling of Firmware Upgrades

Bovie2K
Getting noticed

Wish: Actual scheduling of Firmware Upgrades

Dear Meraki,

 

I wish for actual scheduling of Firmware Upgrades. If I say to do an upgrade at 9pm the device should load the firmware beforehand and reboot exactly at 9pm not 9:01 or 9:02 or frequently for me even with a gigabit internet connection 9:30 or 9:45. On some networks it doesn't matter just set it for the middle of the night and good but on other networks exactly scheduling is extremely important. For example on a server lan 2-3 minutes of downtime instead of a 45 to 60 minute window where switches reboot at will all at different times is much preferred.

10 Replies 10
PhilipDAth
Kind of a big deal
Kind of a big deal

I think I would prefer that Meraki kept it simple, and that the upgrade didn't start till the scheduled time, and it takes as long as it takes.

Bovie2K
Getting noticed

I would agree if that was the case but Meraki randomly adds time to the update on the switches instead of just downloading and rebooting they wait a random amount of time before doing so after being commanded to update. A rep told me this was in place to prevent a switch from being cut off in the middle of a download when an upstream switch reboots. I don't see why other software methods could be in place to prevent this.

Also Its not so much the downtime is the problem I can plan for that and or have redundancy where its justified its the fact you don't know where devices are in the process i.e. The dashboard says up to date before the devices and I've personally had switches reboot as many as 45 minutes after they claim to be up to date. If they keep it as is at least give me accurate data of where things are in the process. Like Downloading, Installing, Pending Reboot, Rebooting, then finally Up to Date.

PhilipDAth
Kind of a big deal
Kind of a big deal

Does that happen even when you schedule a single switch to upgrade?

 

Perhaps Cisco Meraki could consider the topology (considering the system already has a topology map) to consider the order to download and reboot the switches when multiple switches are being scheduled.

lpopejoy
A model citizen

Couldn’t agree more. This nearly bit me once when I waited for 45 min and switched said up to date. I assumed I must have missed the reboot, and was about to cancel the maintenance window.

If you aren’t going to install the firmware as scheduled, then AT LEAST let us know it hasn’t happened yet. The dashboard shouldn’t lie to me.
Zilla
Getting noticed

I used the staged upgrades feature today.  The switches rebooted about 7 minutes after the stated upgrade time.

 

I still don't like the dashboard showing that the upgrade has completed even though the switches are still downloading the code.

Bovie2K
Getting noticed

I don't believe there is a delay on a single switch.

Zilla
Getting noticed

If you web into the management address of each switch you can see the download progress.  Unfortunately, it pause for a period of time between reaching 100% and rebooting.  In our networks it seems like all switches reach 100% and then hold for a while before rebooting all at the same time.

PhilipDAth
Kind of a big deal
Kind of a big deal

ps. If the downtime is a real issue then design for redundancy - so that everything will keep working even if a switched is turned off.

JohnL
New here

The updates are designed so that every single item is rebooted at the same time, to avoid spanning tree issues.  If you have a very small amount of switches it should take very little time, however, if you have many it could potentially take a lot longer.

Network guy
PhilipDAth
Kind of a big deal
Kind of a big deal

The Cisco Meraki switches using rapid spanning tree.  The convergence time, even for a large network, should be no more than a couple of seconds.

Get notified when there are additional replies to this discussion.