So, we are concerned about loops in a Layer 2 network.
If we have this situation where we have two connections between two Layer 2
devices, that
this will create a loop, especially for broadcast packets, and we have to do
something about
that.
But why do we care about this so much at Layer 2 and not Layer 3?
Layer 3 seems like it can handle loops just fine whereas Layer 2 has a lot of
issues.
Well this has everything to do with the fact that we are running different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well this has everything to do with the fact that we are running different
protocols.
We are running specifically Ethernet.
Not every Layer 2 protocol has this problem.
In fact, Ethernet is really one of the only ones that has this problem.
And Ethernet was a protocol that happened to win out a long time ago, primarily
because
it was a cheap protocol.
The hardware was cheaper than things like token ring and such, and so it won
out, but one
of the reasons it was cheaper is that it had some issues.
The way it was deployed, it required less sophistication as a result, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The way it was deployed, it required less sophistication as a result, which is
why it
was cheaper.
And sometimes the cheaper solution wins in an industry that needs to figure out
which
protocol it is going to get behind.
So the industry got behind Ethernet.
And within the Layer 3 world, we say, "Well, why doesn't this problem exist
there?"
Well it is because we run IP version 4 or IP version 6.
And there's a couple of things working in our favor here.
First of all, we have an actual control plane at the Layer 3 level, meaning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
First of all, we have an actual control plane at the Layer 3 level, meaning
that we're running
some kind of routing protocol, so something like EIGRP or OSPF.
Even static routing counts as a control plane.
It's not a dynamic control plane, but it does provide us with a loop-free top
ology in
theory.
EIGRP and OSPF handle that automatically for us, whereas static routing relies
on us as
admins being at least somewhat intentional about how we deploy our static WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
admins being at least somewhat intentional about how we deploy our static
routes.
But in theory, these are creating loop-free topologies.
Furthermore, in the event that there is a loop, we at least have something
known as the
Time to Live field.
Time to live in IPv4 and IPv6 headers, make sure that eventually if a packet
gets looped
around, it will eventually get dropped.
Either net doesn't have any of this.
It doesn't have a control plane at all, and furthermore, it doesn't have any
kind of
mechanism to eventually time out a packet and allow it to drop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
mechanism to eventually time out a packet and allow it to drop.
And on top of that, it relies a lot more heavily on broadcasts, even though
there are technically
broadcast at Layer 3, we don't use them nearly as much as Layer 2 broadcasts.
And so the fact that we have a lot of broadcast traffic, like DHCP requests for
example,
we rely on that at Layer 2, and therefore we're creating a bunch of it, and we
don't have
the mechanisms in place to make sure that a packet that gets sent out one link
doesn't
come right back and then get looped around.
And indeed, this is the problem with the Ethernet, is that this is exactly what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And indeed, this is the problem with the Ethernet, is that this is exactly what
will happen
when we're talking about broadcast traffic.
And for that matter, by the way, flooded traffic.
Which from a behavior perspective is the same, but those are two different
scenarios.
So broadcast is intentionally sent out all interfaces, a flooded message is
sent out
simply because we don't know where the destination is.
So this situation here is why we needed a hero to save us from the evils of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this situation here is why we needed a hero to save us from the evils of
this loop,
and that hero takes the form of spanning tree protocol.
Now I know what you're thinking already.
Spanning tree protocol is typically treated like a villain, not a hero.
So why are we talking about it in this way?
Well, it's because it actually is accomplishing something that we desperately
need.
It's creating a loop-free logical topology.
And I say logical because it still allows for there to be a physical loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I say logical because it still allows for there to be a physical loop.
We have physical connections, we have created a physical loop here, and yet it
's creating
a loop-free logical topology over the top of this.
This basically means that from Ethernet's perspective, Ethernet sees no loops.
And that's what's going to prevent us from hitting these issues with flooded
and broadcast
traffic.
Now, spanning tree protocol was invented all the way back if we can believe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, spanning tree protocol was invented all the way back if we can believe
this in 1990.
And yes, for those of us who are younger, we did have networks back in 1990.
I myself was pretty young at that point and not in the networking world, let
alone even
in middle school, but at the same time, we had Ethernet networks this early.
And it was quickly discovered that, you know, yeah, we could build a physical
loop-free
topology.
But then if this connection goes down, we've broken our network.
We'd really like to have a physical loop just for the sake of redundancy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'd really like to have a physical loop just for the sake of redundancy.
And furthermore, even if we don't care about the redundancy because in 1990 our
networks
weren't that critical, we still needed to worry about somebody coming along and
saying,
"Oh, well, this cable's here, maybe in the event of a failure.
It's just not plugged in.
Oh, I'll go ahead and plug it in."
It looks like somebody accidentally left it unplugged and they plug it in and
it creates
a loop.
And that is going to take down our whole network.
So we needed something to step in and that was spanning tree protocol. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we needed something to step in and that was spanning tree protocol.
Tree protocol was the work famously of Radiopherlman and she famously wrote a
poem about spanning
tree and it goes something like this.
I think that I shall never see a graph more lovely than a tree.
A tree whose crucial property is loop-free connectivity.
So just a bit of a poet as well.
And it's a poem you can go Google that or run internet search and see that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's a poem you can go Google that or run internet search and see that.
But in the end she and her group came up with this based on a lot of
mathematical functions.
The idea was to create sort of that mathematical tree concept where everything
logically hangs
off of something else in a tree format.
Now you say, "How does that look like a tree?"
Well, flip it upside down.
Now look at it.
When we flip it upside down and we draw things from the root perspective, we do
start to
see that, oh yeah, that kind of grows like a tree and here at the bottom we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
see that, oh yeah, that kind of grows like a tree and here at the bottom we
could call
this the root.
Hmm, interesting.
I think that we're going to see a lot more about these spanning tree roots as
we talk
more and more about the technology.
But this is the idea.
We might have physical connections in here.
But in the end those physical connections are used for redundancy.
They're not used to forward traffic.
And so when broadcast messages arrive somewhere in the network, we now see that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so when broadcast messages arrive somewhere in the network, we now see that
they can get
sent out in that loop free topology.
So that is the goal of spanning tree protocol.
And again, even though sometimes it gets a bad rap, mostly because we're
talking about
our spanning tree loops that get formed, what we're really saying is it's a
loop that
isn't protected by spanning tree for some reason.
This is not a flaw of spanning tree, although I guess it could be a flaw of the
spanning
tree process or something along those lines.
Ultimately, it's a flaw of ethernet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Ultimately, it's a flaw of ethernet.
Ethernet is the problem.
Spanning tree protocol is a solution to that problem.
And what we'll find is sometimes it's not a perfect solution to the point that
we'd really
rather not rely on it at all.
This is why we come up with technologies like ether channels.
We just talked about ether channels.
I would really rather not rely on spanning tree.
If I've got two links here, I could block one of these ports and that prevents
a loop.
But for a lot of reasons, we might just want to bundle these together and that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But for a lot of reasons, we might just want to bundle these together and that
gives us
redundancy, it gives us bandwidth and it removes the need for spanning tree to
even have to
worry about blocking a port.
And so this is why as we build out modern networking topologies by using
chassis switches.
And stackable switches.
As well as things like multi-chassis ether channels and virtual port channels,
a lot of
the goal of this is to eliminate the need for spanning tree to be blocking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the goal of this is to eliminate the need for spanning tree to be blocking
ports.
That said, spanning tree can't just go away, it needs to continue to run just
in case there's
a loop.
But if we can prevent spanning tree from being a critical part of the process,
what we're
really saying is we'll build our own physical loop for e topology by leveraging
some of
these special technologies.
Now when spanning tree was created, it ended up getting standardized as an IEEE
specification,
which is 802.1d. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is 802.1d.
We often will refer to 802.1d as sort of traditional spanning tree protocol,
the protocol
that was originally created.
This protocol has a lot of characteristics that we're a lot of us are familiar
with.
For example, we often talk about the timers that are associated with
traditional spanning
tree.
And we're going to talk about the election process as well as priorities. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're going to talk about the election process as well as priorities.
But spanning tree, like a lot of technologies, evolved over time.
And we eventually saw the creation of two new standardizations, 802.1w, which
is known
as rapid spanning tree, and then also 802.1s, which is known as multiple
spanning tree or
mst.
Now we say, well, okay, that's cool and all, but does that mean that all of
these properties
are no longer needed?
The answer is no, actually, all of these properties are going to be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The answer is no, actually, all of these properties are going to be used
heavily by these newer
forms and more modern forms of spanning tree protocol.
So this is why we start by learning the basic traditional spanning tree.
The purpose is not for us to say, hey, in our networks, go deploy 802.1d
spanning tree,
because nobody should be running that today.
But sometimes in order to understand how a modern protocol works, we need to
understand
where it came from, sort of that, if we're going to know where we're going, we
need to
know where we came from. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
know where we came from.
And that's this situation exactly.
So we're going to start by drilling into 802.1d and making sure we fully
understand the election
process, the priority values, the way ports are blocked, and the timers,
because even
the timers are used exactly the same way by rapid and mst might say, well, wait
a second,
wouldn't the timers be faster?
No, they're not any faster with rapid spanning tree.
It uses a different mechanism, but yet it falls back on the timer mechanism. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It uses a different mechanism, but yet it falls back on the timer mechanism.
So we must learn, we must understand all of these basic tenets of 802.1d in
order to then
talk about rapid and multi-span multiple spanning tree as well.
Of course, as Cisco's per VLAN spanning tree, PVSD plus and the rapid flavor of
that.
So let's go ahead and dive into that and start to see how spanning tree
protocol is able
to create a loop free topology automatically for us and prevent those broadcast
storms.