From: Ahamed-Maideen Sadayan-Abdul-Hutha (asadayan@xxxxxxxxx)
Date: Wed Aug 28 2002 - 15:41:04 GMT-3
You are right..But In this case setting the priority to 0 in the other
switch will cause the switch which you don't want to be a root to be
consistent in it's behaviour.
Thats what I have said with an example..
Switch A---Switch B---Switch C
If you don't want Switch B to be the root for a VLAN say 10, then you can do
that by setting the priority to be zero for VLAN 10 by configuring it on
either Switch A or Switch C.
If you do that Either Switch A and Switch C will be the root for VLAN 10 and
Switch B cannot be the root. Even if you issue the command set spant root on
Switch B, then Switch B cannot be the root unless you specify the priority
also zero explicitly on Switch B.
-AHamed
-----Original Message-----
From: Bauer, Rick [mailto:BAUERR@toysrus.com]
Sent: Wednesday, August 28, 2002 11:01 AM
To: 'Ahamed-Maideen Sadayan-Abdul-Hutha'
Cc: 'ccielab@groupstudy.com'
Subject: RE:
You're thinking of OSPF DR/BDR election. Zero in SPT would give the switch
the best chance of becoming root.
Rick, #9482
-----Original Message-----
From: Ahamed-Maideen Sadayan-Abdul-Hutha [mailto:asadayan@cisco.com]
Sent: Wednesday, August 28, 2002 1:17 PM
To: Jim Brown; 'Colin Barber'; 'Zhang, Ou (David)';
ccielab@groupstudy.com
Subject: RE:
There is an another way around here..
That is setting the spanning tree priority to 0 on the root switch.
In this case the user can configure a switch to not becoming a root.
Say,
Switch A ---- Switch B
If the user want's switch B to be a Non-root switch then configure Switch A
priority to be Zero. In that case Switch B can never be the root at any
case, Unless the priority is set to Zero on the Switch B followed by the mac
check.
CHeers,
AHamed
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Jim Brown
Sent: Wednesday, August 28, 2002 9:22 AM
To: 'Colin Barber'; 'Zhang, Ou (David)'; 'ccielab@groupstudy.com'
Subject: RE:
I would disagree with you on which answer is correct from a testing
standpoint. The word 'never' means to me, there must be no way the bridge
could become the root.
It you set the spantree priority as high as possible the switch could still
become the root. Bridges with duplicate spantree priorities then select the
root based on the MAC address.
I don't think the proctors would clarify this requirement anymore than
saying "read it again."
This is one of those questions that tests if you understand root bridge
selection and spanning tree priority.
Through our discussion of it on the list, we have effectively "dumbed down"
the requirement.
-----Original Message-----
From: Colin Barber [mailto:Colin.Barber@telewest.co.uk]
Sent: Wednesday, August 28, 2002 9:01 AM
To: 'Zhang, Ou (David)'; 'ccielab@groupstudy.com'
Subject: RE:
This have been discussed a few times before on this list.
The two options are the two you have listed. The first is I believe the
answer they are looking for although it does not guarantee 100% that the cat
will not become the root. The other option is not a very smart move although
a lot of the things we do in these labs are not very smart.
The best answer is ask the proctor if you get something like this in the
actual lab. If it's not the real lab then it doesn't matter which option you
take as long as you know both options and the pros/cons of each one.
Colin
-----Original Message-----
From: Zhang, Ou (David) [mailto:OuDavid.Zhang@gs.com]
Sent: 28 August 2002 14:57
To: 'ccielab@groupstudy.com'
Subject:
Hi,
Please help me with the answer for this question: Ensure that a Catalyst
5000 switch never becomes the root bridge for a given vlan.
I see two possible answers because I find the question ambiguous. Does it
mean 'the vlan can still run spanning tree without ever becoming the root',
or 'the vlan does will no longer run spanning tree'?
1. Set the spantree bridge-priority for the vlan to the highest possible
value.
!
set spantree priority 65535 <vlan#>
!
2. Disable spantree altogether for the vlan.
!
set spantree disable <vlan#>
!
Thanks.
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:40 GMT-3