BCMSN question - Root guard and Uplinkfast

Unanswered Question
May 28th, 2008

Came across this question in my BCMSN studies Link is here:


The question is:

spanning-tree guard root command is configured on interface G0/0 on S2 and S5. Global command spanning-tree uplinkfast has also been configured on both S2 and S5. The link between S4 and S5 fails, Will host A be able to reach host B.

I'm just not sure how the answer is D.

I know that root guard prevents a switch with a superior priority from becoming the root bridge. Root guard is configured on both the Gi0/0 ports of S2 and S5.

Uplink fast helps protect against direct link failures by keeping a backup link in 'standby' and moving it straight to the forwarding state.

So in the question, S5 would have either its link to S4 in blocking or the link to S2. It must be the Gi0/0 link on S5 blocking because if the link to S4 was blocked and it failed nothing would happen as far as STP goes.

So the link between S4 and S5 fails, the Gi0/0 link between S5 and S2 is put into forwarding. If thats the case then this would create a loop between S5, S2, S3 and S6. Root guard shouldn't come into play here since the link between S4 and S5 is now down, S1 can't be configured with a better priority then the root (whatever that is) or there would be no connectivity at all to host B.

So im assuming now that STP would block the link between S5 and S6 making the correct answer D.

Does this rambling of mine seem like correct logic?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
svermill Wed, 05/28/2008 - 08:11

What is answer D?! ;~)

(and is there more to the question or is the above word-for-word? - I see some detail in that drawing that is not really touched upon in the above version of the question...or does this question build upon an earlier scenario that would afford more insight as to what was forwarding, who the root is, etc, before the failure?)

LucaSalvatore_2 Wed, 05/28/2008 - 14:23

ah sorry forgot to put the possible answers in.

a)Yes Traffic can pass from S6 to S3 to S2 to S1 or from switch S6 to S5 to S2 to S1

b)NO traffic will pass from switch S6 to S5 and dead-end at the interface g0/0

c)No Traffic will loop back and forth between switch S5 and S2

d)Yes traffic will pass from S6 to S3 to S2 to S1

e)NO traffic will pass from S6 to S5 and dead end or from S6 to S3 to S2 and dead end.

So yea the correct answer given was D. I would of thought A was correct.

And no there are no other details at all, its a stand alone question, thats whats making it a bit difficult.

svermill Wed, 05/28/2008 - 20:58

OK, I admit that I just spent a fair bit of time staring at this drawing and I'm actually thinking at this point that it doesn't really matter which switch is the root for the purposes of this scenario. When uplinkfast was configured on SW2 and SW5, their priorities would have been automatically raised to 49152 for all VLANs (recall that uplinkfast makes no sense on a root and thus no switch configured with it should be root). So knowing that the root is any switch other than SW2 or SW5, and also knowing that the G0/0 link between those same two switches can't be on the path to the root due to rootguard, an SW4-SW5 link failure would invariably lead to a linear SW6-SW3-SW2-SW1-SW4 topology, regardless of who along it was root, no? So the second path option outlined in answer choice A wouldn't be valid (again, rootguard prevents either switch from having G0/0 on the path towards the root, wherever it may lie). Make sense? I think it does but I promise to look once again when I've had some rest - been a really long day…



LucaSalvatore_2 Wed, 05/28/2008 - 21:31

Thanks for the replies.

Im just not sure what you mean when you said:

"also knowing that the G0/0 link between those same two switches can't be on the path to the root due to rootguard"

I thought that a port configured as a root guard port are always in the Designated state, so does the failure of the SW4-SW5 link mean that superior BPDs are being sent to the root guard ports which puts them into the err-disabled state?


svermill Wed, 05/28/2008 - 23:01

Sorry, my original post was easily four or five times the length of what I ultimately ended up going with. I was touching on too many issues and so chose to shorten it for clarity and in the interest of staying on topic.

Let me throw out the below link just for the sake of discussion:


While interesting and a great reference, the above doesn't really touch upon the rather odd corner case scenario of back-to-back rootguard ports. I personally don't see how it could strictly be the case that a rootguard port would *always* be designated, as you suggest, though. If that were the case, in this topology anyway, wouldn't you have a L2 loop with both SW2 and SW5 forwarding on the G0/0 segment? Designated = forwarding.

OK, let's just jump in and look at two scenarios after the SW4-SW5 link fails and try to think through what happens:

1. The root is either SW1 or SW4. In this case, SW5 will clearly be receiving superior BPDUs on G0/0 via SW2. So that port goes into err-disable and I think we have the linear topology that I earlier described.

2. The root is either SW3 or SW6. SW2 obviously can't get to either of those two via SW1, as the SW4-SW5 link is down (not to mention it just wouldn't make sense unless there were some unequal link speeds or something in the mix). SW2 can't get to either of those via SW5, as to do so would mean that the root would be via a rootguard port, which is unallowable for obvious reasons. So all that we're left with is SW2 having its root port via SW3. Again, I think we wind up with the same linear topology as before.

Now with scenario 2, you can get into some interesting what-if scenarios. But regardless of whether SW2 G0/0 is simply in blocking or if it's in err-disable, it can't be on the path towards the root. It could be forwarding traffic towards the root for hosts on the SW2-SW5 segment, but the question at hand relates to the transit traffic between Host A and Host B.

I think I've covered all the major bases here but my brain really is flagging at this point, so I don't swear by it. I'd have signed off for the night after my last post but I got sidetracked with a printer/WiFi issue that was about to cause my wife to do physical violence on some rather expensive gear...

LucaSalvatore_2 Thu, 05/29/2008 - 15:06

Thanks for the help, i hope your gear survived the night!!

Anyway i have another theory on this topology / question.

Sine uplink fast is configured on SW2 and SW5 their priorities will be 49152.

Now it is unlikely that any other switch has a priority that is worse than 49152, so wouldn't this mean that as soon as either G0/0 port on either SW2 or SW5 receives a superior BPDU that link between them would be put into err-disabled.

This may even occur before the link between SW4 and SW5 fails..

does this make sense?

svermill Thu, 05/29/2008 - 15:43

Yes Luca, everything survived the night (including the household IT mule)!

And yes, I think certainly there exists the possibility that this link will wind up in err-disable even prior to any link failure. I will perhaps lab up back-to-back rootguard ports to see what happens (I certainly have no real-world experience with such a condition!). However, I cannot immediatly reconfigure my lab environment to support such a test.

If, for example, we look at the scenario of SW1 being the root, then SW5 (assuming consistent link speeds throughout) would be receiving identical BPDUs in terms of root path cost via SW2 and SW4. Now normally the default behavior would to simply choose the lowest number port, which would be G0/0. This port cannot lie in the path to the root, so at the very least I think we can assume that it would choose G0/1 instead, which is a non-default behavior. Whether or not it would go into full-blown err-disable I know not; the BPDUs received at G0/0 would not necessarily be , per se.

As I said, you can really start to get into a lot of "what if" type of scenarios with so little information given and such a strange topology. But I think regardless of whether the ultimate result is err-disable or not, if we assume that neither SW2 nor SW5 are root due to uplinkfast, then answer choice A cannot be valid - particularly after an SW4 - SW5 link failure (and possibly before).

I'll post back if I can work this into my lab (but I am limited to four switches in any case, so I cannot fully replicate this topology).



svermill Thu, 05/29/2008 - 21:35

OK, I did manage to set up a very quick four-switch scenario. Imagine if you will just the four switches on the left, SW1, SW2, SW4, & SW5. SW1 is the root. SW5 has two equal-cost paths to same - one via SW2 and one via SW4. G0/1 is forwarding (root is via SW4). G0/0 is alternate/blocking.

Not surprisingly, when I enable rootguard on SW2 G0/0, nothing immediate happens. The port does not go into root-inconsistent and does not block. It is a designated port. See next post (exceeded the maximum character count!):

svermill Thu, 05/29/2008 - 21:36

SW2#sh span inconsistent

Name Interface Inconsistency

-------------------- ------------------------ ------------------

Number of inconsistent ports (segments) in the system : 0

SW2#sh span blocked

Name Blocked Interfaces List

-------------------- ------------------------------------

Number of blocked ports (segments) in the system : 0

The instant that I enable rootguard on SW5 G0/0 (recall that this is our alternate port), it immediately goes into root-inconsistent/blocked. See below (note: wherever you see "FastEthernet0/1," just substitute in G0/0 in your head - I only have one gig port per switch and didn't use any of them as part of this test):

SW5#conf t

Enter configuration commands, one per line. End with CNTL/Z.

SW5(config)#int fa0/1

SW5(config-if)#span guard root


*Mar 1 01:18:01.841: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Fast


*Mar 1 01:18:01.983: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/1 on VLAN0001.


SW5(config-if)#do sh span inconsistent

Name Interface Inconsistency

-------------------- ------------------------ ------------------

VLAN0001 FastEthernet0/1 Root Inconsistent

Number of inconsistent ports (segments) in the system : 1

SW4(config-if)#do sh span blocked

Name Blocked Interfaces List

-------------------- ------------------------------------

VLAN0001 Fa0/1

Number of blocked ports (segments) in the system : 1

So a couple of important things to be noted here before we move on:

1. Wherever you or I said "err-disable" in the earlier discussions, we weren't being very precise. The "root-inconsistent" state is not an err-disable condition.

2. In an earlier comment I skipped a step in STP tie-breaking. I said a switch would simply choose the local lower-numbered port. True if it has multiple connections to the same switch along the root path. But the first tie breaker is lowest bridge-id, as we all well know! Oops. Well, I I was hurtin' last night. ;~)

OK, there's more I wanted to capture and post here, but those WiFi woes are actually getting worse and I need to figure out what's going on in my network. Looks like some kind of intermittent hardware problem, which is always a real treat to troubleshoot. So maybe when I can get a consistent connection to the box I have tied to all of my switch consoles I can come back add a little more to the discussion. But to wrap things up with what we have from just this little experiment...

In the full-blow six-switch topology, if we again assume the root is any switch other than SW2 or SW5 due to uplinkfast and that all links are equal-cost, then either SW2 or SW5 is going to have G0/0 in root-inconsistent state right out of the gate. We can't tell from the information given in the drawing which of the two available paths (upper or lower) that Host A - Host B traffic will follow prior to any failure. However, in the event of SW4-SW5 failure, we go back to the same situation discussed earlier where answer choice D is really the only viable option. If the root is SW1 or SW4 on the left, SW5 cannot have G0/0 in the path towards either one of those. If the root is SW3 or SW6 on the right, SW2 cannot have G0/0 in the path towards either one of those. Thus, in either case, we still wind up without a way for Host A - Host B traffic to transit the SW2-SW5 segment because of the root-guard on each opposing G0/0.

I'd love to string all six switches together just for the satisfaction of actually seeing and posting up the spanning tree state in the various scenarios. I simply don't have the hardware to play with and I need to shift focus to finding out what keeps mysteriously bring my network to its knees intermittently...



LucaSalvatore_2 Thu, 05/29/2008 - 21:41

Ok well you have helped me out heaps with this. thanks a lot for your assistance.

Hope you find your network issue.

svermill Thu, 05/29/2008 - 21:52

Sure - glad to help! Spanning tree is full of little details and potential gremlins so this was a really good exercise. Memorization of stuff is not exactly my strong suit, so it's nice to have these opportunities to revist features not likely to be encountered every single day.

And I'll find the network problem soon enough - thanks! I already suspect an ill-behaved WiFi board in my Mac Mini. Have been doing some capture with my trusty AirPcap and some of the stuff coming out of that box sure looks fishy...


This Discussion