Well, Rapid Spanning Tree is going to make some other changes, including the
fact that
the port states are going to be slightly different.
Now we think about 802.1D, traditional spanning tree, we had five different
port states, starting
with disabled, saying that the port just isn't working right now, at least from
a spanning
tree perspective.
And then of course we have blocking, which says that we're receiving BPDUs, but
we're
not doing anything else.
And then listening, learning, and forwarding, which is our traditional path to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then listening, learning, and forwarding, which is our traditional path to
bring a port
online.
Well, 802.1W, Rapid Spanning Tree, recognized that these three states largely
have the same
function.
Even those different situations, especially for example listening, we know that
we're
trying to bring a port online, but functionally it's doing exactly what
blocking is doing,
which is we're not doing anything.
We're not learning MAC addresses, we're not sending any packets or anything
like that.
So 802.1W, again, Rapid Spanning Tree calls this the discarding state, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So 802.1W, again, Rapid Spanning Tree calls this the discarding state, which is
abbreviated
as DIS.
Now notice DIS over here stood for disabled.
Now it stands for discarding.
So we're discarding packets regardless of what the situation is, which yes
means that
when I bring a port online, it's going to sit in the discarding state for 15
seconds
by default, then it will go to learning for 15 seconds, and then it will go to
forwarding. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forwarding.
So it still takes 30 seconds to come online.
We're just not going to see LIS listed.
We're going to see DIS listed because we're discarding for 15 seconds.
And this is important because again, even though we are getting rid of the
listening
state, we haven't gotten rid of what the listening state was doing.
So that process still plays out.
And when we look at our Cisco iOSXE later, we're going to see that yes indeed,
we do
still have to wait for those 15 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
still have to wait for those 15 seconds.
Now that said, when we do connect two switches together using Rapid Spanning
Tree, we're
going to use those negotiations to spin things up a whole lot faster to the
point that we
really don't see this process pan out very often.
Specifically, we're going to see that when we get a superior BPDU sent across
this link,
that this port here decides that, hey, this is my root port.
Or potentially, maybe it's not my root port, but let's just say it's the root WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or potentially, maybe it's not my root port, but let's just say it's the root
port.
It's going to alert the other side that, hey, I have decided this is my root
port, which means
that this side knows immediately it can be an affording state.
This side can immediately be an affording state because it's its root port.
And this is why it comes up so quickly.
And so the odds of us even paying attention to this enough to see that there's
no listening
are pretty low.
We don't see the listening and learning process, which is now discarding and
learning.
We don't see that process play out very often.
We also need to pay attention to the edge ports because our edge ports are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We also need to pay attention to the edge ports because our edge ports are
again going
to transition directly into forwarding just like they did before.
Now before this is interesting, as we talk about our port types, we have a port
type edge
now defined officially in rapid spanning tree.
So remember Cisco created the concept of port fast and port fast allowed an
edge port
to transition immediately to forwarding. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to transition immediately to forwarding.
And that would hopefully just allow us to bring end devices online immediately
without
a risk of there being a loop.
Furthermore, they do not trigger TCNs as topology change notifications.
That's a very important part of the edge port concept.
And if a BPDU is received, it's going to transition to normal operation,
meaning it's
going to go back to this process and more likely to the negotiation process of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to go back to this process and more likely to the negotiation process of
rapid
spanning tree.
So Cisco created this concept with traditional spanning tree, but they created
their own
way of doing it with port fast.
Well now again, it is part of the rapid spanning tree standard.
They basically copied and pasted port fast and said, okay, this is now in rapid
spanning
tree.
However, this is still a manual configuration.
I can do it per interface.
I can do it globally as we described before. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I can do it globally as we described before.
But this is not something that spanning trees is going to be able to figure out
on its own.
We need to indicate to rapid spanning tree, which ports are edge ports in some
capacity.
And the beautiful thing about this is that in iOS Xe, the configuration still
uses the
port fast commands.
Even though on the back end, it's configuring the standardized version of it.
We understand that there's value in keeping commands the same.
And so we still enable it with spanning tree port fast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we still enable it with spanning tree port fast.
However, in other platforms, for example, Cisco's Nexus platform, NXOS, we don
't have
port fast because we don't use many Cisco terms on NXOS.
We always want to run standardized commands.
Or at least that's how Cisco built it is to run port channel commands instead
of ether
channel commands, as we talked about earlier.
And so instead, we're going to see a much longer command where we say spanning
tree port
type edge in NXOS. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
type edge in NXOS.
And so the command might look different.
Technically, NXOS's version is more accurate because we are no longer running
Cisco port
fast.
We're running the rapid spanning tree official version of that.
But do understand that the command is the same, even though it's not react
ivating port
fast, it is, however, activating all of the same features that poor fast had.