Well, as we just said in the intro, spanning tree topology seems to have been
developed
with dynamic topologies in mind.
So when we think about maybe back in the day when spanning tree first came out,
we might
have had a series of switches and the thought was just, hey, I might just keep
adding switches
and who knows where I'm going to add switches and where there's going to be
loops.
And if I install a new switch here that has a good priority or a better
priority than
the current route up here, well, then we'd want this route to take over. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the current route up here, well, then we'd want this route to take over.
And so it would take over and all of these ports would go down.
And this type of topology is not really what we have in modern networks.
Maybe we could call this more of a legacy type of architecture.
But in the modern network, we have pretty established architectures.
In fact, we've talked about a lot of these in this course.
So we are likely going to have a pair of switches that are going to form a
distribution layer.
And then we're going to connect our access switches up to the distribution. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we're going to connect our access switches up to the distribution.
And we might have access switches hanging off of access switches here in sort
of a looped
fashion.
But what's probably not going to happen is I'm probably not going to connect an
access
layer switch that I want to be the root.
This is not a good idea. And if I do connect to access layer switch that's
going to take
over his route, it's probably an accident.
This is going to cause us a whole lot of grief.
It's going to cause outages. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to cause outages.
Yes, rapid spanning tree will help to mitigate this a little bit.
But the question is why even allow this?
Why would we go to the trouble of making it so that I can accidentally do this?
I mean, why not just lock this whole scenario out by establishing that one of
these distributions
switches on a purview land basis will be the root.
And again, it gets locked into place.
This is the goal of this conversation is to make it so that I as the network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is the goal of this conversation is to make it so that I as the network
admin can
decide exactly how I want my spanning tree to apology to be.
Furthermore, we have to worry about potential threat actors out there, the bad
guys.
Because I can take software on my laptop and I can configure it to do pretty
much whatever
I want.
So what's the harm or what's stopping me rather?
There's a lot of harm.
What's stopping me from carrying my laptop in connecting into an access layer
port, maybe
one that's just in the hallway or in an unoccupied conference room and sending WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one that's just in the hallway or in an unoccupied conference room and sending
BPDUs that are
superior.
I can guarantee that I can make a superior BPDU, I can set a priority of zero
and I can set
my MAC address to whatever I want.
So I could make it zero dot zero dot one or something along those lines.
There's no way this wouldn't take over as the root.
So even if I as the network admin and very careful with my switch deployments,
there's
still an opportunity for these threat actors to show up and perform some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
still an opportunity for these threat actors to show up and perform some
nefarious deeds.
And so they just send some BPDUs out in all of the switches in my network
immediately
react and they reelect the root.
The laptop is now the root of the network and I have to send topology change
notifications
and there's massive flooding on the network.
As we can tell, this is going to be a major vulnerability.
And so whether it's an accident here or whether it's nefarious, either way, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so whether it's an accident here or whether it's nefarious, either way, we
need to prevent
our topology from reacting to, I guess we call them switches or other devices
that are accidentally
or not trying to take over as the network root.
So there are two points of vulnerability in the network that we need to address
.
First of all is down here.
This is our access layer connections and we are saying that there should be no
BPDUs
coming in at the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
coming in at the edge.
So that's point number one and this is what we're going to talk about here in
this video.
But the second point of vulnerability would be here, a port where BPDUs are
expected,
but they should always be inferior.
And so that will be our root guard conversation in the next video.
So let's go and talk about case number one here and that is going to be
resolved with
the mechanism that Cisco gives us called BPDU guard.
Now what I just said there is very important. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now what I just said there is very important.
This is a Cisco mechanism.
This is not part of the STP standard.
And so when we're looking at what spanning tree is and how it's designed, it
doesn't
help us out with any of this.
Fortunately, Cisco does give us these mechanisms.
And so when we're building a network on Cisco switches, I can deploy something
like BPDU
guard.
BPDU guard is intended to go where BPDUs are expected.
It's okay or it's easy for us to identify where in the network this would be, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's okay or it's easy for us to identify where in the network this would be,
especially
when we have a modern architecture.
Because I can look at it and say at the edge is typically where I'm talking
about, which
is those access layer ports, we should never get a BPDU.
So again, we look at our threat actor down here.
They're using a laptop to send BPDUs at the edge.
Why even allow BPDUs?
That scenario is there going to be where I as a network admin want BPDUs to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That scenario is there going to be where I as a network admin want BPDUs to
show up on
an edge port.
Now again, spanning tree back in the day here, we didn't know which ports a
switch would
show up on.
It could be this port here with a switch, it could be this port here with
another switch,
and that's why it's so dynamic.
But in the modern architecture, we never want BPDUs to show up and be processed
into
influence the topology if they're showing up at the very edge.
So what we can do is we can get onto our switch and when we have an access port WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what we can do is we can get onto our switch and when we have an access port
, meaning that
this is intended for laptop and printer connectivity, I can place BPDU guard as
a configuration
onto this port.
BPDU guard does exactly what it sounds like it's going to do.
It's going to guard against BPDUs.
So normal operation, everything is fine, but if a BPDU were to arrive, it's
going to place
the port into what's known as air disable. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the port into what's known as air disable.
Now air disable is a little bit of a topic in and of itself.
It's effectively in a shutdown state, meaning that it's not going to process
any traffic.
It's going to block all traffic, not just BPDUs.
So if the threat actor here sends a BPDU to an interface with BPDU guard, this
port effectively
gets shut down and that means that the threat actor has no access to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
gets shut down and that means that the threat actor has no access to the
network.
Or for that matter, if I accidentally plug a switch in and it sends a BPDU, the
exact
same thing is going to happen and that port will be shut down.
Now like I said, air disable can be a topic in and of itself.
The long story short of air disable is that it will require manual intervention
.
I'm going to have to go to that switch port and say, "Okay, I see why it was
shut down.
I'm going to remove air disable."
And I simply do that by shutting the port and then bringing it up using no shut WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I simply do that by shutting the port and then bringing it up using no shut
.
So I do a shut, no shut.
Air disable is cleared, port comes back online.
If the issue's still there, it'll go right back into air disable.
If a BPDU shows back up, just going to go back into that state.
So long as no BPDU's are showing up, then I can clear it out.
I can also perform air disable recovery as a global configuration and that'll
allow it
to attempt to automatically restore connectivity on air disabled ports.
But either way, we understand it's going to get shut down and it's either going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But either way, we understand it's going to get shut down and it's either going
to require
manual intervention or maybe I can configure it to just automatically try to
recover every
30 seconds or 60 seconds or something along those lines.
Now when we consider the configuration for BPDU guard, it can be enabled on a
per interface
basis.
So I can get on to every interface and I can enable BPDU guard, but this is an
access layer
technology.
It's going to require being placed on all edge ports and that could be hundreds WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to require being placed on all edge ports and that could be hundreds
if not
thousands of ports in my network.
So fortunately Cisco gives us another option.
So we can actually tie BPDU guard to the port fast configuration that we talked
about earlier,
which can then be tied to access ports and all of this from a global
perspective.
So remember, I can globally tell a Cisco switch that I want to deploy port fast WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So remember, I can globally tell a Cisco switch that I want to deploy port fast
to
all access ports.
Well, I can also tie BPDU guard to this.
This means that any port that's in access mode will automatically not only
receive port
fast, but also BPDU guard.
This is typically desired in production networks.
I want this configuration to go on every edge port.
That is where it belongs.
That is where it should go in the vast majority of production networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That is where it should go in the vast majority of production networks.
If not all production networks.
We want BPDU guard to protect us from BPDUs showing up on interfaces where BPD
Us do not
belong.