I have a large number of 2024p/2048p switches that we deployed last summer with 22.214.171.124,16 or 18 and CPLD 13. I was looking over the notes for the upgrade to 126.96.36.199 and trying to figure out the impact of the CPLD update from 13 to 15. The language of the patch notes is not worded as strongly as most of the other content, they mention you can upgrade it where for other components they tell you that you must upgrade it (like boot code), but that you MUST downgrade it to go backwards.
In addition, they requirement to visit every switch and connect directly to it/power cycle it locally is a gigantic burden.
Its it required to update to CPLD 15 at the same time as upgrading to 188.8.131.52? Is is possible to go to 184.108.40.206 and stay on CPLD 13 until someone can go to each switch and do the CPLD update (weeks or months), or should we stop at some lower release, like 220.127.116.11 that did not yet have the CPLD update until we can schedule the visits?
Solved! Go to Solution.
It is recommended for everything to be at the latest version. It may work with the older CPLD and the newer firmware, but it would be better to have them all updated at the same time. Just updating the firmware to a version that doesn’t need the newest CPLD is the best option.
We have three Dell Networking N2048 units in a stack. I upgraded from 18.104.22.168 --> 22.214.171.124 today. Going by the included PDF upgrading guide, I attempted to telnet into the stack and issue the command 'update cpld' to get from CPLD 13 --> CPLD 15.
The console line showed that it was issuing the CPLD update command and after about a minute it printed a new line saying that it successfully issued the update command and returned me to my enable prompt.
However, when I go back into the console and issue 'show version' my CPLD version is still 13. I can't seem to get it to update the CPLD version to 15 from the stack master. Any help is appreciated.
Wanted to chime in with how we've done it (completely remotely)
By manually setting the stanby unit you are able to control which unit will become the next master unit. This allows you the ability to cycle through each switch in the stack, updating each switch as they become the master of the stack.
Your solution is good, but it will not work on stack with only 2 members. I can't demote the current Mgmt switch to standby. Example:
SWCORE_01_MRT02#show switch Management Standby Preconfig Plugged-in Switch Code SW Status Status Model ID Model ID Status Version --- ---------- --------- ------------- ------------- ------------- ----------- 1 Stack Mbr Cfg Stby N3048 N3048 OK 126.96.36.199 2 Mgmt Sw N3048 N3048 OK 188.8.131.52
Whenever i try to put switch2 as standby i get this message
SWCORE_01_MRT02#configure SWCORE_01_MRT02(config)#stack SWCORE_01_MRT02(config-stack)#standby 2 Error: Management unit cannot be set as Standby
Maybe i'll have to deal with uploading the startup-config to a tftpd server, edit the "standby" line and download it again to startup-config.
Nwildner, With a two switch stack there is no need to manually set the standby unit. There will always be one master switch and one standby switch.
The process should look similar to this:
- Update the CPLD on switch2(master) and reboot.
- When switch 2 reboots, switch 1(standby) will take the master role.
- Update the CPLD on switch1(master) and reboot.
- When switch 1 reboots, switch 2(standby) will take the master role.
Now you have updates CPLD on both switches, with 2 being master and 1 being standby.