Hello and welcome to Jeremy’s IT Lab. In this video, we will cover one more feature in the STP toolkit, Loop Guard, which basically acts as an extra line of defense against layer 2 loops. Now, the entire point of spanning tree protocol is to prevent loops, that’s why we use it, so what role does Loop Guard play? Well, that’s what we’ll cover in this video. In the previous few videos we’ve covered these four features of the STP toolkit: PortFast, BPDU Guard, BPDU Filter, and Root Guard. Now we’re moving on to Loop Guard, which protects the network from loops by disabling a port if it unexpectedly stops receiving BPDUs, ensuring it does not mistakenly enter the Forwarding state. There are a few situations where this might happen, such as a software bug on one switch that stops it from sending BPDUs. But in this video we’ll look at one specific scenario: a unidirectional link. So, we’ve got these two switches, SW1 and SW2, and let’s connect them together. Under normal circumstances, this is a bidirectional link, meaning SW1 can transmit data to SW2, and SW2 can transmit data to SW1. But a unidirectional link is a network link where data transmission occurs in only one direction. For example, SW1 can send frames to SW2, but SW2 can’t send frames to SW1. This is obviously not a desirable situation, and is typically caused by a layer 1 issue, some physical problem with the hardware preventing data from flowing in one direction. For example, damaged cables could cause this, or faulty connectors or transceivers, such as the SFP, small form-factor pluggable, transceivers used for fiber optic connections. In fact, unidirectional links are more common with fiber-optic cables than copper UTP cables. Why is that? Let’s see. As we covered back in the beginning of the course, fiber-optic connections typically use two separate fibers, as I’ve changed the diagram above to show. The Tx, transmission, side of SW1 connects to the Rx, reception, side of SW2. And the Tx side of SW2 connects to the Rx side of SW1. Although they are separate fibers, these two fibers are considered one cable, connecting one interface on SW1 to one interface on SW2, and allowing both of them to send and receive data. The problem is that if one fiber is damaged, it can disrupt data flow in one direction, while the other remains unaffected. And on top of that, fiber-optic cables are simply more vulnerable to physical damage than copper UTP cables. If you bend a fiber cable too far, you’ll hear a small snap, and then the cable is dead: you won’t be able to use it. Now, for a fiber-optic interface to be up/up, both fibers must be connected and functional. For example, look at this connection between two switches. They’re connected by a fiber-optic cable, and the two fibers are connected on both sides, so the link lights are green. So, that’s what a functional fiber-optic connection looks like. If there is a problem with either fiber, the devices should be able to detect it and disable their interfaces. So, if you disconnect or cut this fiber, SW1 and SW2 should detect it and disable their interfaces. This doesn’t result in a unidirectional link – the link is disabled entirely. Let’s take a look at that connection again. With one fiber disconnected, the link lights are now off. And after damaging the fiber, even if I connect it, the link lights remain off. But not all physical problems preventing communication will be detected. And if the devices fail to detect the physical problem, it could result in a unidirectional link. If there is a problem on one of these fibers that prevents data transmission, but the devices don’t detect it, their interfaces will remain up/up, and now we have a unidirectional link. SW1 can transmit data to SW2, but data that SW2 transmits can’t reach SW1. They both think the connection is up and running, but actually it only works one way. So, what’s the problem with a unidirectional link? Before we cover Loop Guard, let’s see the problem it solves. Loop Guard doesn’t prevent unidirectional links, but it can protect against the negative effect that a unidirectional link has on STP. As you know by now, BPDUs originate from the Root Bridge and are forwarded out of designated ports like this, every 2 seconds. And these BPDUs are how the switches share information with each other to determine the STP topology; which interfaces should be forwarding, and which interfaces should be blocking. In this network, SW3 G0/1 is a non-designated blocking port because it receives superior BPDUs from SW2. To keep the diagram simple I didn’t include any details, but this is either because SW2 has a superior root cost or bridge ID compared to SW3. But if the SW2-SW3 link becomes unidirectional and SW2’s BPDUs can’t reach SW3, what will happen? Let’s assume there’s a physical issue that prevents SW2’s frames from reaching SW3, but doesn’t cause the switches to actually disable their G0/1 interfaces; the switches don’t detect the underlying physical issue. SW3, which no longer receives BPDUs from SW2, will assume there is no more loop in the LAN. After the max age timer expires, SW3 G0/1 will become a Designated port and start forwarding BPDUs to SW2. And because SW3’s BPDUs are inferior to SW2’s, SW2 simply ignores SW3’s BPDUs. So, SW2 G0/1 and SW3 G0/1 are both in the forwarding state, meaning we have a loop from SW1 to SW3 to SW2. Let’s see how that loop works. If SW1 receives a broadcast frame on one of its other interfaces, it will flood the frame toward SW2 and SW3. The frame flooded to SW2 won’t loop because of the unidirectional link; SW2’s frames can’t reach SW3. But the frame flooded to SW3 will loop around the three switches like this. Each switch that receives it will flood it repeatedly. So, that’s the problem with a unidirectional link in a LAN using STP. SW3 G0/1 stops receiving BPDUs, thinks it should become a designated port and start forwarding frames, and then causes a loop. It would be better if the hardware issue caused the link to go down entirely. In that case, SW2 and SW3 would both disable their G0/1 ports, and there would be no loop. But how can we deal with a situation like this, where a hardware issue causes a unidirectional link? You guessed it: the answer is Loop Guard. So finally let’s see how Loop Guard solves this problem. As I said before, Loop Guard doesn’t prevent physical unidirectional links, but provides a mechanism to detect unidirectional links and then prevent layer 2 loops. When a Loop Guard-enabled port’s max age timer counts down to 0, it doesn’t become a designated port and start transitioning to the forwarding state. Instead, it enters the broken (loop inconsistent) state. That probably sounds familiar. Like the broken (root inconsistent) state triggered by a root guard violation, this blocks the port. Note that, in both cases, whether it’s Root Guard or Loop Guard , the ports remains up/up. So the port isn’t actually shut down, it’s just that STP blocks it. So, let’s say Loop Guard is enabled on SW3 G0/1, and the SW2-SW3 link is unidirectional, preventing SW2’s frames from reaching SW3. The max age timer on SW3 G0/1 starts counting down. Normally, when it reaches 0, it will become a designated port and start transitioning to the forwarding state. But when Loop Guard is enabled, it enters the broken state, preventing a layer 2 loop from occurring. And like Root Guard, recovery is automatic. If the physical issue is solved and the broken port starts receiving BPDUs again, it will be automatically re-enabled. So, how can we configure Loop Guard? Like the other features in the STP toolkit, the actual configurations are simple. It can be enabled in two ways. The first is per-port, with SPANNING-TREE GUARD LOOP in interface config mode. The second is by default in global config mode with SPANNING-TREE LOOPGUARD DEFAULT. This enables Loop Guard on all ports by default. And then you can use SPANNING-TREE GUARD NONE in interface config mode to disable it on specific ports if needed. Loop Guard should typically be activated on any ports that aren’t designated: root and non-designated ports. In other words, ports that are supposed to receive BPDUs from designated ports. Then, if they stop receiving BPDUs, Loop Guard will disable them to prevent loops. Now let’s take a look at Loop Guard in the CLI. I enabled Loop Guard on SW3’s G0/1 port with SPANNING-TREE GUARD LOOP. In the output of SHOW SPANNING-TREE INTERFACE DETAIL, it says “Loop guard is enabled on the port”. So, that’s it; it just takes that one command to enable Loop Guard on a port. But before we see it in action, let’s also see how it looks when you enable it by default. So, this time, instead of enabling it in interface config mode, I used SPANNING-TREE LOOPGUARD DEFAULT to enable it in global config mode. Then, the output of this command is basically the same, but it says “by default” at the end. Okay, now let’s see what happens when Loop Guard blocks a port. Currently, all links are operational and SW3 G0/1 is receiving BPDUs from SW2. But what if the link connecting them becomes unidirectional? Well, this message is shown in the CLI: Loop guard blocking port GigabitEthernet0/1. And in the output of SHOW SPANNING-TREE, G0/1’s status is BKN, and it also says LOOP_Inc. As you probably guessed, BKN means broken, and LOOP_Inc means Loop Inconsistent. The port is blocked because it stopped receiving BPDUs. Maybe there’s a sharp bend in one of the fibers that degraded the signal, preventing SW2’s BPDUs from reaching SW3. But then, perhaps someone adjusts the cable and the data starts flowing again, and Loop guard automatically unblocks the port because it starts receiving BPDUs again from SW2. As you can see here, G0/1’s status is now blocking, not broken, and it doesn’t say Loop Inconsistent anymore. So, like Root Guard, Loop Guard automatically re-enables a port if the problem is fixed; you don’t have to issue any commands to re-enable the port. I’ve added another switch to this LAN, one that is not your switch; you don’t have direct control over its configuration. Before we wrap up this video, let me point out something about Loop Guard and Root Guard. These two features are mutually exclusive, and by that, I mean they can’t be enabled on the same port at the same time. And that’s because they basically serve opposite purposes. Root Guard is meant to prevent designated ports from becoming root ports. If a Root-Guard enabled designated port starts receiving superior BPDUs, it will be blocked. And Loop Guard is meant to prevent Non-Designated or Root ports from becoming Designated ports. If a Loop Guard-enabled port stops receiving BPDUs, it will be blocked. So, looking at SW3 in the network above, G0/0 and G0/1 should use Loop Guard, and G0/2 should use Root Guard. It wouldn’t make sense to configure the opposite. For example, SW3 G0/0 and G0/1 are supposed to receive BPDUs from SW1 and SW2. If you configure Root Guard on them, they’ll both be blocked, cutting off communication in the LAN. Okay, so just remember that you can’t enable both on an interface at the same time. How does that affect the configurations? If Loop Guard is configured on a port, with SPANNING-TREE GUARD LOOP, and you then configure Root Guard, with SPANNING-TREE GUARD ROOT, Loop Guard will be disabled on the port. The Root Guard command will replace it. And vice versa. If Root Guard is enabled on a port and you then configure Loop Guard, Root Guard will be disabled. And if Loop Guard is enabled by default, in global config mode, and you then configure Root Guard on a port, Loop Guard will be disabled on the port. In other words, the more specific configuration takes effect. The interface command applies only to one interface, it's more specific than the global command, so the interface command takes effect. This is true for many features in IOS. For example, it’s the same for PortFast, BPDU Guard, and BPDU Filter. If you enable PortFast by default in global config mode, but then disable it on a specific interface, the interface command takes effect. Remember that about IOS commands. Usually, the more specific command takes effect over the less specific command. Okay let’s summarize Loop Guard. Its purpose is to protect the network by blocking a port if it unexpectedly stops receiving BPDUs. This could happen if, for example, there is a software bug preventing a switch from sending BPDUs. Or if there is a hardware issue causing a unidirectional link. A unidirectional link is a network link where data transmission occurs in only one direction. A normal link should be bidirectional, allowing communication in both directions. A unidirectional link is typically caused by layer 1 issues on fiber-optic cables; that’s the most common scenario. If the connected devices don’t detect the issue and disable their interfaces, it can result in a unidirectional link. This prevents BPDUs from reaching the neighboring switch. And if a root or non-designated port stops receiving BPDUs, it will become a designated port, potentially causing a layer 2 loop. Loop Guard’s role is to protect against this. If a Loop Guard-enabled port stops receiving BPDUs, it enters the broken “loop inconsistent” state, effectively disabling the port. But if it starts receiving BPDUs again, it will be automatically re-enabled. There are two ways to configure it. The first is per-port, with SPANNING-TREE GUARD LOOP in interface config mode. The second is by default, with SPANNING-TREE LOOPGUARD DEFAULT in global config mode. This enables it on all ports, but you can then use SPANNING-TREE GUARD NONE to disable it on specific ports if needed. It’s similar to enabling PortFast, BPDU Guard, or BPDU Filter by default and then disabling them on individual ports. Final point: Loop Guard and Root Guard are mutually exclusive, so they can’t be active on the same port at the same time. So, if Loop Guard is configured on a port and you then configure Root Guard, Loop Guard will be disabled, and vice versa. And if Loop Guard is enabled by default and you configure root guard on a port, Loop Guard will be disabled on the port. Only one can be active at a time on each port. Okay, that’s all for this video on Loop Guard. I hope it was helpful. Thanks for watching.