The best part about using iptables to track bandwidth is that the tracking is enabled by default. To see this feature in action, add the “-v” into the command:

[root@server ~]$ iptables -vnL
Chain INPUT (policy ACCEPT 2495 packets, 104K bytes)

The output includes counters for both the policies and the rules. To track the rules, you can create a new chain for tracking bandwidth:

[root@server ~]$ iptables -N tracking
[root@server ~]$ iptables -vnL
...
Chain tracking (0 references)
 pkts bytes target 	prot opt in 	out 	source           	destination

Then you need to set up new rules to match the traffic that you wish to track. In this scenario, let’s look at inbound http traffic on port 80:

[root@server ~]$ iptables -I INPUT -p tcp --dport 80 -j tracking
[root@server ~]$ iptables -vnL
Chain INPUT (policy ACCEPT 35111 packets, 1490K bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
    0 	  0 tracking    tcp  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	tcp dpt:80

Now let’s generate some traffic and check it again:

[root@server ~]$ iptables -vnL
Chain INPUT (policy ACCEPT 35216 packets, 1500K bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
  101  9013 tracking    tcp  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	tcp dpt:80

You can see the packet and byte transfer amounts to track the INPUT — traffic to a destination port on your server. If you want track the amount of data that the server is generating, you’d look for OUTPUT from the source port on your server:

[root@server ~]$ iptables -I OUTPUT -p tcp --sport 80 -j tracking
[root@server ~]$ iptables -vnL
...
Chain OUTPUT (policy ACCEPT 26149 packets, 174M bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
  488 3367K tracking    tcp  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	tcp spt:80

Now that we know how the tracking chain works, we can add in a few different layers to get even more information. That way you can keep your INPUT and OUTPUT chains looking clean.

[root@server ~]$ iptables –N tracking
[root@server ~]$ iptables –N tracking2
[root@server ~]$ iptables –I INPUT –j tracking
[root@server ~]$ iptables –I OUTPUT –j tracking
[root@server ~]$ iptables –A tracking –p tcp --dport 80 –j tracking2
[root@server ~]$ iptables –A tracking –p tcp --sport 80 –j tracking2
[root@server ~]$ iptables -vnL
 
Chain INPUT (policy ACCEPT 96265 packets, 4131K bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
 4002  184K tracking    all  --  *  	*   	0.0.0.0/0        	0.0.0.0/0
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
 
Chain OUTPUT (policy ACCEPT 33751 packets, 231M bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
 1399 9068K tracking    all  --  *  	*   	0.0.0.0/0        	0.0.0.0/0
 
Chain tracking (2 references)
 pkts bytes target 	prot opt in 	out 	source           	destination
 1208 59626 tracking2   tcp  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	tcp dpt:80
  224 1643K tracking2   tcp  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	tcp spt:80
 
Chain tracking2 (2 references)
 pkts bytes target 	prot opt in 	out 	source           	destination

Keep in mind that every time a packet passes through one of your rules, it will eat CPU cycles. Diverting all your traffic through 100 rules that track bandwidth may not be the best idea, so it’s important to have an efficient ruleset. If your server has eight processor cores and tons of overhead available, that concern might be inconsequential, but if you’re running lean, you could conceivably run into issues.

The easiest way to think about making efficient rulesets is to think about eating the largest slice of pie first. Understand iptables rule processing and put the rules that get more traffic higher in your list. Conversely, save the tiniest pieces of your pie for last. If you run all of your traffic by a rule that only applies to a tiny segment before you screen out larger segments, you’re wasting processing power.

Another thing to keep in mind is that you do not need to specify a target (in our examples above, we established tracking and tracking2 as our targets). If you’re used to each rule having a specific purpose of either blocking, allowing, or diverting traffic, this simple tidbit might seem revolutionary. For example, we could use this rule:

[root@server ~]$ iptables -A INPUT

If that seems a little bare to you, don’t worry … It is! The output will show that it is a rule that tracks all traffic in the chain at that point. We’re appending the data to the end of the chain in this example (“-A“) but we could also insert it (“-I“) at the top of the chain instead. This command could be helpful if you are using a number of different chains and you want to see the exact volume of packets that are filtered at any given point. Additionally, this strategy could show how much traffic a potential rule would filter before you run it on your production system. Because having several of these kinds of commands can get a little messy, it’s also helpful to add comments to help sort things out:

[root@server ~]$ iptables -A INPUT -m comment --comment "track all data"
 
[root@server ~]$ iptables -vnL
Chain INPUT (policy ACCEPT 11M packets, 5280M bytes)
 pkts bytes target 	prot opt in 	out 	source           	destination
   98  9352        	all  --  *  	*   	0.0.0.0/0        	0.0.0.0/0       	/* track all data */

Nothing terribly complicated about using iptables to count bandwidth, right? If you have iptables rulesets and you want to get a glimpse at how your traffic is being affected, this little trick could be useful. You can rely on the information iptables gives you about your bandwidth usage, and you won’t be the only one … cPanel actually uses iptables to track bandwidth.

-Mark

In an effort to help some of the bigger names in the hosting industry get in on the ground floor of PHIL’s DC, I took a stroll down the HostingCon aisles. Vendors like Parallels and cPanel were obvious choices to discuss business partnerships, and I was sure TheWHIR wanted the scoop on the next big thing in hosting, so I made sure to give them all a chance to speak with me. The documentary film team I hired (the guy I met outside the San Diego Convention Center who said he’d follow me with a camera for $3.50/hour) recorded our interactions for posterity’s sake:

I’d like send shouts out to thank Candice Rodriguez from TheWHIR, Aaron Phillips from cPanel and John McCarrick from Parallels for agreeing to let us film our organic interactions. They’ve further inspired me to build a data center that will make these apparent “snubs” and “rejections” a thing of the past. To Summer and Natalie at the SoftLayer booth: Please stop making fun of my Server Challenge attempt every time you see me at the office … I think I had something in my eye when I was competing, so it wasn’t a fair measure of my skillz.

Oh, and if you didn’t get a chance to attend our “Geeks Gone Wild” party at HostingCon, you’d probably be interested in seeing video from The Dan Band’s performance of “Total Eclipse of the Heart,” cPanel posted it here: http://www.vimeo.com/28160105 (NSFW language, The Dan Band take artistic license with profanity)

-PHIL

Next week a crowd of SoftLayer peeps are making the H-Town connection at cPanel Conference 2009. Representatives from the support, operations, sales, development, and management teams will be out in full force meeting, greeting, and learning. The conference is from Monday Oct 5 to Wednesday Oct 7 at the Hilton Americas Houston Hotel. Stop by our booth if you’d like to chat. We’re throwing a reception for our awesome customers and partners at the lobby bar on Monday at 9pm. If that’s not enough, yours truly will be giving a talk on Tuesday about how to extend cPanel and WHM through a 3rd party API. Y’all get three guesses as to whose API we’re showing off. Bring your ripest fruits and vegetables and ready your air horns. It’s been a while since I’ve had a good, old-fashioned heckling.

Come on out if you can make it. We love getting to know the folks who pay our salaries. See you there!