|
0:00:12
|
Next we have the backbone fast feature
|
|
0:00:15
|
which is used to detect an indirect failure in the network.
|
|
0:00:20
|
Now backbone fast is not going to allow us to converge as quick as uplink fast did
|
|
0:00:25
|
because it's used to figure out that out our root port
|
|
0:00:30
|
someone else's root port upstream changed.
|
|
0:00:35
|
So if we were to look at our topology here
|
|
0:00:41
|
let's assume again that switch four is the root bridge
|
|
0:00:46
|
and we are looking at these calculations from the perspective of switch one.
|
|
0:00:52
|
Switch one says that on port sixteen, that's my root port,
|
|
0:00:56
|
this one is designated. Actually, no, that's not designated. That is blocking.
|
|
0:01:02
|
The reason that the port sixteen is the root port
|
|
0:01:07
|
is we have a cost of nineteen plus twelve, which is a total of thirty-one.
|
|
0:01:13
|
Okay? The other two interfaces are nineteen plus nineteen, which is a total cost of thirty-eight.
|
|
0:01:18
|
So we're choosing the lower path, thirty-one over thirty-eight.
|
|
0:01:22
|
From switch three's perspective, port thirteen is going to be designated, port channel one is going to be the root port.
|
|
0:01:31
|
No if we configure backbone fast on switch one
|
|
0:01:38
|
what should happen is that if switch three's port channel link goes down,
|
|
0:01:46
|
switch three is going to start sending inferior BPDUs
|
|
0:01:54
|
or basically a worst cost to the route
|
|
0:02:02
|
because whatever switch three has to change over to re-converge
|
|
0:02:06
|
it's going to be a higher cost than what it was advertising before, which was twelve.
|
|
0:02:11
|
Switch one then realizes that somewhere upstream in the network a failure has occurred
|
|
0:02:17
|
so what I'm now going to do is take my maximum age timer
|
|
0:02:23
|
which by default was twenty seconds, I'm immediately going to expire that and then start to recalculate.
|
|
0:02:31
|
So the key of this feature is that it's used to detect indirect failures upstream
|
|
0:02:36
|
but it's only an optimization of twenty seconds at the best case scenario.
|
|
0:02:44
|
So configuration wise we would do this on essentially everyone.
|
|
0:02:49
|
Okay, we need to do it on everyone because it is essentially a negotiated parameter between the switches.
|
|
0:02:56
|
So we'll say spanning tree backbone fast.
|
|
0:03:08
|
So on all the switches I'm going to say this.
|
|
0:03:11
|
Okay, we could look at then between switch one and switch three the
|
|
0:03:19
|
actually first let's look at show interface trunk. I have that other port still shut down so let me bring that back up.
|
|
0:03:36
|
So switch one, it should be using it's port FastEthernet sixteen as the root port.
|
|
0:03:43
|
Let's show spanning tree root
|
|
0:03:51
|
and we should see here shortly that we're going to change from...and which we did, uplink fast is doing it for us.
|
|
0:03:59
|
We're changing from port thirteen to sixteen.
|
|
0:04:07
|
So eventually the other ones will change over as well but it's not that fast to converge with the default timers.
|
|
0:04:13
|
Okay, really the only one I care about right now is VLAN ten, which it already has changed over.
|
|
0:04:21
|
So on switch one, let's un-debug everything else that we had
|
|
0:04:27
|
and instead we will debug spanning tree backbone fast.
|
|
0:04:34
|
Debug spanning tree backbone fast.
|
|
0:04:39
|
Now on switch four
|
|
0:04:43
|
I am going to disable the port channel which in turn is going to
|
|
0:04:49
|
make the line protocol of ports twenty and twenty-one on switch three go down.
|
|
0:04:57
|
From switch one's perspective, this is going to be seen as an indirect failure
|
|
0:05:02
|
because switch three will start reporting now an inferior BPDU in order to reach the root bridge.
|
|
0:05:09
|
So if we look at switch four here, let's say
|
|
0:05:16
|
on interface port channel one I'm going to shut that down.
|
|
0:05:22
|
This in turn should cause switch three to lose it's links which then in turn
|
|
0:05:31
|
will result in, if we look at the top here, it says it received an inferior BPDU for these particular VLANs.
|
|
0:05:40
|
Okay, then we're sending a request. This is a, I believe this is the root link query.
|
|
0:05:46
|
This is a packet format that is specific to backbone fast
|
|
0:05:50
|
that we're trying to figure out do you have an alternate path to the root.
|
|
0:05:56
|
Now we're not getting the response back from them
|
|
0:06:01
|
where...okay, so now we've received the response. It says received the response on VLAN twenty
|
|
0:06:10
|
FastEthernet thirteen. So now thirteen is moving to
|
|
0:06:16
|
forwarding but the key was that at this forty-six second after
|
|
0:06:25
|
normally this would have happened twenty seconds later
|
|
0:06:29
|
or in the case of VLAN ten, if we show spanning tree VLAN ten,
|
|
0:06:34
|
it would have happened ten seconds later because the maximum age is ten.
|
|
0:06:38
|
So as soon as backbone fast sees this inferior BPDU coming in
|
|
0:06:43
|
it knows that FastEthernet sixteen may not now be the best path in order to reach that particular
|
|
0:06:49
|
that particular destination. But if we look at the show interface trunk,
|
|
0:06:58
|
port sixteen is still up so it's not a direct failure here, it's an indirect failure
|
|
0:07:04
|
that is causing the switch to converge faster than it normally would.
|
|
0:07:16
|
Okay, there's a couple of questions here - an inferior BPDU is just a higher cost to the root? Correct.
|
|
0:07:22
|
So previously our cost was
|
|
0:07:31
|
our cost was thirty-one to go through switch three then switch three's link went down
|
|
0:07:40
|
so switch three is going to start advertising us a cost that is at least the addition of
|
|
0:07:52
|
this link plus this link or this link plus this one plus this one.
|
|
0:08:00
|
So at a minimum it's always going to be higher than thirty-one. Okay, it could potentially be equal to thirty-eight
|
|
0:08:06
|
because this link here has nineteen, this link is nineteen.
|
|
0:08:10
|
So it doesn't mean that switch three will automatically be removed from the forwarding path
|
|
0:08:15
|
but it means that switch one is going to try to figure that out.
|
|
0:08:19
|
So now look at the new BPDUs coming in and make a new decision based on that.
|
|
0:08:24
|
Because otherwise we would have to wait for the maximum age to expire first.
|
|
0:08:32
|
Okay, there's also a comment here, or it might advertise it's own bridge ID if it has no other links to the root.
|
|
0:08:38
|
Correct. So in the case that switch three
|
|
0:08:44
|
only has one path to the root
|
|
0:08:47
|
so let's say that it did not have this interface.
|
|
0:08:55
|
So if switch three's only possible path is that way
|
|
0:08:59
|
then when this link goes down, switch three is going to say basically I am the root.
|
|
0:09:07
|
When switch one receives this it's now an inferior advertisement to what it had before
|
|
0:09:13
|
so the same thing is going to happen - the MACs age is going to expire then either switch three will be elected the new root
|
|
0:09:20
|
or switch three is going to say no, now my root port has transitioned to thirteen and now the traffic is going to forward that direction.
|
|
0:09:34
|
So there's another comment here, correct, so in a nut shell, backbone fast only shaves off the MACs age time
|
|
0:09:39
|
from the detecting the topology change? Correct. So with all of the default timers,
|
|
0:09:45
|
worse case scenario is that it's going to take fifty seconds to move from blocking to forwarding or from disabled to forwarding.
|
|
0:09:53
|
Because we move from blocking to listening to learning to forwarding which is
|
|
0:10:00
|
first to get from blocking to listening, we would have to wait for the MACs age to expire so that takes twenty seconds.
|
|
0:10:07
|
Then to move from listening to learning is fifteen, then from learning to forwarding is another fifteen, so it's fifty.
|
|
0:10:13
|
So with backbone fast on, then our worst case convergence time is somewhere in the order of thirty seconds.
|
|
0:10:21
|
But in reality, thirty seconds is not much better than fifty seconds to begin with.
|
|
0:10:27
|
So in a real design there's no reason that you're going to run this anymore
|
|
0:10:31
|
because from a high availability point of view, thirty seconds is definitely not acceptable.
|
|
0:10:37
|
Okay, in most networks we're looking for ideally sub-second convergence or near second convergence
|
|
0:10:43
|
in order to deal with applications like voice over IP not having to fail over.
|
|
0:10:56
|
There's another question here - could you set the maximum age to its minimum on all switches to achieve a similar result as backbone fast?
|
|
0:11:02
|
You technically could set the max age to be a really low value
|
|
0:11:08
|
but we would need to look at what's the minimum supported so if I said spanning tree VLAN one max age the minimum is six.
|
|
0:11:18
|
So if I set the max age to six, the hello timer to one,
|
|
0:11:27
|
and the forward delay to four,
|
|
0:11:33
|
then this would be the fastest that you can converge with the normal spanning tree. So then the result of this
|
|
0:11:41
|
would be if you're trying to move from blocking to forwarding
|
|
0:11:45
|
it's going to take you six seconds to figure out that you need to recalculate,
|
|
0:11:50
|
it's going to take you another four to move from listening to learning,
|
|
0:11:55
|
then another four to go from learning to...
|
|
0:12:00
|
no, excuse me, so six seconds to detect the failure, four seconds to go from listening to learning, then another four from learning to forwarding.
|
|
0:12:08
|
So in this case our best, or excuse me, our worst case convergence time would be fourteen seconds.
|
|
0:12:16
|
But again still really not great if we want something on the order of sub-second or around at least one or two seconds maximum.
|
