HOWTO: Prioritize Vonage (and other) traffic in Fedora (and other) Linux

I use Vonage telephone service and Fedora Linux. My Fedora box is the router for my network.

Vonage recommends letting its box sit between the Internet and my computer, so that its traffic always gets priority. However, there’s no way I’m going to give Vonage control of Internet connection, so I have it plugged into my network, routing traffic through my Fedora box.

Unfortunately, this means that when something is generating a lot of outbound traffic, there isn’t enough outbound bandwidth for Vonage, so call quality is extremely poor.

With Linux Advanced Routing & Traffic Control (LARTC), it is possible to configure Linux to prioritize Vonage (or any other preferred application) higher than other outbound traffic. There’s lots of information on the Web about how to configure LARTC, but I found that most of it is either too dense and detailed or not detailed enough, and I couldn’t find any plug-and-play LARTC configuration tool for Fedora (it’s somewhat puzzling why such a thing hasn’t yet been written, given how long LARTC has been around for). With a little work, however, I managed to figure out how to do it. For the benefit of the others, I’m spelling it out step-by-step here with a level of detail I was unable to find elsewhere.

Shaping Vonage traffic

1. Download Wonder Shaper and read the README file in it.
2. Now download my tweaked version of the “wshaper.htb” script that’s included in the Wonder Shaper distribution. The most important change in my tweaked version is to add a “real-time” traffic class and put Vonage in that class, so Vonage is prioritized even higher than interactive traffic like SSH.
3. Copy my version of the script that you downloaded into “/etc/init.d/wshaper”, making sure that it is executable.
4. Edit the “DOWNLINK”, “UPLINK”, and “DEV” settings at the top of the script. Note that the first two sittings are in kilobits per second, not kilobytes, and that the values you put here should probably be about 90% of the nominal speeds of your Internet connection. You can use a higher percentage if you find that you aren’t using all of your bandwidth when doing network-intensive operations — you might have to do some trial and error to get it right. Don’t forget to update these if you switch to a faster or slower Internet connection!
5. Run “/sbin/chkconfig wshaper on“.
6. Run “/sbin/service wshaper start“.

That’s it!

A note about how Vonage traffic is matched

This is the code in my version of wshaper that matches Vonage traffic:

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
        match ip tos 0xb8 0xff flowid 1:10

The secret to what makes this work is the “match ip tos 0xb8” which I’ve shown in bold. “TOS” stands for “Terms Of Service”, which basically means, “The section in the packet header which indicates what level of service the packet should be given.” I figured out the correct TOS value to match against by doing the following:

1. Use wireshark to capture packets on the interface of your Internet connection or the interface of the local network your Vonage box is plugged into.
2. Make a Vonage phone call while wireshark is capturing.
3. Find a packet in the capture with protocol “RTP” and source IP corresponding to your IP address (if you’re capturing your Internet traffic) or the IP address of your Vonage box (if you’re capturing your local network).
4. Expand the “Internet Protocol” subtree of the packet analysis and note the value following “Differentiated Services Field:”. That is the TOS value you should match against in your LARTC configuration.

Other traffic shaping

Here are some examples of other traffic shaping you can do with Wonder Shaper. If you’d like help figuring out how to make other kinds of traffic not mentioned here either high-priority or low-priority, feel free to post a comment and I’ll try to help.

Amazon S3 and other recurring large uploads

I back up my system on a daily basis to a ReiserFS filesystem stored on Amazon S3, using the wonderful package s3backer. For ten cents per gigabyte per month plus minimal upload costs, I get highly available, redundant storage of my critical data. It took a little tweaking to make this configuration stable enough for my tastes (when I get a chance I’ll post the details about that separately), but now that I’ve got it set up, I’m pretty happy with it.

The one thing I’m not happy about is that while the backup is running, it consumes a huge amount of bandwidth, and interactive performance for everything else suffers. I don’t want a Web page to take ten seconds to load just because I’m running a backup! Wonder Shaper can help with this problem:

1. Note that files are uploaded to Amazon S3 at the host s3.amazonaws.com.
2. Run “host s3.amazonaws.com” to get its IP address.
3. Run “whois ip-address” to look up the whois information for the IP address.
4. Find the “CIDR” line in the whois output, e.g., “72.21.192.0/19”.
5. Add the CIDR value to the “NOPRIOHOSTDST” line at the top of the “wshaper” script (if you have multiple destinations on this line, put them all in quotes separated by spaces, and make sure there’s no space before or after the “=” sign).
6. Run “/etc/init.d/wshaper” to reload the new configuration.

One caveat I’ll note is that the network block for Amazon S3 may change from time to time, so if you start to notice network performance suffering while a backup is running, repeat the steps above to find out if there’s a new network block you need to add to the prior ones in NOPRIOHOSTDST.

You can use this for any service to which you do large data uploads on a recurring basis.