For example, if we consider the following diagram:
R5
| |
| |
| |
R3---------R4
| |
| |
R1---------R2------R6
If R5 is root. only host ports on all switches and R2 port which is connect
to the R6 should be configure with root guard.
On Tue, Nov 15, 2011 at 12:19 PM, Pedram Zadeh <[email protected]>wrote:
> Hi all,
>
> My understanding of this diagram is as following:
>
> R5
> | |
> | |
> | |
> R3---------R4
> | |
> | |
> R1---------R2
>
> In this case, it is possible to have R3---R1---R2---R4---R5 as a root path
> in case of R3--R5 and R3--R4 is disconnected at the same time. So, R3---R1
> could be root port. My understanding is that in this kind of redundant
> topologies usually only ports that connect to the PCs or connect to other
> switch (which that switch doesn't have other redundant path to the root)
> should be configured with root guard. All other ports could be potentially
> root port. So, Patrick I am disagree with
>
> "If you insist on making R5 the root bridge with R3/R4 as it's backup,
> practically the same rules apply and you want to enable rootguard on the
> R3/R4 ports leading towards R1/R2 as well as whatever happens, the root
> bridge should never be behind the border between those 4 devices. "
>
> Am I missing something?
>
> Regards,
> Pedram.
>
> On Tue, Nov 15, 2011 at 2:09 AM, <[email protected]> wrote:
>
>> Amit,
>>
>> If you make R5 the root bridge, in case it fails which one will you
>> specify as the secondary root?
>>
>> I assume the following: All links equal bandwidth (and therefore equal
>> STP cost) and all Rx devices are Switches.
>>
>> I would suggest the following:
>> - Root bridge R3 with R4 as the backup (remember all traffic will go
>> through the root bridge to reach other devices making it useful to be in
>> the middle of the network). If you only have the routing function on R5,
>> you can make that the root bridge with R3 as it's backup, but even then I
>> would suggest putting the root on R3 with R4 as secondary.
>> - R1 will choose the direct path to R3 as its root path
>> - R2 will choose the path through R3 as it's root path (has 2 options of
>> 2 hops but the sending bridge ID (secondary root bridge will have a lower
>> bridge ID due to lower priority)
>> - R3 is the root bridge
>> - R4 will choose the direct path to R3 as it's root path
>> - R5 will choose the direct path to R3 as it's root path
>> - Root failure, R4 will become the root
>> - R1 will choose the path through R2 as it's root path (so the link to
>> R2 on R1 cannot use the rootguard
>> feature)
>> - R2 will choose the direct path to R4 as it's root path
>> - R3 is down
>> - R4 is the root bridge
>> - R5 will choose the direct path to R4 as it's root path
>> - R2 link failure to R4
>> - R2 will choose the path through R1 as it's root path (it's other link
>> is down so no other option, therefore
>> R2 cannot have rootguard enabled on the link to R1).
>> - R4 link failure to R3
>> - R4 will choose the path through R5 (2 hops preferred over 3 hops with
>> equal link cost) as it's root path so
>> R4 cannot enable the rootguard feature on the port leading towards R5.
>> - R2 will now choose the path through R1 because the path R4,R5,R3 is 3
>> hops instead of 2.
>> - R4 can never be the root when R3 is up, so on the ports leading to any
>> of the other switches you can enable root guard (though I would let STP
>> take care of this).
>>
>>
>> I end up with a situation in which I would only enable rootguard on the
>> ports of R3 and R4 leading towards R1 and R2 as there is always a better
>> secondary path on which the root can be found. On all access ports enable
>> portfast with bpduguard (no need for rootguard as bpduguard will close the
>> ports). In case you have a port on any of the switches where a switch might
>> have to be connected, disable portfast and bpduguard + enable rootguard in
>> order to prevent ceasing of the root by that switch.
>>
>> If you insist on making R5 the root bridge with R3/R4 as it's backup,
>> practically the same rules apply and you want to enable rootguard on the
>> R3/R4 ports leading towards R1/R2 as well as whatever happens, the root
>> bridge should never be behind the border between those 4 devices.
>>
>> If you have additional questions let me know.
>>
>> Kind regards,
>>
>> Patrick Keja
>>
>> -----Original Message-----
>> From: [email protected] [mailto:
>> [email protected]] On Behalf Of Syed Asif Raza
>> Sent: 14 November 2011 14:38
>> To: [email protected]; [email protected]
>> Cc: [email protected]
>> Subject: Re: [OSL | CCIE_RS] Rootguard placement
>>
>>
>> Hi Amit,
>>
>> Can you please send a better diagram, i'm not able to understand from
>> this.
>>
>> Regards,
>> Syed Asif RazaCCIE (R&S) 29012
>>
>> > Date: Mon, 14 Nov 2011 16:36:48 +0530
>> > From: [email protected]
>> > To: [email protected]
>> > CC: [email protected]
>> > Subject: Re: [OSL | CCIE_RS] Rootguard placement
>> >
>> > HI Adam and Syed,
>> >
>> > thanks for the prompt reply...
>> > now here i have a Diagram
>> >
>> >
>> > R1--------R 3-__
>> > | | __ __ R5 R3 and R4 is connected to R5
>> > | | _
>> > R2--------R4-
>> > I want R5 to be the root Bridge.
>> >
>> > now should i apply the root guard command. Kindly explain in more detail
>> >
>> >
>> > Thanks!!
>> > On Mon, Nov 14, 2011 at 3:18 PM, Adam Booth <[email protected]>
>> wrote:
>> >
>> > > Hi Amit,
>> > >
>> > > In the document you indicate, it's placed on Switch C on the interface
>> > > facing Switch D - Switch C is not the root bridge though.
>> > >
>> > > Place rootguard on any interface you don't want to receive superior
>> BPDUs
>> > > from but still expect to be involved in the STP topology (otherwise
>> you
>> > > could take other protective measures such as bpdufiltering however if
>> that
>> > > peer device also has another connection into your switching domain and
>> > > could introduce a bridging loop).
>> > >
>> > > Simply described, rootguard prevents a new device (typically outside
>> of
>> > > your administrative control) from influencing the placement of the
>> > > rootbridge in the network which could provide a sub-optimal topology
>> in
>> > > your network by moving the port with the new device claiming it
>> should be
>> > > the root bridge into a root inconsistent state until it stops sending
>> BPDUs
>> > > that are superior to the current root, at which state it becomes a
>> regular
>> > > STP interacting port.
>> > >
>> > > Cheers,
>> > > Adam
>> > >
>> > >
>> > > On Mon, Nov 14, 2011 at 7:19 PM, Amit Jp <
>> [email protected]>wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >>
>> > >> I need to knwo where exactly should the root guard should be
>> configured. I
>> > >> feel it should always be on Root Switch .
>> > >>
>> > >> And if not kindly explain with a diagram .
>> > >> I have this Link(
>> > >>
>> > >>
>> http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml
>> > >> )
>> > >> but i am still confused abt it. What should go wrong if i have this
>> > >> commmand on Root Swtich.
>> > >> _______________________________________________
>> > >> For more information regarding industry leading CCIE Lab training,
>> please
>> > >> visit www.ipexpert.com
>> > >>
>> > >> Are you a CCNP or CCIE and looking for a job? Check out
>> > >> www.PlatinumPlacement.com <http://www.platinumplacement.com/>
>> > >>
>> > >
>> > >
>> > _______________________________________________
>> > For more information regarding industry leading CCIE Lab training,
>> please visit www.ipexpert.com
>> >
>> > Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>>
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>> Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>> _______________________________________________
>> For more information regarding industry leading CCIE Lab training, please
>> visit www.ipexpert.com
>>
>> Are you a CCNP or CCIE and looking for a job? Check out
>> www.PlatinumPlacement.com
>>
>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
Are you a CCNP or CCIE and looking for a job? Check out
www.PlatinumPlacement.com
