nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Packet Tracer and STP

CodeBlox

Okay, I think after a few hours of sort of scratching my head, I've come to the conclusion that STP does not function as it should in PT. Someone back me up on this.

Example 1:

In a two switch topology with redundant trunks between the two switches, as expected, one port will block. However, the "not functioning properly" comes in when I configure a lower port priority on the one blocking port. Quite simply, IT DOESN'T WORK. If I configure it on the designated port for that segment however, the once blocking port changes to the root port. Unless I understood this wrong, thats incorrect. So the question I guess for this example is: Does a port base its desicion of selecting a root port in the event of a tie on its LOCAL port priority for that interfaces, or is it the port priotority of the remote switch? From my reading, it sounds like it should come from the local switch. I know I'm not crazy and I just believe that packet tracer is whacked.

Example 2:

In a four router topology, there is one switch (as expected) with a blocking interface. I think it chooses the root port incorrectly. Per the way STP works, if the cost tie to reach the root, the next tie breaker is port priority, then internal interface number. Well, if I configure a port priority value on the blocked interface, root port never changes for that switch. In fact, in packet tracer, it appears that the root port is based on the remote switch with the less BID when a tie occurs and NOT port priority/internal interface number. Question for that is: Root ports ARE selected before designated ports right?

Someone tell me I'm not crazy! I have two 2950 switches that I'm going to test this with in a bit and see if I get the expected behavior.

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

networker050184

The port priority value is examined in the recieved BPDU. The port ID has two fields, port priority and port index.

CodeBlox

I couldn't find the actual fields searching google, but in PT, "Port ID" is the priority part of the BID. I don't see either the port priority or port index in the fields. But thats good to know that the port priority is examined from the BPDU of the remote switch. I don't think wendle odems book clarifies on that.

How about my second example, it doesn't appear that packet tracer is even considering port priority/internal interface number in its tie breaking decision. In my current example, i have a STP cost tie and it appears that the port priority wasn't even considered and the interface that recieved the lower BID became the root port and the other blocked.

It's the 4 switch topology on the left. Switch12's Fa0/1 interface has a port priority of 16 yet Switch14's Fa0/2 still blocks.

topology.jpg

networker050184

I believe you may be seeing the switch using the lower sending bridge ID prior to checking port ID. The election process uses cost to root, then sending bridge ID and after that it checks the port ID portion.

CodeBlox

That would explain the whole thing then, because in the two switch topology, things work as expected and changing port priority changes the root port. This is because the BPDU contains the SAME BID regardless of the interface because they come from the same switch. This was not clarified in the book at all, they mention that the lower BID is considered as a tie breaker for selecting the designated port but they don't say so for selecting the root port. Thank you, it makes perfect sense now! Two things learned here:

1) The port priority is examined from the recieved BPDU and it is NOT considered from the local switches configured value in a tie breaker.
2) A lower BID IS considered in the root port selection process. Too bad "spanning-tree vlan [vlan-id] cost [value]" is not implemented in PT. I could play with this further. I am limited to the two switches that I own as far as hardware goes.

networker050184

This is definitely one of the more cloudy parts of STP I hav enoticed. Remember port ID only comes into play if both ports go to the same switch.

hiddenknight821

networker050184 wrote: »

This is definitely one of the more cloudy parts of STP I have noticed. Remember port ID only comes into play if both ports go to the same switch.

+1. I was stuck on this as well a while back, and I had to lab it to understand what's happening. I was using Odom's book, and it has an error, which threw me off. So, I had to look at the errata. I hate it when that happen, especially on an important major topic that I need to understand.

1. Whoever forward the lowest cost to the root get to be the designated port.

2. If there's a tie, then the lowest bridge ID (priority followed by main MAC address) wins.

3. If there's a tie on the Bridge ID (even if the MAC address and priority are the same [This mean that both ports are connected to the same switch]), then the lowest port ID (port priority followed by port number) wins.

Ltat42a

Does this help?

Spanning Tree Protocol - YouTube

There are several other Packet Tracer/STP videos on Youtube