Re: STP- Port cost vs. Port-priority

From: ccie2be (ccie2be@nyc.rr.com)
Date: Mon Jun 06 2005 - 20:06:13 GMT-3


Bob,
 
I also tend to give the benefit of a doubt to the double ccie if what I
believe differs with what a double ccie.
 
However, with the knowledge you now have regarding STP, I would think that
you can verify any STP config for the scenario my comments applied to.
 
Here's the mnemonic I used to keep this crap straight.
 
D U D
 
C P I
 
Where D = downstream and U = Upstream (which includes root)
 
And, C = cost; P = port priority; and I = interface #
 
So, what the table says is this:
 
If you want to influence which ports are blocking or not by using cost, make
change on Downstream switch.
 
If you want to influence which ports are blocking or not by using port
priority, make change on Upstream switch.
 
Of course, you can't change the interface # but it's in there because it's
the last tiebreaker when all else is equal. But, just the same, you need to
know that it's the Downstream which uses interface # as the tiebreaker.
 
By knowing that fact, you can determine which port will go into forwarding
mode next after a port failure.
 
Bob, I think you're doing the right thing by experimenting with these
variations. But, don't take my word for it or a double ccie or even a quad
ccie.
 
Only TRUST what the switch tells you empirically from your experiments.
 
I read over your note quickly and didn't see any glaring mis-statements but
at the moment I'm seeing double so don't go by that.
 
I think that for you do this right, you need to do these experiments
systematically.
 
First, start by getting used to configuring STP to put ports in blocking and
forwarding mode by changing these parameters, one at a time, for all vlans.
 
IOW, for your first experiment, see which ports are blocking and forwarding,
by default and determining which STP rules are causing the default result.
 
Then, manually change which switch is the root and looking at the same show
commands. What changed? Does this change make sense based on how you
understand the STP rules? IF so, now, decide which ports you want to be in
blocking and forwarding mode and the order of which ports change mode in
case of failure. Write this down on paper.
 
IOW, as an experiment, let's say you decide you want the downstream switch's
ports, fa0/x, fa0/y, and fa0/z to be forwarding blocking and blocking,
respectively.
 
And, if fa0/x fails, fa0/z should forward next and if both fa0/x and fa0/z
fail, then fa0/y goes into forwarding mode.
 
Now, config only the Upstream switch to achieve that result. Once that
works, undo whatever config's you made and now config only the downstream to
achieve that result.
 
Once you're very comfortable with doing and verifying those types of
config's, now config your various vlan load-balancing scenarios by changing
those same parameters but on a per-vlan basis.
 
Once you're good with those scenarios, you shouldn't have anything to be
concerned about on the lab when it comes to STP.
 
Remember, in the lab, there are only 2 3550's connected back to back. So,
there are only so many potential STP scenarios they can throw at you.
 
Of course, you also have to know how and when to use the various STP
commands that lower STP convergence time. But, that's another topic.
 
BTW, assuming you really want to understand STP, you should read the Kennedy
and Clark classic book, LAN Switching especially the chapter on STP.
 
Make sure you know how STP elects the root bridge and then determines which
ports are put in forwarding and blocking states.
 
HTH, Tim
 
  _____

From: Bob Nelson [mailto:nelsnjr@cox.net]
Sent: Monday, June 06, 2005 4:06 PM
To: ccie2be
Subject: Re: STP- Port cost vs. Port-priority
 
Tim:
 
I labbed up each combination of settings as per your last reply. I have a
5-6 page report on the combinations, but thought I would shorten it here
with text.
Sorry, this may be a little long. If you have input, it would be most
appreciated.
 
Scenario: Configuring STP load sharing, with two 3550 switches and one
designated the root for all vlans.
The switches are connected together with two trunks on ports 23 and 24.
The testing was done using the cost and port-priority parameters to
determine what effect each had on the
forwarding and block of the specified vlans.
 
Results:
1. On the primary switch, no matter what the configuration, both ports 23
and 24 were always forwarding.
The cost parameters and the port-priority parameters changed from their
default STP values when using either
cost command or port-priority configuration, however the ports remained in
forwarding status.
 
2. Using the cost commands on the primary switch changed the costs
parameters for STP, but did not
    cause a load balancing condition as the only port that was blocking was
port 24 on the secondary switch for all vlans.
    Adding the cost commands to the secondary switch caused the load
balancing conditions to become effective
    where vlans 3-6 were blocked on port 23 of the secondary switch, but
were forwarded on port 24
    Vlans 8-10 were forwarded on port 23 but were blocked on port 24.
 
3. Using the port priority commands on the secondary switch changed the
priority parameters for STP, but did not
    cause a load balancing condition as the only port that was blocking was
port 24 on the secondary for all vlans.
    Adding the port priority commands on the primary switched caused the
load balancing conditions to become effective
    where vlans 3-6 were blocked on port 23 of the secondary switch, but
were forwarded on port 24
    Vlans 8-10 were forwarded on port 23 but were blocked on port 24.
 
Conclusions:
Configuring the switches for load balancing must be done using the
port-priority commands on the primary (root) switch
or the cost commands on the secondary (non-primary) switch to cause a load
balancing condition between the switches.
 
The commands need only be placed on a single switch, in the case of a two
switch configuration lab scenario, to create the
required load balancing condition. Putting cost commands on the primary or
port-priority commands on the non-primary,
would be an incorrect configuration, even though there was no effect. It is
up to the test candidate to determine which method,
cost or port-priority, to use depending on the language in the task. The
answer may be given earlier in the switching scenario,
where the root switch is to be designated for particular or all vlans. When
in doubt ask the proctor.
 
In addition to using the cost and port priority commands, I can accomplish
the same result by setting one switch as
the primary for vlans 3-6 and the other switch primary for vlans 8-10. In
this instance, port 23 on both switches
forwards vlans 3-6 and port 24 on both switches forwards vlans 8-10. Again
the lab will dictate which of the three
methods to use.
 
Tim, if you want to see the interface configs and the show spanning-tree
commands for this, let me know
as I have them in a Word document. The reason I was so concerned about
learning this is that I attended
a CCIE lab prep class and the instructor gave the following result for this
question of load balancing.
I did not agree with him, but he told me I was wrong. Thanks to you, I
believe I have the correct
answer. He had 2 CCIEs already, so I gave him credit for the CCIEs.
 
From my studies of this, I think this is incorrect.
Configure VLANs 4, 12, and 57 to use F0/23 and VLANs 111,112, and 113 to use
F0/24.

SW1
Interface F0/23
  Spanning-tree vlan 4 port-priority 240
  Spanning-tree vlan 12 port-priority 240
  Spanning-tree vlan 57 port-priority 240
Interface F0/24
  Spanning-tree vlan 111 port-priority 0
  Spanning-tree vlan 112 port-priority 0
  Spanning-tree vlan 113 port-priority 0
 
SW2
Interface F0/23
  Spanning-tree vlan 4 port-priority 0
  Spanning-tree vlan 12 port-priority 0
  Spanning-tree vlan 57 port-priority 0
Interface F0/24
  Spanning-tree vlan 111 port-priority 240
  Spanning-tree vlan 112 port-priority 240
  Spanning-tree vlan 113 port-priority 240
 
 
Thanks again!!
 
Bob
----- Original Message -----
From: "ccie2be" < <mailto:ccie2be@nyc.rr.com> ccie2be@nyc.rr.com>
To: "'Bob Nelson'" < <mailto:nelsnjr@cox.net> nelsnjr@cox.net>
Sent: Friday, June 03, 2005 2:01 PM
Subject: RE: STP- Port cost vs. Port-priority
 
> Bob,
>
> What I was describing isn't load-sharing. In my description, the ports
that
> would be forwarding would be forwarding for all vlan's and the ports that
> are blocking are blocking all vlans.
>
> However, what I described can very easily be adapted to vlan
load-balancing
> because the same rules apply.
>
> For example, instead of changing the port cost for all vlans, just change
it
> for one or more vlans. Likewise, for port priority.
>
> Just remember, for priority (port or per-vlan) to have any affect, it must
> be changed on the upstream switch and for cost to have any effect, it must
> be changed on downstream switch.
>
> Here's why.
>
> The root switch will always have all it's port in forwarding mode. But,
the
> downstream must use the STP decision tree to determine which ports are
> designated and which are blocked. Also, the root or upstream switch sends
> priority to the downstream switch but doesn't send cost. Cost is always
> determined based on the incoming port, not the outgoing port.
>
> Now, review my notes for the STP decision tree.
>
> -Cost is determined the same way for STP as it is for IGP's: Cost = cost
of
> local int (going towards root) plus the cost of all int's pointing
upstream
> towards destination.
> -If there are multiple trunks connecting the 2 Cat's & each trunk is
allowed
> to carry traffic for all vlan's (the default), STP will block at least one
> interface. Assume Cat1 is the root bridge for vlan X. Once Cat1 is set
(or
> elected) Root Bridge, Cat2 must decide which port is its root port to
Cat1.
> 1. Cat2 will compare the cost of each trunk interface (by def, they're
> all equal)
> 2. Cat2 will compare BID's from each trunk - of course, they're equal.
> 3. Cat2 will then compare the port priority for each link sent from
> Cat1.
> 4. Last, Cat2 will use its own port's ID as the last tiebreaker
>
> -As a result of above process, if you have to config a particular link to
be
> in forwarding mode & you can't config Cat2 to do this, then change Port
> Priority on Cat1.
> -If the change can only be made on Cat2, lower port cost on Cat2. Notice
> that if you're restricted to modifying either port cost or port priority,
> that restriction determines on which Cat you have to make the change.
> -Verify config with show spanning-tree [options].
>
> Please let me know if you find any discrepancies between what I say and
what
> your experimenting shows.
>
> HTH, Tim
>
>
>
> -----Original Message-----
> From: Bob Nelson [mailto:nelsnjr@cox.net]
> Sent: Friday, June 03, 2005 4:44 PM
> To: ccie2be
> Subject: Re: STP- Port cost vs. Port-priority
>
> Tim:
>
> I have been researching this topic for some time, and I do not necessarily
> understand your answer.
> The usual case for this question seems to be the load sharing of traffic
> between switches, where
> you are given the requirement that vlan abc uses port one of the trunk and
> vlan xyz uses the other
> port of the trunk.
>
> I have labbed this up with my 3550s and found no difference in the
> functioning using port-priority or cost
> from either the root switch or the secondary. Using vlans 3-6 and 8-10, I
> can make 3-6 prefer trunk fa0/23 and
> 8-10 prefer trunk fa0/24 using either method. The correct ports are
blocked
> in either case. This example is
> directly out of the 3550 DOC CD.
>
> Cisco does make a distinction between the two methods:
> You configure load sharing on trunk ports by using STP port
> priorities or STP path costs.
> For load sharing using STP port priorities, both load-sharing
links
> must be connected to the same switch.
> For load sharing using STP path costs, each load-sharing link can
be
> connected to the same switch or to two different switches
>
> Tim, in taking your answer literally, I would believe it to mean that I
> could use the priority command from the root to the secondary,
> but I would have to use the cost to configure this from the secondary to
the
> primary. However, it does not work, at least for me,
> to do this. Can you elaborate on your answer a little more?
>
> Thanks,
>
> Bob
> ----- Original Message -----
> From: "ccie2be" < <mailto:ccie2be@nyc.rr.com> ccie2be@nyc.rr.com>
> To: "'Sumit'" < <mailto:sumit.kumar@comcast.net> sumit.kumar@comcast.net>;
< <mailto:ccielab@groupstudy.com> ccielab@groupstudy.com>
> Sent: Thursday, June 02, 2005 1:08 PM
> Subject: RE: STP- Port cost vs. Port-priority
>
>
> > Sumit,
> >
> > Which parameter you change depends on which switch you're making the
> change.
> >
> > The port priority is sent by the upstream switch (root) to the
downstream
> > switch so changing this value on the downstream switch wouldn't do any
> good.
> >
> > Likewise, changing cost on the upstream switch wouldn't affect the
> selection
> > of which port the downstream switch decides is the root port.
> >
> > Make sure you know this stuff. It's very important.
> >
> > HTH, Tim
> >
> >
> > -----Original Message-----
> > From: <mailto:nobody@groupstudy.com> nobody@groupstudy.com
[mailto:nobody@groupstudy.com] On Behalf Of
> > Sumit
> > Sent: Thursday, June 02, 2005 3:27 PM
> > To: <mailto:ccielab@groupstudy.com> ccielab@groupstudy.com
> > Subject: STP- Port cost vs. Port-priority
> >
> > Mates,
> >
> > As I understand the "Spanning tree port cost " manipulation should be
> able
> > to make vlan traffic prefer a trunk port over another one.
> > Is there any case we need to change "port-priority" unless changing
port
> > cost is restricted?
> >
> > thanks
> > Sumit
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > <http://www.groupstudy.com/list/CCIELab.html>
http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > <http://www.groupstudy.com/list/CCIELab.html>
http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3