Hello and welcome to Jeremy’s IT Lab. In this video, we’re continuing with the STP toolkit section of our CCNA course. We’re going to focus on BPDU Guard and BPDU Filter, two features that are often used in combination with PortFast, which we covered in the previous video. These features determine how a port reacts when receiving BPDUs and, in the case of BPDU Filter, whether it sends BPDUs, helping to protect and manage your network's STP behavior. Let’s get started. Here’s what we’ll cover. We’re continuing with the STP toolkit. The previous video covered PortFast, a feature that you should enable on switch ports connected to end hosts, allowing them to communicate over the network right away after connecting. In this video, we’ll cover two more. BPDU Guard, which automatically disables a switch port if it receives a BPDU, and BPDU Filter, which stops a port from sending BPDUs or processing received BPDUs. As I said before, these features are often used in combination with PortFast, on ports connected to end hosts. Cisco also expects you to know Root Guard and Loop Guard for the CCNA, and we’ll cover them in the next video. Before introducing BPDU Guard and Filter, let’s see how a PortFast-enabled port handles STP BPDUs. PortFast makes a port start in the Forwarding state when it is connected, but it doesn’t disable STP on the port. So, this switch’s G0/1 port has PortFast activated, and it sends BPDUs every 2 seconds, like a regular STP port. The PC, which doesn’t run STP, ignores the BPDUs, but G0/1 keeps sending them. I used SHOW SPANNING-TREE INTERFACE G0/1 DETAIL, the same command I showed a few times in the previous video. As highlighted, PortFast is enabled on G0/1, and it has sent 77 BPDUs so far, but received 0 from the PC. Because end hosts don’t run STP and send BPDUs, a PortFast-enabled port shouldn’t receive BPDUs. But here’s the question. What if it does? Maybe a user brings their own switch to work, and connects it to the network. What happens then? Let’s see. Instead of a PC, SW1’s G0/1 is now connected to another switch, SW2. As you know, when a switch comes online it assumes it is the root bridge and sends its own BPDUs. So, what does SW1 do upon receiving a BPDU from SW2? If a PortFast-enabled port receives an STP BPDU, it will revert to acting like a regular STP port, without PortFast. Let’s say SW1’s priority is 32768. And SW2’s is 4096. Because SW2 has a lower priority, and therefore a lower bridge ID, SW2 becomes the root bridge, and SW1 G0/1 becomes a root port. So, what’s the problem here? Let’s rewind a bit. Here’s a simple LAN of three switches. SW1 is the root bridge, with all designated ports. SW2 and SW3 each have one root port leading toward SW1, and the link between SW2 and SW3 is blocked. Bob from accounting is a user in the office. Now, usually users don’t connect directly to a switch. Instead, there is a wall jack near the user, such as on the wall of their office, if they have their own office. The switch connects to the wall jack, and the user’s device does too. This is a pretty standard setup. But let’s say Bob is tired of walking to the printer and decides to bring his own printer to work. And maybe the Wi-Fi is slow, so he wants to connect his laptop to the wired network instead of Wi-Fi. But the wall jack in his office only has one port. So, what does he do? Instead of following procedure and creating a support ticket with the IT department, Bob takes things into his own hands. He brings an old switch he had at home to work and connects it to the network. Then, he connects his devices to his switch, and they can all access the LAN. Problem solved, right? Well, maybe Bob’s problem has been solved, but his switch and SW3 start exchanging spanning tree BPDUs, and this could impact the network. For example, what if Bob’s switch becomes the root bridge? If Bob’s switch has a lower STP bridge ID and becomes the root bridge, that can affect the rest of the STP topology. Now each switch’s root port points toward Bob’s switch, and the SW1-SW2 link is blocked. This is a problem – we don’t want a user’s switch affecting the STP topology. For example, maybe SW1 was the root bridge because it’s connected to the LAN’s router. By making SW1 the root bridge, we ensure that each other switch has an efficient path to reach SW1, and therefore the router. But now, SW2’s most efficient path is blocked, and frames from hosts connected to SW2 have to take the less efficient path through SW3 instead. This isn’t a disaster, but in any case, we don’t want unauthorized user devices negatively impacting the network. Let’s summarize and then see how BPDU Guard solves this problem. PortFast should only be enabled on ports connected to non-switch devices, like end hosts or routers. And these devices don’t send BPDUs. However a PortFast-enabled port still sends BPDUs and will operate like a regular STP port if it receives BPDUs from a neighbor. So, if an end user carelessly connects a switch to a port meant for end hosts, like Bob from Accounting, it could affect the STP topology. Shame on you, Bob. Do better. But fortunately, BPDU Guard acts as a safeguard against such a situation. Let’s see how BPDU Guard works. BPDU Guard protects the network from unauthorized switches being connected to ports intended for end hosts, such as SW3’s G0/1 port in this example. BPDU Guard can be configured separately from PortFast, but both features are usually used together, because they both enhance STP’s functionality on ports intended for end hosts. So, what exactly does BPDU Guard do? A BPDU Guard-enabled port continues to send BPDUs, but if it receives a BPDU it enters the error-disabled state. So, if Bob connects his switch to the wall jack and it sends a BPDU to SW3, SW3 will error-disable its G0/1 port. In effect, this disables the port. It can no longer send or receive data or BPDUs. This prevents Bob’s switch from affecting the STP topology, and Bob’s gonna be thinking “the internet doesn’t work” and come complaining to the IT department. Mission accomplished. Let’s see how to configure BPDU Guard. Like PortFast, it can be configured in two ways. First, it can be configured per-port in interface config mode. The command to do that is SPANNING-TREE BPDUGUARD ENABLE. And here’s the output of SHOWING SPANNING-TREE INTERFACE DETAIL for G0/1. As I’ve highlighted, BPDU Guard is enabled. Okay, so you can configure BPDU Guard on each individual port, or you can enable it by default from global config mode. The command to do that is SPANNING-TREE PORTFAST BPDUGUARD DEFAULT. And note that, in modern Cisco IOS, you can optionally add the EDGE keyword when configuring it. Either way, the device will automatically add the keyword to the configuration, like we covered in the PortFast video. Here’s that same SHOW command, showing that BPDU Guard is enabled by default. Now, when you enable PortFast by default it’s activated on all access ports. But BPDU Guard works a bit differently. When you enable BPDU Guard by default, it is activated on all PortFast-enabled ports. Not necessarily all access ports. Remember that difference – points like this can definitely be tested on the CCNA exam. But just like PortFast, after enabling BPDU Guard by default you can then disable it on specific ports if you want: the command is SPANNING-TREE BPDUGUARD DISABLE in interface config mode. Okay, that’s how you configure BPDU Guard. Use whichever method suits you, but make sure you don’t enable it on a port that is supposed to be connected to another switch, as that will disable the port. Continuing on the topic of disabling the port, let’s look at how that works. SW3’s BPDU Guard-enabled port has received a BPDU from Bob’s switch, so it is error-disabled. In SW3’s CLI, you’ll see this message appear. “Received BPDU on port GigabitEthernet0/1 with BPDU Guard enabled. Disabling port.” And another similar message. “bpduguard error detected on G0/1, putting G0/1 in err-disable state”. And then these two messages saying the interface status has changed to down and down. In the output of SHOW INTERFACES G0/1, you can see that the interface has been err-disabled. ErrDisable is a Cisco switch feature that disables a port under certain conditions, such as a BPDU Guard violation. If a BPDU Guard-enabled port receives a BPDU, that’s a violation, and the port is disabled. You will learn a few other examples for the CCNA exam, such as power policing violations, Port Security violations, and DAI, dynamic ARP inspection violations. But those are topics for later in the course. Let’s see BPDU Guard in action on a Cisco switch. I’ve configured PortFast and BPDU Guard on port 1 on the left of the top switch. Below it is another Cisco switch, so let’s connect them. Notice that the link light turns solid amber right after connecting it. That means the port has been err-disabled due to BPDU Guard. It can’t send or receive data. Even if I disconnect the cable, the solid amber link light remains on. Normally, the link light turns off when you disconnect the cable, but in this case it stays on to indicate that the port is err-disabled. As we just saw, disconnecting the cable from the switch doesn’t solve an err-disabled port. So let’s see how to re-enable it so the port can be used again. First of all, to re-enable an err-disabled port, you should first solve the underlying issue. This is key, because if you re-enable the port without fixing the issue, it will just be err-disabled again. In this example, if I re-enable SW3’s G0/1 port, it will just receive another BPDU from Bob’s switch and be disabled again right away. So, let’s disconnect Bob’s switch from the wall jack. And then re-connect Bob’s PC. Now let’s see how to re-enable the err-disabled port. There are two ways to re-enable a port that has been err-disabled: The first is manual, using the SHUTDOWN and NO SHUTDOWN commands to reset the disabled port. The second is automatic, using a feature called ErrDisable Recovery. Let’s see how it works. ErrDisable Recovery is a feature that automatically re-enables err-disabled ports after a certain period of time. To view the status of ErrDisable Recovery on the switch, use SHOW ERRDISABLE RECOVERY. Here’s the output. At the top there’s a list of ‘errdisable reasons’ and their status. The list is quite long, so I’ve omitted most of it, but as I’ve highlighted, BPDU Guard is second on the list. And as it says, ErrDisable Recovery is disabled by default. So, that means that err-disabled ports won’t automatically recover by default, you have to enable ErrDisable Recovery if you want it. As I’ve highlighted in pink, the default recovery timer is 300 seconds, or 5 minutes. This means that err-disabled ports will be automatically re-enabled after 5 minutes if you enable errdisable recovery. You can modify this interval if you want with ERRDISABLE RECOVERY INTERVAL, and then the interval in seconds. But even if you modify the interval, you still need to enable ErrDisable Recovery for it to work, so let’s do that. Use ERRDISABLE RECOVERY CAUSE, and then the cause, to enable it for ports disabled by the specific cause. The ‘cause’ is the feature that disabled the ports. For this video we’re talking about BPDU Guard, but as I said before we’ll cover a few other causes later in the course. For example, if you look at the top of the “ErrDisable Reason” list in the output above, the top one is “arp-inspection”, referring to DAI, Dynamic ARP Inspection, another CCNA topic. To enable it for BPDU Guard, use ERRDISABLE RECOVERY CAUSE BPDUGUARD, as I did here. This time, SHOW ERRDISABLE RECOVERY shows that it is enabled for BPDU Guard. And G0/1 is listed at the bottom of the output, meaning that it will be automatically re-enabled after 296 seconds. When this timer counts down to 0, the interface will be re-enabled. One final point: even if you use ErrDisable Recovery to automatically re-enable disabled ports, you still have to solve the underlying problem like I said before. In our scenario, if Bob’s switch is still connected to G0/1, right after ErrDisable Recovery re-enables the port, it will just be disabled again after receiving a BPDU. Okay, we’ve covered BPDU Guard, now let’s move on to BPDU Filter. Before we look at how it works, let’s see the problem it solves. A switch port connected to an end host continues sending BPDUs every 2 seconds. And it does this regardless of whether PortFast and BPDU Guard are enabled. So, even though Bob’s PC doesn’t run spanning tree and simply ignores any BPDUs, SW3 keeps sending BPDUs to Bob’s PC, once every 2 seconds. If the port doesn’t connect to a switch, sending BPDUs is both unnecessary and also undesirable, for a couple of reasons. First is that sending BDPUs uses some bandwidth and processing power on the switch, although it’s minimal. Not a big deal, but still unnecessary. Second is that BPDUs contain information about the LAN’s STP topology. And if maximum security is a concern, you should avoid sending this info to user devices. BPDU Filter solves this by preventing a port from sending BPDUs. Let’s explore how BPDU Filter works. As I just mentioned it stops a port from sending BPDUs. So, if you enable it on SW3 G0/1, it won’t send any more BPDUs to Bob’s PC. But unlike BPDU Guard, BPDU Filter doesn’t disable the port if it receives a BPDU. How the switch reacts when it receives a BPDU depends on how you configure BPDU Filter, so let’s see how to do that. BPDU Filter can be enabled in two ways, just like PortFast and BPDU Guard: it can be configured per-port in interface config mode, or by default in global config mode. However, unlike PortFast and BPDU Guard, BPDU Filter functions differently depending on how you configure it. To configure it on a specific port, use SPANNING-TREE BPDUFILTER ENABLE in interface config mode. With BPDU Filter enabled, the port will not send BPDUs. On top of that, the port will ignore any BPDUs it receives. Basically, this disables STP on the port, and for that reason you should use it with caution, in bold red letters. PortFast enabled on the wrong port can cause temporary layer-2 loops. But BPDU Filter enabled on the wrong port can cause permanent layer-2 loops, and is a great way to cause a broadcast storm and bring down the network. STP is a key protocol for preventing loops, so disabling it on a port can be very risky. A better choice is to enable BPDU Filter by default in global config mode. The command is SPANNING-TREE PORTFAST BPDUFILTER DEFAULT. And again, you can optionally use the EDGE keyword after PortFast. Just like when enabling BPDU Guard by default, BPDU Filter will be activated on all PortFast-enabled ports. And then you can use SPANNING-TREE BPDUFILTER DISABLE to disable it on specific ports if necessary. When BPDU Filter is activated on a port by default, the port will not send BPDUs, just like above. But here’s the difference. If the port receives a BPDU, PortFast and BPDU Filter are disabled, and it operates as a normal STP port. This is the best of both worlds. Under normal circumstances the port doesn’t send BPDUs, but if it receives BPDUs it is able to react appropriately – it doesn’t just ignore them. Before we finish up, let me give you my recommendation and one final note about BPDU Guard and BPDU Filter. You can enable PortFast and BPDU Guard however you prefer, either per-port or by default. It doesn’t affect how they operate. However you configure them, just make sure you enable them on the correct interfaces. But I recommend that you only enable BPDU Filter by default, in global config mode. Unless you have a very good reason to enable it per-port. Disabling STP on a port is risky business. Okay, one final note about BPDU Guard and BPDU Filter: they can be enabled on the same port at the same time, but the end result depends on how you configured BPDU Filter. If BPDU Filter is enabled in global config mode, so it’s enabled by default, and the port receives a BPDU, BPDU Filter will be disabled, and BPDU Guard will be triggered, meaning it will err-disable the interface. But what about if BPDU Filter is enabled in interface config mode, enabled per-port, and the port receives a BPDU? In that case, the BPDU will be ignored, and BPDU Guard will not be triggered. Basically, BPDU Guard doesn’t have any effect in this case. So once again, I think it’s better to activate BPDU Filter in global config mode, rather than interface config mode. Okay, here’s a one-slide summary of this video. PortFast should only be enabled on ports connected to non-switch devices that don’t send BPDUs. Usually you enable it on all ports connected to end hosts like PCs, and maybe routers. The port still sends BPDUs and will operate like a regular STP port if it receives BPDUs from a neighbor. This means that if an end user carelessly connects a switch to a port meant for end hosts, like Bob from Accounting did in our example, it could affect the STP topology. To prevent this, you should use BPDU Guard. BPDU Guard protects the network from unauthorized switches being connected to ports intended for end hosts. If a port with BPDU Guard receives a BPDU, the port enters the err-disabled state; it can no longer send or receive data. You can enable BPDU Guard per-port with SPANNING-TREE BPDUGUARD ENABLE, or by default with SPANNING-TREE PORTFAST BPDUGUARD DEFAULT. The default option enables it on all PortFast-enabled ports. You can then use SPANNING-TREE BPDUGUARD DISABLE to disable it on specific ports, if necessary. Now, if a port has been err-disabled by BPDU Guard, how can you re-enable it? There are two ways to do so. Manual with SHUTDOWN and NO SHUTDOWN, or automatic with ErrDisable Recovery, which automatically re-enables the port after a certain period of time, 5 minutes by default. To enable ErrDisable Recovery for BPDU Guard, use ERRDISABLE RECOVERY CAUSE BPDUGUARD. But whether you want to re-enable ports manually or with ErrDisable Recovery, make sure you fix the underlying problem that caused the port to be err-disabled. Otherwise, it will just be disabled again. Okay, finally we covered BPDU Filter, which prevents a port from sending BPDUs. But unlike BPDU Guard, it doesn’t disable the port if it receives a BPDU. How the port reacts upon receiving a BPDU depends on how you configured BPDU Filter. Like BPDU Guard, there are two ways to configure it. You can enable it per-port with SPANNING-TREE BPDUFILTER ENABLE. In this case, the port will ignore any BPDUs it receives. So use it with caution! This basically disables STP on the port, so if you enable it on a port connected to another switch, it could cause a loop. You can also enable BPDU Filter by default with SPANNING-TREE PORTFAST BPDUFILTER DEFAULT, which enables it on all PortFast-enabled ports. In this case, if the port receives a BPDU, PortFast and BPDU Filter are disabled, and the port operates as a normal STP port. And you can use SPANNING-TREE BPDUFILTER DISABLE to disable it on specific ports if necessary. Okay, that’s all for this video on BPDU Guard and Filter. I hope it was helpful. Thanks for watching.