The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
Spanning Tree Protocol priorities
By stretch | Monday, May 5, 2008 at 1:38 a.m. UTC
STP is vital for detecting loops within a switched network. Spanning tree works by designating a common reference point (the root bridge) and systematically building a loop-free tree from the root to all other bridges. All redundant paths remain blocked unless a designated link fails. The following criteria are used by each spanning tree node to select a path to the root bridge:
- Lowest root bridge ID - Determines the root bridge
- Lowest cost to the root bridge - Favors the upstream switch with the least cost to root
- Lowest sender bridge ID - Serves as a tie breaker if multiple upstream switches have equal cost to root
- Lowest sender port ID - Serves as a tie breaker if a switch has multiple (non-Etherchannel) links to a single upstream switch
We can manually configure the priority of a switch and its individual interfaces to influence path selection. The values given below are defaults.
Switch(config)# spanning-tree vlan 1 priority 32768 Switch(config)# interface g0/1 Switch(config-if)# spanning-tree vlan 1 port-priority 128
So where do these configured STP priorities come into play? There is no BPDU field for priority; instead, both bridge and port IDs have their administratively configured priorities embedded in them. Note the Bridge Identifier and Port Identifier fields in this Wireshark capture of a PVST+ BPDU:
Although the bridge ID field has been conveniently split into a bridge priority and MAC address for us by Wireshark's protocol descriptor, it is actually a single eight-byte value. The following field, which contains the port ID unique to each interface, is similarly composed at one-fourth the size.
Because this switch is running PVST+, the VLAN ID (1) is added to the configured bridge priority of 32768 (the default priority) for a sum of 32769. The unique bridge ID, taken from a MAC address, is appended to this value to form the complete bridge ID. Similarly, the port ID is formed by prepending the 4-bit port priority (the default value of 128, or 0x80) to the interface ID, which happens to be 0x001 because we are connected to the first physical switchport. These two values form the complete port ID of 0x8001.
Posted in Switching
Comments
August 25, 2009 at 2:39 p.m. UTC
"Similarly, the port ID is formed by prepending the 4-bit port priority (the default value of 128, or 0x80)"
128 will not fit in 4 bits. It is 8 bits for priority and 8 bits for ID AFAIK
August 25, 2009 at 9:48 p.m. UTC
@spanner: The priorities are offset by four bits, with the other four bits of the first byte dedicated to the interface ID, which is why you can only assign priorities which are evenly divisible by 16.
August 26, 2009 at 9:34 a.m. UTC
You are right. Mentioning offset would make the article more clarifying. Also interpretation of the port priority field is standard version dependent. I guess it is 4+12 bits for PVST+ and 802.1D-2004. Though it was 8+8 bits for the legacy STP in 802.1D-1998.
So nowadays 256 ports is not enough :)
February 1, 2011 at 10:41 a.m. UTC
i'm confused about the default value for "Port Priority". Is it 128 as you mentioned in this article (or) 32 according to this url : http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96a.shtml
February 1, 2011 at 3:20 p.m. UTC
@achilles: That appears to be a very outdated document (CatOS). The default port priority on modern Catalyst switches is 128.
July 20, 2013 at 10:37 p.m. UTC
pg.72 Section 3.4.6 Assigning Port Numbers from "Interconnections Second Edition"
"Someone recently complained to me that bridges couldn't have more than 256 ports because of the spanning-tree algorithm... I checked out the 802 standard. It says that the 2-byte priority port ID should be divided into two portions: the top byte should be "priority," and the bottom byte should uniquely specify the port. This would allow only 256 ports..." Radia Perlman
To me this implies that 256 should be divided, equaling 128. But still doesn't make sense to me, because 1byte= 8 bits = 255 in decimal...
I couldn't find anything on RFC 3418 either. It's possible that's not the one to read. The funny thing about all this is the bridge priority of 32768, I just except blindly.
Why 128?
February 28, 2014 at 3:24 a.m. UTC
Jeremy, thanks! Really good!
I have also just finished on a new article regarding bridge id, priorities, etc.
http://blogbt.net/index.php/2014/02/stp-determining-setting-root-bridge/
You/your readers might find it useful too.
March 24, 2014 at 2:39 p.m. UTC
Hi guys... Not sure if this is the right place to post this, but I've been reading about STP tiebreakers and I have a little question:
As far as I know, STP tiebreakers for electing the root ports are:
BID (Electing the root bridge) Lower Path Cost (Selecting the best route to the root brige Lower BID (If two or more paths have the same cost to the root brige) Lower Recieved Port-Priority (This only happens if I a switch have multiple links connected to the same neighboor switch) Lower Local Port-Priority (This only happens if a switch have multiple ports connected to the same port of a neighboor switch. I think using a hub, for example) I've made some test and tiebreakers work fine. But I've also noticed that this tiebreakers apply for electing root ports, and not when electing designated ports.
Let's say that I have a root switch (Switch A) connected to (Switch B). Switch A have two ports connected to the same segment ( Port 1 and 2 through a hub). Switch B have one port to that segment (Port 1). Obviosly, switch B is going to elect that port as the root port, but Switch A have to choose one designated port and it also have to block the the other one.
In that case, if you see the tiebreakers rules, switch A should go to rule number 4 (Lower Received port priority), because It received the same path coost to root (0) on both ports, and the same BID (his BID). Port 1 should receive a port priority of 128.2, which is the default priority sent by port 2. And port 2 should receive a priority of 128.1 which is the default priority sent by port 1. The rule says that lowe received por priority should break the tie, so port 2 recieve the lower priority and should be elected as the designated port.
When I did my test, port 1 was elected as the designated port, ignoring rule number 4 and going directly to rule number 5.
So, when electing designated ports, does the tiebreak rules apply?
I'm sorry if this post is too long or if it is in the wrong place, but this seems a good place to ask because I found really good information on this site.
Thank you all.
April 29, 2014 at 6:38 p.m. UTC
@stretch
When we do Rack1SW1#sh span bridge id VLAN0001 8001.0019.060c.9080 VLAN0003 8003.0019.060c.9080 VLAN0005 8005.0019.060c.9080 VLAN0006 8006.0019.060c.9080
So we See Different Bridge ID for every Vlan..... While we normally say we had one bridge ID (when we apply show spanning tree protocol command) for One Switch
Can u explain ?
August 12, 2014 at 1:41 a.m. UTC
@maybeeccie: Per Vlan Spanning Tree will run an instance of STP for each Vlan.
December 27, 2014 at 1:19 p.m. UTC
I do have a question for you why we always say that many switches are capable of Rapid Spanning Tree Protocol (IEEE 802.1w) but you did not mentioned why few network administrator enable that what is the reason behind that?