Upgrade of VDX 6740T and VDX6740

[stefantomasevic]

Hi, I am about to perform my first Brocade upgrade and I have read several threads from here from other engineers. My environment is made from 6 brocade switches, and all of them are on 7.0.2b version.

Brocade 1 and 3 are copper, Brocade 2,4,5,6 are fibber.
Brocade 1 is principal.

BR1# show vcs
Config Mode : Distributed
VCS Mode : Logical Chassis

I am familiar with upgrade methods. All learned from nos-7.4.1-upgradeguide.pdf

My final destination is upgrade to 7.4.1e via Cold Boot
path:
7.0.2b
>7.1.0b3
>7.2.0g
>7.3.0b
>7.4.0b
>7.4.1f

All this hops are major so Cold Boot is logical choice.

My questions are:

When I finish upgrade of first switch (brocade 6 for example) to 7.0.1b3 switches are no longer software version levelled.
1. Will this have impact on data flow between switches until all switches get 7.0.1.b3 version (get levelled)? What will happened with chassis when/if software version is not levelled?

2. What this part of command output SHOW VERSION shows? What are SW/0 and SW/1

Slot Name Primary/Secondary Versions Status
---------------------------------------------------------------------------
SW/0 NOS 7.0.2b ACTIVE*
7.0.2b
SW/1 NOS 7.0.2b STANDBY
7.0.2b

Thank you for any help.

[Michael_Morey]

Stefan,

When a switch in a previously established fabric is upgraded and the FW Version is not levelled it will be segmented from the VCS Fabric.  This only impacts the Management functionality; config management (any changes to the fabric config will not be communicated) and central point of management (the principle will not "see" the segmented switch).  All Layer2/Layer3 traffic will continue to flow over the fabric as it did prior to the upgrade.

My recommendation is to not make ANY changes to your configuration during the upgrade process.  Doing so can cause a Config Database mismatch, which presents as an "ESC Mismatch" while looking at the ISLs, and will require the segmented switch to be defaulted in order to rejoin the fabric once the FW is leveled.  Additionally, do not leave the device segmented for an extended period (several days).  If there is any excessive drift in the database time stamp you can see the same "ESC Mismatch" when no changes were made.

Regarding the output you listed for "show version"; there are two partitions in the VDX (Active and Standby), both of which have a primary and secondary.  SW/0 is typically the partition your device is actively running on, and SW/1 is typically the Standby/backup partition that will take over in the case the Active fails.  This design also allows the staging of code as well as the ability to not "commit" to a version.;

When issuing the "firmware download" command you should see additional options including:

noactivate Perform Firmwaredownload without Activation on the local.
nocommit Skip auto-commit after firmwaredownload

"noactivate" will download the code to the "STANDBY", in your case SW/1 only, and will leave the device running on the original code.

"nocommit" will download the code to the "ACTIVE", in your case SW/0 only, and will start running the new code leaving a "backup" of your previous code on the "STANDBY"

Using the "firmware [activate|commit]" command(s) would finish the process by:

"activate" will load the code over to the "ACTIVE" and trigger the device to start using the new code (this is how you can stage code and then initiate an upgrade at the time of your choosing)

"commit" will overwrite the old code on "STANDBY" with the newly upgraded version. (this is how you can test code then choose to commit to it)

These processes can be backed out using the "firmware [recover|restore]" commands.

Hopefully this answers your questions,

[stefantomasevic]

Hi Michael, first thank you for detailed explanation. 

I think you did not understand me well or I was not clear with question.

Switches are in Logical Chassis mode. They are acting like one switch from 1/0/1 to 6/0/48 ports and software version of all of them are the same, levelled.

When I start upgrading them, one by one (with attention to the principal switch to be upgraded as last one) version between them will not be the same. I will not perform any other config changes, ONLY upgrade: firmware download interactive and then choose, ftp, IP,user,pass, file, cold boot method and so on.

What will happened with with traffic between host on brocade 1 who is trying to communicate with host on brocade 6, who has one hop higher software version then brocade 1,2,3,4 and 5.

• Brocade 1: 7.0.2b
• Brocade 2: 7.0.2b
• Brocade 3: 7.0.2b
• Brocade 4: 7.0.2b
• Brocade 5: 7.0.2b
• Brocade 6: 7.1.0b3

[stefantomasevic]

I think I understand you better now, after several reading of your post.

So,

1. only management will be impacted,
2. L2 and L3 continue to flow, and
3. DO NO CHANGE any config during upgrade (during upgrade of all 6 switches).
4. Do not leave the device segmented for an extended period (several days) BC of drift in the database time stamp that can cause ESC Mismatch even if there is no config changes.

is that so?

Because all this hops are major, cold boot is recommended method?

About sw/0 and sw/1. I have one test brocade here with me, and I practice downgrading. Before starting it, show version  was:

sw0# show version

///

Slot Name Primary/Secondary Versions Status
---------------------------------------------------------------------------
SW/0 NOS 7.1.0b3 ACTIVE*
7.1.0b3
SW/1 NOS 7.1.0b3 STANDBY
7.1.0b3

Then firmware download interactive

Download to multiple nodes in the cluster? (y/n) [n]: n
Server name or IP address: 10.10.10.20
File name: nos7.0.2b
Protocol (ftp, scp, sftp, tftp) [ftp]: ftp
User: admin
Password: ****
Enter VRF name [mgmt-vrf]:mgmt-vrf
Select procedure (1=ISSU, 2=coldboot, 3=default-config) [1]:2
Performing system sanity check...

This command will cause a cold/disruptive reboot and will require that existing telnet, secure telnet or SSH sessions be restarted.

Do you want to continue? [y/n]:y

30 minutes later, show version shows both version:

Slot Name Primary/Secondary Versions Status
---------------------------------------------------------------------------
SW/0 NOS 7.0.2b ACTIVE*
                    7.1.0b3
SW/1 NOS 7.0.2b STANDBY
                     7.1.0b3

15 minutes later, version became the same.

Slot Name Primary/Secondary Versions Status
---------------------------------------------------------------------------
SW/0 NOS 7.0.2b ACTIVE*
7.0.2b
SW/1 NOS 7.0.2b STANDBY
7.0.2b

Is this normal behaviour?

Sorry for long post and amount of questions.

Thank you

[Michael_Morey · Accepted solution]

Stefan,

A: For 1-4, yes it seems your understanding is correct.

Q: Because all this hops are major, cold boot is recommended method?

A: If you wish to retain your config, cold boot is the only method to perform a traditional major step upgrade. You could technically jump directly to the latest release, however that would require you to default your configuration.

You can review the following article: How to perform VCS Fabric Multi-Version Upgrade which may save you some downtime in your production network.  This combines the method of upgrading one switch step by step, thereby retaining the config via cold-boot and then upgrading the rest of the network in a single step (default-config).  Once the fabric is formed the defaulted switches will download the retained config from the surrogate principal.   The time consuming part of the upgrade can be done beforehand, however it does require the use of a spare switch or taking an existing switch offline to upgrade and then act as a surrogate principal.  The article is brief, however the attached White Paper is very detailed.

Q: Is this normal behaviour? (Regarding downgrade and "show version" output)

A: Yes that output and duration is normal for a VDX upgrade/downgrade.

Best of luck,