Stubby Post – UplinkFast

I’ve got a few switches daisy chained together with single links and have enabled UplinkFast on them. ┬áThis switch is not the root bridge; F0/24 is the root port and F0/23 is a blocked alternate port. I’ve got debug spanning-tree uplinkfast on to help out.

Now let’s unplug F0/24 and see what happens.

Before the switch even reports that F0/24 is down, F0/23 is brought into the forwarding state. Now let’s plug F0/24 back in.

Notice that the port comes back up, but it isn’t returned as the root port immediately. It should be, though, right? The original STP convergence said that it was the closest to the root bridge, so it makes sense that it should be the root port again, right? Since the port just came up, STP still has to make sure there’s no loop, so it has to step through all the states like any good port does. If we wait a few more seconds, we see this.

Now we’re back to where we were originally. The moral of the story is that UplinkFast already knew the status of both ports, so it could quickly move the blocked port to fowarding when the port failed. Traditional STP would have to send a TCN message to the root bridge, which would then forward them out with the rest of the switches so they can reconverge. UplinkFast skips the whole reconverging thing.

Send any questions my way.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

1 comment for “Stubby Post – UplinkFast

Leave a Reply

Your email address will not be published.