These formulas lead to the sample values in the table. To prevent the use of looped paths, no user data is sent or received over a blocking port. BPDU data is still received in blocking state. A blocked port may go into forwarding mode if the other links in use fail and the spanning tree algorithm determines the port may transition to the forwarding state. Listening The switch processes BPDUs and awaits possible new information that would cause it to return to the blocking state.
|Published (Last):||8 June 2009|
|PDF File Size:||4.42 Mb|
|ePub File Size:||15.29 Mb|
|Price:||Free* [*Free Regsitration Required]|
That is the same knowledge I will now attempt to impart to you, the reader, in this article. There are many facets to The protocol has many enhancements that make it converge quicker and detect failures faster. This article is not meant to describe those features.
The goal of this article is very simple. After reading this article, the learner should be able to look at any topology diagram of LAN switches and given the appropriate information about each switch be able to determine the following information: 1.
Which switch will be the spanning-tree root bridge 2. Which switch will be the secondary root bridge, in the event that the primary root bridge fails 3.
Which switch ports are in the forwarding designated state 4. Which switch ports are in the forwarding —root port state 5. In short, STP was developed to block bridging loops. In its simplest terms, a bridging loop means that a broadcast frame can be flooded out of one switch and, due to the cabling in the topology, eventually find its way back to that very same switch.
This is a loop. While there are distinct differences between bridges and switches, those differences are irrelevant from a spanning-tree perspective. All Cisco switches run There is nothing you need to do manually to turn it on. Keep in mind that because ISL and Notice that in this simple drawing there is no bridging loop, so technically speaking, STP is not needed.
In reality, it would just be additional overhead for the CPU on this switch to run the protocol. This identifier is called the bridge ID. This bridge ID is frequently used in the spanning-tree process when two or more switches are attempting to elect something between them, such as who will be the root bridge, or which port on a shared segment will forward data frames. Think of the bridge ID as being similar to the name of the switch.
These two values put together are called the bridge ID. The bridge priority, unless manually changed, is always the default value of That being the case, the one value you can always count on as being unique from one switch or bridge to the next is the MAC address.
So the combination of the bridge priority and bridge MAC address will always result in a unique bridge ID for each and every switch. All the switches will initially exchange special spanning-tree protocol data units PDUs that are called bridge protocol data units BPDUs. The root bridge within STP has a few very important tasks, such as these: 1. It is the only switch when running All other switches in the topology will simply receive BPDUs from the root bridge and then forward them on to other, downstream switches.
If the root bridge temporarily stops creating BPDUs maybe because the CPU is too busy running other protocols , all other switches will be silent.
It controls the various timers that STP uses. It informs the Layer 2-switched topology of something called topology changes not covered in this article. When a new switch comes online and determines that it needs to run Not knowing this information, the switch takes the safest course of action and immediately begins flooding the topology with its own BPDUs and advertising itself as the spanning- tree root bridge.
How exactly does it do this? The priority shown here as is really a hexadecimal number. Better put, it would be displayed as 0x, which when converted to decimal is 32, The final number of is not technically part of the bridge ID.
This number represents another descriptive identifier, called the Port- ID. This is a unique number representing the port or interface that is transmitting this BPDU. In this case, this switch is advertising itself as the root bridge.
The root bridge election process is very simple. Switches look for the switch that has the numerically lowest bridge ID, and elect that switch to be the spanning-tree root bridge. Keeping in mind that a bridge ID is technically composed of two subfields bridge priority and MAC address , the election process happens as follows: 1.
All bridges exchange BPDUs with each other. The bridge priority value is viewed and compared. If one bridge has a numerically lower bridge priority than all the others, the election process stops and that bridge is elected the spanning-tree root bridge. Because each bridge is guaranteed to have a unique MAC address, one of them is numerically lower than all the others, and that bridge is elected the spanning-tree root bridge.
So in the following topology, which switch do you believe would end up becoming the root bridge? Remember to always compare the bridge priority values first. Only if two or more of them are identical will you need to move on to comparing MAC addresses. And always read MAC addresses from left to right. So if the bridge priority values had all been identical, which switch would have won? The switch with MAC address cc would have won.
And you would have known this after comparing only the third number At this point, the root bridge no longer needs to proceed in any further elections. A switch can be a root bridge for more than one VLAN. One remaining fact about the root bridge is that all the ports it has in this particular VLAN including VLAN trunks will be placed in the forwarding designated role. I will talk more about that in a moment. Designated port 3. Nondesignated blocking port The next step that each switch except for the root bridge determines is which of its ports will become the root port.
For each active VLAN on a switch, that switch will have only one root port. The root bridge itself has no root ports. The root port is that port on the switch that has the fastest path back to the root bridge. Look at an example: In the drawing, both Bob and Cindy can drive directly to the airport.
Bob can drive directly down K Street, and it will take him 12 minutes to reach the airport. Cindy can drive directly down M Street, and it will take her only five minutes. But they are also both connected to L Street. Unless someone connected to L Street advertises that this is a viable path to the airport, neither Bob nor Cindy will even consider driving on L Street. So as a courtesy, both Bob and Cindy advertise to each other along L Street the paths they know about that lead to the airport.
If Bob and Cindy knew about multiple ways to get to the airport, they would only inform each other of the best way the fastest. He only tells her his perspective. Both Bob and Cindy now know they each have two possible ways to get to the airport. For Bob, one way will take a total of 12 minutes along K Street. The other way along L Street will actually take less time—a combined total of 11 minutes. So Bob would choose his connection to L Street as his root port. This example used driving and time expressed in minutes to make a point.
But what about switches? How do they determine how fast they can get to the root bridge? Electrons can travel from one switch up to the root bridge in microseconds. Is that the value used?
In spanning-tree terminology, the speed of a link is represented by a numerical value called cost. The higher the bandwidth is on a link, the lower the value of its cost. Remember when two or more bridges were trying to determine who would be the root bridge? Using that same rule for cost, you can understand, hopefully, why a higher-bandwidth link translates to a lower cost.
The lower the number, the better it is. These are the cost values you should memorize: Speed of link Cost.
Spanning-Tree Cost Calculation
Calculating an 802.1d Spanning-Tree Topology
Calculating an 802.1d Spanning-Tree Topology Whitepaper