UplinkFast

[asepiacci]

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.

[Jon Marshall]

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

[Jon Marshall]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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