Understanding Switch Stack Uptime

When you have multiple Switches as part of a Stack, it can be slightly confusing when checking the uptime to determine what is what. Let’s take a look at how to understand this better.

Here’s some example output of a Stack comprising of 2 Switches.

Note that all sensitive information has been redacted.

SWITCH-STACK#show version


SWITCH-STACK uptime is 2 weeks, 4 days, 11 hours, 20 minutes
Uptime for this control processor is 1 week, 1 day, 9 hours, 4 minutes
System returned to ROM by SSO Switchover at 07:01:57 UTC Tue Sep 18 2018
System restarted at 11:24:36 BST Fri May 1 2020


Switch 01
Switch uptime : 1 day, 11 hours, 11 minutes

We have 3 things represented here that we need to understand:

  1. The uptime of the logical Stack
  2. The uptime of the Stack Master
  3. The uptime of the rest of the Stack Members

Let’s go through these one by one.

Uptime of the Logical Stack

Line 5 from the output above tells us how long the Stack as a virtual, logical unit has been up for. Remember that a Stack is considered as up if only 1 Switch in it is still functioning as normal. So even if you have a Stack of 5 Switches and 4 are down, the Stack is technically considered up (but of course you should do something about those 4 down Switches).

Uptime of the Stack Master

Line 6 states that ‘The uptime for this control processor is …’. Remember that for a Stack there is only one Master. This serves as the Management Plane, and when you connect via SSH/Telnet to the Stack you are in fact connected to this Switch. Any commands you issue to the Stack will be propagated via the Master. This is what the output is referring to when it mentions ‘The uptime for this control processor is…‘. Since we are connected via SSH/Telnet to the Stack, we must be on the Master, therefore the following uptime will mean the uptime for the specific Master Switch itself.

As a reminder, you can see how many Switches are in a Stack by using the ‘show switch‘ command.

Example output is as below for this current Stack:

SWITCH-STACK#show switch

Switch/Stack Mac Address : [REDACTED] - Local Mac Address
Mac persistency wait time: Indefinite
                                             H/W   Current
Switch#   Role    Mac Address     Priority Version  State
 1       Standby  [REDACTED]         15     V01     Ready
*2       Active   [REDACTED]         14     V01     Ready

The asterix in front of the 2 on Line 9 tells us that Switch 2 is currently the Stack Master, therefore we can understand that we are currently on Switch 2.

Uptime of the Remaining Stack Members

As we further scroll down the initial ‘show version’ output, we can see that eventually we reach some information about the remaining Switches in the Stack. In the output at the beginning of this post, I have removed a lot of the output that wasn’t relevant to our goal here, but as you can see on Lines 12-14, we have the uptime information for the other Switch that is a part of this Stack.

Our example is quite simple as we only have 2 Switches in the Stack, but if we had many (remember, up to 9 Switches is possible!), we could easily run the ‘show switch’ command like we did above to compare the uptimes against each Switch number.

Interpreting the Data

Now we know the following:

  • The Stack is made up of 2 Switches
  • The Stack has been up for 2 weeks
  • Switch 1 has been up for 1 day, 11 hours
  • Switch 2 has been up for 1 week, 1 day and 9 hours
  • Switch 2 is the Stack Master

We can then begin to build the story of what happened with this Stack.

  • Roughly 2 weeks ago, the entire Switch was rebooted
  • 1 week, 1 day and 9 hours ago, Switch 2 rebooted. The Stack remained up and Switch 1 became the Master
  • At least 1 day and 11 hours ago (remember, it could have happened even before then too!), Switch 1 rebooted. Switch 2 became the Master and the Stack remained up

It’s as simple as that, I hope this helped!

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Subscribe to Blog

Enter your email below to subscribe to this blog.