Hi,

Just a quick one from me today, detailing the steps required to upgrade the CPLD against a Dell switch stack.

I’ve seen all too often that customers have got issues with their switch stacks that are caused by CPLD version mismatch, such as ports not working intermittently on all but specific switches.

To remind you, once you’ve upgraded your Dell switch firmware, you should check the bootcode and CPLD are up to date.

To update the CPLD you run the following command once you’re in privileged EXEC/enable mode:

update CPLD

Seems simple enough right? But there are some complications that aren’t well documented to discuss:

How do I know the CPLD version of each switch?

If you run the following command, you’ll only see the CPLD of the current management switch.

show version

If you add a suffix of the stack member you wish to check, you can get individual outputs.

show version 1

We can use this information to find out the CPLD of each individual switch!

Updating CPLD doesn’t update the whole stack

That’s right, you’re only updating the CPLD against the current management switch when configured as a stack. You need to individually update the CPLD on each switch to upgrade it completely. Dell supply the following command, but I’ve found it extremely inconsistent (and Dell also only recommend running this from the switch master’s serial console).

update cpld <Switch Number>

Instead, to force a CPLD update to specific switch members (or to complete a stack upgrade after you’ve upgraded one of your switches). You need to perform the following steps:

• Identify switches to be upgraded
• Set a switch requiring to be upgraded as the standby management switch.
• Force the management switch to failover to the standby management switch.
• Update the CPLD on the switch.

To complete this list, run the following commands.

standby <Switch Number>

This will specify the switch number that needs to be upgraded next, by using the standby command, you’re setting that switch to take over the management role when a failover occurs, which we’ll be triggering shortly.

initiate failover

By running initiate failover, we’re forcing a reload on the current management switch, forcing the standby switch that we just configured with the previous command to take over.

Once this is complete you can run the following command to actually update CPLD.

update cpld

IMPORTANT Note: It’s possible to set your next standby management switch prior to updating CPLD to chain these updates together faster, whilst this isn’t by itself a problem, be mindful of creating switch isolation scenarios. For example, look at the following diagram.

In typical deployments, each switch will be connected to its nearest neighbours apart from the top and bottom switches which will be connected to a nearest neighbour and the other end of the stack. This prevents isolation within the stack during a single device failure.

When we’re rebooting these switches they are down until they’ve booted back up, so they should be treated as a failed device until they return to the stack. If I needed to update the CPLD on switches 2 and 4 and I triggered their CPLD updates to run simultaneously, I would end up with a stack that looks like the below:

In this scenario, switch 2 & 4 are temporarily in a failed state, switch 1 and 5 can talk to each other, but as switch 3 has no surviving connections to the rest of the stack, it is isolated. To mitigate this, it would be required to wait for one of the switches to complete its update before updating the other switch.

Hope this helps!

Image by Brett Sayles