From: Anthony Sequeira (terry.francona@gmail.com)
Date: Wed Sep 14 2005 - 13:52:12 GMT-3
Wow - Lee - this is a superb post! Thank you so much!
This really demonstrates exactly what is meant by UPSTREAM! We do not have
to be on the ROOT DEVICE itself in order to use priority - but we do need to
be UPSTREAM as you have demonstrated here.
Also - I found this quote from InternetnetworkExpert - just a restatement
of everything you have taught us Lee.....but still always nice to see it put
another way!
"To influence which port is elected the root port, the two user
configurable values to change are port cost and port priority. Changing port
cost will effect both the local bridge and all downstream bridges. Changing
the port priority will only affect the directly connected downstream bridge.
Keep in mind that port priority is only taken into account if there is a tie
in both cost and bridge-ID (a tie in bridge-ID implies that a bridg has
multiple connections to the sme upstream bridge.)
In summation - if there is a root device out of your control - you can
still use port-priority to control load-balancing - you just need to use it
in the right place (UPSTREAM DEVICE).
The only time I would need something like ROOT GUARD would be if I truly
need to take over as ROOT. For example, I have a backbone root device
connected to BOTH of the switches in my control. Now I have both of my
trunks in the BLOCKING state on one of my switches. Here I must wrestle the
ROOT role away from the backbone I believe.
On 9/14/05, Lee Donald <Lee.Donald@t-systems.co.uk> wrote:
>
> Tim,
>
> Port-priority is set on an upstream switch to influence a downstream
> switch
> so you could use it, however it is at the bottom of the list and will only
> get chosen should everything else be equal, which is unlikely in the real
> world, and unlikely in any network with more than 2 switches.
>
> However....
>
> Your topology
>
>
> ROOT-----------SW1===============SW2
>
>
> The factors that will make SW2 choose 1 path over another is as follows
>
> Path cost ( end to end cost) = same
> Bridge-ID of upstream switch ( down each link) = same
> Port-ID (lowest port number and priority) =
>
> So if SW2's cost to the ROOT is the same down both links, and the
> bridge-ID
> is the same also, you could set the port-priority on one of SW1's ports,
> to
> affect which path SW2 forwards and which one it blocks.
>
> But you could not set the port priority on SW2 as it would not make any
> difference.
>
> Does this make sense?
>
> HTH.
>
> -----Original Message-----
> From: Tim [mailto:ccie2be@nyc.rr.com]
> Sent: 14 September 2005 13:58
> To: 'Lee Donald'; 'Anthony Sequeira'; 'Group Study'
> Subject: RE: Load Balancing Across Trunks
>
> Well, yes, sort of.
>
> OK, here's my issue.
>
> You said,
>
> "the cost and Bridge-id would be identical down each link."
>
> which is true but I'm trying to apply that statement to the STP decision
> process between sw1 and sw2 and understand why port priority couldn't be
> used on sw1 (or maybe sw2) to influence which link sw2 forwards and
> blocks.
>
> When sw2 receives the port priority value from it's upstream neighbor, is
> that the port priority of the root or it's directly connected neighbor?
>
> I guess I'm missing something here because I don't understand why port
> priority can only have influence between the root and it's directly
> connected downstream neighbor and NOT between sw1 and sw2.
>
> TIA, Tim
>
> -----Original Message-----
> From: Lee Donald [mailto:Lee.Donald@t-systems.co.uk]
> Sent: Wednesday, September 14, 2005 8:54 AM
> To: Tim; Lee Donald; 'Anthony Sequeira'; 'Group Study'
> Subject: RE: Load Balancing Across Trunks
>
> Tim,
>
> I think I have, haven't I?
>
> As I explained below.
>
> STP decision process is as I have described below.
>
> Regards
>
> Lee.
>
>
>
> -----Original Message-----
> From: Tim [mailto:ccie2be@nyc.rr.com]
> Sent: 14 September 2005 13:07
> To: 'Lee Donald'; 'Anthony Sequeira'; 'Group Study'
> Subject: RE: Load Balancing Across Trunks
>
> Lee,
>
> Thanks for responding to this thread.
>
> If you wouldn't mind, could you take the example shown earlier and
> describe
> the STP decision process as it applies to STP selecting which link between
> sw1 and sw2 would be forwarding and blocking.
>
> Also, could you tell us what we could configure on sw1 or sw2 to change
> the
> default outcome of the STP process?
>
> For this example, let's assume there's only one link between the Root and
> sw1. And, assume there are 2 links between sw1 and sw2 using fa0/1 and
> fa0/2, respectively.
>
> Using this example, if all port costs are left at their default, sw2 will
> have 2 equal cost paths to the root bridge.
>
> TIA, Tim
>
> -----Original Message-----
> From: Lee Donald [mailto:Lee.Donald@t-systems.co.uk]
> Sent: Wednesday, September 14, 2005 7:08 AM
> To: Tim; 'Anthony Sequeira'; 'Group Study'
> Subject: RE: Load Balancing Across Trunks
>
> Tim,
>
> Port-priority would be last in the decision process. End to end cost would
> be first, if the costs are equal, then it would be based on the lower
> Bridge
> ID. Lastly it would be port-ID, which consists of the port-priority and
> the
> lowest port number.
>
> That is why you would only use the port-priority on the root to a directly
> connected switch, because the cost and Bridge-id would be identical down
> each link, so port-priority would come into play.
>
> Further down the network port-priority would never be used.
>
> Regards
>
> Lee.
>
>
>
> -----Original Message-----
> From: Tim [mailto:ccie2be@nyc.rr.com]
> Sent: 14 September 2005 11:16
> To: 'Anthony Sequeira'; 'Group Study'
> Subject: RE: Load Balancing Across Trunks
>
> Anthony,
>
> I'd be very interested in seeing how you tested this.
>
> If your topology is like this:
>
> Root bridge --- sw1 ==== sw2
>
> Where there are multiple physical paths between sw1 and sw2, there must be
> someway that STP puts the redundant ports on sw2 into a blocked state and
> determines which port will forward.
>
> In your testing, what did you find was the way STP determined this?
>
> Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Anthony Sequeira
> Sent: Wednesday, September 14, 2005 12:31 AM
> To: Group Study
> Subject: Re: Load Balancing Across Trunks
>
> I have confirmed through lab tests that you cannot use port-priority on
> two
> downstream switches from the root to control the choice of trunk port for
> the traffic.
> Certainly, as Tim suggested in this thread, if you use Root Guard to block
> the backbone device - you can then get yourself in a situation where you
> can
> use port-priority, since now you can control the election of the root
> device.
> I am waiting for someone to PROVE otherwise - but at this point - it looks
> like load-balancing using port-priority is only an option when one of the
> two switches you are trying to load balance between is the root!
>
> On 9/13/05, Anthony Sequeira <terry.francona@gmail.com> wrote:
> >
> > It seems to be a simple task to load balance traffic on a VLAN basis
> > across your trunk links if you are dealing with only two switches that
> you
> > completely control. For example, if you are forbidden from using port
> cost,
> > just make one of your two switches the root for all VLANs and then set
> the
> > port priorities apropriately on this upstream switch for each VLAN.
> > But what if the root of a VLAN you need to load balance is on a third
> > switch out of your control? Now you can play with port-priority all you
> want
> > on your two switches but your configurations will have no effect.
> > Must we be able to control the root switch election in order to properly
> > load balance across trunk links using port priority? I have "labbed"
> this
> up
> > - and it seems that we do need this level of control.
> > Is there another way to control load balancing across trunk links beyond
> > port cost and port priority? I think not.....
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3