Tag Archives: stp

STP: Port ID’s..making sense of it all.

Posted by on March 1, 2010 2 comments

I won’t lie, when I understood the STP tiebreaker process, it was one of those “ohhhhhh” moments. And by understand, I mean, actually proved and saw it work firsthand. Here’s the deal, and I’ll explain any highlights of little things that I found may be confusing for others. First, some key notes about STP and root port selection:


STP Root port selection (and tiebreaker) process notes:

  • There’s 2 ports per segment..a designated port (closest to the root switch), and a root port. The designated port sends out BPDU’s on the segment as it receives them (in 802.1D)..the root port does not send out any BPDU’s with the exception of TCN BPDU’s..another time, another place.

When a switch is trying to decide between two ports in regards to root port selection, it has a few tiebreakers it tries:

  • Lowest Root BID (should be the same)
  • Lowest Root Path cost (remember, this is root PATH cost..not just the local configured cost)
  • Lowest sending BID (BID = Priority + MAC address, so even if the priorities are the default 32,768, the lowest MAC will win)
  • Lowest Port ID..NOT just lowest port number. Port ID is a 16 bit field composed of two subfields, Port priority, and Port number. By default, Port ID would be something such as 0×8001 for Port 1/1. 0×80 in hex = 128 (default port priority). 01 equals 1, which is the last section of the interface number. So, by default, with dual links to the same switch, lowest PORT NUMBER wins, but that’s only a part of the Port ID. The other part is priority, which if configured, will cause a sway in the decision process.

So a general rule of thumb could be developed:

-When two separate paths exist to separate bridges, with the same root path cost..the lowest MAC wins by default. Configuring a lower priority on the non-designated switch (the “loser”) would change this, and cause it to become the designated bridge. If multiple redundant links are in place, this will break down further and not only choose a designated SW with the lowest MAC, it will use the interface with the lowest port number.

-When dual links exist to the same bridge, lowest port number wins. Best way to influence this (IMO) is simply adjust STP port cost on a per-interface basis.

Key point to take away: It’s so important to remember that BPDU’s are sent out the designated port as they are received. Knowing this, you know that a downstream (away from the root) switch is making it’s decisions based on RECEIVED information, with some minor exceptions such as cost (assuming that the locally configured cost affects the root path cost enough to make a difference).

 

 

STP: Root port selection

Posted by on February 28, 2010 No comments

While doing my reading on Spanning-tree and my INE Vol I labs, I kept referencing back to the book for the tie-breaker criteria for root port selection, and decided I’d post it.

In our scenario, we have two switches, SW4, and SW1, which are directly connected with three fast ethernet links. Here’s how STP would select the root port by the book, then we’ll go over what actually happens, and see how we can influence it.


Root port selection (tie breakers)

  1. Lowest sending bridge ID
  2. Lowest STP port cost
  3. Lowest port-priority
  4. Lowest interface number


Lowest Sending Bridge ID

Now, in our scenario, the sending bridge is naturally going to have the same BID, because we have 3 links all to the same switch. Remember, the BID is the priority of the bridge (32768 + VLAN ID if system-id extension is enabled), and the MAC address. That being said, regardless, this won’t matter if the links are all to the same switch…

Lowest STP Port cost

This is referring to the outbound port cost. Remember, STP port cost is associated with an interface, NOT the link itself. So, SW4′s interface is 19 by default, which means, all three interfaces tie.

Lowest port-priority

This one confuses people. If we configure a low port priority on SW4..it will NOT influence root port selection. Why? Well, BPDU’s are being sent TO us from SW1, listing the port priorities. You can verify this by debugging and seeing that the port priorities for all three ports are included in incoming BPDU’s.

Lowest interface number

Sad, but true, this is the best we can do! It ends up selecting f0/13, instead of f0/14, or f0/15.


How we can influence root port selection on redundant links

  • Adjust the STP port cost (outgoing, remember that) on SW4
  • Adjust the port priority on SW1′s links to SW4

At the end of the day, because of the order tiebreakers occur, cost will always override the priority. It makes sense, cost is locally configured, priority is configured on the designated port for that segment. It should be noted, however, that if there is say, a ring topology with 4 switches (such as the INE topology), and you have two links, to two different switches, the process is the same, but root path cost comes into play.

Anyway..off to bed..got some solid labbing done tonight.



Keeping track of it all: ip access-list log-update threshold

Posted by on February 26, 2010 No comments

I’ve been doing some great studying lately. Here’s my progress:

-Read up to page 85 on the CCIE Exam Cert Guide (4th edition)

-Read 10-20 pages of the BCMSN book, used it to review on some layer 2 topics that the exam cert guide didn’t go into to much detail with

-Did up to page 40′ish on the INE Volume I labs. I’ve been taking my time to make sure I have the verification commands down, and know that I’m “good” at certain technologies. This is especially important to me, since switching is doubtedly a core topic..everything else would break without it!


ip access-list log-update threshold X

I stumbled onto this command thanks to the INE ATC. By default, when you add the “log” keyword to an access-list entry, it will log the first hit, and subsequent identical hits will be logged at 5 minute intervals. Great for the real world (sometimes), not so great for the lab. I find it helpful to know one-for-one, that I have a packet passing through that meets that particular ACL. By entering this command, and putting a “1″ where the X is, it will log hits 1-for-1. Pretty helpful I think.


Anyway, back to studying. I’m now entering the world of STP, so if you don’t hear from me, send help ASAP I’ll be fine.



The effects of Uplinkfast

Posted by on April 26, 2009 No comments

Uplinkfast. How many of you can honestly say you’ve used it? Some of you? Most of you? Ok, well I guess I am the minority! I have seen spanning-tree uplinkfast used in configs, but never took the time to really understand the effects of it. The idea is simple enough. You have an access layer switch, with redunant links to the distribution layer. What if one of those links fail? Yes, the access switch will change it’s root port to the other (still working) link, but only after transitioning through the listening and learning states. The length of time it will take is based on the forward timer, which by default is 15 seconds. The default time to transition from blocking to forwarding can take up to 50 seconds. What uplinkfast will do is transition within 5 seconds from the failed link to the new link (changing it’s root port in the process). Much better!

Now, onto the actual effects of uplinkfast. First, uplinkfast will raise the STP priority from the default 32,768 to 49,152 for all VLAN’s. The best way to understand the logic behind this is to figure that by configuring uplinkfast on a switch, you are essentially saying “this switch is an access layer switch”..since uplinkfast is designed for access/edge devices. The higher priority will prevent this switch from becoming the root switch for the STP instance. As you can imagine, having an access-layer switch become the root switch is a very poor design!

The second effect of uplinkfast is that the STP path costs will be changed to 3000 + the current cost (assuming they are the default, we’ll say 19 for a 100 meg link)..this means the costs will be 3019. Why? This will also prevent the access switch from becoming somewhat of a transit point for traffic, because the cost will be so high that every other link into the core will appear much more attractive.

Finally, it’s worth mentioning that when uplinkfast transitions the new root port from blocking to forwarding, it will send out station-learning  multicast frames at a default of 150 packets per second. You can adjust this flood of multicast traffic in the following way: spanning-tree max-update-rate {0-32000}

Note: If you configure the max-update-rate to 0, no station-learning frames will be sent out. This will slow the convergence after a link failure.

There you have it! I was  talking to a buddy of mine about these bits of information regarding the path cost, and decided it’d be good to put it up for others to benefit from. Enjoy! Time to get back to STP and all the details.