UplinkFast

Unanswered Question
Nov 19th, 2010

From the CCNP SWITCH Book:

"The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use.

[...]

UplinkFast also makes some modifications to the local switch to ensure that it does not become the root bridge and that the switch is not used as a transit switch to get to the root bridge. In other words, the goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root."

I don't get the point why the Uplinkfast should be enabled only on leaf-node switches. Can you give me an example of a transit switch where putting the port that receives suboptimal BPDUs into FW state, immediately after the failure of the link connected to the Root port, could bring to a loop?

Thanks in advance for help.

Alessandro.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
Jon Marshall Fri, 11/19/2010 - 12:05

Alessandro

Firstly, good question, made me think about uplinkfast and STP in a bit more detail.

Using the diagram below -

RP = Root port
DP = Designated port
BLK = Blocked port

Note also that the alternate root port (Alt RP) is also blocking in normal operations.

SW2 is the transit switch to root.

the diagram represents a stable L2 topology with no loops.

If the link between SW2 and SW1 fails then SW2 activates it's Alt RP. As soon as it is activated it can begin forwarding on that link.

But now we have a loop in the network because if a broadcast, for example, was sent from SW2 it would go to SW3, SW3 would forward it to SW1 (which is fine) but it would also forward it to SW4. SW4 would then forward it to SW2 again.

This is why you should not use uplinkfast on transit switches. You should allow STP to work out a loop free topology using BPDU's sent by switches before forwarding any traffic.

Jon

Attachment: 
Jon Marshall Fri, 11/19/2010 - 12:42

Actually i've done so much thinking about STP for this question i an now second guessing myself

I know that a blocked port still receives BPDUs and processes them. Can someone confirm for me that a BPDU received from SW1 on the blocked port on SW3 (see diagram in previous post) will still be processed and hence a BPDU will be sent to SW2 via the SW3 -> SW2 link which means that SW2 could indeed have that port as an Alternate root port.

Jon

asepiacci Sat, 11/20/2010 - 12:45

Hi Jon,

thanks for your answer but I don't understand some of those ports' roles.

Let's call Nxy the network that connects SWx and SWy, Cxy the cost associated to it (100 for Ethernet, 19 for FastEth., 4 for GigabitEth. ), Pxy the port from where SWx "sees" SWy [i.e. (SW2)P23-----N23-----P32(SW3), C23 is N23's cost].

If I'm not mistaken, P32's and P23's role and state should be swapped (assuming that all other ports' roles and states are correct), with P23 as DP and P32 in Blocking state (since it's neither DP nor RP). This consideration comes from the fact that the DP on a network has to be chosen on the switch, connected to that network, with the smallest root path cost. SW3's root path cost is C12 + C24 + C34 (the one associated to the root port) that is obviously bigger than C12, that is SW2's root path cost. So the DP on N23 must be P23 on SW2.

As an example, you can assign these costs to the networks and the STP will lead to the same loop-free tree as in your drawing:

C12 = 4

C13 = 100

C23 = 19 (or 100)

C24 = 4

C34 = 4

Now, the two blocking ports are P31 and P32, both on SW3. Both BLK ports are also ALTN ports. The ALTN port that will be put into FW state in case of fault, will be the one receiving BPDUs with the best root path cost.

If there's a fault on N12, SW3's P34 (the root port) won't be receving BPDUs anymore (it's 802.1d STP's behaviour), and the same will happen to P32. So, the only available ALTN port will be P31. This port can be immediately put into forwarding state with no loop.

Even if the fault happened on N24 or N34, the Uplinkfast would work, either with P32 as the best choice or P31 (depending on C23's value).

Of course I'm not saying that this is true in any case: simply I can't conceive an example where this is not true.

Alessandro

Jon Marshall Sun, 11/21/2010 - 10:09

Alessandro

Let's call Nxy the network that connects SWx and SWy, Cxy the cost associated to it (100 for Ethernet, 19 for FastEth., 4 for GigabitEth. ), Pxy the port from where SWx "sees" SWy [i.e. (SW2)P23-----N23-----P32(SW3), C23 is N23's cost].

Wow, lets not, as it's giving me a headache just looking at it 

The diagram was only meant to be an example of why transit switches should not use uplinkfast so i wasn't really concerned with costs etc.

Jon

andtoth Sat, 11/20/2010 - 15:23

Hi,

A STP blocking port will still process BPDU packets, otherwise it would not know it needs to be in blocking state (ports not receiving any BPDU are designated). Just think about the LoopGuard feature which is monitoring non-designated (root and blocking) ports for a sudden loss of BPDU packets (without a link flapping) then it moves them to loop inconsistent.

However, SW3 will not send the BPDUs to SW2 not because it learns them on the BLK port rather because it knows about a better path through it's current RP. If SW3 would not have any other path other than his BLK port, that would not be in blocking state because that's the only path, hence loop-free. So to confirm your statement, SW3 will not send the BPDU learnt on BLK port, rather it'll send the better BPDU learnt on RP. (Of course, according to STP rules, it will generate new BPDUs and not forward the received BPDUs.)

Your theory in your first reply is not accurate because as soon as the link between SW1 and SW2 goes down, SW3 will transition it's link towards SW1 to be a Root Port (being the only one towards the root) and the other switches will recalculate their spanning tree topology and make decisions for their port roles. Eventually, the link between SW2 and SW4 is the most likely candidate to become a blocked link (based on port costs of course) so there's no loop in the network.

By the way, here's a somewhat old but still decent documentation about UplinkFast feature:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094641.shtml

Andras

Jon Marshall Sun, 11/21/2010 - 09:29

Andras

Your theory in your first reply is not accurate because as soon as the link between SW1 and SW2 goes down, SW3 will transition it's link towards SW1 to be a Root Port (being the only one towards the root) and the other switches will recalculate their spanning tree topology and make decisions for their port roles.

That's where i am bit confused. An alternate port begins forwarding immediately. If the link between SW1 and SW2 goes down then SW3 will not immediately transition it's link to SW1 to an RP because it relies on STP timers to learn of an indirect link failure. Does it not have to wait until it no longer hears the BPDU via SW4 ? In the meantime the alternate root port on SW2 is forwarding traffic.

Jon

andtoth Sun, 11/21/2010 - 09:45

If not using UplinkFast, the switch will wait until the BPDU expires (MaxAge) then it will start the STP calculation. With UplinkFast, the switch already knows about a secondary path to the root and can safely assume that the link can be moved to forwarding state as soon as the active root port link goes down (direct link failure). The UplinkFast documentation describes and illustrates this.

I was referring to your assumption about "a loop will stay in the network" which is not correct as other switches will recalculate the topology when the uplinkfast is bringing up the link between SW2 and SW3.

Jon Marshall Sun, 11/21/2010 - 09:52

andtoth wrote:

If not using UplinkFast, the switch will wait until the BPDU expires (MaxAge) then it will start the STP calculation. With UplinkFast, the switch already knows about a secondary path to the root and can safely assume that the link can be moved to forwarding state as soon as the active root port link goes down (direct link failure). The UplinkFast documentation describes and illustrates this.

I was referring to your assumption about "a loop will stay in the network" which is not correct as other switches will recalculate the topology when the uplinkfast is bringing up the link between SW2 and SW3.

It wouldn't stay in the network forever, but as the alternate port transitions to forwarding immediately then data packets are being forwarded down that link before the other switches have had time to start recalculating the topology and the other switches are not aware of a topology change yet so they forward the packets.  This is a loop and would more than likely bring the network down before any of the other switches managed to recalculate a loop free topology.

As the docs say, uplinkfast should not be used on transit switches. If what i have described is not the reason why, then can you explain why you shouldn't run it on transit switches.

Jon

andtoth Sun, 11/21/2010 - 09:57

Basically, you have just explained why it's not recommended to have UplinkFast on transit switches That is the reason. Although switches will start STP recalculation as soon as they receive the first BPDU on their designated ports or receive a better BPDU on their RP, it might take a few or more seconds.

droeun141 Fri, 12/03/2010 - 03:59

Glad I found this post! I've been banging my head against the wall for the past 24 hours.  I think John is spot on.  When SW1/SW2 link fails, S2/S3 begins forwarding immediately but a loop is created between S2/S4.

asepiacci Fri, 12/03/2010 - 05:23

But the question is: is that example correct? How is it possible that (assuming that all other port states are correct) on the network segment SW2-SW3 the Designated Port is on SW3 instead of SW2? If it were on SW3 it would mean that the cost of the path SW3-SW4-SW2-SW1 is lower than the cost of SW2-SW1, that is obviously impossible.

I simply think we are discussing about an impossible situation.

Jon Marshall Fri, 12/03/2010 - 05:34

asepiacci wrote:

But the question is: is that example correct? How is it possible that (assuming that all other port states are correct) on the network segment SW2-SW3 the Designated Port is on SW3 instead of SW2? If it were on SW3 it would mean that the cost of the path SW3-SW4-SW2-SW1 is lower than the cost of SW2-SW1, that is obviously impossible.

I simply think we are discussing about an impossible situation.

Okay, leave it with me and i'll have another look. As i say, the scenario was only there to show why transit switches should not use uplinkfast but i'll see if i can come up with a scenario that actually takes into account STP costs etc. that also demonstrates this.

Jon

droeun141 Fri, 12/03/2010 - 06:36

Why'd you have to bring that up now my headache is back & I'm stumped again.  I made like 5-6 different diagrams trying to create a loop when it immediately failed over but I couldn't.  I wonder if a loop isn't the issue and there's another reason?  The switching book doesn't go into much detail.  It just says you should things this way but doesn't tell you why.

Jon Marshall Fri, 12/03/2010 - 06:51

Why'd you have to bring that up now my headache is back & I'm stumped again.

Sorry   To be honest it took a while to come up with that diagram so it may take me a while yet to come up with one that works with costs etc.

Jon

asepiacci Fri, 12/03/2010 - 08:09

Sorry guys, I've already caused two headaches and I feel a bit guilty...

Seriously speaking, I just think there's a lack of good scenarios in books: they always show very simple situations and, in that way, they end up in not being exhaustive at all.

Anyway, no rush, take your time, and thanks again!

andtoth Fri, 12/03/2010 - 09:41

The example is correct if we assume that the STP cost on the link between SW2 and SW3 (root) is set to an artificially high value that is higher than the cumulative cost of the best path to the root.

However, the theory behind that example is not precise because in that example SW2 does not have a "real" alternate root port, as the alternate RP is going back to itself. In other words, imagine that as soon as link between SW1 and SW2 goes down, SW2 does not hear about the root anymore, not even through the alternate port as there's only one path to the root from that perspective. By the way, in reality the alternate root port would be on SW3's link which goes to SW2. And SW2 would have designated ports towards SW3 and SW4 as he's advertising the best path towards the root (still assuming the artificially high cost on the SW2-SW3 link on top).

By the way, if the link on SW2 to the root would go down, SW2 would either consider itself as the new root (if we assume the link on top would be shut down) and other switches would start calculating new port roles immediately as they receive new BPDU from SW2. In reality SW3 would enable it's port as root port and start sending better BPDU on it's designated port causing other switches to recalculate their port roles.

Andras

droeun141 Fri, 12/03/2010 - 10:49

I thought Uplinkfast increases the bridge priority & port costs to incredibly high values.  How would S2 become new the root?  Ok, check out this diagram.  Cisco says uplinkfast should only be on enabled on edge switches, not core or distribtion.  But why?  Let's presume A is the root and C is a distro switch with uplinkfast enabled.  If link AC goes down, why would transitioning to BC immediately cause any problems? I've tried it numerous ways but can't get it to form any sort of loop.

http://i586.photobucket.com/albums/ss302/d_roeun/uplinkfast.jpg

Jon Marshall Fri, 12/03/2010 - 12:18

In your scenario i don't believe it could form a loop. I told you it took me sometime to actually come up with a scenario where it would

I think Cisco are not saying that using Uplinkfast on any transit switch will always cause a loop. What they are saying is that using it on transit switches could cause a loop and therefore it is recommended not to use it.

Jon

Mohamed Sobair Fri, 12/03/2010 - 13:36

Hello,

The Uplink fast and backbone fast features are PVST+ features , that is used to spead up the convergence time in STP.

Let me try to navigate on what Cisco says here and Why?

Cisco Says , the Uplink fast feature is not recommended to be applied on the transit Switches and here is why, In your example, If Switch C link to the root bridge fails, then Switch C shall wait for the max age timer to expire before start to accept Superior BPDUs from Switch B on its blocking port. Once the max age timer expires , the blocking port goes through normal STP states before it becomes Root Forwarding. This operation takes about 50 sec in normal STP timers, However , when you apply Uplinkfast, the Switch doesnt have to wait for the max age timer to expire and would therfor choose alternative root port towards switch B.

In transit Switches on some specific design approach it could be a risk to have a transit switch not to wait for the Max age timer expires and transit its port to root forwarding state, However, your Example doesnt show any kind of Switching loop risk when its applied in your Scenario.

I shall come up with Specfic design that could introduce loop when uplinkfast is enabled and post it here.

HTH

Mohamed

Actions

Login or Register to take actions

This Discussion

Posted November 19, 2010 at 10:32 AM
Stats:
Replies:19 Avg. Rating:
Views:1453 Votes:0
Shares:0
Tags: uplinkfast
+

Related Content

Discussions Leaderboard

Rank Username Points
1 15,007
2 8,150
3 7,730
4 7,083
5 6,742
Rank Username Points
155
77
70
69
50