It's often fun to verify what we think
is happening in a network.
So what I'd love to do in this Nugget with you
is take just a moment and take a look at A Spanning tree
topology in our current network for VLAN 100,
and then cause a network failure in one part of our network,
and then see the results of Spanning Tree adapting
to that failure and choosing an alternate path to go ahead
and forward frames through.
So here is our current technology.
We're going to focus on VLAN 100 for this discussion.
So the switches have all shared their BPDUs
with each other, and as a result have
chosen the lucky winner, which is Switch-1 to act as the root
bridge.
And the way the winner works with BPDUs is the bridge that
has the lowest, like a golf score,
the lowest bridge ID becomes the winner
of the election for the root, and that's
how that happened here on Switch-1 as well.
And as a result, Switch-1 for VLAN 100
is forwarding on all ports associated with VLAN 100,
including gig 0/1, 0/2, 0/0 the trunk, and gig 1
slash 3, the other trunk.
Switch-2 and Switch-3 both have one root port respectively.
That's this guy and this guy, which are both forwarding
frames, but over here on this segment,
Switch-2 is forwarding frames on it's gig 0 slash 3.
In this topology, we only have a single block port,
and that is Switch-3 on gig 0 slash 2.
Everything else is in a forwarding state
with Spanning Tree.
So what we'll do is we'll go in, we'll
verify that everything's forwarding for VLAN 100
except for that one port, and then what we'll do
is we'll go ahead and we'll simulate a failure by shutting
down one of these interfaces between Switch-1 and Switch-2.
Spanning Tree will recognize that change,
and it will move this interface right here
on Switch-3 out of the blocking state,
and move it into the forwarding state,
so we still have connectivity through the network.
Before we make any changes, let's take a look
at the current state.
And to do that, we're going to issue the command show
space spanning dash tree space and then add VLAN space
100 on this Cisco switch.
In fact, I'm going to send this command to all three switches
simultaneously so we can focus on the results.
So we'll send that command to each of our three switches,
and let's take a look at the results.
So here on Switch-1 regarding VLAN 100
and its four interfaces that are involved with VLAN 100,
notice here that the forwarding status
on all of those ports from a Spanning Tree perspective
is that it is willing to forward traffic,
and that's partly because this switch, Switch-1, won
the election, and this switch is the rot for the Spanning Tree.
Let's take a look at Switch-2.
Over here on Switch-2, using the same command.
So here on Switch-2, we have gig 1/1,
which is the port that's going up to PC-4 in VLAN 100,
and we have two trunks.
We have gig 1/0, which is the trunk over to Switch-1,
and gig 0 slash 3, which is the trunk over to Switch-3.
And all three of those ports are in the forwarding state,
not being blocked.
It's also indicating here that the root port on Switch-2,
that's the port that's the fastest path to get to the root
bridge, is gig 1 slash 0, which based on our typology, it is.
But somebody has got to be blocking,
so that's going to be Switch-3.
Let's go take a look at Switch-3.
So here in Switch-3 gig 0 slash 1,
which is the port that connects over to Switch-1,
it's in a forwarding state.
It's also the root port, the fastest path
from Switch-3's perspective to have access towards the root.
We can also see that 0 slash 2 here
is in a current blocking state, and it's
because of that one port in this topology that's
blocking due to Spanning Tree that's preventing a layer 2
loop.
So let's simulate a failure of a link between Switch-1
and Switch-2, and what we'll do is we'll go to Switch-1,
and we'll simply shut down the gig 0/0 interface, which
will stop this root bridge from being able to send BPDUs over
to Switch-2.
It'll also remove the parallel path, and as a result,
the Spanning Tree topology is going to change,
and it's going to move gig 0 slash 2
on Switch-3 into a forwarding state,
and that's the real focus regarding
the change that we want to verify in this demonstration.
So back on the switches, let's go over to Switch-1.
We'll go into Configuration mode on this Cisco switch.
We'll go into Interface Configuration mode
for gig 0 slash 0, and we'll use the command
of shut down to go ahead and bring that interface
down and out of commission.
And then based on that version of Spanning Tree we're using
and how it's tweaked, the actual change from a Spanning Tree
topology could take anywhere from a few milliseconds
up to many, many seconds.
So we'll give that a moment to settle and while it's doing so,
we'll go over to Switch-3, and here on Switch-3
when we run this command again, show Spanning Tree for VLAN
100, we expect to see gig 0 slash 2
no longer to be blocking, but rather to be forwarding.
And with traditional Spanning Tree, IEEE's 802.1D,
as in David, that's the actual Spanning Tree Protocol,
the original flavor, and it does take a few seconds to converge.
And this port, gig 0 slash 2, is going
to go out of blocking state, it's
going to go into something called listening state.
It's then going to go into learning state,
and then eventually forwarding state once it knows
the coast is clear, and there are no loops in the layer 2
topology.
So what we'll do here is we'll hit the Up arrow key,
do a show Spanning Tree for VLAN 100
again, and focus on the change.
And that is that gig 0 slash 2 used to be in blocking state,
but it's now in forwarding state because Spanning Tree realized
there is no longer parallel paths, and as a result,
it didn't have to put any of the ports in the topology
into a blocking state.
In this Nugget, we had a chance to see
the results of Spanning Tree Protocol reacting
to a topology change.
I hope this has been informative for you,
and I'd like to thank you for viewing.