How well does SWIM work in RME 3.5-IDU 13?

[getwithrob]

ANY FEEDBACK IS GREATLY APPRECIATED

1) Is RME 3.5 "solid" when it comes to upgrading images on devices?

2) What kind of issues did you run into that may have or did cause an outage?

3) How many devices can be upgraded at a time.

4) Any other important factors that need to be taken into consideration.

The network I'm working on has close to 15,000 devices. Approx 5,000 of these are 3500 series switches and we've identified a serious bug that affects approximately 4,000 of these switches and they need to be upgraded.

I've only recently used SWIM to successfully upgrade 1-2900 switch and 1-3550 switch to 2-3 slightly different versions each and that worked fine, and that's it.

I'm basically looking for tips, pointers or would someone even attempt such a task.

P.S. There are 7 different models of the 3500s. There are 17 different versions of IOSes running on these 7 different model devices. What a mess!

[Joe Clarke]

There is one bug of which I am aware that could bite you (CSCea62915). If the transfer is cut off for some reason, you might be left with a bad upgrade. To avoid this, do not reboot the switches until you have confirmed the checksum of the new image is good.

For these devices, be sure to use TFTP for your transfer protocol. Do not upgrade more than 12 devices in one job, and do not run more than 12 parallel SWIM jobs. Test one device first that you have good recovery access to just to check for any local gotchas. Be sure to schedule a large enough maintenance window for recovery.

[getwithrob]

Any suggestions on the preferred order to upgrade the devices in?

For some reason, that's where I think the gotcha' for me would be...

[Joe Clarke]

That's up to you. You know the topology, so you know which devices are furthest out. Those should be upgraded first to avoid cutting off access to other switches.