Tracking Down Blips

Option 1: Use a Hub

If you look at Figure 3, you can see how this option works. All the internet traffic flows through the hub into the router. Because hubs repeat all data to every port on the hub, you simply plug the monitoring computer in to that same hub, and it "hears" all the network traffic to and from the internet. There are a few problems with this method. One, it's difficult to find hubs anymore, especially those capable of 100mbps. Even if you can find a hub, it will be a cheap desktop type that is likely not reliable enough to handle all your data. Quite honestly, even though option 1 is technically still feasible, it's a really bad idea, and I don't recommend it.

Figure 3. A hub is technically an option, but not a good one.

Option 2: Mirror a Port on Your Switch

This is probably the best way to monitor network traffic in a modern LAN environment. Figure 4 shows what it looks like. The only problem with this method is that it requires a "smart" or "managed" switch. That usually increases the cost drastically, but it gives you other management features like VLANs. Still, if you already have an unmanaged switch, this can be a large expenditure. If you want to use this method in an environment already populated with unmanaged switches, perhaps consider getting a small managed switch and put it in place of the hub shown in Figure 3.

Figure 4. This is probably the best way to monitor traffic, but it requires a managed switch, which I didn't have.

The actual process for mirroring a port works differently on different brands of switches. Regardless of the specific method, however, all managed switches should allow you to mirror the traffic from one port to another. Then your monitoring computer can listen on that mirror port and analyze the traffic. It's sort of like creating an internal two-port hub that sends traffic only one way. Usually if you do this, it's wise to "sniff" with a second Ethernet card on the monitoring computer. That way, you're not confusing traffic to and from the monitoring computer with the internet traffic.

Option 3: Inline Linux Bridge

Figure 5 shows what I actually did on my network. I didn't use this method because it's better than option 2; rather, I used it because I didn't have a managed switch. Basically, in this setup, you need a monitoring server with two Ethernet cards. You create a "bridge" interface, and plug the computer in between the switch and the router. This does capture all the traffic because it literally flows through the computer. Unfortunately, it means if something goes wrong with your monitoring computer, it can take down internet access for your entire network, along with DHCP and DNS if your router hosts those for you. There are special Ethernet cards with multiple ports that "fail open", so that if the machine does, traffic still flows. If you're going to spend money on this, however, I recommend just getting a managed switch and doing a mirrored port.

Figure 5. Although possibly not the best way to do it, this is probably the nerdiest. It's also the way I did it, because it didn't require any new hardware.

Option 4: Use Your Router

This option works only if your router is robust enough to run bandwidth-monitoring tools. Some are, especially if you're using a full-blown server as a router. Most can do it, but not well. Still, if you only want simple monitoring and your router can handle the load, it's an easy way to do it.

My Bridge Install

I went with Option 3, which meant I needed to install a network bridge on my Linux machine. On Ubuntu, the process is really simple. It's not difficult on other distros like CentOS, but if you're using something other than Ubuntu, you'll need to google the specific steps. For Ubuntu, do:

apt-get install bridge-utils

Then edit your /etc/network/interfaces file:

# The loopback network interface
auto lo
iface lo inet loopback

# The bridge interface
auto br0
iface br0 inet dhcp
    bridge_ports eth0 eth1
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0


Shawn is Associate Editor here at Linux Journal, and has been around Linux since the beginning. He has a passion for open source, and he loves to teach. He also drinks too much coffee, which often shows in his writing.