Intermittent Slowness on a Third-Floor Access Switch
Users on the third floor (about 45 workstations, one 48-port access switch SW3-A) report slow and intermittent access to the finance file server on the second floor. Pings from SW3-A to the core switch show an average of 2 ms but spikes to 300-600 ms every 30-40 seconds; no packet loss is reported by users, but SMB copy throughput falls from 90 MB/s to 8 MB/s. SW3-A connects to the core via a 1 Gbps fiber uplink. The switch log shows repeated %SPANTREE-2-BLOCK_BPDUGUARD and %CDP-4-DUPLEX_MISMATCH messages on interface Gi1/0/24, which was patched last Thursday when a desk was moved. The patch cable from the desk to the wall outlet runs 3 m alongside a 380 V riser for a copier. The new hire in IT used a straight-through cable to connect a small unmanaged switch at the desk so two laptops can share the outlet. Users say the problem began Thursday afternoon.
1. Give an ordered isolation plan for the intermittent slowness, naming the command or check at each step and what result would confirm or eliminate each hypothesis.
Read the worked answer
Work from the user experience toward the physical layer, changing one variable at a time.
1. Confirm scope and pattern. Test from two third-floor hosts and one second-floor host with ping -c 200 and mtr. If only third-floor hosts see the 30-40 second spikes, the fault is local to SW3-A or its uplink. If all floors see it, look at the core or file server.
2. Check interface health on Gi1/0/24. Use show interfaces Gi1/0/24, show interfaces counters errors and show interface status. Rising FCS/CRC errors, late collisions, runts or giants indicate a physical or duplex problem. The %CDP-4-DUPLEX_MISMATCH message strongly suggests one side is half-duplex while the other is full-duplex. Confirm with show interfaces Gi1/0/24 | include duplex|speed.
3. Examine spanning tree. Run show spanning-tree interface Gi1/0/24, show spanning-tree detail and show log. A BPDU guard message means the port received BPDUs from a device that should not be there, such as the unmanaged switch. Repeated topology changes flush the MAC address table and cause flooding, which matches periodic spikes every 30-40 seconds. Check the topology-change counter before and after a spike.
4. Check for a broadcast or multicast storm. Compare broadcast and multicast rates with show interfaces | include broadcast and inspect storm-control counters. A loop through the unmanaged switch can saturate the uplink briefly on each topology change.
5. Test the cable. Replace the patch cord with a known-good Cat6 lead, move it away from the power riser, and run a cable tester or TDR if the switch supports it. CRC errors that stop after replacement confirm the cable; errors that continue point to the switch port or NIC. Swap the device to another port as a final check.
2. Explain the mechanism by which the unmanaged switch and the cable routing could each cause the symptom, and state the switch configuration that prevents the first.
Read the worked answer
The two causes produce different signatures, which is why the evidence must be separated.
Unmanaged switch and STP. An unmanaged switch does not participate correctly in the managed spanning-tree domain, but it can forward BPDUs or create a loop. When a BPDU reaches an access port that has PortFast enabled, BPDU guard err-disables the port. Repeated topology-change notifications cause the switches to flush learned MAC addresses and flood unknown unicast traffic. A 1 Gbps uplink carrying flooded frames for a few seconds explains a throughput collapse from 90 MB/s to 8 MB/s every 30-40 seconds, while normal ping latency remains low between events. The %SPANTREE-2-BLOCK_BPDUGUARD log is the direct clue.
Cable near the 380 V riser. Electrical noise induces bit errors. Ethernet frames fail the FCS check and are dropped, TCP retransmits, and effective throughput falls. A damaged or incorrectly terminated cable can also cause autonegotiation to fail, producing a duplex mismatch and late collisions. This usually gives continuous or load-dependent errors, not a clean 30-40 second period. If CRC counters rise steadily and stop when the cable is replaced, the cable is the cause.
Prevention. On all access ports configure switchport mode access, spanning-tree portfast, spanning-tree bpduguard enable, storm-control broadcast level 5 and a port-security maximum. Disable unused ports and put them in an unused VLAN. Enable err-disable recovery with logging so a port does not stay down silently. For the cable, use certified Cat6, route it away from power feeders, and terminate it properly. Neither fix substitutes for the other; both are needed here.
3. Write the remediation and verification plan, including cabling and documentation changes, and explain how you would prove the fix.
Read the worked answer
Immediate remediation. Remove the unmanaged switch and connect only approved devices. Replace the patch lead, re-route it away from the 380 V riser and secure it in a tray or conduit. If the desk genuinely needs two ports, install a second wall outlet or a managed access switch under change control. Clean the cable ends and test with a cable certifier; record the result.
Switch hardening. Apply access-port templates: switchport mode access, spanning-tree portfast, spanning-tree bpduguard enable, storm control and port security. Enable err-disable recovery and send logs to the central syslog server. Check the uplink for errors and confirm that speed and duplex are consistent at both ends; if autonegotiation is unreliable, hard-code the same settings on both sides.
Verification. Run a 24-hour ping and mtr from two third-floor hosts, an iperf3 test between floors, and a large SMB copy. Expect throughput near the 90 MB/s baseline with no spikes. Confirm that show interfaces counters errors does not increment, that the spanning-tree topology-change count stays flat, and that no new BPDU guard messages appear. Repeat after one week.
Documentation and control. Update the port map, cable schedule, rack diagram and CMDB entry for SW3-A. Record the change, the before/after test results and the rollback. Label the outlet and the new cable. Brief users that personal switches are prohibited and give them a service-desk route to request extra ports. Add a quarterly check of access-port templates and error counters so the same configuration drift is caught before users report slowness.