RE: mnemonics - eg for BGP Route selection

From: ccie2be (ccie2be@nyc.rr.com)
Date: Thu Jun 09 2005 - 17:32:26 GMT-3


Hi Daniel,

Actually, I don't but I don't concern myself with that anymore. Once I
realized that the path selection algorithm was right at the beginning of the
BGP section on the Doc-CD which is available in the lab, it didn't seem
worthwhile to try to memorize this.

I figured it would be more valuable to save mental bandwidth for all the
other stuff that isn't on the Doc-CD.

HTH, Tim

-----Original Message-----
From: Daniel Kutchin [mailto:daniel@kutchin.com]
Sent: Thursday, June 09, 2005 4:22 PM
To: ccie2be; ccielab@groupstudy.com
Subject: mnemonics - eg for BGP Route selection

   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 > > > > _______________________________________________________________________ > > 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