bandwidth throttling with dummyNET

Bandwidth usage became a very sensitive issue as I ventured into running a site that used a lot of bandwidth. Being colocated and basically hooked up to the ISP’s backbone meant that I could potentially get hit with enough traffic to make me go broke in one month alone. This was very scary, so in an effort to enable us to traffic, throttle, or manage bandwidth usage, I found that Dummynet was the best solution. Dummynet was originally setup to allow admins to simulate slower connections by allowing them to set bandwidth limitations on particular services, ports, IPs, network cards, etc. I use it for throttling outgoing bandwidth on a specific IP address. Perfect for my application of hosting a high-traffic webserver with a lot of outbound traffic and very little inbound traffic.

These are the settings that I needed to add to custom kernal to enable dummynet:
options DUMMYNET # (enables dummynet for bandwidth throttling)
options HZ=1000 # (dummynet option highly recommended by man but I’m not really sure what its purpose is)

Dummynet then gets activated by setting up entries in ipfw. Basically, you create a pipe for data to go through, and then a bandwidth rule for that pipe. I added this /etc/rc.firewall so that these were implemented at startup. Like ipfw, you can add/modify/delete these optiosn on-the-fly:
# DummyNET config: limits outgoing bandwidth, doesn’t
# limit incoming bandwidth.
# 2/16/2004
#
# Throttle traffic from: 192.168.1.10 (main site & e-mail)
${fwcmd} add pipe 1 ip from 192.168.1.10 to any
${fwcmd} pipe 1 config bw 1250Kbit/s

# Throttle traffic from: 192.168.1.11 (users & hosted sites)
${fwcmd} add pipe 2 ip from 192.168.1.11 to any
${fwcmd} pipe 2 config bw 512Kbit/s

Basically, what the above does is setup all outgoing bandwidth from IP address 192.168.1.10 to use up to 1,250 kbps or 1.25 Mbps of bandwidth. Incoming bandwidth is not throttled. I setup a much lower bandwidth ceiling for pipe #2 as you can see. These sites are less important that they receive bandwidth and are of much lower usage anyway, so nobody will really even know that they are being throttled. The key was to throttle bandwidth down a lot for secondary sites while keeping the ceiling significantly higher for the main site, but still keep it within reason and not allow it to go way beyond what we could afford.

Post to Twitter

Tags:

Related posts

Eric Long: I’m an experienced online marketer, information architect, web strategist, and social media enthusiast. I’m an analytical, process-oriented thinker, focused on leveraging technology to solve business problems in B2C/B2B environments and am passionate about providing outstanding online experiences.

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

Discussion

No comments yet, be the first.

Leave a Comment

You must be logged in to post a comment.