From: Tim (ccie2be@nyc.rr.com)
Date: Wed Sep 14 2005 - 09:58:04 GMT-3
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.....
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3