Lab Report Example - CCNA 3 Class

Lab 3 – Redundant Links, Rapid PVST+, PortFast, & BPDU Guard

What We Did/What was the Purpose

There were 2 labs in this chapter. The purpose of the first lab was to configure a switched network with redundant links so that we could examine the process of determining a root bridge and see how STP selects ports based on cost or priority. The objective of the second lab configure a switched network to examine convergence in a PVST+ network versus Rapid PVST+ with PortFast and BPDU Guard. For both labs, we followed the instructions as outlined.

Problems & Solutions

We only had 1 problem while working through these 2 labs. We didn’t check that all of the switches had been reloaded properly. We incorrectly made the assumption that if the first was clear, then the rest would be, too. This became a problem when we checked the VLANs we’d created and noticed there were a few there that we had not created. Since we’d already configured quite a bit, we decided to use the no vlan <vlan_id> command to remove the unwanted VLANs from the database so we didn’t have to delete vlan.dat and reload the switch. Once we had all the VLANs matching on the three switches, we were able to verify connectivity.

How We Tested the Lab

As usual, we tested the labs by making sure our output matched what was expected according to the lab instructions. For the first lab, we tested connectivity of switches after initial configuration and setup by using the ping command. After configuring STP, we used the show spanning-tree command to determine the root bridge, as well as the bridge priority and port roles on each switch. We used the same command to view STP changes after we changed the port cost on the blocked port, as well as when we viewed changes based on port priority.

In the second lab, we didn’t verify anything until after configuring VLANs. We used the show vlan brief command to check that we’d configured the correct VLANs ad assigned the required ports. (This is where we noticed that one of the switches had not been properly reloaded by the last user.) We checked trunk interfaces by using the show interfaces trunk command. We also verified all the other configuration settings we made by using the show running-config command. Then we tested connectivity of our configuration with a ping from PC-A to PC-B. We used the debug spanning-tree events to watch the process of convergence happening after we shutdown a port. (We used no debug spanning-tree events to turn it off.) We used the same commands to view convergence with PVST+ and Rapid PVST+ configurations. All of our tests with both labs were successful.

What We Learned

In the first lab, we learned there are several numbers that can affect the election of the root bridge in STP. First, the switches look to the priority number (or combination of priority number and vlan id). If the priority is equal, then the switches will use the lowest MAC address. In order to determine port roles, switches look at the port cost for each port involved. Because defaults might lead to sub-optimal network switching, both the priority and port cost can be configured by an administrator. Finally, if port cost and bridge IDs are equal, port roles are determined by the port number, with the lowest port number taking priority.

In the second lab, we learned about PVST+ and Rapid PVST+. The default setting for spanning-tree mode on Cisco switches is PVST+. We learned how to configure a primary and secondary root bridge using the spanning-tree vlan <vlan_id> root primary and spanning-tree vlan <vlan_id> root secondary commands. While using a debug command to watch network convergence, we learned that Rapid PVST+ converges noticeably quicker that PVST+. Using PortFast helps with faster convergence, because it allows configured ports to go directly into forwarding mode, rather than cycling through all the steps to get there. Additionally, BPDU Guard helps protect a port by shutting it down if it receives a BPDU packet (which is not the expectation on a port where it is enabled), allowing time for an administrator to check and see if some topology change happened which would require re-configuration of the port. Overall, we learned there are several configuration factors that can be set to influence traffic patterns on a network.

Document Build Time: 2024-10-30 23:55:40 UTC
Page Version: 2022.08

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License