Performance Evaluation using Spanning Tree Protocol, Rapid Spanning Tree Protocol, Per-VLAN Spanning Tree, and Multiple Spanning Tree

1. INTRODUCTION

The second layer of the OSI model, known as the data link layer, encounters redundancy issues, notably the emergence of network loops when connecting numerous switches through multiple paths. In addition, these challenges necessitate effective protocols to prevent loops and ensure the stability of switched networks. Moreover, the widely employed spanning tree protocol (STP) addresses this concern by implementing a spanning tree technique, eliminating loops within switches, and restoring broken links [1]. This protocol, specified in the IEEE 802.1D standard, designates a root switch and builds a topology tree to optimize the network’s efficiency [2]. Finally, the root switch is chosen based on criteria such as the lowest MAC address or priority. STP ensures a loop-free topology by blocking certain links with higher path costs to the root switch [3]. Designated ports, root ports, and backup ports play crucial roles in determining the network’s optimal configuration [4], [5]; moreover, to enhance the convergence speed of (STP), the rapid STP (RSTP) was introduced. In addition, this improved version combines several states of (STP) into a single discarding step [6], [7], significantly reducing convergence time to (30) to (50) seconds. Moreover, the port states in RSTP include disabled, blocking, listening, learning, and forwarding [2], [8]. Recognizing the limitations of a single instance (STP) for each VLAN, Cisco introduced the per-VLAN spanning tree (PVST) protocol. In addition, PVST operates as a distinct instance for each VLAN, addressing the challenge of slowed BPDU transmission [9]. Finally, the evolution of STP continues with the introduction of the multiple STP (MSTP), described in the 802.1S standard [10]. Moreover, MSTP incorporates features from both (RSTP) and VLAN protocols, reducing the number of instances and allowing for better scalability. MSTP introduces the concept of multiple spanning tree instances and regions to organize switches with similar configuration attributes [11], [12].

However, today’s publications have a problem. They used only a few metrics to evaluate these protocols, similar to combining delay and convergence to evaluate a protocol. This paper attempts to assess each of the four approaches using around seven metrics. Moreover, these measurements’ outputs allow for the determination of the optimal approach in every circumstance. Moreover, neither of the papers evaluated these four protocols together. The tests in this study will be STP, PVST, RSTP, and MSTP. Finally, this paper will evaluate the proposed protocols using key metrics for evaluation including:

These metrics form the basis for a comprehensive evaluation of the protocols’ effectiveness in real-world networking scenarios.

Besides, in the following sections will briefly discuss how each protocol is assessed. Moreover, the test parameters and outcomes will be shown, also methods of measuring observations. Finally, discuss the conclusions made by the evaluators.

2. ILLUSTRATIONS OF STP, RSTP, PVST, AND MST

Figures illustrating protocols will be provided in this part so that their operation can be better understood. As can be seen, Fig. 1 (STP) represents the easiest design to comprehend and the one with the simplest loop. Finally, to shorten the path and obtain a free-loop design, one of the ports is being blocked.

Fig. 1. An illustration of spanning tree protocol.

Moreover, in Fig. 2, which depicts how (RSTP) operates, (RSTP) includes more ports, including backup and alternate ports. However, the concept behind STP remains the same, with the exception that RSTP converges more quickly. PVST, as depicted in Fig. 3. The root bridge for each VLAN can be a different switch. Every link is functional in PVST mode. According to VLAN 10, one of the links is blocked, in addition for VLAN 20, another link is blocked. The number (STP) instances are equal to the number of VLANs.

Fig. 2. An illustration of rapid spanning tree protocol.

Fig. 3. An illustration of per-VLAN spanning tree.

A diagram of MST is shown in Fig. 4. Furthermore, it is well known that (MST) uses regions to divide switches with identical configurations. Moreover, the diagram makes it simple to see the regions. Those switches that have the same configurations will be in the same region.

Fig. 4. An illustration of multiple spanning tree.

3. LITERATURE REVIEW

The majority of papers discussing this topic only cover a small portion of the evaluation. However, the majority of the publications employed almost two evaluation protocols, or a limited set of metrics has been used for testing these protocols. This work attempts to assess seven metrics and four protocols using improved tools such as GNS3. Consequently, some of the papers cited in this work are old. Based on the findings of today’s research, it can be stated that there are just a few different kinds of studies on the performance evaluation of free-loop algorithms. However, to describe the convergence time between (STP) and (RSTP), Sergio et al. (2018) conducted an environment using the (GNS3) tool. To calculate the topology’s convergence time and connectivity loss, he needed a steady stream of data as can be seen in Tables 1 and 2.

TABLE 1: STP convergence time after connectivity loss

TABLE 2: RSTP convergence time after connectivity loss

In Sánchez-Herranz [14], moreover, according to Lapukhov et al. (2010), only under specific circumstances can (RSTP) convergence occur in less than one second, demonstrated by the tests in this paper, it cannot benefit from (RSTP’s) fast convergence if the topology expands to include more than five bridges [15]. According to evaluations by Wang on various iterations of the STP protocol, PVST convergence is much slower than RSTP and MSTP, taking longer than 30 s as shown in Tables 3 and 4 [16].

TABLE 3: MSTP convergence time

TABLE 4: RSTP convergence time

In addition, ring topology and tree topology were the two different topologies that Pallos et al. (2007) tested (RSTP). Above all, this paper made use of the OPNET tool. The first ring implements topology. In addition, different versions are used to test (3, 4, 5, 6, and 7 bridges). The results demonstrate that the time for recovery increases as the number of bridges increases [17]. Moreover, according to Al-Balushi et al. (2012), PVST, MSTP, and RSTP are the STPs employed in this experiment. Data between an (FTP) server and a client on each (STP) mode is captured using a wire shark. The test results demonstrate that all modes may transfer data up to a maximum size of (700); however, (PVST) has captured fewer loops than (MSTP) and (RSTP). This study demonstrated that the optimal mode in terms of performance is PVST [18]. Both (RSTP) and (STP) were put to the test in various topologies by Amit noting that (STP) is more scalable and (RSTP) has a quicker convergence time but in smaller designs [19]. Furthermore, Abuguba et al. performed (RSTP) simulations on mesh and ring topologies for networks with 3–30 nodes in various sizes. They found that when the number of nodes grew, message loops might also grow [20]. A work by Craiova et al. (2013) was released to speed up (MSTP) convergence. The configurations utilized to lower (MSTP) from 50 ms to 15 ms are as follows: Maximum age is (34); forward delay is (5), and hello timer is (4). They were able to accelerate (MSTP) and even (RSTP) convergence by using various configurations on various topologies. They only mentioned that the theoretical portion of the test was conducted; the practical portion was left out [5]. Farhan et al. (2019) employed a spanning tree in some cases to test load balancing on (SDN) networks. The final test, which looked at bandwidth utilization, indicated that there is not a significant difference between systems that use load balancing and those that do not. This research used common (STP) for layer-2 free loop architecture to test (SDN) with load balancing more efficiently [21]. In addition, Joseph et al. published a paper in 2013 about testing (STP) and (RSTP) with (OPNET) simulators. The results show that (STP) and (RSTP) both respond to connection failure in roughly 160 s, with (RSTP being somewhat faster). Furthermore, (303) seconds are required for recovery in (STP). In any case, there is not much of a difference between the two protocols. RSTP is faster, taking 3–5 s [8]. Chandan et al. (2014) used the port channel to implement several spanning tree research studies. The findings demonstrate that employing the port channel for (STP) has a significant impact on obtaining a faster convergence time from 56 s to around 5 s, as well as having a greater bandwidth of almost twice that of common (STP) with a single physical link as shown in Table 5.

TABLE 5: Port channel test on STP

Finally, Firmansyah et al. (2023), did a study on (STP) and (PVST) together using (Cisco packet tracer). For discovering convergence and overall network performance, the results show that (PVST) can provide faster convergence time and better load balancing. However, PVST needs more configuration and management compared to (STP) [23].

Above all, the main area of research right now is STP convergence. Although there are many crucial metrics to consider when assessing a network design, this paper will examine overall (STP) modes with various topologies and determine which mode is operating most effectively in all circumstances.

4. METHODOLOGY

This study used (GNS3) tool and (vIOS2) ISO for layer-2 switches to evaluate protocols. Using the cloud built within the program and building a bridge out of (GNS3)’s (VM), the topology was connected to the internet. In addition, the connection was established to the actual network and used ping to send traffic to any DNS. Moreover, DHCP server is used to assign IP addresses to the devices. In addition, the techniques to be used to gauge the metrics during the tests must be mentioned. The decision was made by using advanced technology. Accurate data is required to make decisions. However, this cannot be obtained without a large data flow. IPERF tool is being used, which is employed to determine the network’s maximum practicable bandwidth. Numerous protocols, including TCP, UDP, and SCTP with IPv4 and IPv6, are supported in IPERF tool. In addition, it returns the average of all parameters along with the bandwidth, loss, and jitter for each test. IPERF has been chosen, because it can be used as a server, a tool for creating load, and a tool for monitoring. Moreover, (IPERF) functions as the client and server idea. Once the (ISO) of (IPERF) has been imported into (GNS3), two (IPERF) devices are configured and connected to the network. As shown in the Fig. 5. It ‘is effortless to put this into practice.

Fig. 5. Connecting IPERF servers to the network.

Above all, IP addresses are manually assigned to the IPERF devices after configuring the network. Although set up one of them to serve as a client and one as a server, the command to emulate a server on a device is (iperf3 -s) as shown in Fig. 6. The server then creates a port and is prepared to respond to requests.

Fig. 6. iperf3 -s command for setting up the server and listening to requests.

Finally, on the client device, this command is been used (iperf3 -c 192.168.1.2 -I 1 -t 30 -b 100 m) as shown in Fig. 7.

Fig. 7. Command for sending packets to server from client.

(-c) denotes that this device is the client, and after that assign the server’s IP address. (-i) used to receive information every second. The test’s period, which in this test is 30 s, is determined by the value of (-t). The bandwidth is configured with (-b), which in this example is 100 Mb. The test’s results are displayed in the Fig. 8.

Fig. 8. Results shown after a connection between IPEERF client and server happens.

In summary, the report informs that 107 Mbytes of data were transported during this test with an average bandwidth of roughly 30 Mbits/s. Because IPERF is a sophisticated tool, (-P) can send multiple client requests from various ports on the same IP. For instance, it is possible to assign (-P 10). As a result, when the test starts, the server receives requests for 10 separate devices. Moreover, using the (-u) command, which requests using (UDP) rather than (TCP), an even higher load can be created. As is well known, the network can experience a significant strain due to the use of UDP for streaming. Bandwidth, jitter, and loss on the networks can be assessed by employing (IPERF), which allows network performance decisions more effectively. Moreover, these indicators have an impact on output. In the following tests, data that are more accurate and realistic can be gathered through the utilization of appropriate methods. Finally, by evaluating the requests that fail to arrive at the desired location, other metrics, such as convergence, can be discovered. Ping command (which is a command used to ensure connectivity of two devices that use ICMP protocol) is being used with the (-t) flag to ping repeatedly see Fig. 9.

Fig. 9. Discovering convergence by calculating the time connection loss.

However, the average response time for a ping request is 1 s, within this time frame, there were six general failures (requests timed out). It can be inferred from this that there was a disconnection from the internet for approximately 6 s. Convergence in STP is measured using the same methodology. The topology was manually adjusted and made a ping (-t), finally timed-out requests will be measured till the requests get a replay once more. No switch path requests were sent throughout the convergence period. This period occurred when STP rebuilt the topology (to put it simply, the internet ceased to function). To enable pinging and receive accurate data from the internet, DHCP is used to link the devices to the cloud and assign an IP address to them. Based on a comparison of the output from the small and big topologies, reliability and scalability must be determined. In addition, the final issue is congestion; a massive load must be created utilizing (UDP) and roughly 100 parallel networks. They are all making data requests at once.

5. EVALUATION

5.1. Test (STP)

Testing STP is the first test that is going to be done. Because the configuration of this protocol is the simplest. In addition, 50 parallel networks were employed. UDP protocol was used. A bandwidth of 1000 Mbits was requested for around 60 s. Moreover, to measure actual (delay) data, the network was connected to the cloud. Finally, another test was done by employing 100 parallel networks to create a massive load that lasted 100 s. In summary, (STP) can manage enormous amounts of data.

The small and large test topology is shown in Figs. 10 and 11 see Tables 6 and 7 for LAN characteristics.

Fig. 10. Small topology.

Fig. 11. Large topology.

TABLE 6: LAN characteristics of Figure 10

TABLE 7: LAN characteristics of Figure 11

The data measured on (STP) for both small and big topologies are shown in Table 8.

TABLE 8: STP results

The chart demonstrates that (STP) can give an excellent result overall. The huge topology has reduced delay; 1-s change in convergence time is an excellent result. It scales very well. However, the jitter’s output reveals that there has been a significant change. It is crucial to note how well 100 parallel networks performed on (STP). The only issue with (STP) is the delay and jitter, which for small networks is a little high at 146 ms.

5.2. Test (RSTP)

However, testing (RSTP) is the second test. The same (IPERF) parameters are used for (STP). Moreover, the test will last 60 seconds. It has a combined bandwidth of 1000 Mbits and 50 parallel networks. Plus, the (UDP) protocol. First, the compact design was set with five switches and two (IPERF) components. In addition, the cloud-assisted in identifying (delays) in both topologies. Similar to (STP), 100 simultaneous networks are requested with a bandwidth of 1000 Mbits to detect congestion. The test was not finished since connection was lost on devices, in summary (RSTP) cannot handle that much demand because it has repeatedly lost connection.

The data measured on (RSTP) for both small and big topologies are shown in Table 9.

TABLE 9: RSTP results

Table 9 shows that (RSTP) performs well in delay and convergence. However, for other metrics, such as jitter and congestion, it is arguable that (RSTP) cannot be relied on for large networks. Moreover, it can be beneficial for small networks that do not need to expand in the future. Another issue with RSTP is a connection loss, which caused it to repeatedly disconnect from the cloud while running the ping command (ping 8.8.8.8 -t). However, it did not perform well in the congestion test. Finally, the small design transferred 143 Gigabytes of data. This amount is very good but not particularly useful due to connection loss issues.

5.3. Test (PVST)

First, PVST was set up by turning all links into trunks, except those that connected to end devices. Moreover, IPERF devices’ IP addresses are assigned and configured. One of them is set to be the server and another as the client. As in STP and RSTP, the command (iperf3 -c 192.168.1.1 -I 1 -t 60 -u -b 1000m -P 50) is used.

The data measured on PVST for both small and big topologies are shown in Table 10.

TABLE 10: PVST results

These results indicate that (PVST) fared the best across all fields. Many metrics in the largetopology decreased, indicating that (PVST) has a very high degree of scalability. In summary, the delay decreased from 121 ms to 77 ms, and congestion decreased from 32 s to 26 s. Jitter increased by 1.642. Moreover, it operates best when all 100 networks are simultaneously requested. Given its excellent capabilities, PVST can be used for sophisticated designs and networks.

5.4. Test (MST)

In the beginning, the network was inaccessible even with switch configurations. However, MST test was conducted several times. This indicates that the network requires time to prepare for use. The examination was extended for an additional 10–15 min. Moreover, the results of the mini and large tests are shown in Table 11. However, (delay) encountered difficulty during testing since the connection was repeatedly lost. In addition, the design went completely down while 50 parallel networks had been used. Finally, the test had to be stopped. In addition, 100 parallel requests using TCP were tested and there was no issue. In summary, UDP was used for MST with a single parallel network.

TABLE 11: MST results

The data measured on MST for small and big topologies are shown in Table 11.

MSTs performance fell short of what was predicted in the other articles. It scales poorly and has a large delay. In addition, due to very poor congestion capacity, just one parallel network was used for all MST tests on big designs. However, using more than one network caused it to lose connectivity. The record for the worst outcome was broken by the jitter in the small network.

The data that were measured on (all modes) for both small and big topologies are shown in Table 12.

TABLE 12: STP, RSTP, PVST, and MST results

A comparison of all modes for all metrics with small and large design tests is shown in the table. According to the findings, PVST can be claimed to be in the top spot. As can be seen in the table, it had the best performance across all criteria. Moreover, STP and PVST worked best for congestion. Regarding the delay, RSTP comes in first for small topologies. Moreover, for large topologies, PVST comes in first. PVST or STP can be options if a network needs to be designed to be scalable. In addition, RSTP is recommended for throughput. However, due to the issue of connectivity loss, PVST can be helpful in that area. In terms of packet loss, all modes fared the best. The best performance, according to the statistics in the table, belongs to PVST.

6. CONCLUSION

STP, MST, PVST, and RSTP examinations produced several significant conclusions. Above all, it was discovered that each of these protocols has distinct advantages and disadvantages and that the ideal protocol to use depends on the particular needs of the network. In summary, the test results show that STP is easy to use and achieves average or even good performance overall. However, it has an issue with delay, which consistently has a high latency. On the other hand, RSTP performs well on small networks and has quick convergence, which is a benefit, but it cannot support as much load as STP. In addition, PVST performed best in the experiments. It is notable from its outputs that it can withstand a lot of pressure and is quite scalable. The only issue with PVST is that it requires strong hardware. PVST is a good option if a very high-performance network design is needed. While MST is thought of as a fairly dependable way of operating, but sadly, MST did not perform as well as it had anticipated. It cannot handle large amounts of data and has delay problems as well as very high jitter. Finally, while no mode is 100% flawless, it is suggestible to use (RSTP) if the network is simple and has fast convergence with dependable delay and capacity. Moreover, STP can be utilized if latency is not focused on. Because it can bear pressure during irregular times and is good at scaling and bandwidth. Finally, PVST can be chosen if pricey, cutting-edge hardware can be afforded. It is incredibly high-performance and capable and serves well in every area. MST applies to both simple networks and networks with outdated or subpar hardware that cannot execute at a high level of performance.