Skip to main content

How Spanning-Tree Works 802.1D / Made-Easy STP Process in Steps

There are three major Steps of Spanning tree process, these are shown in the table below with brief descriptions. Look at these first then we explain the STP process Steps in a brief and very comprehensive way.

Table 1
Electing a Root Switch
Only one switch can be the root of the spanning tree; to select the root, the switches hold an election. Each switch begins its STP logic by creating and sending an STP Hello bridge protocol data unit (BPDU) message, claiming to be the root switch. If a switch hears a superior Hello—a Hello with a lower bridge ID—it stops claiming to be root by ceasing to originate and send Hellos.
Instead, the switch starts forwarding the superior Hellos received from the superior candidate.
Eventually, all switches except the switch with the best bridge ID cease to originate Hellos; that one switch wins the election and becomes the root switch.
The original IEEE 802.1d bridge ID held two fields:
  • The 2-byte Priority field, which was designed to be configured on the various switches to affect the results of the STP election process.

  • A 6-byte MAC Address field, which was included as a tiebreaker, because each switch’s bridge ID includes a MAC address value that should be unique to each switch. As a result, some switch must win the root election.

The format of the original 802.1d bridge ID has been redefined. Figure 1 shows the original and new format of the bridge IDs.
Figure 1
The format was changed mainly due to the advent of multiple spanning trees as supported by Per VLAN Spanning Tree Plus (PVST+) and IEEE 802.1s Multiple Spanning Trees (MST). With the old-style bridge ID format, a switch’s bridge ID for each STP instance (possibly one per VLAN) was identical if the switch used a single MAC address when building the bridge ID. Having multiple STP instances with the same bridge ID was confusing, so vendors such as Cisco Systems used a different Ethernet BIA for each VLAN when creating the old-style bridge IDs. This provided a different bridge ID per VLAN, but it consumed a large number of reserved BIAs in each switch.
The System ID Extension allows a network to use multiple instances of STP, even one per VLAN, but without the need to consume a separate BIA on each switch for each STP instance. The System ID Extension field allows the VLAN ID to be placed into what was formerly the last 12 bits of the Priority field. A switch can use a single MAC address to build bridge IDs, and with the VLAN
number in the System ID Extension field still have a unique bridge ID in each VLAN. The use of the System ID Extension field is also called MAC address reduction, because of the need for many fewer reserved MAC addresses on each switch.
Determining the Root Port
Once the root is elected, the rest of the switches now need to determine their Root Port (RP). The process proceeds as described in the following list:
1. The root creates and sends a Hello every Hello timer (2 seconds default).
2. Each switch that receives a Hello forwards the Hello after updating the following fields in the Hello: the cost, the forwarding switch’s bridge ID, forwarder’s port priority, and forwarder’s port number.
3. Switches do not forward Hellos out ports that stabilize into a blocking state.
4. Of all the ports in which a switch receives Hellos, the port with the least calculated cost to the root is the RP.
Figure 2
A switch must examine the cost value in each Hello, plus the switch’s STP port costs, in order to determine its least cost path to reach the root. To do so, the switch adds the cost listed in the Hello message to the switch’s port cost of the port on which the Hello was received. For example, Figure 2 shows the loop network design and details several STP cost circulations.
In Figure 2, SW1 happened to become root, and is originating Hellos of cost 0. SW3 receives two Hellos, one with cost 0 and one with cost 38. However, SW3 must then calculate its cost to reach the root, which is the advertised cost (0 and 38, respectively) plus SW3’s port costs (100 and 19, respectively). As a result, although SW3 has a direct link to SW1, the calculated cost is lower out interface fa0/4 (cost 57) than it is out interface fa0/1 (cost 100), so SW3 chooses its fa0/4 interface as its RP.
While the costs shown in Figure 2 might seem a bit contrived, the same result would happen with default port costs if the link from SW1 to SW3 were Fast Ethernet (default cost 19), and the other links were Gigabit Ethernet (default cost 4). Table 2 lists the default port costs according to IEEE 802.1d. Note that the IEEE updated 802.1d in the late 1990s, changing the suggested default port costs.

When a switch receives multiple Hellos with equal calculated cost, it uses the following tiebreakers:
1. Pick the lowest value of the forwarding switch’s bridge ID.2. Use the lowest port priority of the neighboring switch. The neighboring switch added its own port priority to the Hello before forwarding it.
3. Use the lowest internal port number (of the forwarding switch) as listed inside the received Hellos.
Note that if the first tiebreaker in this list fails to produce an RP, this switch must have multiple links to the same neighboring switch. The last two tiebreakers simply help decide which of the multiple parallel links to use.
Determining the Designated Port
A converged STP topology results in only one switch forwarding Hellos onto each LAN segment. The switch that forwards onto a LAN segment is called the designated switch for that segment, and the port that it uses to forward frames onto that segment is called the Designated Port (DP).
To win the right to be the DP, a switch must send the Hello with the lowest advertised cost onto the segment. For instance, consider the segment between SW3 and SW4 in Figure 2 before the DP has been determined on that segment. SW3 would get Hellos directly from SW1, compute its cost to the root over that path, and then forward the Hello out its fa 0/4 interface to SW4, with cost 100. Similarly, SW4 will forward a Hello with cost 38, as shown in Figure 2. SW4’s fa 0/3 port becomes the DP due to its lower advertised cost.
Only the DP forwards Hellos onto a LAN segment as well. In the same example, SW4 keeps sending the cost-38 Hellos out the port, but SW3 stops sending its inferior Hellos.
When the cost is a tie, STP uses the same tiebreakers to choose the DP as when choosing an RP:
lowest forwarder’s bridge ID, lowest forwarder’s port priority, and lowest forwarder’s port number.


Popular posts from this blog

How to check Gray-log current running version

If you planning to upgrade your graylog and want to see what your graylog current version is, here is how you can check it. Go to the Graylog Web Interface Click on System/Nodes Under System/Nodes --- Click on the N odes  Scroll down to the ' System ' Here you can see the current version of your graylog server

How to import Putty Saved Connections to mRemoteNG

Just started using mRemoteNG and its being very cool to connect to different remote connection with different protocols e.g Window Remote Desktop, VNC to Linux, SSH, HTTP connection etc. from a single application. As new user I configured some remote desktop connection which was quite easy to figure out. But when I wanted to add SSH connections, it came in my mind to import all of the saved connections in the putty. But I couldn't figure it out how can it be done, though it was quite easy and here are the steps. Open your mRemoteNG Create a folder if you want segregation of multiple networks Create a new connection Enter the IP address of remote server under connection in Config pane Under the config pane, select protocol " SSH version 2 ".  Once you select protocol to SSH version 2 you are given option to import putty sessions, as shown in the snap below. In the above snap, I have imported CSR-AWS session from my saved sessions in Putty.

Connection control operation failed for disk 'ide1:0'

I was getting this error while removing Operating System ISO image mounted on the Virtual Machine. What worked for me, is 1. Uncheck the "Connected and Connect at power on" from Device Status. 2. Then Change the Device type from " Datastore ISO File to Client Device " Radio Button 3. and press OK to save the changes. Note:- I was able to remove the mounted ISO only by directly logging to the ESXi at https://esxi-ip-address/ui where it asks "The guest operating system has locked the CD-ROM door and is probably using the CD-ROM, which can prevent the guest from recognizing media changes. If possible, eject the CD-ROM from inside the guest before disconnecting. Disconnect anyway and override the lock?" You need to select yes to eject the CD-ROM and then remove the ISO file successfully.