STP Puzzle #3 – Answer Part 1, and Part 2 of the Problem

Plain and simple: check out the STP Puzzle 3 problem statement, and predict all the STP details you can. Todays post gives what I think you can (and cannot) figure out from the initial problem statement. It also gives more info, namely STP port costs, so you can figure out the rest of the STP details in this case. Answers are below the fold. Enjoy!

• All STP Puzzles in the blog
• Overview of how to approach these STP puzzles
• Link to the ICND2 book (to learn more STP)

Step 1: Rule Out Switches from Being Root Switch

In the post where I suggest how to attack these problems, I suggest starting by finding the root switch. Everything in the STP topology revolves around the root, so that makes sense. In this puzzle, you can directly rule out S1 and S2, as follows:

• S2 has a root port; only non-root switches have an RP.
• S1 has a higher (worse) Bridge ID (BID) than S3, so S1 would not win the root election.

Working Backwards to Guess the Root Switch

So far, we know that S1 and S2 are not the root, so that S3 and S4 may be the root. However, the problem does not tell us anything about S3 and S4’s BIDs, which is what STP actually uses to choose the root switch. The problem does allow us to infer which is root, but it requires a long look the other information.

In this case, you can rule out another switch as being root by assuming a switch is the root switch, and then looking to see if the other listed details can still be true. This process requires you to think outside the box, and think hard about how STP makes each choice. (That’s actually part of the challenge with these STP puzzles, and where the learning happens.)

So, if you haven’t already, pretend S3 is root, and see if that works given the other details listed in the figure. Then do the same, assuming S4 is root.  Then come back and read the rest of this post.

Working Backwards with S4 as Root

Every root switch becomes the Designated Port (DP) on all its links, because the root will always have the least cost path (cost 0) to the root, and the neighboring switch will not. So, if you assume S4 as root, you can also assume S4’s links are DPs, as shown in Figure 2:

Figure 2 – S4 Assumed to be Root

Now ask, does the figure show any cases of breaking the rules? When you read that, you may wonder what the rules are, so here’s a brief review of some that matter in this case. On a single link between two switches, the STP roles with either be:

• DP on one end, and RP on the other
• DP on one end, and no role (and therefore blocking) on the other

In this case, neither of those rules is broken, so this analysis does not rule out S4 as a possible root.

Working Backwards with S3 as Root

Now repeat the process, assuming S3 as root. Again, S3’s two ports will be the DP on their links, as shown in Figure 3.

Figure 3 – S3 Assumed to be Root

This figure shows that with S3 as root, one of the STP rules has been broken. The S3 to S2 link lists two DPs, which cannot happen with STP. If that one leaves you scratching your head a bit, think back to the more traditional view of STP: the switches elect a root, the non-root switches select a local root port, and the switches on each link select one switch to be the DP on that link. The S3-S2 link cannot have two DPs.

Summary

In conclusion, with the information shown, S3 cannot be root, and S4 can, so S4 must be the root switch (as shown in Figure 2).

The Rest of the Story – a New Problem for Next Time

That’s it for what you can definitely know about STP in this network, with the assumption that the switches may not be using default settings. If you find a way to convince yourself of other details, like the RP of S1 and S3, then feel free to post here, and give some defense of your answer.

To figure out the rest of the story, I need to give you more information about port costs. So, for the next activity, assume that all port costs use default settings. Think about that, complete the list of RPs, DPs, and blocking interfaces, and I’ll post some comments about it for the next blog post.