Certified - CompTIA Network +

Some of the most disruptive network outages don’t begin with an ISP failure or a device crash—they start with mismanaged traffic flow. Layer 2 and Layer 3 loops can bring a network to its knees, flooding it with unnecessary packets, overwhelming CPU and bandwidth, and rendering devices unresponsive. These problems usually arise from simple misconfigurations, bad cabling decisions, or a lack of fail-safes like Spanning Tree Protocol. Once a loop begins, it doesn't stop unless manually interrupted, making rapid detection and mitigation essential.
In this episode, we break down the mechanics behind three critical concepts: collision domains, broadcast storms, and routing loops. These issues often appear in real-world troubleshooting, as well as on the Network Plus exam. Understanding how traffic behaves—how it’s forwarded, broadcasted, or misrouted—helps you prevent loops from forming and resolve them quickly when they do. Let’s begin by looking at collision domains, the most fundamental building blocks of traffic segmentation.
A collision domain is a network segment where data packets can interfere with each other if two devices attempt to transmit at the same time. This was a common problem in hub-based networks where all devices shared the same medium. Today, each port on a switch represents a separate collision domain, eliminating most collision-related problems. Collisions are primarily a concern in half-duplex environments, where devices must take turns transmitting and receiving. In full-duplex, where devices can send and receive simultaneously, collisions don't occur.
When collisions do occur—typically in legacy environments or when auto-negotiation fails—data must be retransmitted. This results in performance degradation and application timeouts. You may see increased late collisions and CRC errors in interface statistics. These symptoms are detectable using show interfaces or similar commands, and they signal that duplex mismatches or outdated equipment may be at fault. Resolving these issues typically involves setting both ends of the link to full-duplex and replacing any hub-style devices with switches.
While collision domains are limited by switch ports, broadcast domains operate at a broader level. A broadcast domain is the segment of a network where broadcast traffic—like ARP requests or DHCP discoveries—can be received. Switches forward broadcasts to all ports within a VLAN, but routers act as boundaries and do not forward broadcast packets between subnets. This segmentation helps prevent excessive broadcast traffic from propagating network-wide and ensures scalability.
When broadcast traffic spirals out of control, it results in what’s known as a broadcast storm. A broadcast storm occurs when excessive broadcast packets flood the network, consuming all available bandwidth and CPU resources. Switches struggle to process the incoming frames, and end-user devices experience random disconnections, high latency, or total network failure. Broadcast storms can be caused by Layer 2 loops, certain types of malware, or misbehaving devices that constantly flood the network with discovery packets.
Symptoms of a broadcast storm are often abrupt and wide-reaching. You may observe a sudden spike in switch CPU usage, massive traffic volume on a packet analyzer, and intermittent connectivity across the entire subnet or VLAN. Workstations may report network errors, and IP phones may reboot due to loss of contact with the controller. Since storms propagate at Layer 2, their effects are seen across devices regardless of their IP addresses or routing configurations.
The root causes of broadcast storms are typically one of three things: physical loops where switch ports are incorrectly connected to each other; STP misconfigurations or disabled protocols; or devices—such as cameras or unmanaged switches—that flood the network. Firmware bugs can also lead to devices generating continuous broadcast traffic. Diagnosing the storm requires identifying where the excessive traffic originates and breaking the loop or isolating the faulty device as quickly as possible.
Spanning Tree Protocol, or STP, is designed to prevent Layer 2 loops from forming in the first place. It works by identifying redundant paths in the network and blocking some of them to ensure there is only one active path between any two devices. STP elects a root bridge—a switch that acts as the center of the spanning tree—and calculates the shortest path to that bridge for all other switches. Ports that are not on a shortest path are placed into a blocking state, preventing loop formation.
STP misconfigurations can still lead to disaster. If STP is disabled, intentionally or accidentally, the network becomes vulnerable to loops. If a port is manually forced into forwarding mode, it may override STP logic and allow a loop to form. Another issue arises when the wrong switch is elected as the root bridge—perhaps one at the edge of the network or with insufficient capacity. Always ensure that STP is enabled, root bridge priorities are configured intentionally, and ports behave as expected. Commands like show spanning-tree help identify the current topology and whether any ports are in a blocked or forwarding state.
Finally, we move up to Layer 3 to address routing loops. A routing loop occurs when packets are forwarded between two or more routers in a cycle with no exit. This typically happens when incorrect static routes are entered or when dynamic routing protocols miscommunicate path information. Without proper safeguards, packets can circulate endlessly until their Time to Live (TTL) value expires, resulting in unnecessary bandwidth usage and delayed or lost traffic.
Routing loops can be difficult to diagnose because they mimic other issues like latency, intermittent drops, or poor application performance. Traceroute becomes a valuable tool here, often showing the same set of IPs repeating over and over. High CPU usage on routers, rapidly changing routing tables, and interface queues backing up are all indicators of a possible routing loop. When identified, loops must be stopped immediately by disabling affected interfaces, correcting route advertisements, or removing conflicting static routes.
For more cyber-related content and books, please check out cyber author dot me. Also, there are other podcasts on Cybersecurity and more at Bare Metal Cyber dot com.
Routing loops are often more subtle than their Layer 2 counterparts but can be just as disruptive. The symptoms include packet delay, sporadic drops, and excessive retransmissions. In environments running dynamic routing protocols, you might see routing updates flapping—where the same route appears and disappears repeatedly—or you may notice high CPU usage on routing devices. Traceroute output often reveals the telltale sign of a routing loop: a repeating sequence of router IPs as packets circulate endlessly. In some cases, packets will never reach their destination and instead expire due to their Time to Live (TTL) counter reaching zero.
To prevent routing loops, routing protocols implement various loop avoidance and detection mechanisms. RIP, for example, uses a maximum hop count of 15 to prevent routes from looping indefinitely. It also employs split horizon, which prevents a router from advertising a route back out the same interface it learned it on. OSPF and EIGRP, being more advanced, use topology databases and metric-based decisions to avoid loops. They also implement hold timers and loopback detection techniques that allow routers to suppress or dampen unstable routes. TTL values, route poisoning, and triggered updates further help keep loops contained and resolved quickly.
Detecting routing loops involves analyzing both live and historical data. Start with traceroute and identify any repeating hops. Then check router logs and protocol debugging output to look for frequent updates, neighbor resets, or error messages. Compare the routing tables of adjacent routers using commands like show ip route to look for inconsistencies. Logs may show changes in advertised prefixes, route withdrawals, or protocol timeouts. If the same network is learned from multiple sources inconsistently, this could indicate a misconfigured redistribution policy or missing route filters between protocols.
Isolation is a crucial technique when diagnosing loop conditions. In Layer 2 loops, you can disable interfaces one by one to see when the broadcast storm stops. The goal is to break the loop without completely disrupting traffic. STP topology commands such as show spanning-tree vlan X let you view the active topology and which ports are currently blocking or forwarding. On Layer 3 devices, isolate routing loops by removing problematic static routes or shutting down specific dynamic protocol sessions. Re-enable services incrementally to confirm where the fault originates and prevent a loop from forming again.
Modern network devices offer several loop protection features that help mitigate problems before they cause network-wide failure. In Layer 2, features like BPDU Guard automatically disable a port if an unexpected bridge protocol data unit is received—often from an unauthorized switch. Loop Guard protects against unexpected topology changes by preventing ports from transitioning into forwarding state if STP updates are lost. On Layer 3, route dampening or suppression can reduce the impact of flapping routes. These tools are especially useful at network edges, where instability is most likely to enter from less-controlled devices or external links.
The Network Plus exam often includes questions based on symptoms associated with loops, collisions, and broadcast storms. You may be presented with a scenario describing high switch CPU usage, widespread intermittent disconnections, or repeating IPs in a traceroute output. Your task will be to identify the most likely cause—such as a Layer 2 loop due to a missing STP configuration or a routing loop caused by duplicate static routes. Other questions may test your understanding of domain segmentation by asking how many collision or broadcast domains exist in a given topology. Recognizing how traffic flows at Layer 2 versus Layer 3 is critical to answering these questions correctly.
Many of these problems arise from simple design mistakes. One of the most common is connecting two switch ports to each other without proper spanning tree configuration. This creates a loop the moment both ports go active. Another mistake is disabling STP altogether or failing to manually set root bridge priorities—leading to unpredictable network behavior. On the routing side, accidentally redistributing a route between two protocols without appropriate filtering can create recursive loops that are difficult to catch until performance degrades. Good documentation, regular audits, and strong configuration standards are the best defenses against these oversights.
To summarize the fixes and preventive measures for loop and collision-related problems: always segment networks properly using switches to eliminate collision domains. Use STP on all Layer 2 devices and configure loop protection features like BPDU Guard and Loop Guard where appropriate. On routers, use TTL, route filters, and loop avoidance features built into the protocol. Use traceroute and logs to detect routing loops, and isolate faulty interfaces or route announcements incrementally. Ultimately, understanding how data moves across the network—and what happens when it moves the wrong way—is key to resolving and preventing these disruptive conditions.
Troubleshooting traffic-related failures is not just about speed or connectivity—it’s about maintaining control of how traffic flows. When loops form, whether through misconfigured cables or improper routing updates, that control is lost. The result is chaos: dropped packets, overwhelmed CPUs, unusable networks. But with a clear understanding of collision domains, broadcast boundaries, and route behavior, technicians can restore order quickly. Loops don’t just happen—they’re allowed to happen. Your job is to stop them before they do damage.