ICND2 200-105

ICND2 200-105

Cisco Per VLAN Spanning Tree Plus

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.

PVST+ Load Balancing

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-tree


VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    16385
             Address     aabb.cc00.0100
             Cost        100
             Port        1 (Ethernet0/0)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec


  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     aabb.cc00.0300
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec


Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0               Root FWD 100       128.1    Shr
Et0/1               Altn BLK 100       128.2    Shr


VLAN0010
  Spanning tree enabled protocol ieee
  Root ID    Priority    32778
             Address     aabb.cc00.0100
             Cost        100
             Port        1 (Ethernet0/0)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec


  Bridge ID  Priority    32778  (priority 32768 sys-id-ext 10)
             Address     aabb.cc00.0300
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec


Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0               Root FWD 100       128.1    Shr
Et0/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.

Root Bridge config example

SWA#sh spanning-tree
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    28673
             Address     aabb.cc00.0200
             Cost        100
             Port        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 1
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    24577
             Address     aabb.cc00.0100
             This bridge is the root
             Hello 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.