Tracking Down Blips

In a previous article, I explained the process for setting up Cacti, which is a great program for graphing just about anything. One of the main things I graph is my internet usage. And, it's great information to have, until there is internet activity you can't explain. In my case, there was a "blip" every 20 minutes or so that would use about 4mbps of bandwidth (Figure 1). In the grand scheme of things, it wasn't a big deal, because my connection is 60mbps down. Still, it was driving me crazy. I don't like the idea of something on my network doing things on the internet without my knowledge. So, the hunt began.

Figure 1. That blip drove me crazy for weeks.

Most folks immediately told me to use Wireshark to analyze the data. That's good advice, but the problem makes me want a real-time monitoring system rather than a one-off packet search. Plus, even with Wireshark, you need to address the issue of capturing all the data flowing to and from the internet. Modern switching hardware purposefully directs traffic only to the ports on your switch where the traffic is intended. That means you can't just "sniff" the whole network without some effort. So regardless of how I was going to analyze the traffic, I had to be able to see the traffic. Thankfully, there are a few ways to accomplish that.

Sniffing All the Data

Network hubs were very common 20 years ago. The idea with a hub is that the network data coming in is repeated to every port on the hub, and whichever computer the packet was intended for accepts it. Every other computer just ignored the data. This worked fine when the amount of data was low and the speed of the data was slow, but as more devices were added to the network, it quickly became congested. About that time, "switching" technology entered the picture. A switch would accept data on every port, but repeat the packets only to the single port on which the intended device was listening. At first, switches were extremely expensive, so it wasn't uncommon to see a four-port rackmount switch that had hubs connected to each port. It was a way to segregate the congestion into manageable chunks. Eventually, switching technology became mainstream. Now even the $10 eight-port devices you can buy online are switches instead of hubs, and the idea of a hub is outdated.

Although Ethernet networks rarely use hub technology anymore, Wi-Fi doesn't have that same luxury. In fact, the reason Wi-Fi access points can support only a certain number of devices before they become unusable is that Wi-Fi functions conceptually like a hub. All the devices on a Wi-Fi network receive all the packets and "accept" only packets destined for them. That's the reason it is so important to be security-conscious when using a public Wi-Fi network. Anyone else connected can see all your traffic, so make sure any sensitive data is encrypted via SSL, or even better, encrypt all your traffic via VPN.

Why is all that important? Well, if you're trying to monitor an entire network, switches work against you. Back in the day of hubs, every computer saw all the traffic on a network, which made it easy to monitor what was happening. (It also made it easy to sniff other people's packets, but that's another story altogether.) Thankfully, there are a few options for capturing all the data so you can analyze traffic on your network.

The first thing to determine is where you want to monitor. You can monitor only traffic flowing through a certain place, so you need to determine where that place is. In my case, I want to monitor internet traffic, so from a port standpoint, I want to see all the traffic flowing into and out of where my router plugs in to my LAN (Figure 2). There are a few ways to capture that data—let me run through the options.

Figure 2. This is the bottleneck through which all internet traffic flows.


Shawn Powers is a Linux Journal Associate Editor. You might find him on IRC, Twitter, or training IT pros at CBT Nuggets.