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.

More Posts

Follow Me:
Twitter

1 comment for “Stubby Post – UplinkFast

  1. Ken Lai
    May 7, 2010 at 11:06 am

    i know a real project that have used 9 switches daisy chain for redundancy with every thing they can do to make faster converge.

    when any link failed, the converge time is about more than 10 mins.

    can you believe it? orz

Leave a Reply

Your email address will not be published. Required fields are marked *