Having recently moved to a lower-bandwidth area (from 12Mb/s to 7Mb/s… sucks ), I really needed to find a way of controlling and optimizing the Internet usage from my home connection. That’s basically what traffic shaping, or bandwidth management (BWM) comes into play. I still have a low-end sonicwall TZ200 from my support days, and I decided to tackle the issue using this unit.
Aside : it is possible to implement the same thing using a hardcore iptables/shorewall + TC linux box, maybe i’ll have time to implement and write about this 🙂
First, some background into what I want to accomplish. This is actually a really important step. Most of the time, rushing into bandwidth management without having clear objectives leads to a lot of troubleshooting and ambiguity later on, so I really don’t advise you skip this over.
I have a grand total of about 4 machines in my network. Running ntop, I monitored the network for a while and as expected, the vast majority of the traffic was HTTP and HTTPS traffic. The rest of the traffic was some P2P traffic, and a small but important percentage of DNS traffic.
Now that I have a pretty good idea of what traffic is passing, the next step is deciding which traffic should be given priority. SonicWALL units have 8 priority classes, ranging from 0 (highest) to 7 (lowest). Also, the sonicwall allows you to limit (set a maximum) traffic for any one protocol, and also guarantee (set a minimum) for any protocol. My traffic to priority mapping would be something like:
- DNS : priority 0, a very small percentage of guaranteed bandwidth. “Management” traffic like DNS
- Web Browsing Traffic (HTTP/S) : priority 1, and about 75% guaranteed bandwidth. This traffic will account for the main volume of traffic, so this is where the core of our BWM policy resides. I allocate a maximum bandwidth of 100%, and a guaranteed bandwidth of 75%. In other words, at any point in time, HTTP/S traffic should have 75% of the bandwidth available. If HTTP/S is not using this bandwidth, it should be available to other traffic
- Other protocols : priority 5, no guaranteed bandwidth. The rest of the traffic on my network (like P2P) is not important, so it’s given a lower priority. It’s given a guaranteed BW of 0%, but it still is given a maximum BW of 100%, so that is no higher priority traffic is present, it can still use my whole BW.
is often left out of BWM, which is a mistake because if DNS is slow, all the network will be slow. Basically, remember that in most networks, until DNS completes, nothing can flow. So it’s useless having guaranteed bandwidth for HTTP/S if DNS is slow… so keep DNS in mind
Now that the theory part is over, we implement the above policy on the sonicwall itself.
1. Our first step would be telling the firewall exactly how much traffic we have available to us. It should be easy to figure out the available bandwidth, by visiting any of the multitude of speed test sites. Most of these site work over port 80, so it should be easy to test with. My initial results:
We input these values to the sonicwall. This is done from Network > Interfaces > WAN interface properties > Advanced
Note I entered higher values than I actually have for ingress (download) and egress (upload). To be on the safe side usually enterprises put this as less…
2. Next, we identify where our traffic originates from. In my case, most of my clients reside on the wireless LAN (WLAN), and the traffic almost exclusively goes to the internet (WAN). So we open the firewall rules from WLAN > WAN
I define three rules, one for each of the bullet points I mentioned above:
3. For each of those rules, under the Advanced tab, we implement the BWM policy I outlined. So for DNS:
And similarly for the other rules.
As a test to see if the rules really worked, I set the web browsing rule to have a maximum download (inbound) speed of 500Kb/s:
Then I run the same speedtest to the same site using the same server…
And viola! The speed really is limited. During live testing, I ran a bit torrent download of a linux ISO with no other traffic, and got about 500Kb/s. I then started the speed test above (which dont forget, uses port 80 so is considered higher priority than bit-torrent), and we see the speed test reach 6 Mb/s and the torrent drops down to 50Kb/s, showing a successful implementation
David Vassallo's Blog 