<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>SGT CCIE &#187; tiebreaker</title>
	<atom:link href="http://www.sgtccie.com/blog/tag/tiebreaker/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sgtccie.com/blog</link>
	<description>A man on a mission</description>
	<lastBuildDate>Sun, 02 Oct 2011 14:22:40 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>STP: Port ID&#8217;s..making sense of it all.</title>
		<link>http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/</link>
		<comments>http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/#comments</comments>
		<pubDate>Tue, 02 Mar 2010 01:47:40 +0000</pubDate>
		<dc:creator>Mike</dc:creator>
				<category><![CDATA[CCIE]]></category>
		<category><![CDATA[Cisco tech]]></category>
		<category><![CDATA[Routing & Switching]]></category>
		<category><![CDATA[802.1D]]></category>
		<category><![CDATA[root port]]></category>
		<category><![CDATA[stp]]></category>
		<category><![CDATA[tiebreaker]]></category>

		<guid isPermaLink="false">http://www.sgtccie.com/blog/?p=532</guid>
		<description><![CDATA[<a href="http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/" title="STP: Port ID&#039;s..making sense of it all."></a>I won&#8217;t lie, when I understood the STP tiebreaker process, it was one of those &#8220;ohhhhhh&#8221; moments. And by understand, I mean, actually proved and saw it work firsthand. Here&#8217;s the deal, and I&#8217;ll explain any highlights of little things &#8230;<p class="read-more"><a href="http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/">Read more &#187;</a></p>]]></description>
			<content:encoded><![CDATA[<a href="http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/" title="STP: Port ID&#039;s..making sense of it all."></a><p>I won&#8217;t lie, when I understood the STP tiebreaker process, it was one of those &#8220;ohhhhhh&#8221; moments. And by understand, I mean, actually <strong>proved </strong>and<strong> saw</strong> it work firsthand. Here&#8217;s the deal, and I&#8217;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:</p>
<p><br class="spacer_" /></p>
<p><strong>STP Root port selection (and tiebreaker) process notes:</strong></p>
<ul>
<li><strong>There&#8217;s 2 ports per segment..a designated port (closest to the root switch), and a root port. The designated port sends out BPDU&#8217;s on the segment as it receives them (in 802.1D)..the root port does not send out any BPDU&#8217;s with the exception of TCN BPDU&#8217;s..another time, another place.</strong></li>
</ul>
<p><strong>When a switch is trying to decide between two ports in regards to root port selection, it has a few tiebreakers it tries: </strong></p>
<ul>
<li>Lowest Root BID (should be the same)</li>
<li>Lowest Root Path cost (remember, this is root PATH cost..not just the local configured cost)</li>
<li>Lowest sending BID (BID = Priority + MAC address, so even if the priorities are the default 32,768, the lowest MAC will win)</li>
<li>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&#215;8001 for Port 1/1. 0&#215;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&#8217;s only a part of the Port ID. The other part is priority, which if configured, will cause a sway in the decision process.</li>
</ul>
<p><strong>So a general rule of thumb could be developed:</strong></p>
<p><strong>-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 &#8220;loser&#8221;) 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.</strong></p>
<p><strong>-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. </strong></p>
<p><strong>Key point to take away: It&#8217;s so important to remember that BPDU&#8217;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&#8217;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).</strong></p>
<p><strong> </strong></p>
<p><strong> </strong></p>
]]></content:encoded>
			<wfw:commentRss>http://www.sgtccie.com/blog/2010/03/stp-port-ids-making-sense-of-it-all/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

