In terms of spanning tree design guidelines always enable spanning tree even if you do not yet have redundant paths. The reason is if later on you add redundancy to your network you do not need to come and configure spanning tree on all of these switches. Also it is possible for somebody to make a mistake and plug a loop into the same switch and plug a port, a cable from one port to another part of the same switch. And without spanning tree the switch will not be able to detect that. Secondly always plan and set bridge priorities. You should always be sure which bridge is going to be the root bridge. Make that trace deterministic and try to include an alternative root bridge if you have the hardware, if possible, if the switch supports it. Do not accept BPDUs on end user ports. This way you do not want something that can potentially become the root bridge showing up on an end user port because if somebody plugs in a switch with a priority of zero and it has a lower mark address it could become the root bridge. So this is an example strategy of how you could pick bridge priorities. One thing about spanning tree is the bridge priorities are not arbitrary, they are all multiples of 4096 or 4k. "k" being 1024 bits and they're set inside the standards and because of the size of the field you can only have 32k as the largest one or 3768 as the largest possible bridge priority. These suggested bridge priorities follow our design our suggested design of a compass network where you root at the core and you switch at each of the buildings so your core switch will have a priority of zero if you have a redundant core switch that would have for 0.96 and we continue through with this same strategy um including redundancy where possible so your building distribution switch would be one uh two two two eight to eight or 12 k your redundant one would be 16k then for your access switch they will typically have 24576 or 24k if you have a daisy chained access switch which we strongly recommend you do not but sometimes you cannot avoid it then you would have the 28k applied to it and then 32k would be the default so anything which is not configured would come up as 32k this is an example strategy that we recommend now 802.1d has a problem of convergence speeds moving from a blocking state to a folding state requires certain timers to expire and so it means you can take 30 seconds and this can be very annoying when you're connecting end stations so you plug in something into the port and you have to wait 30 seconds before it can even start doing dhcp so some vendors have added an enhancement which they'll call something similar to port first to reduce this time to a minimum for edge ports but you should never use this feature in switch to switch links because you can quickly create a loop and by the time spanning tree notices that there is a loop it is out of cpu so never enable this on switch to switch links the second problem is topology changes will also typically take 30 seconds too and port first wouldn't help in this case and this can be unacceptable in a production network so to solve the speed of traditional spanning tree rapid spanning tree was designed which is 802.1w it's backwards compatible with 802.1d and provides faster convergence and basically it allows you to configure which ports are edge ports for end users not for the connections to other switches however if it receives a bpdu then it automatically the protocol will automatically change the port from an edge port to a nan edge port we shall cover this in detail in a different presentation multiple spanning tree 802.1s builds on rapid spanning tree and it's backwards compatible with both rapid spanning tree and traditional spanning tree it includes the first convergence or from rstp and it allows you to configure multiple trees with different routes for different groups of vlans and this solves the problem that when a link is put in blocking state that means that that link is not being used so in some cases you might want to instead load balance so you want some vlans to use one link some vlans to use another link however our recommendation is maintaining that configuration is usually not worth the complexity you are likely not limited by the bandwidth on your switching links you're likely limited by the bandwidth towards the internet.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.