ICND2 200-105

# Troubleshoot spanning tree protocol

We just completed a really simple example. Two switches, two segments, but topologies are usually not that simple. Four switches, this is your chance to practice using your knowledge now of what we just discussed, going through it step by step. So folks, take this opportunity, elect your root bridge here. Remember, it's based on the lowest bridge ID, or BID. Figure out which switch will be our root bridge, and then continue reading.

All right, electing the root bridge, lowest bridge ID. What two components make up our bridge ID? The BID is going to consist of the priority, which is 16 bits, then a Media Access Control, or MAC, address, which is 48 bits. We'll look at the priority first. And in this case, it looks like we have some default priorities in C and D, 32768, and some slightly lowered priorities on switches A and B, but I see a tie of the two distribution layer switches. I would think that those are distribution layer switches up top, access switches down below, okay. And so I have to dig deeper. I have to go to the next component of the BID, which is the MAC address, and there I'm going to be looking for the lower MAC address. I find it and I find the lowest on Switch B and that is what makes it the root bridge.

How do we read our MAC address? Left to right. Just comparing it hexadecimal value by hexadecimal value. First six values, 0s with a c. Then I see a and 9. Which is lower, a or 9 in hexadecimal? 9, Switch B is our root bridge.

We're going through that same methodology that we took you on earlier, and now we've got a key step. This is what is going to separate you, is your moving into the harder steps. Finding the root bridge, that's great, but it doesn't really do anything for you if you don't know the other steps of figuring out your root ports and your designated ports, so here we're at that step. Find your root ports. Now let me give you a hint. That is, we should have one for each nonroot. So how many do we need? How many nonroot switches do we have, which set the number of root ports you should find in this topology? So find those root ports, this is extremely important.

Were you able to find the root ports? If not, that's all right. Practicing and reviewing will help you. Let's go through it together. Which ports will be the root ports? The ones on the nonroot bridges, so switches A, C, and D, which have the lowest cost back to that root bridge. We can see the cost values here. Let's start with Switch A. If I choose the port that goes down to Switch C and then up to Switch B, I have a total cost of 8. If I choose the one that does to D and then back up to B, 8. But if I choose the directly connected segment, that's a cost of 2. That's lower than all the other paths I could have used. So Switch A, the port directly connected to Switch B, that's our root port. If we look at Switch C, some quick math shows that if we go directly to Switch B, cost of 4. But if we go the other way around, it has a higher cost of 6. And in Switch D, the same scenario, cost of 4 on that segment directly connected to Switch B and the cost of 6 taking the long way. So Switch D and Switch C, both the root ports will be the ports that are directly connected to Switch B. It's time to move on to the next operational step.

This is the last of the really tough parts of spanning-tree topology analysis, finding your designated ports. How many designated ports do we need here? You can't analyze the topology successfully if you can't answer that question. So I'm going to ask it again - how many designated ports does this topology need? Take the time.

Let's think back to our earlier discussion. The designated port, we will find one for each and every single segment. So the question was how many designated ports will we have to find. You notice, how we are predetermining always with the Spanning-Tree Protocol? We can figure out how many root ports we need ahead of time and designated ports, then when we do the calculations and we do the procedure, it is easier for us to verify our work. There is no guessing here. It is exact. So, if we count the number of segments, how many do we have?

It's the number of links, it's also the same as collision domains. It's five, it's five. Two from each access layer switch to the distribution layer and the link between the two distribution layer switches, switches A and B, up top. So now we know we need five designated ports and you are tasked with determining which ones those are.

So take a moment and pick the correct designated ports. All right, when we are determining the root ports, we put ourselves on the switch, jump on it, point out those interfaces, but when it comes to the designated ports, where do we put ourselves?

So let's recall here. We originally said, five segments, five designated ports, have we found them all? We have, each and every single one of them. So we found the root bridge, we found the root ports, we found the designated ports, are there any ports left here that don't have a label? I see two of them, the port on Switch C that points to Switch A and the port on Switch D that points to Switch A. So what are they? Let's look at that.

These are the ports that will be blocked. This ensures we don't have a loop. And you can see from this topology, how we could have multiple loops here, many different types. I can see two different triangle loops. I can see a figure eight loop. There are really a lot of different types of loops we can have, so if you're surprised that we had to block two ports in this topology, don't be. We had to make sure that no loop would form at all. So now we have these root ports and designated ports that are in the forwarding state, and we have these nondesignated ports that are in the blocking stage.

Spanning tree has done its work for us. It has blocked the loops, but more importantly, we have gone over the discussion that is so critical for you, folks. And that is spanning-tree topology analysis, this is something you need to have down, okay. So go through it, practice it, and get confident with figuring out your root ports, designated ports, and your blocking ports.

So far, the examples we've explored have been relatively simple. And I mean simple because when we needed to figure out the root ports or the designated ports, we looked specifically at cost and nothing else. Now why do I say nothing else? Well remember, how we said earlier, Spanning-Tree Protocol, lower is better and ties are unacceptable? What if our cost is tied? Did that ever occur to you? What happens if there is a tie with cost? We need a tiebreaker. The first tiebreaker is to look at the upstream bridge ID, and whichever bridge ID is lower is the path we will use. What if the upstream bridge ID is tied? Now wait a second. Is it possible for the upstream bridge ID to be tied? What is the bridge ID? A combination of priority? Well that could be tied and a MAC address. Is it possible for a MAC address to be tied?

It is if you're going to the same switch, two links go into the same switch because the MAC address is not the port we connect up to, it's a reference MAC address, it's the first on the chassis. And so that's always going to be part of the BID for that switch, the bridge ID always uses that one MAC address regardless of which port you're connecting up to. So in this case, we would see the same bridge ID necessarily coming from the upstream switch.

So it can be tied, that bridge ID. Lower is better, ties are unacceptable. Therefore, we need a tiebreaker now again. And that tiebreaker is the port unique identifier, or ID, value from the switch that is sending the Bridge Protocol Data Units, or BPDUs. So it's our upstream neighbour and when they send that BPDU, there is a port ID in that BPDU. We will compare them and we will determine based on the lower port ID where there will be root port or a designated port. Let's do an example together here.

In this example, we have Switch A, Switch B, we have multiple links going between them. So focus on step 2, and what do we want to do? We want to identify our root bridge. Who is going to be the root bridge, in this case, based on our bridge ID, priority, MAC address? Switch A is our root bridge, so Switch B is our nonroot bridge.

So we found our root bridge. Let's move on, and what was the second step in our process? Remember, four steps, first find the root bridge, then find the root ports, we've done this. This is a slightly different topology, right? So therefore, we're going to still be challenged. So step 4, determine the root ports. How many root bridges do we have? One. We find ourselves trying to find the root port on Switch B, put yourself on Switch B, which is better. Okay, this is kind of a nasty one. Let's say they are the same speed. Let's move to step 5, same speed resulting in the same cost. Certainly, the same upstream bridge ID, so we don't find a lower value to use there. Let's move to step 6 for a moment, okay. We're going to look at port ID. If you remember from above - sending port ID, so we do keep that in the BPDU, it is communicated, Switch B does see something lower. We're always trying to find something lower, space abhors a vacuum, spanning tree abhors a tie and here, Switch B finds a lower sending port ID. Seems kind of silly, but 1 is lower than 2, Fa0/1 is lower than Fa0/2. And it's not Switch B's ports, it's Switch A's ports. Those are what decide that.

When Switch A sends out its BPDUs, it's going to send out one on FastEthernet 0/1 and one on FastEthernet 0/2. And in this BPDU, it will state port ID. If there is a value we can manipulate, it's the first value. The default is 128. You can change that, but then there is a dot, dot something, .1, .2, .3, .4, whatever it is. And that is determined by the switch and we're not allowed to change that value, so by default it is 128.something. FastEthernet 0/1 usually receives 128.1 and FastEthernet 0/2 usually receives 128.2, so those BPDUs are sent out from Switch A and they arrive at Switch B. Switch B receives the one that says 128.1 and the one that says 128.2, which is better, which is better? Lower is better, so 128.1 is better and as a result, that's the path we would take, that's the preferred path. So focus on step 7 now. Switch B, FastEthernet 0/1 interface, that's the preferred path back to Switch A.

So we found a key port there, which was the root port and that was our biggest challenge. Now we can move on, something not tremendously exciting, finding designated ports. Remember, how we find designated ports? One per segment, we have two because we have got two links and the designated ports, we're going to see this in step 9. It's just the ports that are on the root bridge, nothing new, nothing super challenging there. We didn't have to look at port IDs. We are still using cost. It's got a very low cost because it is going right up there to the root bridge, but then remember what we're doing. We're trying to shed away all the ports that we don't want. And the ports that we shed from the forwarding portion of the topology are those that do not have root port designation or designated port designation, so are there any ports remaining? Step 10 answers that question and we know now that there is one, Fa0/2 on Switch B.

We never block a port on the root bridge. We knew we had a blocked port, so we knew it had to be somewhere on Switch B and we could've guesstimated that and now we can. We can just say, you know what, I know that if I have two links in common between two switches, that the link that has the higher port ID from the sending bridge is going to be the blocked port, and we can see that here in step 11. We block Fa0/2 and so we know now that we could cable two switches together, but Spanning-Tree Protocol hits us with a mallet and it says, you know what, you can't have your cake and eat it too, you can't add extra throughput to these two switches. That might have been why we did it. We might have wanted the redundancy, but we might have done it for throughput except one Fast Ethernet link is not cutting the mustard, so I want to make this a 200 Mb link. But we can see very definitively, spanning-tree doesn't want to give us extra bandwidth.