All right, so let's remember our scenario here.
The idea is that loops can form if we have an established topology and we've
got some
kind of loop type of physical loop where spanning tree is blocking a port here.
We're receiving our BPDUs to maintain that topology and then the BPDUs just
stop.
Now if this stops because of a unidirectional link and we have UDLD configured,
then we're
good to go because we're just going to shut that link down from whichever side WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
good to go because we're just going to shut that link down from whichever side
detects
the unidirectionality, maybe both sides place it into air disable.
But what if this isn't actually the situation?
What if we are in a bidirectional link type of scenario and yet the BPDUs still
stop?
What would even cause that?
Well, believe it or not, I actually got to experience this firsthand.
As a consultant, I was called down one of our major customers that their whole
data
center was down and they couldn't figure out what was going on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
center was down and they couldn't figure out what was going on.
Fortunately, they're only about 20 minutes away.
I popped in my car and drove over there, started logging into the consoles on
their core devices
and their data center, come to find out that for whatever reason, one of their
aggregation
switches, so this would be like their distribution switch in the data center,
which was the root
bridge at the time, just decided to stop sending BPDUs.
But spanning tree protocol process that's supposed to send the BPDUs out just
crashed
and it didn't take all of the iOS device down, it didn't crash the whole switch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it didn't take all of the iOS device down, it didn't crash the whole switch
, it
just crashed spanning tree topology.
It's one of those situations that feels like it's something that should never
actually
happen and yet it absolutely happened.
And had they had loop guard deployed into their environment, then that would
not have
been a problem.
Unfortunately, they set their own environment up and so all of our best
practices for deploying
loop guard didn't actually happen to be in place.
And so what happened was the BPDUs stopped because the spanning tree protocol WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so what happened was the BPDUs stopped because the spanning tree protocol
process
stopped and because this switch downstream stopped receiving the BPDUs, it
transferred
that block state into forwarding and as a result, there was a massive loop in
the data center.
And I wish I could say we just got the network back online and everything was
good to go,
but because the network was down for 20 minutes or so, 25, 30 minutes, whatever
it was, we
got it back online, but their data center experienced a massive data corruption WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
got it back online, but their data center experienced a massive data corruption
out
of that they were down for a very long time.
So it's amazing how loop guard in this environment could have actually saved
them from literal
days of outages as a result of this simple network outage.
So what exactly is loop guard and how is it going to keep us up in this
scenario?
Well, loop guard sort of does the same thing as UDLD, except it does it from a
spanning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
spanning
tree protocol perspective.
It's going to be watching for BPDUs and specifically when BPDUs stop.
If BPDUs stop coming in and the link stays online, which was again part of this
scenario,
BPDU stop, the link stays online, it says, you know what, in a hubless
environment, this
is not okay.
Remember, the reason why spanning tree says that this is okay is because there
might
be a hub in here.
Like we said, and this link up here goes down, but in the modern network, or at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Like we said, and this link up here goes down, but in the modern network, or at
least in
any network where we're being intentional about things, we can look at that and
say
there is no hub there.
And therefore, this is not okay.
And so we're going to block the port.
Now loop guard doesn't throw it into air disable.
Instead it uses that spanning tree protocol inconsistent state inconsistent.
And because it uses spanning tree protocol inconsistent, it will actually place WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because it uses spanning tree protocol inconsistent, it will actually place
it into
not the blocking state, but that broken state that we saw.
And then if the BPDUs come back and now we're getting those BPDUs again, it
will transition
to the forwarding state.
So loop guard in a way maintains our topology, but it's focusing on the loop
protection element.
It's saying, hey, I don't care why the BPDUs stopped.
If the BPDU stopped for any reason, whether it was a unidirectional link or a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If the BPDU stopped for any reason, whether it was a unidirectional link or a
spanning
tree protocol failure, whatever the situation doesn't matter, that link is
online, the BPDU
stopped, and that's not okay for lack of better words.
And so we're going to go into that broken state via STP inconsistent.
And that's effectively holding and maintaining the blocking nature of that
interface.
Now just like with UDLD, we can enable this on a per port or on a global
perspective or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
perspective or
global level.
However, in this case, it's the same.
We're not focusing on fiber versus copper because this could happen on any type
of port.
It's not more likely on fiber versus copper or anything like that.
So if we do it to global or if we do enable it globally, this is going to
enable it on
all ports.
And we might look at that and say, okay, is there any harm in that?
Generally speaking, the answer is no.
There is no harm in loop guard.
The only harm with loop guard would be if there is that hub sitting out there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The only harm with loop guard would be if there is that hub sitting out there
somewhere in
which case we would not want to keep that port in a blocking state.
But if there are no hubs in our environment, which is every single environment,
every single
network in the modern era, then this is perfectly fine.
This is a okay.
And generally speaking, in production networks, we want to see loop guard
enabled globally
so that it's running on every single port.