Fibre Channel (SAN)

Reply
Occasional Contributor
Posts: 11
Registered: ‎10-14-2010

Massive upgrade of backend switches skipping versions in between

Hello everyone,

I know that the supported solution is to do upgrades of Brocade switches with one version hops.

However a customer is facing requirements to upgrade ~1500 Silkworm 5100 switches which are used for backend to connect to disk shelves.

2 switches per fabric with 2 fabrics per storage controller. Not administrated by DCFM or anything like that.

Most of the switches runs 6.1.1a. They need to upgrade them to 6.3.2b2 and then to 7.0.0b2.


If there is any way to do it in supported way skipping 6.2 and 6.4 it would help to save a lot of time.

Can they run upgrade 6.1.1a. => 6.3.2b2 => 7.0.0b2 in a supported way (could be under some conditions)?

Any other ideas how to make the upgrades faster/automated ?

The configuration is really simple and will be saved before upgrades.

Valued Contributor
Posts: 931
Registered: ‎12-30-2009

Re: Massive upgrade of backend switches skipping versions in between

I don't know if there are supported ways to skip FW levels while upgrading.

The documented /supported way is one step upgrades.

Perhaps some else on the forum can help you with this part.

As to automation without BNA,

You'll have to script it.

With ssh access you'll have something along the lines of

sshpass into the box passing commands to check current FW

sshpass into the box passing the firmwaredownload command with parameters

sshpass into the box passing command to check the update/FW level in both partitions

repeat for each FW level foreach switch

You could make your script as elaborate as you want.

Occasional Contributor
Posts: 11
Registered: ‎10-14-2010

Re: Massive upgrade of backend switches skipping versions in between

Are all commands possible in non-interactive mode?

I was thinking that even if you provide all parameters in command line it will ask you if you really want to do reboot.

In this case I was about to use expect.

Side question: on some switches it's possible to execute remote commands without any issue, on others it's doable via ssh 'echo "command" | bash'. For same FOS and switch time. I never figured out what setting changes this behavior. Anyone knows ?

Valued Contributor
Posts: 931
Registered: ‎12-30-2009

Re: Massive upgrade of backend switches skipping versions in between

Are all commands possible in non-interactive mode?

I was thinking that even if you provide all parameters in command line it will ask you if you really want to do reboot.

In this case I was about to use expect.

Yep expect is indeed another option, you could also try screengrabbing

I don't know by head if all command are possible in non-interactive mode,

You have to try this or visit the help for the command.

Side question: on some switches it's possible to execute remote commands without any issue, on others it's doable via ssh 'echo "command" | bash'. For same FOS and switch time. I never figured out what setting changes this behavior. Anyone knows ?

Never come across this issue and I don't think it's worth changing on X% of your environment manually or scripted.

Why invest time in figuring out which parameters you need to change, script that first only to run your upgrade script?

If ssh echo command|bash works for you on each en every occasion you're already have automated the upgrade of your switches. Unless I'm missing a point you're trying to make I wouldn't bother with the setting.

Occasional Contributor
Posts: 11
Registered: ‎10-14-2010

Re: Massive upgrade of backend switches skipping versions in between

dion.v.d.c wrote:

Side question: on some switches it's possible to execute remote commands without any issue, on others it's doable via ssh 'echo "command" | bash'. For same FOS and switch time. I never figured out what setting changes this behavior. Anyone knows ?

Never come across this issue and I don't think it's worth changing on X% of your environment manually or scripted.

Why invest time in figuring out which parameters you need to change, script that first only to run your upgrade script?

If ssh echo command|bash works for you on each en every occasion you're already have automated the upgrade of your switches. Unless I'm missing a point you're trying to make I wouldn't bother with the setting.

The problem is I'm not able to say on which switch it will work which way.

Still open question is if there is a way to do upgrades with omitting some version on the way.

External Moderator
Posts: 4,907
Registered: ‎02-23-2004

Re: Massive upgrade of backend switches skipping versions in between

--->>> If there is any way to do it in supported way skipping 6.2 and 6.4 it would help to save a lot of time.

Can they run upgrade 6.1.1a. => 6.3.2b2 => 7.0.0b2 in a supported way (could be under some conditions)?


This Upgrade procedure is not supported, that for First.

Second, Upgrade with automated script ending in most case with crash.

TechHelp24
Occasional Contributor
Posts: 11
Registered: ‎10-14-2010

Re: Massive upgrade of backend switches skipping versions in between

TechHelp24 wrote:

Marcin Lubojanski

--->>> If there is any way to do it in supported way skipping 6.2 and 6.4 it would help to save a lot of time.

Can they run upgrade 6.1.1a. => 6.3.2b2 => 7.0.0b2 in a supported way (could be under some conditions)?

This Upgrade procedure is not supported, that for First.

Second, Upgrade with automated script ending in most case with crash.

Are you saying that the only supported way to perform FOS upgrade is to do it manually? Even for 1500 switches ??

External Moderator
Posts: 4,907
Registered: ‎02-23-2004

Re: Massive upgrade of backend switches skipping versions in between

-> Are you saying that the only supported way to perform FOS upgrade is to do it manually? Even for 1500 switches ??

1) Apart from that I'm not a script friends for such things, you have no way to create a script and test it before you begin to launch "firmwaredownload" for a such large Fabric.

2) Such a script show maybe simple, but you must spend more week to create one bug free.

3) As per my opinion, you have to create the script in the form:

    start upgrade from switch IP x.x.x.x

    then switch IP

    third s switch IP

    and so on....

4 ) I'm the opinion, you cannot or better to say you should not start firmwaredownload for all switch at the same time.

-> Not administrated by DCFM or anything like that.

Your can try with BNA in the Trial Edition.

   

Another way is, you looking for a experienced On-Site SE, as per my experience such upgrade can be made in +/- 30-45 Day.

TechHelp24
Occasional Contributor
Posts: 11
Registered: ‎10-14-2010

Re: Massive upgrade of backend switches skipping versions in between

Fabrics in this case are extremely small As I wrote in the first post "2 switches per fabric with 2 fabrics per storage controller.". This also makes it not feasible for BNA.

I never said there is a plan to upgrade all switches at once... Nobody sane would do that. In fact the problem is that company policy is very limiting the amount of concurrent maintenance activities. 

BTW the switches are in different locations around the world.

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.