Well, BPDU Guard was a great start, but it can't be used on all interfaces.
For example, what if we've got our distribution layer here and we've got our
access layer
and we've got BPDU Guard down here, which is exactly where it belongs at the
edge of
the network.
But then I'm going to connect this access layer, switch up to the distribution
layer,
and what if this is a 4K priority on the root?
And then we have an 8K priority on the backup root, but then down here we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we have an 8K priority on the backup root, but then down here we
configure this
to be a zero.
Maybe it was a misconfiguration, maybe it was, again, an old lab switch that
was accidentally
connected to the network.
Maybe it was malicious, but either way, this switch is going to take over as
the root.
I say, well, maybe we should deploy BPDU Guard, but we can't.
We can't deploy BPDU Guard up here because even though BPDU's tend to flow only
downstream,
we might have a situation where this port goes down and then it comes up and
when the
port comes up, this switch sends a BPDU first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
port comes up, this switch sends a BPDU first.
Yeah, it's inferior, so it doesn't really matter.
But if we have BPDU Guard configured here, then that port will be placed into
air disable.
And so we cannot place BPDU Guard here on the off chance that we receive an
inferior
BPDU.
So now we have this situation where BPDU Guard is great when there should be no
BPDU's expected.
But now we need something for up here where we say that inferior BPDUs are okay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But now we need something for up here where we say that inferior BPDUs are okay
.
However, if we have a superior BPDU come in, then this is not okay for lack of
better
words.
This is the mechanism that, or this is going to lead us to a conversation
around a mechanism
that's going to do exactly this for us to allow the inferior BPDUs to come in,
but not
allow superior BPDUs.
So that mechanism in particular that we're talking about here is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that mechanism in particular that we're talking about here is going to be
known as
root guard.
Now yes, there is a pretty large similarity in some of these mechanism names, B
PDU Guard
or root guard, it's not always easy to keep them all apart in our minds.
So as best we can, just keep in mind that BPDU Guard protects against any BPDUs
coming
in, whereas root guard prevents any kind of root claim from coming in.
So try to think of it in that terms. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So try to think of it in that terms.
We're trying to block superior BPDUs, meaning you're claiming to be the root.
Therefore, I'm going to block you.
So root guard is going to go on downstream interfaces.
Now remember, in our modern networks, we have a sense of what a downstream
interface should
be.
We know that our root is here at the distribution layer with intentionality,
meaning that these
two interfaces going down towards axis layer switches should be considered WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
two interfaces going down towards axis layer switches should be considered
downstream.
These are ports that are normally going to be in designated port status.
So remember our roles.
We've got root ports, designated ports.
This is going to be a DP role in a stable network.
And importantly, it's going to allow our inferior BPDUs.
So if that link flaps for any reason, or if I'm just, for that matter, allowing
a, or
bringing a new switch online, then it's going to allow those inferior BPDUs to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bringing a new switch online, then it's going to allow those inferior BPDUs to
show up because
it ignores inferior BPDUs.
They don't impact my topology.
In fact, all I have to do is wait for my Hello Timer to expire, and I will send
the superior
BPDU.
And as long as everybody's playing by the right rules, the axis switch will
recognize,
hey, I'm not actually the root.
And therefore I'm going to stop sending BPDUs upstream.
But even if for any reason it keeps sending inferior BPDUs upstream, that's
fine because
inferior BPDUs always get ignored. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
inferior BPDUs always get ignored.
And I will, as the root, or as another switch, I will continue to send the
superior BPDUs
down that link.
So what happens if a superior BPDU is received on a root guard port?
Well, at this point, what happens is we've got a device, and this could be the
root.
It could just be an upstream switch.
And so I connect this switch down here with a priority of zero.
It sends a superior BPDU, and we have root guard enabled. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It sends a superior BPDU, and we have root guard enabled.
But what's going to happen is we're going to place that port, that interface,
into an
interesting status.
We're going to call this STP, your Spanning Tree Protocol, inconsistent state.
This is not a state that we have covered because it's really not a real
spanning tree
state.
This is something that, again, ties to these Cisco enhancements that are going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is something that, again, ties to these Cisco enhancements that are going
to allow
us to protect our network.
The STP inconsistent is essentially saying, "Hey, we're going to temporarily
block a
port."
Meaning that we're not placing it into shutdown, we're not doing any kind of
air disable or
anything like that.
That is not what root guard is going to do for us.
We don't need to worry about a port being inaccessible and us having to go
manually
intervene or rely on air disable recovery.
In this case, we are temporarily blocking the port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In this case, we are temporarily blocking the port.
As long as I'm receiving superior BPDUs, I'm going to keep this port in an STP
inconsistent
state.
We'll see in the lab later that this actually does show up as the status in our
Spanning
Tree commands.
The keyword here is temporarily, meaning that once the superior BPDUs stop,
once the superior
BPDUs stop, then we place this back into our STP listening state and ideally we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
BPDUs stop, then we place this back into our STP listening state and ideally we
transition
all the way up to forwarding.
This is meant to protect us in the event that, oops, I accidentally connected a
switch with
the bed priority.
Fortunately, the network was protected by root guard, so I get in here.
I make my configuration change.
Now it's no longer zero, but it is back to its default 32K, whatever it is I
set it to.
At this point, the superior BPDUs stop, meaning that I transition from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
At this point, the superior BPDUs stop, meaning that I transition from
inconsistent now to
listening, which eventually goes to learning, which eventually goes to
forwarding.
Root guard is a very important part of our protection mechanisms and it's
absolutely
critical that we deploy this into our networks.
The question is always where, where are we deploying these key technologies?
So I have my distribution layer here, I have my access layer, switches, and so
as we've
said, our BPDU guard is going to go down here at the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
said, our BPDU guard is going to go down here at the edge.
This is where there's not to be any switches at all.
However, that doesn't help us on these links that are among switches.
So where does root guard go?
Root guard is going to again go on our downstream interfaces specifically here
and here, but
if for any reason I do have switches hanging off of other switches at the
access layer,
then it can also go here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
then it can also go here.
It's any downstream interface in my established topology.
And so that prevents a switch from showing up down here, the priority of zero,
and this
switch thinking that this is the root, at which point root guard will still
protect the
distribution layer, but it wouldn't actually protect this intermediary switch.
So that's why it's useful to put on all downstream ports, again in our stable
state or steady
state topology.
Now here's the question. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now here's the question.
What about this link in here?
Because technically speaking, this is a downstream connection.
And so we could put root guard on that port here.
But it doesn't really, it's not as effective because in this particular
scenario, the distribution
layer is pretty well set.
I mean, the odds of somebody coming in here and changing the priority statement
number
one is pretty unlikely.
It's a very important switch.
But number two, it also isn't the worst case scenario for us to have to deal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But number two, it also isn't the worst case scenario for us to have to deal
with that.
The topology will shift where now the other distribution switch is the root and
yes, that
will create a disruptive event, but at least the root remains in the
distribution layer.
So that's fine to put the root guard here.
But here's the biggest caveat.
Root guard is not perviland, meaning that if I have multiple topologies in a
perviland WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
perviland
spanning tree environment, which I absolutely should, well now I can no longer
place that
link into a root guard perspective because I'm going to be getting superior BP
to use
this way for the other VLANs.
So long story short, we do not actually apply root guard onto this interface
between our
distribution switches as much as anything because we cannot do it on a perv
iland basis.
And therefore we can't define which side is downstream perviland. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And therefore we can't define which side is downstream perviland.
So root guard primarily belongs down here on these interfaces facing the access
layer
and it can also go down here on access layer switches that face other access
layer switches
always again in the downstream direction.
Now one last note on the configuration.
We mentioned before that BP-DU guard belongs at the edge and therefore can be
deployed
automatically to all of our edge ports.
And that's based on a port being in access mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's based on a port being in access mode.
Root guard doesn't have that same benefit.
Root guard must be configured on every single interface.
And this is with intention because we as network admins have to define which
interfaces
are intended to connect to other switches.
Again I have to decide which of these interfaces are downstream and will be
receiving on occasion
those inferior BP-DUs.
So I must do the configuration myself, I can't automatically deploy this and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I must do the configuration myself, I can't automatically deploy this and
that really
again does make sense given the location and the role that we expect root guard
to play.