The master switch is responsible for performing the management tasks of the stack. Which switch you choose to use for the uplinks, whether etherchannel or not, has no affect on the choice of master switch or choice of the backup master switch (with the second highest priority). So if the scenario you described happened, connectivity would still be maintained via the second link from the 5th switch.
Remember that the stacking of switches will take place (ideally) using a closed loop stack. This is where SW1 is connected to SW2, SW2 to SW3, SW3 to SW4, SW4 to SW5 and SW back to SW1 thus creating a loop. If any single switch goes down or if any single stack link between switches goes down, all switches are still connected because of the loop. The only way some switches will become isolated and subsequently disconnected is if two switches, such as SW2 and SW5 fail.
The uplinks however can be on any switch in the stack and even a failure of the master switch will still allow the uplink to function.
If I have 5 switches in a stacked arrangement and have access to each of the members via OOB access (e.g. a terminal server), how can I tell which switch Iām logged into? That is, when I log into each switch in the stack, is there a way to see if Iām logged into the active switch, the standby switch or a member? I can see they are stacked and I can see the stack MAC address, but I just canāt find a command that tells me WHICH switch Iām logged into (the active, standby or member). Iām guessing thereās some way to do this, but just havenāt found it yet.
When connecting to the CLI of an already configured stack of switches, you are always connecting to the master switch. If you use an IP address, you are connected to the master switch. Even if you connect to the console port of a member switch, you are still given access to the CLI of the master, and being provided with configuration abilities for the stack as a whole. If you do want to access the CLI of a particular member, you can do this via the master switch using the remote command.
You can find out more information about this command on page 25 of the following Cisco documentation:
Also, according to page 17 of the above document, it is good practice to use only one CLI session at a time:
Be careful when using multiple CLI sessions to the stack master. Commands that you enter in one session are not displayed in the other sessions. Therefore, it is possible that you might not be able to identify the session from which you entered a command.
We recommend using only one CLI session when managing the switch stack.
Thanks for that info. Itās still kind of odd how you always have access to the master CLI regardless of which switch youāre consoled into. Thereās some voodoo going on there.
As per Cisco below is the sequence for Master selection. Can you please explain 2nd point āThe switch that uses a non-default interface-level configurationā ?
a.The switch with the highest priority value
b.The switch that uses a non-default interface-level configuration.
c.The switch with the higher Hardware/Software priority. This priority is based on the software
d.The switch with the longest system up-time.
e.The switch with the lowest MAC address
Does Matser re-election occur if we connect one more switch in existing stack ?
Consider, in 4 Switch stack topology 1st switch is Master with priority 15 and rest 3 switches have default priority 1. If we connect 5th switch in stack which already has priority 15, which switch will be Master? Switch1 or Switch 5 ?
It means the switch that has been pre-configured vs a switch that hasnāt been pre-configured. What do I mean by this? it means the switch which had some configurations before joining the stack will be selected ahead of the switch that had zero configs in its nvram.
@sales2161 has got it right. And more specifically, the switches look at the configuration found within the interfaces themselves. If even one interface does not have the default IOS configuration, then it is considered a non-default interface-level configuration and it takes prescience.
If a new switch is added to the stack, an election does not take place. The current stack master is retained. An election will only take place when stacked switches are initially powered up or if the master fails.
Since the addition of a switch does not trigger an election, Switch 1 will retain its position as master. If the switches are powered down and re-powered up, then the election will take place normally using the master selection process.
Regarding my doubt no 3, can you please check last point listed below, as per Cisco guideline stack master might be re-elected during below actions. I am still doubtful on whether or not master reelection will occur when we add new switch in existing stack
A stack master keeps its role unless one of these events occurs:
ā¢The stack is reset.*
ā¢The master is removed from the stack.
ā¢The master is reset or powered off.
ā¢The master fails.
ā¢The stack membership is increased by adding powered-on standalone switches or switch stacks.*
In the events marked by an asterisk (*), the current stack master might be re-elected based on the listed factors.
@wlakshmikant,
I think I understand what you are saying. Yes, master re-election will occur (upon powering on the stack) if you add a new switch while the stack was powered off. However, there will be no re-election if you add that switch while the stack is up and running.
Think of this as OSPF DR/BDR/DROTHER election/re-election on multi-access network.
Please @lagapidis, correct me if I am wrong, I want to master these concepts. Thanks
It seems that @sales2161 has got it. The documentation that you are referring to continues and states the following:
Stack members that are powered on within the same 20-second time frame participate in the stack master election and have a chance to become the stack master. Stack members that are powered on after the 20-second time frame do not participate in this initial election and become stack members.
Upon power up, elections occur within the first 20 seconds. If you have a stack of 3 switches functioning and you add an already powered on switch to an already powered on stack, that 20 second window has already passed, so no election will take place.
There is no such thing as standby switch election for stackwise (however as a network engineer, you can predict who will be the next master should the current master fail).
The stack master is only elected to control the stack operation, that is managing the running configs for the switch stack. All other members periodically receive synchronized copies of the configuration files from the stack master.
As @sales2161 has correctly stated, the standby switch is the switch that will immediately take over in the event that the active switch goes down. During the process of the election of the active switch, the standby switch is also chosen. According to Cisco documentation:
The factors for electing or reelecting a new standby switch are same as those for the active switch election or reelection, and are applied to all participating switches except the active switch.
So once the active switch is elected, a second process takes place with the same factors, except that the active switch does not participate. This results in the selection of the standby switch. More info and details on this process can be found here.
Hello @lagapidis, you actually made me do a deep reading about this.
It looks like the behavior is different for 3850s. My answer was based on 3750s stackWise behavior.
According to this 3750 document, āAll stack members participate in re-electionsā which means there is no current standby switch.
When you power on or reset an entire switch stack, some stack members might not participate in the stack master election. Stack members that are powered on within the same 20-second time frame participate in the stack master election and have a chance to become the stack master. Stack members that are powered on after the 20-second time frame do not participate in this initial election and become stack members. All stack members participate in re-elections.
Another difference is the timers for which switches have to be up to participate in initial election. For 3750s is 20 seconds while for 3850s is 120 seconds.
If you power on or reset an entire switch stack, some stack members might not participate in the active switch election. Stack members that are powered on within the same 2-minute timeframe participate in the active switch election and have a chance to become the active switch. Stack members that are powered on after the 120-second timeframe do not participate in this initial election and become stack members. ā link
Itās always good when we need to do a deep reading about these, subjects, thatās how we obtain deep knowledge about them as well!
Cisco stackwise always has the concept of one active member, one standby member, and any number of simple members. Even the documentation of the 3750 you linked to shows this on page 5-20. The documentation doesnāt specify how the standby member is elected however, and this may be the source of the confusion. We can also see other Cisco documentation about stackwise which states:
A switch stack always has one active switch and one standby switch. If the active switch becomes unavailable, the standby switch assumes the role of the active switch, and continues to the keep the stack operational.
Now it is interesting that the documentation of the 3750 does not talk about the standby switch in the context of reelections, but in the context of the switch which has an interface that has an uplink. Having no direct experience with the nuances of Stackwise for the 3750 compared to other platforms, I did a bit of deeper research myself.
Reading some of the Cisco forums that deal with this issue, it seems that the 3750 behaves in the same way as the 3850 as far as the standby/active and reelection procedures are concerned. This is not well reflected in the documentation of the 3750, and may be why the documentation was improved to include this info for the 3850. Iām leaning towards stating that the standby switch is indeed elected even with the 3750 platform, as the stackwise feature (as with many Cisco features) is one that is typically the same across all of the platforms that support it.
The only way to verify this further is to stack up a few 3750s and just test it.
Can you explain what are and when the specific (Waiting,Ready,Initialization,Provision,Progressive) stack states happens? Question regarding this is on the 300-115 exam.
According to Cisco, these states are described as follows:
WaitingāA switch is booting up and waiting for communication from other switches in the stack. The switch has not determined whether or not it is stack master.Stack members not participating in election remain in the waiting state until the stack master is elected and ready.
InitializingāA switch has determined whether it is stack master. If not, the switch receives its system- and interface-level configuration from the stack master and loads it.
ReadyāThe member has completed loading the system- and interface-level configurations and can forward traffic.
Master Re-InitāThe state immediately after a reelection and a different member is elected the stack master. The new stack master is reinitializing its configuration. This state applies only to the new stack master.
Ver MismatchāA switch in version mismatch mode. Version-mismatch mode is when a switch that joins the stack has a different stack protocol minor version number than the stack master.
A typical state transition for a stack member (including stack master) booting up is Waiting > Initializing > Ready.
A typical state transition for a stack member to stack master after an election is Ready > Master Re-Init > Ready.
A typical state transition for a stack member in version mismatch (VM) mode is Waiting > Ver Mismatch.
You could connect the switches in the method you mentioned as long as the loop between all three switches is created. There is no configuration rule that says you should connect port 1 on one switch to port 2 on another. However, there are two reasons why itās a good idea to do the connections like that:
It makes more logical sense, and it is easier to see how to create the ring topology. All connections are the same on all switches. Take a look at this diagram:
You can see that port 1 on each switch connects to the below switch, and port 2 on each switch connects to the above switch.
Stacking cable lengths are made so that the crossover method described above will give you the neatest cabling. It also requires the shortest cabling for a side by side stacking like so:
Yes you can do that if you like. Ultimately however, it is really up to you as to what is more convenient for you.
