Well, Portfast has been around for quite a while. In fact, a lot of us as
network engineers,
even if we haven't been around for very long, we're probably familiar with the
concept of
Portfast. We typically are going to apply this to our edge ports, and the
reason for that
is primarily because it speeds up our ability to connect. Now, how exactly does
it do that?
Well, we have to think back exactly to how Spanning Tree operates with any of
its ports.
So we're looking at a traditional Spanning Tree 802.1D environment. Well, I've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're looking at a traditional Spanning Tree 802.1D environment. Well, I've
got my
switch, I've got my laptop or my PC or my access point or anything I'm trying
to connect
in, and I connect it in and I get to go through the listening and learning
states. Now each
one of these lasts for the four delay timer, which by default is 15 seconds, so
a total
of 30 seconds of wait time. Now, this is great when I've got another switch, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of 30 seconds of wait time. Now, this is great when I've got another switch,
and there's
a potential for loops. And I'm going to connect this and we're going to go
through the listening
and learning phases just to make sure that there are no loops before we bring
this into
a forwarding state. It makes a lot of sense over here. This is very good. But
down here,
we have to ask, why are we doing this? We even know that there's no loops.
There can't be
a loop through a laptop or through a PC, at least not unless somebody's doing
something
extremely malicious. And so at this point, why are we waiting 30 seconds? Now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
extremely malicious. And so at this point, why are we waiting 30 seconds? Now
back when
802.1D came out, waiting 30 seconds for a PC to fully come online or anything
like
that, it's not that big of a deal. But we have mobile devices and we're moving
around
and we might sit down in a conference room with a laptop and plug in and we're
on immediately
faced with the fact that, hey, I'm wired in now. So I was on the Wi-Fi. So the
PC shuts
off the Wi-Fi, tries to use the connection and we lose everything. So maybe I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
off the Wi-Fi, tries to use the connection and we lose everything. So maybe I
was on a
video call and I just lost it for 30 seconds while I wait for spanning tree to
come back
online. All that to say in the modern network, 30 seconds is far too long. And
guess what?
It was far too long a long time ago as well to the point that during the
primary use of
802.1D, Cisco once again said we need a better solution. So they created port
fast.
And incidentally, they created portfast along with two other enhancements for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And incidentally, they created portfast along with two other enhancements for
spanning tree.
One is called uplink fast and the other is backbone fast. So perhaps you've
heard of
these techniques and perhaps not because they are pretty legacy at this point.
But
we noticed that there's that fast at the end of all of them. It sort of binds
them together
from a naming scheme perspective. So generally speaking, uplink fast and
backbone fast and
for that matter port fast, all of this gets wrapped up into the new industry WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for that matter port fast, all of this gets wrapped up into the new industry
standard,
which was rapid spanning tree. And so we don't have to configure uplink fast.
We don't have
to configure backbone fast anymore. Uplink fast was about quickly failing over
between
multiple uplinks in the event of a direct failure. Backbone fast was a little
bit more
of an indirect failure concept to help us detect remote changes and spin that
up a
whole lot quicker. But all of this is baked into rapid spanning tree, including WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
whole lot quicker. But all of this is baked into rapid spanning tree, including
the concept
of port fast. And yet, because we have to define which ports get port fast
configuration, we
still have to do this in iOS XE. And so I'm still getting on to my edge ports
and saying,
Hey, we're going to place this port into spanning tree port fast operation. And
because
it's in port fast operation, now we're going to see a speed up in terms of our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's in port fast operation, now we're going to see a speed up in terms of our
connectivity.
We're trying to eliminate this 30 seconds that we all have to wait. So because
we still
have to configure port fast, a lot of us are familiar with it. Whereas we don't
really,
we don't have to configure these in the modern network. And so we're not as
familiar. But
you know, for our intents and purposes here, we're going to focus in on port
fast, the
uplink fast and backbone fast is really not within scope of our conversation or
what this
exam is going to be testing us on. So what exactly does port fast do? Well, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exam is going to be testing us on. So what exactly does port fast do? Well,
port fast
is going to bypass the listening and learning states, which is pretty
phenomenal. This is
going to save us 30 seconds of uptime. But listening and learning is kind of
important.
We were doing it for a reason, right? So are there any downsides to this? So in
order to
understand that we really need to just kind of think through the process of
what we're
doing here. So remember, we're trying to prevent loops. Listening and learning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
doing here. So remember, we're trying to prevent loops. Listening and learning
is very important
so that we have time to exchange BPDUs. And there might even be a propagation
sort of
a ripple effect, if you will, if this is now in the forwarding state, maybe a
different
port that was in the forwarding state now needs to move to the blocking state,
and so
on and so forth. I mean, a lot of things can happen during that listening and
learning
conversation. But it really only needs to happen with switches. So if I know
that a
port here is going to connect into our access layer devices like a PC or laptop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
port here is going to connect into our access layer devices like a PC or laptop
again, at
that point, I know that there can't be a loop. And so there's no reason for me
to have to
go through listening and learning unless I accidentally connect a switch to
that. So
we'll talk about that scenario in a moment. But in the event that I do just
connect a
laptop into a port fast enabled port, at that point, we are going to
immediately transition
into the forwarding state. And we are making an assumption here, we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
into the forwarding state. And we are making an assumption here, we're going to
assume
that there are no loops. Now assuming can be a very bad thing. It can't really
get us
into a lot of trouble. But in this case, we are probably going to be good in
most situations.
And when we're not, we're going to have a little bit of a fail safe in mind.
But a couple
of quick things about this before we move on. First of all, spanning tree WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of quick things about this before we move on. First of all, spanning tree
continues to
run. In fact, it runs just like any other port and it's going to send BP to use
. So
because we're sending BP to use, it's a downstream port, that means that we're
going to maintain
that this topology. That's how we maintain the topologies to send BP to use. So
I am
still sending BP to use and spanning tree is still running. And this is going
to be exactly
why we're still fine if I do connect a switch. So let's say that I've got this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
why we're still fine if I do connect a switch. So let's say that I've got this
port fast
enabled port and I mistakenly connect a switch that already has a connection,
maybe to the
rest of the network. Did I just create a loop? We can see the loop in here. But
did
I just create a problem for spanning tree? Unfortunately, I did not create a
big problem.
Because what happens here is if a BP to you is received, then we're going to
revert back
to normal operation. We don't want to keep running import fast at that point, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to normal operation. We don't want to keep running import fast at that point,
because
our assumption has been proven false. We received a BP to you, which means we
can't
assume that there's no loops anymore. Therefore, I'm going to immediately
transition to the
listening state and go through listening and learning before I make any
decisions. So this
is a good fail safe. Now what's interesting here is that Cisco actually says if
we enable
port fast on a port that we have to be careful because this can create WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
port fast on a port that we have to be careful because this can create
temporary loops. And
they're technically correct. Why does it create a temporary loop? And how long
is that loop
in place? Well, think about this. What I just said is that we need to receive a
BP view
on the port, which means this switch here needs to send a BP to upstream. How
often
does it send BP to use? By default, every two seconds, but it could be
configured for
four seconds or five seconds. The reality is that we can't react to there being WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
four seconds or five seconds. The reality is that we can't react to there being
a potential
loop until we receive a BP to you. And until that BP to you is received, we
will have a
loop and we will be flooding traffic and sending broadcast traffic through that
loop
and it will create a broadcast storm. So it is temporary and it is very, very
brief,
but we do technically have that risk. And it's a good reason. I would say it's
a good
reason to keep our hello timers at two seconds. But the question is, what's the
switch? Is
this a rogue switch? Is it a, is it a switch that came off out of our stock and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this a rogue switch? Is it a, is it a switch that came off out of our stock and
our inventory?
And if that's the case, maybe it will be still configured for whatever we're
using two seconds,
hopefully. But if it is configured for five seconds, it doesn't matter what the
rest of
my network timers are set to, that's going to be what determines when I form a
loop.
So what do we do in real life in the real world? We absolutely use port fast.
We use
it everywhere that we consider to be an edge port. A lot of our front facing
access layer
ports have port fast enabled. And it is considered good practice. Now, one last WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ports have port fast enabled. And it is considered good practice. Now, one last
consideration
in all this comes back to the end of the last video, where we had said that we
had a problem
with our TCNs. Remember, TCNs are triggered for a couple of situations, but
especially
when a port transitions to forwarding, which is going to apply to my edge ports
, at least
from a standard 802.1d perspective, meaning that if I do plug in this laptop, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
from a standard 802.1d perspective, meaning that if I do plug in this laptop,
it is going
to trigger a TCN. So we can say that we're going to bypass the listening and
learning
state up here. We bypass listening and learning, and it speeds us up. And that
's usually what
we think about when we think about spanning tree port fast. And yet, there's
another
huge part of port fast. With port fast, we do not trigger TCNs. This is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
huge part of port fast. With port fast, we do not trigger TCNs. This is
arguably a bigger
deal than the fact that we're bypassing our listening and learning states. Yes,
it is
extremely noticeable to wait for 30 seconds. And there is no doubt that our
users will complain
like crazy if they have to wait for that. But the fact that we don't send TCNs
means
that our network stays stable. It keeps our Mac address timer for our cam
tables at 300
seconds. We absolutely want to keep it at 300 seconds. If at all possible, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
seconds. We absolutely want to keep it at 300 seconds. If at all possible, we
don't want
to be running at the 15 seconds, which is where we run if we are under a top
ology change.
So let's always keep in mind that port fast is responsible for actually two
major benefits,
not only connecting us faster, but also keeping our spanning tree topology more
stable.