From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri Jun 10 2005 - 18:22:45 GMT-3
You're missing some:
> We - weight
> Love - local preference
Locally originated routes
> Algorithms - as-path
> On - Origin
> My - MED
EBGP over iBGP
IGP metric to next-hop
> Router - router-id
Not to mention route age, cluster list length, and neighbor address ;)
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Drew Whitaker
> Sent: Friday, June 10, 2005 12:35 PM
> To: ccielab@groupstudy.com
> Subject: Re: mnemonics - eg for BGP Route selection
>
> Here's a few that I teach my students:
>
> BGP:
> We - weight
> Love - local preference
> Algorithms - as-path
> On - Origin
> My - MED
> Router - router-id
>
> It doesn't cover all of them, but it does cover most of the main ones.
>
> Also, for EIGRP:
> Big - bandwidth
> Daddy - Delay
> Really - Reliability
> Loves - Load
> Me - MTU
>
> And for logging:
> Entry-level - Emergencies
> Admins - Alerts
> Create - critical
> Errors - errors
> When - warnings
> Networks - notifications
> Improperly - informational
> Designed - debugging
>
> On 6/9/05, Daniel Kutchin <daniel@kutchin.com> wrote:
> > Tim and *,
> >
> > I'd like to know if you or anyone has any mnemonics he'd like to
share
> with
> > us.
> >
> > Especially, I'd like to know if you folks have any mnemonic for
lerning
> the
> > BGB Route selection algorithm below:
> >
> >
> > Discard any route whose next hop is unreachable
> > Prefer the route with the highest weight.
> > Select the route with the highest local preference attribute.
> > Prefer routes originated on this router.
> > Prefer the route with the shortest AS_PATH.
> > Prefer Interior to Exterior to Incomplete origin.
> > Prefer those with the lowest MED value.
> > Prefer routes with external rather than internal sources.
> > Prefer the path through the closest IGP neighbor.
> > Prefer the path with the lowest originating router ID.
> >
> > TIA,
> >
> >
> > ---
> >
> > Dr. Daniel Kutchin
> > Consultant Cisco(TM) Networks
> > Heinrich-Pesch-Str. 55
> > 41239 Moenchengladbach, Germany
> > Tel. +49 173 5348189
> > www.kutchin.com
> >
> >
> >
> > ----- Original Message -----
> > From: "ccie2be" <ccie2be@nyc.rr.com>
> > To: "Group Study" <ccielab@groupstudy.com>
> > Sent: Tuesday, June 07, 2005 1:06 AM
> > Subject: Re: STP- Port cost vs. Port-priority
> >
> >
> > 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
> > > >
> > > >
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3