Redundant Uplink STP

[DHGmem]

What are the metrics i need to look for when adding a redundant uplink to a switch stack?

Our switches currently have one 10G uplink to the core, and I want to add a secondary ALT uplink for redundancy.

I did this once already, and the root bridge moved to the ALT and i lost a few pings when this happened. Not a big deal, but this is not what i expected to happen.

The current ROOT uplink is on Switch 1, set to Priority 15.

The new ALT uplink is on Switch 5, set to Priority 11.

I thought the Priority Setting on the stack was the 1st metric during STP negotiation, but the new uplink on Switch 5 negotiated itself as the ROOT.

*1       Active   xxxx.xxxx.xxxx     15     V02     Ready
 2       Standby  xxxx.xxxx.xxxx     14     V05     Ready
 3       Member   xxxx.xxxx.xxxx     13     V05     Ready
 4       Member   xxxx.xxxx.xxxx     12     V05     Ready
 5       Member   xxxx.xxxx.xxxx     11     V05     Ready

Gi1/0/2             Desg FWD 19        128.2    P2p
Te1/1/1             Altn BLK 2         128.53   P2p
Gi2/0/4             Desg FWD 19        128.100  P2p
Te5/1/1             Root FWD 2         128.437  P2p

What did I do wrong?

[balaji.bandi]

If you looking to 2 uplink to Core.

My suggestion below :

1. Configure the second uplink on standby switch (not memeber of switch)  that is Switch 2

2. Instead of trunk (make it port-channel) so you can use both the links load share, it also give high availability

The one you configuring yes, STP will block one of the port (the priroty you mentioned here is switch priority not STP priority)

So STP root will be slected as per the process

https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/5234-5.html

Root bridge election :

https://www.certificationkits.com/cisco-certification/ccna-articles/cisco-ccna-switching/cisco-ccna-spanning-tree-protocolroot-bridge-rootdesignatedblocked-ports/

[Martin L]

Stack Priority 15 will make sure that switch is Master (Active) for stack election as oppose to Standby or just a Member;  this Stack switch priority is not STP election related nor has anything to do with STP.  STP  elections are based on STP priority and MAC address, then Port Cost to Root and Sender Port number and sender Port priority.  In case of switch stack, MAC is main and same "shared" for all switches in the stack; Then your cost to root sw is the same, 2. so, your election difference falls into port priority/number area (like  128.437 vs 128.53). What are those numbers on the Core switch? compare and verify.  

Also, Cisco STP/RSTP runs per vlan; so, results of STP might be different, aka show spanning-tree vlan 1 maybe different from vlan x.

As mentioned by BB, use port-channel, aka etherchannel instead of trunks so that STP does not block one of the links.

Regards, ML
**Please Rate All Helpful Responses **

[Joseph W. Doherty]

As the other posters have already noted, a stack master has nothing to do with STP root, the latter is a different parameter, which applies to the stack as a whole, not any stack member.

Generally, you don't want the STP root to "move".  Often, you obtain that by adding the STP root option to the switch you want to be your STP root.

BTW, when using STP, rapid-STP is a much better STP variant, and should be enabled (it's not the default) on all your switches.

As also noted by other posters, if possible to use Etherchannel, that's generally considered a "better" choice than using STP.  However, for optimal usage you may need to changes switch's hashing algorithm (which is specific per switch, and may have different defaults per switch, and may not have same options across different switch models, and might need to be intentionally different per switch).

Even if using Etherchannel, where there's no possible L2 loops, STP should still be enabled (to break "accidental" loop creation).