From: P729 (p729@xxxxxxx)
Date: Sun Jul 07 2002 - 16:13:35 GMT-3
This is one of those cases where a poorly worded task or objective leads to
a lot of wasted cycles and analysis paralysis. The bottom line is, when a
bridge must participate in a spanning tree, there is no _practical_ way to
absolutely _guarantee_ it will _never_ become root. I believe the words
"guarantee" and "never" make the problem impractical and prone to
over-analysis.
Sure, you can set the bridge priority to zero and modify the MAC address so
it's the lowest among participating bridges, but I would hope the
comprehension being tested here is that the overall bridge priority is a
combination of bridge priority field and the MAC address and the lowest
combination wins. So it's relative. How far can we take this? Will the
debate rage on over "what's the lowest allowable MAC address?" I hope not.
Likewise, I myself have used the "single bridge running spanning tree
becomes root" example, but I used it to demonstrate the futility of trying
to make a bridge that _must_ run spanning tree _never_ to become root. It
simply isn't possible. You can make it less likely given the initial set of
conditions, control over relevant switches, etc. Now if the initial set of
conditions stipulate something like you're loop-free and "never" allow
so-and-so switch to become root, by all means, turn off spanning tree.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "Marek Osuch" <mosuch@betacom.com.pl>
To: "Colin Barber" <Colin.Barber@telewest.co.uk>; <ccielab@groupstudy.com>
Sent: Sunday, July 07, 2002 2:54 AM
Subject: Re: Root bridge question
> Yes, but condition was "never become root":)
> In case where this switch is only one for this vlan (for example this vlan
> isn't used by routers), solution is disabling spt for this vlan
>
> Marek
> #9498
>
> ----- Original Message -----
> From: "Colin Barber" <Colin.Barber@telewest.co.uk>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, July 07, 2002 11:43 AM
> Subject: RE: Root bridge question
>
>
> > If the switch is the only device in the vlan it doesn't matter what the
> > priority is - it will always become the root.
> >
> > However it's not just switches that run spanning tree, what about any
> > routers connected to the switch with bridging enabled?
> >
> > Colin.
> >
> > -----Original Message-----
> > From: Marek Osuch [mailto:mosuch@betacom.com.pl]
> > Sent: 07 July 2002 10:11
> > To: Manny Gonzalez; ccielab@groupstudy.com
> > Subject: Re: Root bridge question
> >
> >
> > Simple question:
> > what's happend if switch with highest priority (65535) is only one
switch
> in
> > vlan?
> > It will always be root..:)
> >
> > Best regards
> >
> > Marek
> > #9498
> >
> > ----- Original Message -----
> > From: "Manny Gonzalez" <manny@nyp.org>
> > To: <ccielab@groupstudy.com>
> > Sent: Sunday, July 07, 2002 5:23 AM
> > Subject: Re: Root bridge question
> >
> >
> > > None of the solutions for HARD questions relating to Spanning Tree are
> > digestible:
> > >
> > > Q. Make Sure Switch is always the root.
> > >
> > > A. Well, not really doable. Placing the priority at ZERO can still be
> > overridden
> > > by a bridge with a lower ID :-)
> > >
> > > Q. Make sure bridge is NEVER the root.
> > >
> > > A. Well, the sure way is to disable Spanning Tree. You can always
become
> > root
> > > with PRIORITY 65535 if there is someone with that priority and a
HIGHER
> ID
> > on
> > > the bridge.
> > >
> > > So yes, none are easy. However, my suggestion is, "don't go reading
too
> > much
> > > into a question" This is good advice given to me and I applied in the
> lab
> > when I
> > > took it. Actually, I have known many people who have failed the lab
> > because they
> > > overanalyzed questions, NOT because they did not know the right
answer.
> > >
> > > Bottom line is, if I was asked to make sure a bridge never becomes
root,
> I
> > will
> > > probably make it 65535 instead of turning off STP. Turning it off may
be
> > too
> > > harsh because you are making it worse by not being able to prevent
> loops.
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:21 GMT-3