Hello and welcome to Jeremy’s IT Lab. In this video, we will cover another feature in the STP toolkit. This time, the focus is Root Guard. As the name implies, Root Guard guards the root bridge of the LAN, ensuring that another switch with a lower bridge ID can’t take over the role. It’s typically used when connecting your switches to someone else’s switches that you don’t have direct control over. For example, if a service provider connects their switches to a customer’s network, the provider might want to ensure that the root bridge remains in the service provider’s network. And Root Guard can help with that. Let’s get started. Here’s what we’ll cover. This is the third video in the STP Toolkit section of this course. We’ve already covered PortFast, BPDU Guard, and BPDU Filter in the previous few videos. And now we’re moving on to Root Guard, which prevents a port from becoming a root port by disabling it if superior BPDUs are received, thereby enforcing the current root bridge. As I mentioned in the intro, this can be very useful when connecting your LAN to another LAN that you don’t have direct control over. There is also one more feature in the toolkit that you need to know for the CCNA, Loop Guard. We’ll cover that in the next video. So, why is it important to ensure that a specific switch remains the root bridge? Before we look at Root Guard, let’s see why it’s valuable. As you know, STP prevents loops by electing a root bridge, that’s SW1 in the network above, and ensuring that each other switch has only one valid path to reach it. In this network, SW2 has one active path to reach SW1, the direct connection between SW2 and SW1. And same for SW3, only its direct link to SW1 is active. The link between SW2 and SW3 is disabled to prevent loops. Any of these three switches could be the root bridge and STP would fulfill its role of preventing loops. But you shouldn’t randomly select the root bridge. Good placement of the root bridge is important, and some things you should consider are optimal traffic flow. For example, you should try to minimize latency and congestion in the LAN. Latency just means how much time it takes traffic to travel through the LAN. And congestion refers to how busy the network is. If you try to pump too much water through a small pipe at once, it’s not going to be very efficient. And the same principle applies to network connections. So, with that in mind, why did I select SW1 as the root bridge for this LAN? Well, in most LANs like this, the PCs, like those connected to SW2 and SW3, don’t communicate with each other very much. Usually they want to communicate with servers outside of the LAN: over the internet, over the wide area network, the WAN, etc. So, we want to ensure that the PCs have an efficient path to reach R1, their gateway to the outside world. And that’s why I selected SW1 as the root bridge. Traffic from hosts connected to SW2 takes the SW2-SW1 link. And traffic from hosts connected to SW3 takes the SW3-SW1 link. This is the most efficient path for each host’s frames to reach R1. Another consideration when selecting the root bridge is stability and reliability. Once you select a root bridge that provides an efficient path for traffic in the LAN, you want that switch to remain up and operational for as long as possible. So, if you are using multiple kinds of switches in the LAN, one of the more advanced and reliable switches should be the root bridge. For example, if you only have enough budget to buy a couple of new switches, and the rest of them are old junkers you found in the closet, you should make one of the new switches the root, as you can probably rely on it not to die out after a few weeks of operation. So, those are a couple of considerations when selecting the root bridge: optimal traffic flow, and stability and reliability. Let’s focus on the first one and see what happens if we make a different switch the root bridge. Now SW3 is the root bridge. What’s wrong with that? Traffic from hosts connected to SW3 takes the same path, but traffic from SW2’s hosts now has to travel from SW2 to SW3, and then from SW3 to SW1, before reaching R1. This adds a bit of latency, as the frames are taking a less direct path. But to be honest, that’s negligible in most cases: probably less than a millisecond. The true issue is that there could be congestion on the SW3-SW1 link if the network is busy. When a link is congested, frames have to wait their turn to be transmitted, and in the worst case some frames might be dropped, and that could seriously affect network performance and user experience. No one likes a slow network. So, the point is that root bridge selection is important, and after we’ve selected a root bridge, we usually want it to remain stable. Let’s expand the network to show how Root Guard is useful. Within your own LAN, you can easily control the root bridge by setting its priority to 0. For example, here is SW1’s bridge ID. The priority is 0, plus 1 for the VLAN ID. Remember, Cisco switches run PVST+, so they always add the VLAN ID to the priority. Assuming SW2 and SW3 have the default priority, this makes SW1 the root bridge. And for the three switches on the right, we’ll do the same for SW6, making it the root bridge for its LAN. However, there are cases where you might connect your LAN to other switches outside of your direct control. For example, maybe the LAN on the left is controlled by a service provider, and the LAN on the right is controlled by a customer. This is one example where switches controlled by different organizations might be connected. A service provider offering Metro Ethernet service to customers. Metro Ethernet isn’t something you have to study for the CCNA exam, but it’s often used to connect sites within a MAN, a metropolitan area network, such as connecting offices within the same city. So, what happens when the service provider and customer connect their networks in this example? Well, SW2 and SW3 will send BPDUs saying that SW1 is the root bridge. But SW4 and SW5 will also send BPDUs saying that SW6 is the root bridge. So, who is right? Which switch becomes the root bridge? SW1 and SW6 each have the same bridge ID up to this point: a priority of 1, and a MAC address starting with 5254.001, but the next digit for SW1 is “a” and the next digit for SW6 is “8”, so SW6 has a lower bridge ID. And that means it will become the root bridge. So, the lesson here is that, even if you set your root bridge’s priority to 0, its role can be taken by another switch with a lower MAC address, like SW6 in this case. So, with no safeguard in place to enforce SW1 as the root bridge, SW1, SW2, and SW3 all accept SW6 as the root bridge, affecting the service provider’s STP topology. Both the SW1-SW3 link and the SW2-SW3 link are disabled. So, frames from SW3 to SW1 must take a detour through the customer’s LAN. This is obviously not an efficient traffic path, but Root Guard can be used to avoid a situation like this. Root Guard can be configured to protect your STP topology by preventing your switches from accepting superior BPDUs from switches outside of your control. And a superior BPDU is a BPDU with superior parameters when it comes to the STP algorithm. For example, a BPDU that claims a better root bridge ID. SW6’s BPDUs claim a lower root bridge ID than SW1’s, so SW6’s are superior. So, if you want to ensure that the root bridge remains in your LAN, you can configure Root Guard on the ports connected to switches outside of your control. We’re looking at this example from the perspective of the service provider, so that means SW2 G0/2 and SW3 G0/2, which are connected to the customer’s switches. The command to enable Root Guard on a port is SPANNING-TREE GUARD ROOT, in interface config mode. Unlike PortFast, BPDU Guard, and BPDU Filter, there is no command to enable it by default from global config mode. You can only configure it in interface config mode. Now that Root Guard is enabled on SW2 and SW3’s G0/2 ports, what happens when they receive BPDUs from SW4 and SW5, claiming that SW6 is the root bridge? If a Root Guard-enabled port receives a BPDU, it will enter the “broken” “root inconsistent” state, effectively disabling it. We’ll examine what those terms mean when we look at the CLI of these switches, but basically this means that the port won’t be able to forward frames and will discard any frames it receives. All traffic is cut off. And SW1, SW2, and SW3 won’t accept SW6 as the root bridge. So, even though the service provider and customer LANs are physically connected, they can’t communicate. Before moving on, I want to point out that SW2 G0/2 and SW3 G0/2, as well as the ports they connect to on SW4 and SW5, are all designated ports. Normally, there can only be one designated port per link, but in this case the switches disagree on who the root bridge is. Just remember that in a normal, functional spanning tree LAN, there should only be one designated port per link. But this is a special case, because Root Guard is blocking the link. Okay, Root Guard prevented the customer from influencing the service provider’s STP topology, solving the problem for the service provider. But that also means the customer can’t communicate over the service provider’s network. How can we fix this? To re-enable a port disabled by Root Guard, you must solve the issue that disabled the port. (CLUCK2)In other words, the disabled port needs to stop receiving superior BDPUs. To stop the superior BPDUs, the service provider should tell the customer to increase the priority of their switch. So, the customer increases SW6’s priority to 4096, plus 1 for the VLAN ID, and then what happens? Once the superior BPDUs received by SW2 and SW3 age out, the ports will automatically be re-enabled. And how long does that take? Well, as you already know, a BPDU’s Max Age is 20 seconds by default. So, it should take about 20 seconds, and then SW2 and SW3 G0/2 should be re-enabled. And not only will they be re-enabled, but also SW4, SW5, and SW6 will finally accept SW1 as the root bridge. And the final STP topology might look something like this. SW1 is the root bridge, all other switches have one active path to reach SW1, and the remaining links are blocked. So, the point to remember here is that, to re-enable a port that has been disabled by Root Guard, you don’t have to do anything in the CLI of SW2 or SW3, the switches using Root Guard. You just need to stop the superior BPDUs, and then the disabled ports will automatically recover. In this case, the service provider told the customer to modify their switch’s bridge ID, and then the issue was fixed. Since Root Guard only needs a single command to configure it, there’s not much to show in the CLI. But let’s rewind a bit and look at that process once more in the CLI. So, once again SW6’s STP priority is 1, making its bridge ID superior to SW1’s. I enabled Root Guard on SW2 G0/2 with the command SPANNING-TREE GUARD ROOT. I’m only showing SW2’s CLI here, but I did the same on SW3, too. After issuing the command, a message is shown saying that Root Guard has been enabled on the port. So, what happens when SW2 and SW3 receive BPDUs from SW4 and SW5? As this log message says, Root Guard blocks the ports. Take a look at the output of SHOW SPANNING-TREE. G0/2’s status column says BKN, and on the right it says ROOT_Inc. BKN means broken, and ROOT_Inc means Root Inconsistent. A “broken” port is basically disabled, it can’t forward or receive data frames. And Root Inconsistent tells us why the port is broken: it was disabled by Root Guard. Let’s fix that problem by asking the customer to increase SW6’s priority, which is now 4097. After about 20 seconds, SW2 shows a message saying that G0/2 is now unblocked. And as you can see here, its status is no longer broken, and the Root Inconsistent message is gone. So, the network once again converges with SW1 as the root bridge. Before we move on to summarize this video, I just want to clarify where you should configure Root Guard. SW1, SW2, and SW3 belong to a service provider, and they want to ensure SW1 remains the root bridge. A customer's switch shouldn’t disrupt the STP topology by becoming the root bridge. Therefore, Root Guard is configured on the ports connecting to customer switches, like SW2 G0/2 and SW3 G0/2. However, note that you shouldn’t always configure Root Guard on every port connected to another network. For example, while the customer’s switches connect to the service provider, the customer shouldn’t configure Root Guard on their own ports. If the customer configures Root Guard on SW4 and SW5’s ports that connect to the provider, those ports will just be disabled if they receive superior BDPUs, blocking those links. And there’s no point in connecting to a service provider if you can’t communicate over their network. Okay let’s summarize Root Guard. When selecting a LAN’s root bridge, you should consider a few things, such as optimal traffic flow that minimizes latency and congestion, as well as the stability and reliability of the switches. The root bridge plays a key role in the spanning tree, so it shouldn’t be a random decision. Within your own LAN, you can easily control the root bridge by setting its priority to 0. And if you have direct control over all of the switches in the network, there’s no need to configure Root Guard. But there are cases where you might connect your switches to other switches that are outside of your control. The example we used in this video was a service provider’s switches connecting to a customer’s switches, which might happen when the service provider is offering Metro Ethernet services, for example. Root Guard can be configured on specific ports to prevent them from accepting superior BPDUs from other switches. For example, a service provider’s switches generally shouldn’t accept superior BPDUs from a customer’s switches. You can use SPANNING-TREE GUARD ROOT to enable Root Guard on a port, and there is no command to enable it by default from global config mode. PortFast can be enabled by default because, in most cases, you want to enable it on all access ports, because they usually connect to end hosts. And BPDU Guard and Filter can be enabled by default on all PortFast-enabled ports, because those features are often used together. But Root Guard isn’t the kind of feature that you want to enable on ports by default. It should only be enabled on specific ports where needed, and that’s why it can’t be enabled in global config mode. And what exactly does Root Guard do? It prevents a port from becoming a root port if it receives a superior BPDU. Instead, the port’s status will be “broken” and “root inconsistent”. Basically, “broken” means the port is blocked; it can’t forward frames. And Root Inconsistent tells us why it is broken: because Root Guard blocked the port. But if the port stops receiving superior BPDUs, it will automatically recover. You don’t need to manually re-enable the port, or use ErrDisable Recovery like with BPDU Guard. Okay, that’s all for this video on Root Guard. I hope it was helpful. Thanks for watching.