Re: BPDU & Root Guard

Babatunde

If you dont configure Root Guard on other switches apart from the root
bridge then these other switches are still susceptible to having their
root bridge changed by another switch.

E.G if SW1 was your root and was attached to SW2 and SW3, SW2 and SW3
are also connected. If you want to stop
SW2 becoming the root, if you only configure root guard on the SW1,
and SW2 starts to advertise a better switch priority than SW1 then SW1
will not allow this due to the root guard configuration.

However SW2 will still send superior BPDUs to SW3 telling it that it
is the root. SW3 does not have root guard so it is seeing BPDUs from
SW1 saying it is the root and from SW2 saying it is the root.
Whoever has the better priority will win so SW2 could still become the
root for SW3.

That is why Tyson was explaining that the other switches also need to
protect themselves from say and Access Switch becoming the root.

On 28 July 2010 15:07, Babatunde Sanda <sbabatunde1_at_ca.rr.com> wrote:
> Tyson,
> My understanding is that the root bridge should be planned to be at the center of the network.
>
> When this is planned out and all switches know of each other and who is the root for each vlan through the initial discovery from sending BPDU traffic into the network.
>
> Identifying your central point and protecting it need be done only at this central point with "guard root". You need not go configure "root guard" on other switches except the are acting as roots for other vlans. Hence the initial command "spanning-tree vlan (vlan or range) root primary/secondary ".
>
> Is there something I missed in your thought process please explain.
>
> Thank you
>
>
>
> Sanda Babatunde B.Sc (Accounting) CCNP, CCVP, CCNA(R,S,V), MCSA, N+, A+.
> Sent from my iPhone
>
> On Jul 28, 2010, at 6:04 AM, "Tyson Scott" <tscott_at_ipexpert.com> wrote:
>
>> root guard should be applied to the edge of your controlled network. So not
>> only the root switch but all your downstream switches too. You wouldn't
>> want half of your network to disagree on who is root.
>>
>> Regards,
>>
>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>> Mailto: tscott_at_ipexpert.com
>>
>>
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Ankur Thakkar
>> Sent: Wednesday, July 28, 2010 12:39 AM
>> To: Tony claros
>> Cc: Cisco certification
>> Subject: Re: BPDU & Root Guard
>>
>> Hi Tony,
>>
>> Root guard is ideally applied on all the ports of a root bridge so that it
>> will not allow any superior BPDU's to demote itself.
>>
>>
>> Rgrds
>> Ankur
>>
>> On Sun, Jul 18, 2010 at 2:46 PM, Tony claros <tonyclaros26_at_gmail.com> wrote:
>>
>>> Hi
>>>
>>> When to use BPDU Guard && Root Guard.
>>>
>>> Condition needs to be applied on SW 2 that it should not become root for
>>> any
>>> vlan
>>> solution : spanning-tree vlan 1-1005 priority 255 ( is this correct )
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> -------------------------
>> "Born with a Noble personality is an accident .
>> But dying with a Noble personality is an achievement "
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Jul 28 2010 - 16:32:00 ART