Tag Archives: 802.1D

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).

 

 

LAN Switching: Read it, or else.

Posted by on February 28, 2010 No comments

I finished the STP chapter in the CCIE exam cert guide, and was almost disappointed. I have a hard time believing anyone could expect to be fully prepared for the written exam after reading that chapter. I would highly recommend that anyone taking the written give a strong look at the LAN Switching book from cisco press, Chapters 6 and 7, which both cover STP and Advanced STP. This book is FANTASTIC as far as STP theory goes. Blows the others out of the water. Granted, the config examples are done in CatOS, but ignore those..use the BCMSN book for configuration, LAN Switching for theory, and the CCIE exam cert guide for review!

I knocked out chapter 6 of LAN Switching, and part of chapter 7. Once I finish Chapter 7, I’m going to read up on a lot of MSTP, and do some STP labs in the next few days. I’d say that I’ll call STP “done” in about 3-5 days, after which it’ll be onto some IP Addressing review, and then EIGRP. If I can maintain this pace, I think I might be able to bump up my written date, which would give me more time to prep for the lab. We’ll see! Stay posted, I may put some STP notes up tomorrow..

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.