cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8212
Views
10
Helpful
16
Replies

Nexus 5500 upgrade

S891
Level 2
Level 2

Hi,

I am planning to upgrade my Nexus 5596 switches and Nexus 2Ks. We are currently running an older version 5.2(1)N1(2).

What should be the upgrade path to the latest version, or would that be just a one-step upgrade?

Anything I should be careful about during the upgrade process?

 

Thanks

16 Replies 16

Richard Michael
Cisco Employee
Cisco Employee

what kind of upgrade are you planning for? is it ISSU or normal one? I would suggest normal one with just one reload to the latest version 7.x using install all command. DONOT ATTEMPT TO CHANGE BOOT VARIABLE AND RELOAD that kind of screws up configs and you would have missing configs. So use Install all.

 

Richard

Thanks Rick. I believe I should do the normal upgrade. So as you suggested I don't need to do it in steps and it would be just one step to the latest 7.x code. If BOOT variable is not defined would it automatically detect the newer version?

If its normal upgrade, just do the following,

Step1:

Copy the latest image to the bootflash

Step2:

install all kickstart bootflash:n5000-uk9-kickstart.7.0.5.N1.1.bin system bootflash:n5000-uk9.7.0.5.N1.1.bin

Step3:

After reload verify if version's are correct.

Thanks,

Richard

Thanks Rick. I will try as you suggested.

I have the following "show install impact" output. I see few places of caution. Is there anything I should be concerned about?

Compatibility check is done:
Module  bootable          Impact  Install-type  Reason
------  --------  --------------  ------------  ------
     1        no             n/a           n/a  Incompatible image
   101       yes      disruptive         reset  STP ISSU preupgrade check failed - Upgrade needs to be disruptive!
   102       yes      disruptive         reset  STP ISSU preupgrade check failed - Upgrade needs to be disruptive!
   111       yes      disruptive         reset  STP ISSU preupgrade check failed - Upgrade needs to be disruptive!
   112       yes      disruptive         reset  STP ISSU preupgrade check failed - Upgrade needs to be disruptive!

 

Images will be upgraded according to following table:
Module       Image         Running-Version             New-Version  Upg-Required
------  ----------  ----------------------  ----------------------  ------------
     1      system             5.2(1)N1(2)             7.0(5)N1(1)            no
     1   kickstart             5.2(1)N1(2)            7.0(5)N1(1a)            no
     1        bios      v3.6.0(05/09/2012)      v3.6.0(05/09/2012)            no
     1      SFP-uC                v1.0.0.0                v1.0.0.0            no
   101       fexth             5.2(1)N1(2)             7.0(5)N1(1)           yes
   102       fexth             5.2(1)N1(2)             7.0(5)N1(1)           yes
   111       fexth             5.2(1)N1(2)             7.0(5)N1(1)           yes
   112       fexth             5.2(1)N1(2)             7.0(5)N1(1)           yes
     1   power-seq                    v5.0                    v7.0           yes
     1          uC                v1.0.0.2                v1.0.0.2            no


Additional info for this installation:
--------------------------------------
Remove QoS & ACL config on L3 interfaces and SVIs if any

Service "stp" : Port: port-channel20 in VLAN0001 is Designated. Topology change could occur during ISSU.
Upgrade needs to be disruptive!!!

Service "vpc" : STP Preupgrade Check failed on VPC peer switch

you might get a TCN from the po 20 that might interrupt the ISSU. Incase if you have continuous TCN from that port fix it and move forward.

Use the command to find whats wrong with the configuration,

show spanning-tree issu-impact

 Once fixed do the install all command again you should be able to upgrade it this time. Ofcourse you are upgrading from 5.2 to 7.0 so it would be disruptive and switch will reload and break the data-plane forwarding. That's fine anyways i assume you are going to do this in maintenance window.

More info:

ISSU prerequisites:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/upgrade/421_n2_1/b_Cisco_Nexus_5000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Release_421/Cisco_Nexus_5000_Series_NX-OS_Software_Upgrade_and_Downgrade_Guide__Release_421_c...

 

Hi Rick, I am planning to do a normal upgrade not ISSU. Would it still matter? VLAN 1 is not in use.

Changing boot variables and doing reload is not supported in the N5k. Please see bug CSCuo34379. Any upgrade is now enforced via install all command which is confusing and people might think on why i should do ISSU, Install all essentially reload it due to movement from 5.2 to 7.0 as its not supported from ISSU. Now, just give yes at the install all impact and proceed anyway it should be fine. Let me know how it goes.

we do it gracefully when we do the install all command in N5k, if we do reload the ASCII replay for the config might not even happen properly and you would see missing configs.

 

Thanks,
Richard

Hi ,

Could you able to do the upgrade without doing any changes with " STP ISSU preupgrade check failed - Upgrade needs to be disruptive!" message?

I too planning an upgrade,but when I check the compatibility,me too getting the same messages as above.

Would I be able continue the upgrade?

Appriciate your inputs.

Thanks

The reason could be port-channel20 is mis-configured to be non-edge port. Check with command "show spanning-tree issu-impact" will show you more info if that port is in "DESIGNATED MODE" or not. If the device connected to that port is an edge device, fix it with
int po20
"spanning-tree port type network" for non-trunk port and
"spanning-tree port type edge trunk" for trunk port

glen.grant
VIP Alumni
VIP Alumni

  It will be interesting to see how this works out because according to cisco documentation it should be a non disruptive issu going  from the version you are stating to the 7.X code.  I can tell you we tried this after going thru all the prechecks using the show install all impact commands which shows it should be a non disruptive upgrade which it ended not being as it seem to take down the whole vpc when we did the install all command on the first operational primary box.  The box upgraded to the code ok but we could not reach devices or even the other n5k in the vpc domain when we did this . We could not find a reason for this behavior and decided to back out to 5.2 code and after we did this everything normalized . We have a tac case open for this and right now they do not have an answer other than to say maybe we should go to 6.x code then to 7.X . I am less than impressed with this whole procedure , at least with IOS  you knew what you had , stick the code on , change boot statements and away you went  .  If you try this maybe post back here with your experience.  The cisco tech said they did have cases in the knowledge base of issues going from 5.2 to 7.x code.

Fawad,

 

We have 5596's with 2000 FEXes as well and will be going from a 6.0 to 7.0 NX-OS here in a couple weeks. We're primarily following the upgrade procedures at the end of this guide, in a section titled "Upgrading a Dual-Homed FEX Access Layer." 

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/upgrade/705_N1_1/n5500_upgrade_downgrade_700.html

 

During the listed process it actually does have a portion of the steps where you set the boot variable, save config, then reload. One of the other posters in this thread says not to do this, but according to the documentation you need to do it on the secondary 5K once the primary 5K is upgraded.

Because we have heard issues with the upgrade rebooting all the FEXes upon upgrading the primary 5K (see glen's comment in this thread), we'll be modifying the upgrade process on our end a bit. Might be something to try for yourself. Before we upgrade our primary 5K we'll be shutting down half of the FEX ports on the primary so that the upgrade won't get pushed out to those FEXes. This will prevent upgrades on those FEXes and a reboot if it would have occurred. We'll upgrade those FEXes upon upgrading the secondary 5K with the "install all" command. I ran this by Cisco TAC and they say it should work. Can never been to cautious....

 

Thanks,

 

Logan

Hi Logan,

I was planning to perform an upgrade in a VPC domain an I found this discussion. I was going to follow the recommended procedure, but after reading this I have my doubts. Can you tell me if you were able to perform the procedure successfully by shutting down the FEX ports?

Thanks,

Mariela

Currently because of BA I have a disruptive reset - which the way I read it all FEX will reset at once?  As anyone verified or tested turning off half the FEX's since all our ESXi hosts are redundant this might work for us.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco