When so much effort and pressure are put on designing and implementing strong technology solutions, in my opinion, it’s easy to neglect having visibility into those solutions once they are implemented. While competent design and implementation are important, having access to insight and analytics into the system once the design is in production is just as important. Having a competent design to reduce issues is ideal, but what do you do when the system is not working properly or someone is accusing the system of not functioning properly? Visibility and analytics are important for many reasons, but to me, a big one is troubleshooting. I want to be able to help people resolve issues in the quickest way possible and if I have that deep visibility at the ready, there is a better chance that I can do just that. A more selfish way to put it is “mean time to innocence”. How do I quickly prove or disprove that an issue is my fault so that I can move onto the next task or project? Having visibility, analytics, insight, evidence, etc is key. Whether the system you are designing and implementing has built-in visibility, there is a product out there that can provide that visibility, or you can develop a home-grown solution, leveraging that insight is important. Once the design/solution has been implemented, someone has to support it, and having proper tools can help greatly.
[Factinion Definition: A combination of facts (or at least statements that I believe to be facts) along with my opinions (with which you may agree or disagree).
Background: I am currently on the new CCNP track. One topic that is covered in my studies is Multiple Spanning Tree Protocol. MSTP is something that I’ve seen in the CLI, but never delved into until now. In this post, I’ll go over my understanding of the protocol as well as deliver my opinion. This post can be seen as “high level” and not getting in depth into the protocol in question. I encourage you to comment with your thoughts and to let me know where I got it wrong.
The Need for MSTP: Rapid Per VLAN Spanning Tree (PVST+) gives us the ability to maintain a separate Spanning Tree instance for each VLAN in our environment. In a traditional Layer 2 topology where we have multiple access layer switches that are dual connected to diverse distribution layer switches, leveraging PVST+ allows us to “load balance” VLANs to either distribution layer switch #1 or #2 by alternating forwarding and blocking ports on the different access layer switches. One thought is to have all odd numbered VLANs actively forward to distribution layer switch #1 and all even numbered VLANs actively forward to distribution switch #2. While this practice is valid, it may not scale well. A separate Spanning Tree is maintained for each VLAN and separate BPDUs need to be generated and processed for each VLAN. That could become resource intensive for switches as “many” VLANs are added to the topology. Enter MSTP as a scalability option.
My Understanding of MSTP: MSTP builds off of the PVST+ protocol. We can still achieve the load balancing goal explained above, while minimizing the number of Spanning Tree instances. For example, let’s say we have 20 VLANs in our topology. With PVST+, we would have 20 instances of Spanning Tree running. If we wanted to load balance VLANs across the two distribution switches, we could leverage MSTP and cut the number of instances down to 2. MSTP allows us to group multiple VLANs into a single instance. Building off of our load balancing example, we could have odd numbered VLANs in instance #1 (with distribution switch #1 as the root bridge) and even numbered VLANs in instance #2 (with distribution switch #2 as the root bridge). Any VLANs not specified to a given instance would automatically be joined to the Internal Spanning Tree instance (instance 0).
My Opinion: While I see the place and benefit for MSTP, it also adds a level of complexity that needs to be considered. Certain parameters need to match across switches in the topology, and because of this I can see where it could become difficult to manage and troubleshoot. On another note, outside of the individual Spanning Tree modes, I can see STP altogether becoming less relevant. With Software Defined everything, overlays are bridging the Layer 2 gap over end to end Layer 3 networks. Large native Layer 2 domains can become very complex and difficult to troubleshoot. While STP does its job well, if Layer 3 can be taken as far to the edge as possible, minimizing STP domains and calculations, that makes sense to me to do so. However, if Layer 2 from the distribution layer to the access layer is necessary, there are Cisco technologies such as Virtual Switching System (VSS) and StackWise Virtual in the Catalyst line, and virtual PortChannel (vPC) in the Nexus line to make that more efficient. With these technologies, the physically diverse distribution switches can be paired together to appear as a single logical switch to the access layer.
One of the post styles that I will probably frequent will be titled beginning with the phrase “Factinion”. These posts will be a combination of facts (or at least statements that I believe to be facts) along with my opinions (with which you may agree or disagree). I hope you enjoy.
I am completely new to WordPress and blogging and have no idea what I’m doing. I was inspired by a few in the worldwide network infrastructure community to start a blog to share my thoughts and spark conversation. Hopefully, it will be interesting to look back on this post in the near future and see how I’ve progressed.