Next up, we need to learn about the port states. The port roles tell us a lot
about
where in the network a port is. Is it the best path to the route, for example?
Is it
not the best path? Is it a downstream port? But the port state is actually
going to
determine whether it's blocking or forwarding as well as a couple of other
behaviors. And so there's five different states that we need to worry
about. First of all, is listening abbreviated as LIS. We also have learning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about. First of all, is listening abbreviated as LIS. We also have learning
abbreviated as LRN. And this is something that we see by the way at Cisco CLI.
So
for an iOS XE, we're going to see these usually abbreviated. So then we've got
forwarding like forwarding ports, FWD. We also have blocking. We've already
used
this shortcut BLK for blocking. And then lastly, we have disabled, which can be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this shortcut BLK for blocking. And then lastly, we have disabled, which can be
abbreviated as DIS. Now, just to get a couple of these out of the way, as we
can imagine, blocking means that we have no traffic forwarding. This is going
to be
our loop prevention mechanism. The port in our topology that we had on the
previous video, when we were blocking here, this was in a blocking state.
Remember,
that's the state. But the role was a non designated port or a blocking port. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that's the state. But the role was a non designated port or a blocking port. So
we do need to make sure we understand the distinction between the role and the
state. The other one to knock out here is disabled. Disabled means that it's
administratively shut down. So if I've got a port on this switch and I log into
it and I disable it, well, at that point, from a spanning tree perspective, it
's
considered to be disabled and not part of the spanning tree topology. So the
more
interesting states are these three up here, because what we'll find is that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
interesting states are these three up here, because what we'll find is that
both
designated ports and root ports are going to go through a process that starts
with
listening, goes to learning, and then goes to forwarding. In fact, we might
actually find that a non designated port can do the same thing. It can start at
listening, go to learning, and then go down to blocking. So let's zoom in here
and take a look. Let's say that we just brought a connection online. And let's
specifically look at this port right here. Now, when spanning tree is looking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specifically look at this port right here. Now, when spanning tree is looking
at a
brand new port, it's going to want to know, hey, is there a loop here? Because
maybe we already have a connection to the switch, or maybe we don't. Either way
,
our primary concern is loop prevention. We care greatly about loop prevention,
speed, at least with the original spanning tree, not really a priority. We'd
really rather take our time and make sure that there's not a loop before we
turn this port into a forwarding port. And so what we're going to do is we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
turn this port into a forwarding port. And so what we're going to do is we're
going to start in the listening state. The listening state means that we're
effectively blocking. But we're also doing absolutely no MAC address learning.
So basically, we're doing nothing other than receiving traffic and potentially
allowing the upstream device to recognize that this port is online. It's
more or less a massive buffer. The learning state changes this. It is still
blocking effectively, but we are going to start to learn. What do we mean by WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
blocking effectively, but we are going to start to learn. What do we mean by
learning? Well, that means that we're going to insert entries into our cam
tables. What kind of traffic might I be getting on a port that hasn't sent any
traffic? Well, maybe we're going to get broadcast traffic, or maybe we're going
to get flooded traffic. But either way, if we do get traffic, then we can add
MAC addresses into the cam table so that that will reduce flooding once we
finally come online because we'll have more entries and fewer situations where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
finally come online because we'll have more entries and fewer situations where
we need to flood. Now, if this process goes well, and I'm sending a superior
BPDU out this port, that means that this is a downstream port and it must be
designated. This means that I'm going to transition from learning to
forwarding. If indeed, I'm in a designated port role, which is determined by
the
BPDU flow, we are determining the role somewhere in here. Usually during the
listening state, we're already determining our role. But what happens if we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
listening state, we're already determining our role. But what happens if we
determine that the situation is reversed? What if we're sending superior BPDU's
this way, and I can't send those? Well, at that point, I still progress through
listening and learning. And as I indicated up here, at that point, we're
going to decide, hey, since I am a non designated port, then I'm going to move
into the blocking state. So again, we determine the role pretty early as fast
as we can. And once we have our role, then eventually we can transition over to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as we can. And once we have our role, then eventually we can transition over to
our particular state. Now, we're going to learn about timers, but our listening
and our learning, by default, each take 15 seconds. Because they each take 15
seconds, we have to do both of these, that means that it actually takes a total
of 30 seconds to bring a port online. And yes, this, this actually applies even WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 30 seconds to bring a port online. And yes, this, this actually applies even
to somebody with a laptop. If I'm a college student, and I come home from a
class, and I hard wire my laptop in to a switch, if we don't have anything else
configured other than standard spanning tree operation, it will take 30 seconds
for spanning tree to trust that this is a designated port. And yes, it is a
designated port. It's going away from the route. It's going towards a device
that's not even sending me BP to use. So it will decide to become a designated
port, but it will still take 15 seconds for it to move to the forwarding state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
port, but it will still take 15 seconds for it to move to the forwarding state.
So back to our topology up here, we know that this was in a non designated or
blocking port role. And we already said it's in the blocking state. Everything
else is going to be in the forwarding state when we're in steady state
operation, meaning that we've already gone through, or we've already been
online
for a while. Therefore, we're all going to be, oops, I missed one, there we go.
We're all going to be forwarding other than this port right here. However, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're all going to be forwarding other than this port right here. However,
if I do connect a new switch, well, at this point, that's a really weird
connection. There we go. At this point, we're going to transition from
listening
to learning before we get to forwarding. And that's going to apply to both this
port here and this port on the other side. It doesn't matter, even if this is
the
route bridge, we still have to go through this process. And so it is going to
come
back to taking 30 seconds for us to bring ports online using traditional
spanning tree mechanisms.