So here is how to upgrade Nexus 5000 series switch. In this instance I have 2 Nexus 5010 switches in vPC configuration as they are part of the Vblock. I will be upgrading them from 5.1(3)N1(1a) to 5.2(1)N1(1)
First of all, although upgrade procedure is pretty much the same, please always check with Cisco for latest upgrade guides: http://www.cisco.com/en/US/products/ps9670/prod_installation_guides_list.html
For the upgrade to be done as quick as possible it is important to do some work before it, like downloading the files from Cisco, uploading them to switches and running checks.
Download Kickstart and System files from Cisco.com
Verify that you have enough space on the switch dir bootflash:
Upload both files to the switch. In this case I used TFTP server: copy tftp://x.x.x.x/kickstart_or_system.bin bootflash: <=== replace x.x.x.x with TFTP server IP, kickstart_or_system.bin with your Kickstart or System file name. type management when asked to Enter vrf
Note: In Vblock upload files to both switches. Copy operation might take some time.
Once both Kickstart and System files are uploaded verify that the file size of both files is correct. dir bootflash:
Now we need to run some pre upgrade checks which will show if there any problem that should be fixed before the upgrade can be started show compatibility system bootflash:system.bin <=== replace system.bin with your System file name.
You should get No incompatible configurations message
Next we to see the impact of the upgrade: show install all impact kickstart kickstart.bin system system.bin <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
This procedure might look like a real upgrade but it only does all the checking
It will take some time to complete. It must succeed at all steps and should show that upgrade is non-disruptive
Now check spanning-tree impact. Everything should pass show spanning-tree issu-impact
Check lacp impact show lacp issue-impact
There is also show fex to verify that all fabric extenders are reachable but in the Vblock there are no extenders connected to the switches so this can be skipped.
Once steps 1 – 9 are completed and all are OK you can proceed to upgrade.
Because this is Vblock and 2 switches are in vPC config you need to identify the primary one as the upgrade should be started from primary show vpc role
Start upgrade install all kickstart kickstart.bin system system.bin <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
Once prompted verify to continue by pressing y
The upgrade will begin.
If you connected to switch remotely over SSH, you will lose connectivity after seeing Saving supervisor runtime state message as the switch is rebooting. This should take about 5 minutes. Ping it to find out when it is back online.
Login to the switch and check upgrade status. If upgrade went ok you should see that it was successful. show install all status
Verify version show version
Verify that everything is working as expected.
Upgrade is complete
In Vblock once you’ve verified that primary switch is working fine, upgrade the secondary switch.
This is a quick post for simple error that you might see in Cisco UCSM. Affected object: sys/chassis-2/fan-module-1-2 Description: Fan module 1-2 in chassis 2 temperature: upper-critical Cause: thermal-problem Code: F0382
This may indicate that there is hardware problem with the fan and it needs to be replaced but quite often it indicates logical problem. There are a few bugs depending on the version that UCS is running that might cause this behaviour.
As we can see from the error the problem is with the fan in chassis 2.
If you click on the blue text it will open a new window and you’ll be able to see which fan it is.
The first thing you can try is to reseat the fan and see if the error goes away. If it does not then it most likely hardware issue.
In this case the error has cleared.
This error might reappear in couple day/weeks or months or it could happen on the other fan. There is a known I2C bug in UCS. To clear i2c bus it is advised to reseat all fans, PSUs and IOmodules(one at a time).
The bug was fixed in late 1.4(3*) version but was reintroduced again in 2.0 version. It should be fixed in latest version.
I UCS system affected by this bug than you still need to reseat components as the upgrade alone will not clear the I2C bus.
IMO it would be best to reseat them before upgrading as at least you’ll be upgrading a healthy system.
Here is a simple procedure how to update firmware on UCS C200 M2 server. The procedure should be no different on the other models of C series servers as they use Host Update Utility(HUU).
1. First you need to download the firmware for the upgrade. In this instance the server will be upgraded to 1.4(3p)5
Here is a strange error that popped up recently.
After server reboot the blade got stuck on 47% of associating service profile.
Here is the error:
Remote Result: Service Unavailable
Remote Error Code: 4106 Remote Error Description: Unable to find Storage Controller Device for sys/chassis-4/blade-2/storage-SAS-1 to perform Image update
When looking in the KVM Console for the blade I can see that it was sitting in the screen below:
Here are the things that I’ve tried to fix this and none of these worked:
1. As it was saying about the image update for Storage adapter I though I’ll remove Host firmware policy from the service profile.
2. Next I created a new Host firmware policy but only added firmware SAS storage controller and chose different version than it had.
3. Remove and add service profile back
Here is what worked though:
Removed service profile from blade, re-acknowledged the blade added service profile back. After this the error was gone and the blade was booting normally.
The last step was to add old Hast firmware policy to the service profile and check if that brakes it again, but all worked as expected.
So I’m happy that the blade is back but cannot explain how and why this has happened.
In UCSM you see critical error: Affected object: sys/svc-ext Description: [FSM:FAILED] communication service configuration(FSM:sam:dme:CommSvcEpUpdateSvcEp) Cause: fsm-failed Code: F999616
The error itself is not very descriptive, so in order to find out what the problem is best it to look at UCSM show-tech support logs.To do that select Admin tab, select All and click on Create and Download Tech support.
Here is an interesting thing that happens during Linux installation on Cisco UCS blade.
After installing Suse on Cisco UCS blade the server would not boot and only flashing cursor is seen. Tried other version of Suse and even RHEL, still the same. This looked strange because I had installed Linux on UCS without any problems before.
There is a small thing that you need to be aware when doing installation. Make sure in to add CD-rom in boot order in the the service profile and when after you mount your ISO let the sever to pick it up itself. Do not press F6 and choose for it as this is where interesting thin happens.
When you let the server to pick the boot device it makes Linux installer to think that this server is running in UEFI mode.
When you press F6 and choose the boot device the installer thinks it is BIOS mode and when partitions are created, it messes things up there for after reboot you see flashing cursor.
Here is pretty common problem in UCS 2.0 release.
At any stage of UCS upgrade one or more blades go into discovery mode and never finishes it. Depending on the version they can get stuck at any percentage but usually between 4% and 40%.
Most of the time a corruption occurs in SEEPROM of M81kr CNA card because of this corruption checksum fails and UCS cannot recognize the mezzanine card any longer and this prevent Discovery from finishing.
You can see the following errors when this happens: Configuration Error: adaptor-inoperable. Discovery State: Insufficiently Equipped.
Adapter 1 in server 1/1 has unidentified FRU
There are multiple Cisco bugs for this issue CSCub16754, CSCty34034, CSCub48862, CSCub99354 and I’ve seen it happening on 2.0(1q), 2.0(2r), 2.0(3a) releases.
Unfortunately the issue is not fixed and there is no workaround. The good thing is that if this occurs the fix is pretty simple and quick and no hardware replacement is needed but only Cisco TAC can fix this or whoever has access to their internal resources.
To verify if corruption occurred you can do the following:
SSH to UCSM IP
Enter connect cimc x/y (Chassis/Blade)
Enter mezz1fru on the versions starting from 2.0(3a) you need to enter fru
If corruption has occurred the last line of the output will show something like ‘Checksum Failed For: Board Area!’
Here is a guide how to update the Capability Catalog in UCS Manager. Capability Catalog is updated every time you upgrade UCS firmware but you might need to update it separately when a new hardware is added to UCS infrastructure and upgrading the whole UCS is not possible.
1. Login into UCS manager
2. Select Admin tab and change the Filter to Capability Catalog
