We know that spanning true protocols going to start by establishing a root
bridge.
And we might say, okay, well, cool, these links are probably going to stay
online.
But what do we do with this link?
We know we need to block a port, but is it on this side?
Is it on this side?
And so in order to start having that conversation, we need to understand how
exactly the different
ports can operate.
And it starts with the concept of port roles.
For now, we're going to assume, in this case, that this link on switch three is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
For now, we're going to assume, in this case, that this link on switch three is
going to
be blocked.
It gets placed into the blocking state.
We'll be talking about the states in more detail in the next video.
But at this point, if it's blocking, we can understand that any traffic that's
received
is going to get dropped.
And so we do prevent the loop in this case, making it so this link and this
link are truly
the only ones that are active in the environment.
And we can see how that's loop free.
And each one of these ports is operating in a particular role. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And each one of these ports is operating in a particular role.
And this is what's going to lead us to determining the topology that we're kind
of working our
way backwards from.
So let's go and start with the definition of port roles.
There are three primary port roles.
We have the root port, which can be called the RP.
We have a designated port, which can be called a DP.
And then we also have a non-designated port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we also have a non-designated port.
And sometimes these are called blocked ports.
So we'll see it called that way by engineers.
We'll see it this way in documentation.
But sometimes we'll be referred to as NDPs for non-designated ports.
And sometimes we might see it as BP or a blocked port.
So we can look at this and probably assume that this port here is running as a
blocked
port.
And that would be the case.
But what about the other ports?
I mean, they're all forwarding traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I mean, they're all forwarding traffic.
What's the difference between these other two port roles?
Well, let's go ahead and take a look at that.
So first of all, the root port.
The root port is going to be my upstream port, which means that it's going
towards the root.
When I look at things from Switch3's perspective, we could look at Switch3 and
say, OK, this
is my downstream direction.
But if I look at it from a tree perspective, I realize I've got two different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if I look at it from a tree perspective, I realize I've got two different
upstream
paths to get to the root.
Because that's what I'm trying to do.
I'm trying to figure out how do I get to the root in a loop-free way.
So if I have two different upstreams, that's going to be the big red flag.
I'm going to know that I'm going to identify the port that has the least cost.
This is my best path to the root.
And I'm going to call this my root port.
Well, Switch3 is going to do the same thing.
It's going to see that it has its best connection to the root this way.
And so it identifies this port as the root port for itself. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so it identifies this port as the root port for itself.
We're only going to have a single root port on any given switch.
It is the only upstream port we're going to use.
We're going to block all the other upstream ports if any of them exist.
Other upstream ports will become non-designated ports, which is exactly what
happened here.
My other upstream path to the root is what gets blocked.
And this is how we form the loop-free trees. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is how we form the loop-free trees.
So that's great.
This is a designated port.
Well, a designated port is a downstream port.
So if my root port is upstream, my designated port is downstream.
Now we see right away that the root port should have all downstream ports,
which means it's
going to have all designated ports kind of interesting.
So I can immediately assign these ports to be in the designated port role. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I can immediately assign these ports to be in the designated port role.
But down here with switch 2, we know that I'm going to see this as being a
downstream
path.
So because this is considered to be downstream, I'm going to place this into a
designated
port status.
And then on the other side, we're going to call this either a blocked port or
we could
call it a non-designated port.
Again, either of those terms works.
Switch 3 has to block that interface.
Now there's a few takeaways from this conversation that we're going to want to
keep in mind because
they'll help us when we're trying to figure out which ports would be blocked in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they'll help us when we're trying to figure out which ports would be blocked in
a spanning
tree topology.
First and foremost, the root bridge is going to only have designated ports.
We already said that, but it's worth pointing out here.
Now additionally, when I look at a root bridge here, so the root bridge is
going to have
a DP and the DP is going to connect to another root port.
This is in most cases.
There will be some really oddball scenarios where this doesn't happen, but we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There will be some really oddball scenarios where this doesn't happen, but we
already
see that.
We see that my designated port here connects to a root port down here.
My designated port here connects to a root port down here.
This could change if this is a really bad link.
Maybe this is 10 meg and these over here are 100 meg, something like that.
At that point, we would probably prefer to go the other way and this wouldn't
be my
root port at that point, but we'll get into costs and figuring that all out.
In this topology, we're just sort of assuming all of these links are created WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this topology, we're just sort of assuming all of these links are created
equal.
So at that point, the root bridge's designated port is going to connect to
other bridges
root ports.
Now another takeaway is that a DP, a designated port, cannot communicate with
another designated
port.
Remember, designated port implies downstream and that's one of the biggest take
aways from
this conversation.
A root port implies upstream, designated port implies downstream.
We can't both be sending downstream to one another. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We can't both be sending downstream to one another.
One of these interfaces has to be considered to be upstream.
So a designated port will always communicate either downstream to a root port,
which remember,
root port is upstream, or a designated port will communicate to a non-design
ated port,
which is also upstream, which makes sense because again, these are going to be
considered
downstream.
Now also notice in all of this that only one side of a link gets blocked.
We're not just blocking this whole link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're not just blocking this whole link.
We're only blocking this port, meaning that this switch right here, this
designated port,
is treated as normal.
If a broadcast packet comes in to the switch to from a host, it's going to send
it out
this link.
It's also going to send it out this link.
It doesn't care or otherwise it doesn't impact it whether or not the downstream
port is blocking
or not.
This harkens back to the days where we could have had a hub in here, which has
additional
hosts.
If we have a hub that has hosts hanging off of it, then we still need to get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If we have a hub that has hosts hanging off of it, then we still need to get
those broadcast
packets to those hosts, even though switch three is going to end up blocking it
.
So that behavior doesn't change even in a point-to-point switch-based world.
Now one last conversation, recall that the root bridge creates BP DU's and
sends them
out.
It's going to send them out by default every two seconds.
Well these BP DU's flow downstream.
So the BP DU flows this way and the BP DU flows this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the BP DU flows this way and the BP DU flows this way.
So what happens between switch two and three?
Well again, upstream and downstream.
If we're flowing downstream, that means that switch two is going to send a BP
DU to switch
three.
If we send that broadcast message across, it's going to send the BP DU across.
And the regular receiving of BP DU's is what keeps this port in a blocked state
.
If the BP DU stops showing up, well switch three is going to say, "Alright,
well clearly
you're not a path to the root, so I'm going to bring you out of being in a
blocking state,
which can be really, really bad." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which can be really, really bad."
But the flow of BP DU's, the constant flow of BP DU's, this is what maintains
our topology.
Even when they're received on blocked ports, they are processed and that again
is what
keeps that port in a blocked role.
But because of that and because of the fact that BP DU's always flow downstream
, that
means that BP DU's are only ever going to be sent on designated ports.
They're never sent on root ports because that's upstream and they're never sent WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They're never sent on root ports because that's upstream and they're never sent
on
blocked ports because that's upstream.