Troubleshooting Broadcast Storms and Switching Loops – CompTIA Network+ N10-006 – 4.6

| May 11, 2015


Broadcast storms can cause network slowdowns, and switching loops can cause a complete network meltdown. In this video, you’ll learn how to troubleshoot both of these problems on your network.
<< Previous: Troubleshooting DNS and DHCPNext: Troubleshooting Interface Configurations >>


A broadcast is a frame that is sent from one device that is directed towards every other device in that broadcast domain. There are many processes and protocols that use broadcast to communicate out particular pieces of information, especially if that information needs to be seen by more than one device. You can think of this broadcast domain as a single VLAN. Broadcasts only communicate within that VLAN, and they are not able to pass through routers. So you won’t see broadcasts going outside the scope of where your router happens to be. They will always stay in your local VLAN.

If you have only one or two broadcasts every second, you might not even notice it. All of these broadcasts are going to every single device on the network, and because it is a broadcast, every device has to pull that frame in, look at the contents of what’s inside of that frame, and determine if there’s anything that it needs to do based on that content. Well, if there’s only one or two a second, that’s fine. But what happens when there are 50 or 60 frames every second all being sent as broadcasts to everybody on the subnet? And the more devices on your subnet, the broader the problem is going to be because you have many devices slowing down because of all of these broadcasts going out over the network.

One of the best ways to troubleshoot a broadcast storm is to find out where the broadcasts are coming from. It’s most likely that they are all originating from multiple devices, but the only way you’d know is if you captured the packets themselves. So pull out your favorite protocol analyzer and capture some data from your network to see how many broadcasts are going across the network, and where are they coming from? Once you’ve identified the broadcasts and what devices are sending this, you can then determine if that broadcast is really necessary. Maybe it’s a service that you can disable on a particular device or maybe you can modify the application so it sends unicast instead of broadcasts.

If you find that you do have many different devices, they’re all sending broadcasts, and there’s no alternative, they must send these broadcasts out to operate, then maybe it’s time to split the network into smaller pieces. You can create multiple broadcast domains, decrease the number of devices in each one of these domains, and that will, of course, limit the number broadcasts per second. This will certainly minimize the number of broadcasts sent out in that broadcast domain, and therefore, minimize the impact of having all of those broadcasts on a single network.

A good way to bring down a network is to create a loop. Ideally, your network is going to be running Spanning Tree, and that’s going to prevent your network from looping onto itself. But on many networks, unfortunately, the network administrators, for whatever reason, have decided not to use any type of Spanning Tree Protocol, and they will be susceptible to a switch loop. Switches, of course, determine where traffic goes based on the destination MAC address that’s within a frame.

Every device has a unique MAC address, and so every packet is directed to a single address, a multiple of addresses, or broadcast to all devices on the network. That’s one challenge we have especially with switch loops, that all of these broadcasts and multicasts can begin spinning around the loop in very rapid succession, very quickly bringing down the network. Of course, there’s nothing at the MAC address level to identify how many times it may have gone through a switch or some other device.

There’s no timer like you have with IP that has a time to live. So in this case, if you have a broadcast sent out over network with a loop, it will continue to loop around that network. And the next broadcast will join it, and the next broadcast joins that one, and very soon you will have a network that’s not able to communicate at all because it’s spending all of its time sending all of this data through these loops on the network.

A network that doesn’t have a loop might have a device on each side, and there might be a couple of switches in the middle. And you’ll notice there’s no loop, it’s a straight connection between both sides of the network. When you send traffic, it goes to the switch, the switch determines that the traffic needs to go to the other switch, and then finally, down to the device on the other side.

If you have accidentally connected two switches to each other, then you’ve created a loop, and you’re going to have a very different traffic pattern. Your device will send a frame into the switch, it then sends the frame off to the other switch, which then sends it back through the loop, sends it back to the other switch, which sends it back to the other switch, which sends it back to the other switch. And you can see that this will continue to loop and loop and loop around the network until you break this loop connection.

Tags: , , , , , ,

Category: CompTIA Network+ N10-006

Comments are closed.

X