Spanning-tree priority – Why it should be your priority

Spanning-tree is the red headed step child of networking and I firmly believe it is not spanning-trees fault, I blame ignorance of the engineer. Spanning-tree is a tool and like any tool it is typically designed with a specific purpose; however, like most tools in life, you can apply the tool against something else not intended to get desired results. The ignorance people have for spanning-tree causes a lot of issues on networks I have had to resolve in the past and they were relatively easy to resolve. I will explain the single most forgotten configuration parameter: bridge priority:

When you’re in an environment that is all ONE vendor you typically can rest assure all bridge priorities are the same (Cisco is 32768 and Foundry is 4096, sometimes even 0!). This is a luxury in my opinion because most networks evolve and this could include implementing switches from another vendor. When I worked for a VAR in Virginia I had two issues the owner of the company himself couldn’t resolve and when the issue finally was brought to my attention I dug into the network (mostly of unmanaged switches). A careful wireshark showed a cheesy netgear switch sending BPDUs with a bridge priority of 8192 and the lone Cisco switch out there was default 32768, once again, showing up on a wireshark. After setting the Cisco to bridge priority 4096 the network returned to normal operation and everyone was happy. Once again, this issue happened at a Dentist office with a Dell unmanaged 8 port switch sending BPDUs with priority 8192 and setting the Dell Managed switch to 4096 resolved the issues. The “engineers” who went on site to try and fix the issue didn’t understand networking’s basic principles of operation on an Ethernet network, with or without redundant links. On average, at both sides, over 100 man hours were spent chasing BS problems and it took me 30 minutes to resolve each issue; thus, a high level of understanding about spanning-tree was required to debug the network, especially when unmanaged switches are involved. **Yes, I know I could have went to the Cisco switch at the first location but I didn’t have credentials for it at that time and they pulled the Dell switch at the Dentist office because they believed it “didn’t work”.**

Spanning-tree can be a tool used to take advantage of active/passive High availability protocols like VRRP. I wont’ go into detail but for each VRRP master you set the bridge priority low enough to be elected root bridge per VLAN and across different links; thus, if you 10 VLANs, 5 can be the VRRP master and STP root bridge and the other device can be the VRRP master of the other VLANs and the STP root bridge of those 5 VLANs while the other sits as the passive VRRP slave and the STP value can be low enough that STP can designate the links for those VLANs to that box as Alternet/Backup links.

Never dismiss the power of spanning-tree; however, in today’s designs you’re better off having “Virtual Chassis” configurations and creating aggregate ports to utilize the full bandwidth potential of all links while also have the redundancy of a virtual chassis.