Root Guard Question

larue38462

I have a question regarding root guard. I understand that when root guard is configured on a port, the port will not allow superior BPDUs to be propagated and the port is put into rootinconsistent state when superior BPDUs are received.

Through my initial studies, I took this to mean that BPDUs could not be superieror when compared to the root switch's BID.

Going through my lab today, I enabled root guard on a port connecting to a downstream switch that had a much higher priority than the root. The port was immediately placed in a root inconsistent state. Looking a little further, I saw that the downstream switch had the same priority as the local switch with root guard enabled, but had a lower mac address. While this gave it a lower BID than the root guard enabled switch, its bid was still inferior to the root switch.

This leads me to believe that root guard will always put a port into a root inconsistent state when a BPDU is recieved that is superior to the BID for the local switch, even if that BPDU is actually inferior when compared to the root.

Can anyone clarify this for me?

networker050184

Was the switch you have as the root actually the root for all VLANs?

larue38462

networker050184 wrote: »

Was the switch you have as the root actually the root for all VLANs?

It wasn't, I left that out for simplicity. The port was only in root inconsistent for vlan 200 so that's the only vlan i took the time to really map out the topology for. I could have looked further at the other vlan topologies i guess, but I didn't feel the need after what I saw here. I attached a visio doc to show what the topology looked like.

Forsaken_GA

larue38462 wrote: »

I have a question regarding root guard. I understand that when root guard is configured on a port, the port will not allow superior BPDUs to be propagated and the port is put into rootinconsistent state when superior BPDUs are received.

Through my initial studies, I took this to mean that BPDUs could not be superieror when compared to the root switch's BID.

Going through my lab today, I enabled root guard on a port connecting to a downstream switch that had a much higher priority than the root. The port was immediately placed in a root inconsistent state. Looking a little further, I saw that the downstream switch had the same priority as the local switch with root guard enabled, but had a lower mac address. While this gave it a lower BID than the root guard enabled switch, its bid was still inferior to the root switch.

This leads me to believe that root guard will always put a port into a root inconsistent state when a BPDU is recieved that is superior to the BID for the local switch, even if that BPDU is actually inferior when compared to the root.

Can anyone clarify this for me?

I really don't see anything wrong with that. Rereading a few different sources on Root Guard, all it says is if the switch receives a superior BPDU, so if the switch receives one superior to it's own, or one superior to the roots (which, on a non-root switch, would by definition be required to be better than it's own, so it's basically the same thing).

But yeah, it also makes sense for it to kick anything superior to itself. By configuring root guard on a port, you're basically saying I never want anything on that port to become the root bridge. Ever.

if the actual root bridge were to go offline and force a new election, that means that the local switch would have a chance to become the root (unless other configuration was made to make that impossible). If root guard only dropped BPDU's that were superior to the current root bridge, that could possibly allow the downstream switch to win the root election, so thinking it through, any switch which has a chance at becoming the root bridge would absolutely need to ignore any BPDU's superior to it's own on a root guard port, or weird election results could happen.

larue38462

That makes perfect sense....can't believe I didn't think about it that way from the beginning.

Forsaken_GA wrote: »

I really don't see anything wrong with that. Rereading a few different sources on Root Guard, all it says is if the switch receives a superior BPDU, so if the switch receives one superior to it's own, or one superior to the roots (which, on a non-root switch, would by definition be required to be better than it's own, so it's basically the same thing).

But yeah, it also makes sense for it to kick anything superior to itself. By configuring root guard on a port, you're basically saying I never want anything on that port to become the root bridge. Ever.

if the actual root bridge were to go offline and force a new election, that means that the local switch would have a chance to become the root (unless other configuration was made to make that impossible). If root guard only dropped BPDU's that were superior to the current root bridge, that could possibly allow the downstream switch to win the root election, so thinking it through, any switch which has a chance at becoming the root bridge would absolutely need to ignore any BPDU's superior to it's own on a root guard port, or weird election results could happen.

networker050184

Well, if that was the case wouldn't it have gone inconsistent for all vlans? I haven't messed with this in a while. Time for some labbing when I get a chance.

larue38462

That's depends on the specific switch priority values for each of the vlans. I was playing around quite a bit and in my lab the offending switch had a superior BID for vlan 200 only when compared to the local switch with root guard configured. It was good to see it all in a lab to see what really happens.

You can see this well with only 3 switches - a core (root), a 2nd switch that has a DP for the downstream switch, and the downstream switch that connects through the 2nd switch. I set the core switch as the root for all VLANs, but played with the priority for a few vlans on the 2nd switch and the downstream switch. In each case, the switch with root guard enabled only placed the port in root inconsistent state when the downstream switch sent superior BPDUs for the respective VLAN.

On a side note, I went to the Cisco Learning Network last night to try my hand at some practice exams for switch. I was shocked that Cisco allows that material on their site...those practice exams are a joke....stupid questions, incorrect answers.....it's pretty pathetic.

networker050184 wrote: »

Well, if that was the case wouldn't it have gone inconsistent for all vlans? I haven't messed with this in a while. Time for some labbing when I get a chance.

networker050184

larue38462 wrote: »

That's depends on the specific switch priority values for each of the vlans. I was playing around quite a bit and in my lab the offending switch had a superior BID for vlan 200 only when compared to the local switch with root guard configured. It was good to see it all in a lab to see what really happens.

Gotcha. Thanks, I needed a refresh on some of the STP stuff and this thread got me reading.