On Thu, 15 Nov 2012, Christopher Gray wrote:
I have four switches (A, B, C & D) linked in a loop comprising 1Gbps fibre.
Switch A is connected to a primary WAN router while switch C is connected to
the secondary WAN router - the two routers working in a simple HSRP
fail-over set. I want to ensure that this loop will survive the failure of
any one link (e.g. if the link between A & B goes down, B will still be able
to connect to the primary router via C & D.
I currently have the STP path costs set to A=4, B=5, C=6 and D=7
Question 1: Does this make sense? Should the "root bridge" (using Wikipedia
terminology) always be the one connected to the primary WAN router? Does
STP work well when the WAN uplink fails over to the secondary or doesn't it
matter.
It's generally a good idea to set one switch to be your root bridge (STP
priority of 0). In your topology, the switch that is connected to your
primary WAN router would make the most sense. You can also set a higher
STP priority like 4096 on the switch that connects to your backup WAN
router.
You can set a higher spanning-tree link cost on the link between C and D,
and you really wouldn't need to set link costs on the others. When the
other switches run their STP calculations, they'll see two paths to the
root bridge, and one will have a higher path cost, so that should go into
a Blocked state and be listed as an alternate path.
You didn't say if you were running PVST/PVST+/rPVST/MST or if you have VTP
domains, etc.
Question 2: Should I set all non-uplink (interswitch) ports as "disabled"?
I think this might be worded somewhat backwards. Your inter-switch links
would be your uplinks. You need to run spanning-tree there. Cisco
generally doesn't allow spanning-tree to be disabled on specific ports.
You can set them as access ports in a specific VLAN if needed, and run
portfast. DO NOT run portfast on trunk ports. I think newer versions of
IOS will yell at you if you try to do this, but in older versions, it was
a great way to create bridging loops :(
jms
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
