I'm reading some documentation from Cisco about HA campus design.
This classical campus architecture has a couple of trunks connecting each access switch to a couple of redundant L3 switches, using HSRP. The two L3 distribution switches are connected by a L3 link. Here comes my doubt:
since the link between the active HSRP switch and the standby one is a L3 link, why is STP used anyway? I mean, the configuration example i read shows that the active switch is also configured as STP root for the various VLANs, but I'm not sure this is really needed as it would be if the link between distribution switches were a L2 link. After all both trunks are forwarding and....
I guess one of the reasons that there is a Layer 2 (trunk) link between both switches is that both are in the same VTP domain. Otherwise, if both switches are configured in VTP transparent mode, you would need to create all VLANs manually on both switches...
In this scenario it is not necessary. The overhead though is very low and some people like the idea of being protected from an accidental loop caused by a patching error.
This is what I wanted to hear. Anyway, that document leaves me a bit puzzled ... at first it says: use a L3 link between distribution switches, don't use a L2 link because keeping in sync HSRP and STP for different VLANs is tedious and error prone. Then it goes on showing a config with HSRP
You are using L3 link between DISTRIBUTION layer switches. But you should have L2 links from an access layer switches to the distribution layer. That's the place where you need STP.
HSRP is L3 protocol and STP is L2 protocol. That means that HSRP deals with L3 redundancy, but you still have L2 redundant connection between access layer and distribution, so STP is necessary to provide loop free L2 network. Yes, loops caused by for example unknown unicast frames are still a real threat even if we have L3 links between dist. switches. Just ask your self what will going to happen if you have communication between hosts on the same broadcast domain? In that case some unknown unicast frame would unnecessary traverse another dist. switch. Or worse: some host on this broadcast domain sends frame with non-existent destination MAC address (it's possible if you have static ARP entries) in which case loop will occur if you don't have STP or some another L2 loop free method.
no, but if you have access switches cross-connected with the distribution switches, that is, each access switch is connected with each of the distribution switches increasing L2 links to 4 - real redundancy, L2 loops are possible, so it could be wise to have STP running. Draw yourself a topology as discussed in this conversation (2x dist and 2x access switches) and try to "send" unknown unicast frame from one of the access layer switches to the host accidentally off-line but connected in the same VLAN and then enjoy "looking" this frame looping around:) Remember, HSRP is L3 redundancy technology... It will not do nothing if you don't need to reach hosts on another IP network or subnet, but STP will handle it instead.
Spanning tree is so simple its invisible when it works, but the more complex models can get out of hand. I'm working with a large campus using the cisco model and it took some figuring to learn how to correctly configure things.
Remember that one of the downstream trunks will not be forwarding(blocked). And if each vlan runs a instance of spanning tree, the common suggested design alternates VLANs across the two possible forwarding trunks.
To make it easy for us to remember...
We assign odd VLANs HSRP priority to RTR1, which means we add a DELAY on RTR2 for that VLAN interface. We make the RTR1 switch the STP root for the VLAN. This means the RTR interface is attached to the STP root. An optimal path.
We assign even VLANs HSRP priority to RTR2, which means we add a DELAY on RTR1 for that VLAN interface. We make the RTR2 switch the STP root for the VLAN.
The DELAY keeps return traffic going to the active HSRP router. If all your HSRP priorities were on a single router I don't think you would have to worry about setting DELAY.
One thing which took some research to find and understand... If you don't follow a three-tier design limit, you also have to worry about STP diameter. The metrics are tuned for a diameter of 7 switch hops from the farthest possible points. This means a max of 4 layers of switches from distribution down. We had a diameter of 11 switches in some places and STP stability was very bad. Have to remember that wireless APs count as a switch/bridge.
You measure the seven hops by rising and falling through the layer 2 switches. Like traversing a family tree. i.e.
THe cisco model documentation never shows more than level 1 access switches, but in reality, you at least end up with level 2. We also had prolems due to chains of switches
DISTRIBuTION------ACCESS #1---ACCESS #2---ACCESS #3---ACCESS #4 | | \\_______________________________________________________/ (access #4 loops back to Distribution)
Depending upon how spanning tree sets up this could be a chain of four, two chains of two, one & three. Setting port costs makes the layout predetermined--which is a goal. Nothing should be left to chance or determined by random hardware and port connections.
Last thing that bit us in the ass... PORTFAST not being used. Constantly flushes MAC tables on the switches and increases unicast flooding.
It was a bitch getting all this stuff in order this summer. We went from having 600 spanning tree root change events in 20 days to 2 in the next 60 days. And those two events were legitimate.
No STP needed, no unicast flooding due to HSRP and asymetric routing. Never been there done that however thats the one I like the looks of.
Each VLAN is constrained to only one access switch although each Access switch can support more then one VLAN if trunking or multiple parallel uplinks are used.
WHat you say in text and what you draw is different. By not allowing VLAN trunks to exist beyond the distribs (which means you aren't using VTP) you essentially divide you network into multiple L2s topologies.
For one VLAN you have
and for another VLAN you have this
It is up to you to ensure you never misconfigure any vlan or trunk to allow the diagram you drew to exist. That's why people run STP. One misconfigured trunk or vlan and you've just taken out your network.
Secondly, are you saying you won't be running HSRP? If you run HSRP You still have issues with who talks to which router. If an Access2 device uses a router on DIST1 and an Access1 device uses a router on DIST2 you wil get assymetric routing and promot unicast flooding. DIST1 will know about access1 and DIST2 will know about access 2.
Also if you have hybrid DISTs which many allow devices >No, this is what you want to hear:-)
Since one PPT slide is worth 1000 words, I read "Campus Network Multilayer Architecture and Design Guidelines", which you can find here and probably already know very well:
formatting link
Slide 67 says that with "Layer3 distribution interconnection" you have "no spanning tree" and "all links (are) active". The slide shows what seems a "best case scenario" with VLANs not spanning more than one switch each. There is no mention of STP roots. Note that in the previous slide, showing a Layer2 interconnection, a STP root is explicitly configured.
Slide 87 on the other hand shows what looks the very same configuration, with a "Layer3 distribution interconnection" and VLANs not spanning more than one switch each, but in this case it suggests to do "STP root and HSRP primary tuning".
Well, even Cisco arn't perfect. Clearly a missprint:)
Slide 87 has no need of STP for it to function "as designed".
I think that I read those slides a while back and became a convert:) Bye bye L2 loops, hello wire speed L3:--)))
I agree that it is probably best to leave STP on.
I think that the proposed design will be (almost) free of unicast flooding. The only L2 device in the network that needs to know the mac address of an access-layer connected PC (say) is directly connected to that very PC and therefore will almost always know it's MAC/port relationship.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.