This is how to visualize a real-world topology, and that is to say we want to customize spanning tree. We want to anchor our virtual LANs, or VLANs, and spanning tree at the distribution layer. Job number one, got to have your roots in the distribution layer, which is up top. Switches A and B would probably be multilayer switches, I know. It's a layer 2 switch icon here, but they're probably going to be multilayer switches, higher capacity, and better topologically positioned. That's step one. But then all things being equal, even though we do have Per VLAN Spanning Tree, the numbers still are the same by default for all of your switches. So if I'm the root bridge for VLAN 1, I'm likely to be the root bridge for VLAN 2 if no one has altered anything and that's something we have to change. In a real-world environment, what we do is we trade-off, so we spread it out, okay, instead of anchoring all of the VLANs on one of your distribution layer switches, stretch it, spread the load, and what this is going to do is this is going to change your forwarding ports.
This is, in fact, per-VLAN load balancing. So we can't load balance on a per-frame basis here within a VLAN. So we don't have a technology right on screen to do that, but what we can do is we can say, you know what, I got Switch C, it's got two ways to get to the distribution layer. I don't want to use just one link, I want to use both. See that's the benefit here. Let's say those are gigabit connections from Switch C to A and B. By default you'd only have one gigabit link working because the other gigabit link would be blocked for all VLANs, which is essentially unused. Hey let's give it, essentially, 2 Gb worth of bandwidth. Do you now see the benefit to this? By us manipulating the root bridge for Spanning-Tree Protocol, we anchor different roots in different places, anchor different VLANs with a different reference point, and move our forwarding ports around on a per-VLAN basis. That's the benefit here.
So folks, did you pick up on what we were referring to here? We are not blocking on a physical-by-physical port basis. No we're not. What are we really blocking on here? We're blocking on a per-VLAN basis within each port. That's huge! Understanding that will help you with your spanning-tree operation and the topology when you're dealing with multiple VLANs. Look at the great traffic flow here, VLAN 1, VLAN 2, is this load balancing? Yes it is. But we need to keep track of these VLANs. If we are stating that one spanning-tree instance is this way and another spanning-tree instance is that way, how do we do this? We need to keep a track of it.
Modifying the bridge ID
So we have all these Bridge Protocol Data Units, or BPDUs, floating around now. BPDUs emanate from the root for each VLAN. So now I want you to think about the challenge that exists for engineers within a chassis. BPDUs are going to be coming in every which way potentially, they have to plan for that, and they are coming in every which way for multiple different VLANs. So we need to make sure that we know what VLANs these BPDUs were part of. Now let's go back in time, back when Radia Perlman envisioned this. Our bridge ID was very similar to what we see here, a priority and a Media Access Control, or MAC, address component. We keep the spirit of that alive, but that's only going to give us Common Spanning Tree, or CST, if we use that. Common Spanning Tree used bridge priority and MAC address. That was that CST that we saw when we began this discussion of the different versions of spanning tree out there. Instead what we do is this, for all the modern current versions of spanning tree, we redefine the first 16 bits a little bit differently. Our priority is the high-order 4 bits, and the VLAN is tucked away embedded in the low-order 12 bits. Now do you remember the VLAN range that is possible on a trunk? Do you remember what it is? Do you remember it's like 4,094 specifically? Well what is 4,096? It's the power of 2, right? 4,096 is 2^12. It takes 12 bits to represent up to 4,095. And so what they did is they said, you know what, I know this is a 12-bit space, I'm going to redefine the lower order 12 bits to be the VLAN unique identifier, or ID. This is called the extended system ID or the extended bridge ID and you can see this in the show command output.
SwitchC#sh spanning-treeVLAN0001Spanning tree enabled protocol ieeeRoot ID Priority 16385Address aabb.cc00.0100Cost 100Port 1 (Ethernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32769 (priority 32768 sys-id-ext 1)Address aabb.cc00.0300Hello Time 2 sec Max Age 20 sec Forward Delay 15 secAging Time 300 secInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Et0/0 Root FWD 100 128.1 ShrEt0/1 Altn BLK 100 128.2 ShrVLAN0010Spanning tree enabled protocol ieeeRoot ID Priority 32778Address aabb.cc00.0100Cost 100Port 1 (Ethernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32778 (priority 32768 sys-id-ext 10)Address aabb.cc00.0300Hello Time 2 sec Max Age 20 sec Forward Delay 15 secAging Time 300 secInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Et0/0 Root FWD 100 128.1 ShrEt0/1 Altn BLK 100 128.2 Shr
We have to say it because we don't want you to be confused that you are not able to touch the bridge priority bits that are 5 through 16. We can only manipulate the priority that manipulates the first 4 bits, which means our priority is going to hop by a significance of 4,096.
If we were to twiddle that last bit of the bridge priority of the 4-bit portion, that's 4,096. So that's where we get to count. That's where we get to step our priorities. So back when I started in Cisco, we did use to set any different priority, you could. It's not the case anymore. You can only affect those 4 bits and so when you do choose to change this on a switch, it will bark at you. You can only do increments of 4,096, and so our show command will show that and it helps tremendously for the engineers to know, hey, this BPDU, I know exactly what VLAN it is for, so I can just look at the lower order 12 bits.
Let's create a scenario here. We've just plugged all the switches together. We are running Per VLAN Spanning Tree Plus and a switch in the upper right, Switch B is the root bridge for all VLANs, all of them. We want to change it so that way the Switch A becomes the root bridge for VLAN 1. How do we accomplish this? There are two different ways we can do this. We can explicitly set the priority of that switch to be less than all the other switches forcing it to be the root bridge for that VLAN or we can use a macro, a script, spanning-tree, specify the VLAN, vlan 1, say root and then primary. What does it do? Well first and foremost, the switch, in this example Switch A, looks at the current priority for the root bridge and determines what it is. Is it currently the default value? If it is, we will lower our priority to 24,000 and some change. I believe it is 24,577 by default.
If it's not the default priority, then what we will do is we will lower our priority to 4,096 less than the priority that is currently being used by the root bridge, making us the root bridge. So let's look at the top output here, first of Switch A. The root bridge Priority is 28673 for VLAN 1. We typed in spanning-tree vlan 1 root primary on Switch A forcing us to make ourselves the root bridge. If you look down below at the output after that for show spanning-tree vlan 1, we can see we are now the root bridge. It explicitly says that. This bridge is the root and the Priority is 24577. My math is right here, that is 4,096 less than the original value of that root bridge.
SWA#sh spanning-treeVLAN0001Spanning tree enabled protocol ieeeRoot ID Priority 28673Address aabb.cc00.0200Cost 100Port 1 (Ethernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
SWA(config)#spanning-tree vlan 1 root primary
SWA#sh spanning-tree vlan 1VLAN0001Spanning tree enabled protocol ieeeRoot ID Priority 24577Address aabb.cc00.0100This bridge is the rootHello Time 2 sec Max Age 20 sec Forward Delay 15 sec
We do want to be mindful of the fact that we don't want Switch C to be the root of the topology even if Switch A goes down. So we're going to want Switch B to be root secondary for VLAN 1. Let's trade-off that role and responsibility. So root secondary says I want to back myself off one notch to be next in line for root bridge functionality should the primary fail.
Now be mindful about this command. When you type it in, it does not say I am always the root bridge, you can never take it away from me. No. It's just trying to find the specific priority value that would make it the root bridge. If we go to another switch and we type in spanning-tree vlan 1 root primary, it will go through the same process and become the root bridge. So this is not a permanent command that states I'm always the root bridge, somebody could still take over the root bridge process if that command is typed in somewhere else.
Analyzing the STP topology
How do we analyze our spanning-tree topology? That is a really critical skill that we want you to pick up here. Well you have to have a good map. You have to have a good topological map. If you're trying to do this based on show output without a topological map, good luck to you. Once we have that topological map, maybe built with Cisco Discovery Protocol, or CDP, we can look at spanning tree. Spanning tree is going to show us when we do show spanning-tree vlan 1 or vlan 2 or maybe we will just do show spanning-tree, which lists spanning tree for all VLANs. It's going to show us our root bridge. Is it us? Is it something else? It's going to show us timers, but more importantly, it's going to show us root ports and designated ports and that is what we taught you how to analyze. Here is a short reference of the most used commands when we are analyzing the STP topology:
- show cdp neighbors
- show spanning-tree
- show spanning-tree vlan
So there is the possibility that we look at all this stuff and it doesn't make sense to us, because maybe we have a rogue root bridge that came in below Switch C, someone trying to take over our root. Maybe we injected a new switch out of the box that had a better bridge ID because we never manipulated our distribution layer. It is possible that a low-end switch that was built 15 years ago is going to have the best default bridge ID. So we have to make sure that our root bridge is what we expect and our topological paths are also what we expect. Usually though when we control a root bridge, everything works out very well. It's when we don't control our root bridge, where the problems can ensue.