How To Set Spanning Tree Priority
Allow me start past saying that spanning tree is a Good Affair. Information technology saves you from loops, which volition completely close down a network. But it has to be configured properly to work properly. I can't count the number of times I've had a client call me, desperate with a terribly broken network, and I've responded, "Sounds like a spanning tree trouble."
There are many ways things can go incorrect with spanning tree. In this article I've collected a few of the recurring themes.
As I said, spanning tree is a good thing. But for some reason, a lot of switch vendors disable it by default. So out of the box, you might have to enable the protocol.
Sometimes people deliberately disable spanning tree. The well-nigh mutual reason for disabling spanning tree is that the original 802.1D Spanning Tree Protocol (STP) goes through a adequately lengthy look menstruum from the time a port becomes electrically active to when it starts to pass traffic. This expect flow, typically 45 seconds, is long enough that DHCP tin give upwards trying to get an IP accost for this new device.
One solution to the problem is to just disable spanning tree on the switch. This is the incorrect solution.
The right solution is to configure a feature called PortFast on Cisco switches. (Most switch vendors have a similar feature.) Y'all configure the command "spanning-tree portfast" on all the ports connecting to cease devices like workstations. They then automatically bypass the wait period and DHCP works properly.
Information technology's important to only configure this command on ports that connect to finish devices though. Ports connecting to other switches demand to exchange spanning tree information.
As the proper noun suggests, spanning tree resolves loops in your network past creating a logical tree construction between the switches. Ane switch becomes the root of the tree, and is called the root bridge. All other switches and then figure out the all-time path to get to the root bridge.
If there are multiple paths, then on each switch, spanning tree selects the best path and puts all the other ports into a blocking country. In this way, there's a single path between any ii devices on the network, although it might be rather circuitous.
Every switch taking part in spanning tree has a span priority. The switch with the everyman priority becomes the root bridge. If there'south a tie, then the switch with the lowest bridge ID number wins. The ID number is typically derived from a MAC accost on the switch.
The problem is that, past default, every switch has the same priority value (32768). And so if y'all don't manually configure a better (lower) bridge priority value on a particular switch, the network will simply select a root for you. Then Murphy's Law applies. The resulting root span could exist some tiny edge switch with slow uplinks and limited backplane resource.
To make matters worse, a bad choice of root bridge can make the network less stable. If at that place's a connectivity problem that takes any random switch off the network, spanning tree heals rather apace. But if the root bridge goes downwards, or if the failure ways that some switches no longer have a path to the root bridge, this constitutes a major topology change. A new root bridge needs to be selected. The entire network will freeze during this time and no packets can be forwarded.
I always recommend making the core switch the root span. I also similar to select a backup root bridge. If at that place are dual redundant cadre switches, so one is the root bridge and the other becomes my backup.
Set the span priority on the primary root span to the all-time possible value—4096—and the backup root bridge to the adjacent all-time value—8192. Why these funny numbers? Well, that'southward a longer story that we don't have space for hither, but the lower order bits in the priority field have some other purpose, and then they aren't available for apply every bit priorities.
Spanning tree saves y'all from loops / Photo: darkday on Flickr
The first open standard for spanning tree is chosen 802.1D. Information technology's one of the earliest standards in the IEEE 802 series of standards that includes the specifications for every blazon of Ethernet and Wi-Fi likewise equally a bunch of other protocols. Information technology works well despite its age, and you'll find this blazon of spanning tree on just nearly every switch. Any switch that doesn't support 802.1D is just useful in small isolated environments, and should never be connected to whatsoever other switches.
Just there take been several important advancements to spanning tree since 802.1D. These improvements allow sub-second convergence post-obit a link failure, as well equally the ability to calibration to larger networks and the power to actually take different spanning tree topologies and different root bridges for different VLANs. And so it makes a whole lot of sense to use them.
Almost modern Cisco switches default to a protocol called Per-VLAN RSTP. This stands for Rapid Spanning Tree Protocol. It automatically operates a separate spanning tree domain with a divide root span on every VLAN. In practice, it's mutual to make the same switch the root span on all or almost of the VLANs, though.
The rapid feature or RSTP is what yous'll probably find most useful. This allows the network to recover from virtually failures in times on the club of 1 to ii seconds. Multiple Instance Spanning Tree, or MST, is similar to RSTP. The principal difference is that you can designate groups of VLANs that are all part of the same tree structure with a single mutual root bridge. Still, I recommend using Per-VLAN RSTP in near cases because information technology's easier to configure. Also, I've encountered some interoperabilty problems with MSTP between different switch vendors.
It should be pretty articulate from the descriptions of 802.1D, RSTP, and MST in the previous section that mixing them could go messy. The RSTP and MST protocols accept rules for how to deal with this mixing, and in general it involves creating separate zones within the network for groups of switches running different flavours of spanning tree. This rarely results in the most efficient paths being selected between devices.
The only really valid reason to mix spanning tree types is to allow the inclusion of legacy equipment that doesn't support the more mod protocols. Every bit time goes past, in that location should be fewer and fewer of these legacy devices, and the number of places where it makes sense to mix the protocols should becomes smaller.
I recommend picking one, preferably RSTP or MST, and just using that in a consequent style beyond all of your switches.
Because MST allows a unmarried spanning tree structure that supports multiple VLANs, you need to be extremely conscientious about your inter-switch trunks.
I once had a client with a big complicated network involving many switches and many VLANs. They were running MST. For simplicity, they had designated a single MST instance, meaning that all VLANs were controlled past the aforementioned root bridge.
The problem for this customer arose when they decided that sure VLANs should only exist on certain switches for security reasons. All perfectly reasonable. So they removed the VLAN from the principal inter-switch trunks, and added new special trunks merely for these secure VLANs. And everything broke.
MST considered all VLANs to be part of the same tree, and it selected which trunks to block and which to forward based on that assumption. Simply in this instance, because some VLANs were only present on some trunks and other VLANs were present on the other trunks, blocking a trunk meant simply passing some of the VLANs. Blocking the other trunk meant merely passing the other set of VLANs. For the blocked VLANs in that location was but no path to the root bridge at all.
And then, if yous're going to utilise MST, you lot need to either ensure that all VLANs are passed on all trunks, or you demand to carefully and manually create different MST instances for each group of VLANs with special topological requirements. In other words, y'all have to do careful analysis and pattern the network properly. Or yous could take the easy manner out and run Per-VLAN RSTP.
Another common topological problem with spanning tree networks involves the style that Layer ii and iii redundancy mechanisms sometimes interact.
Suppose I accept a network core consisting of two Layer 3 switches. On each segment I want these cadre switches to act as redundant default gateways. And I want to connect all of the downstream switches redundantly to both core switches and make spanning tree remove the loops.
In this scenario, the spanning tree root span for a particular VLAN might exist on 1 of these cadre switches and HSRP/VRRP master default gateway on the other switch. And so an Ethernet frame originating on one of the downstream switches destined to the default gateway volition need to take an actress hop, going first to the root bridge, and then to the secondary cadre switch that currently owns the default gateway IP.
Usually this isn't a problem, simply imagine that I'm passing packets betwixt two VLANs, both with Cadre Switch A as the root span and Core Switch B every bit the default gateway. Every package must go up to Cadre Switch A, and cantankerous the backbone link to go routed on Cadre Switch B.
Then it has to cross the backbone link once again to get back to Core Switch A to be delivered to its destination. All of the return packets must also cross the backbone link twice. This creates a massive traffic burden on the backbone link where every packet in both directions must cross twice. It also incurs a latency penalty as every packet needs to be serialized and transmitted twice. Even on 10Gbps links, this will typically price a couple of microseconds in both directions, which could add upward for especially sensitive applications.
Suppose instead that the default gateway was on the same switch as the root bridge. Now the packet goes upwardly to the root bridge, Cadre Switch A, and gets routed between the VLANs and immediately switched out to the downstream device. It doesn't cross the backbone at all in either management.
Spanning tree is a terrifically important protocol. Information technology allows us to build redundancy into inter-switch connections. It saves us from catastrophic loops when somebody accidentally connects things they shouldn't.
It'south truthful spanning tree tin can exist misconfigured with bad consequences, just this possibility shouldn't discourage you from using it. The solution is to be careful and deliberate about your network design.
How To Set Spanning Tree Priority,
Source: https://www.auvik.com/franklyit/blog/spanning-tree-mistakes/
Posted by: snydercalkin.blogspot.com
0 Response to "How To Set Spanning Tree Priority"
Post a Comment