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.

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.
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.
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.

Comments

Popular posts from this blog

Basic MPLS BGP and L3VPN Lab Setup

In this lab, we’ve set up a basic MPLS, BGP, and L3VPN environment, which is a great foundation for understanding how service providers build scalable networks. The lab uses the EVE-NG simulator along with Router IOS C7200-ADVENTERPRISEK9-M, Version 15.2(4)M8 to emulate a realistic MPLS environment. Below is a summary of the key components and roles of each router in the lab. MPLS Core Routers : The MPLS core consists of the routers responsible for label switching and forwarding customer traffic through the network: PE1 (Provider Edge 1) : Connects customer networks to the MPLS core and handles both MPLS and BGP routing. It also hosts VRF (Virtual Routing and Forwarding) instances for customers. PE2 (Provider Edge 2) : Functions similarly to PE1, connecting another customer network to the MPLS core. P1 (Core Router 1) and P2 (Core Router 2) : These routers serve as MPLS core routers and handle label switching but do not store or process customer routes directly. They simply f

OSPF Adjacency Stuck in EXSTART on Cisco IOS XR – Issue and Solution

In a recent lab setup using Cisco IOS XR on EVE-NG, I faced a common but frustrating issue with OSPF adjacencies getting stuck in the EXSTART state. After spending considerable time troubleshooting interface MTUs and configurations, I discovered that the root cause was related to the virtual network interface type being used. This post outlines the issue, troubleshooting steps, and the eventual solution that got everything working. Issue: While configuring OSPF between two routers running Cisco IOS XR in my lab, OSPF adjacencies were getting stuck in the EXSTART state. I verified that interface configurations, MTU settings, and OSPF parameters were correct, but the problem persisted. I tried adjusting the MTU size, using the mtu-ignore command, and even checked for ACLs, but nothing seemed to resolve the issue. Troubleshooting Steps: MTU Settings: I started by verifying that both sides of the OSPF adjacency had matching MTUs. I used the default MTU and even tried different values wit

How to Properly Clone an EVE-NG Lab with Configurations

Cloning labs in EVE-NG is a great way to duplicate setups and expand or experiment on a new copy without affecting the original lab. However, if not done correctly, the cloned lab may only copy the topology without configurations. In this guide, I’ll show you how to properly clone a lab in EVE-NG with all configurations using the EVE-NG GUI . Follow these steps to ensure that both the topology and router configurations are retained when cloning your lab. Steps to Clone an EVE-NG Lab with Configurations Save Running Configuration on All Devices In your original lab, make sure all devices have their configurations saved to NVRAM. Go into the CLI of each router and run the command: copy running-config startup-config Export All Configurations (CFGs) On the left sidebar in the EVE-NG Web UI , click on the "More Actions" option. Then select "Export all CFGs" . This step exports the configurations of all devices in the lab. Shutdown All Devices After exporting the confi