cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
909
Views
0
Helpful
4
Replies

question about root guard

Hello,

I have a question about the design guide on LAN with the root guard.

In my example, I have 2 Core switch : Core A and Core B. Core A is root bridge for vlan 1 to 10 and Core B is root bridge for vlan from 11 to 20.

I have only one distribution switch which is connected to the 2 Core switches.

In the design guide it's wrote that we have to configure Root Guard on each interface where the root bridge should not appear. In my case my 2 Core switches are root bridge for differents vlans and I use PVST. So, where must I configure Root Guard on the networks ?

Thank you by advance.

Best regards.

1 Accepted Solution

Accepted Solutions

The concern is that if someone were to plug another switch into your distribution switch, and that switch was configured with a lower priority, it could become the root.

As the previous posters stated, this feature is intended for connectivity providers. Lets say you were in the data center biz, and folks brought their servers into your data center, and paid to connect to your distribution switch. You wouldn't want those people sending you BPDUs, so you'd turn on root guard on the ports where your customers plug in. I used to work for a company that provided data center connectivity, and even though we told our customers they could only plug servers into the ports we provided for them, we'd at times catch them plugging switches and routers into the ports, then building there own little infrastructure off the one prot we provided. If one of their switches had a lower bridge priority then ours they could potentially take over as root, which would be BAD! That's what root guard is supposed to prevent

View solution in original post

4 Replies 4

lgijssel
Level 9
Level 9

I am a bit confused about you mentioning the distribution switch. Now root guard is intended to 'guard' against tampering users and perhaps also against illegal patches.

It does not have to be configured on ports that are not accessible to users.

Basically, the idea is to configure root guard on all ports that are used as access ports. Obviously, both trunks to the core switches should be excluded but you may configure this on all other ports that are not intended to participate in STP.

regards,

Leo

Hi,

Just to add also, that root guard would normally be seen in the service provider environment, where they have a number of ethernet connections to customer lans.

The customers should not be sending bpdus into the sp core, so the sp would enable root guard on the customer links, so that the sp core switches would not choose a customer switch as root.

You wouldnt use root guard in the environment that you describe, as you need to receive bpdus from the secondary switch in order for things like uplinkfast to take effect.

HTH

LR

Hi Leo,

Thank you for the answers.

Effectively I'm agree with you but I don't understand why on the document "Spanning Tree Protocol Root Guard Enhancement" it's specified that we have to put this command on all port where the root bridge should not appear.

The concern is that if someone were to plug another switch into your distribution switch, and that switch was configured with a lower priority, it could become the root.

As the previous posters stated, this feature is intended for connectivity providers. Lets say you were in the data center biz, and folks brought their servers into your data center, and paid to connect to your distribution switch. You wouldn't want those people sending you BPDUs, so you'd turn on root guard on the ports where your customers plug in. I used to work for a company that provided data center connectivity, and even though we told our customers they could only plug servers into the ports we provided for them, we'd at times catch them plugging switches and routers into the ports, then building there own little infrastructure off the one prot we provided. If one of their switches had a lower bridge priority then ours they could potentially take over as root, which would be BAD! That's what root guard is supposed to prevent

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco