We create open-source because we love it, and we share our finding so everyone else can benefit as well.



Ever since I took in a roommate, and then started using a VoIP service, I have learned that even having a decent home broadband solution wasn’t enough for my network. Many nights I would spend trying to talk to someone and realize they couldn’t hear me, or I couldn’t hear them. Other nights I would notice a strong bottleneck at the gateway of my network. After monitoring the obvious, the limitation of bandwidth just wasn’t allowing me to continue to be lazy. It was time for limitation.

I’ve always put off any further tweaking of my OpenBSD firewall/gateway, knowing that relocation was soon to happen, and that the 266MHz beast found in the trash was going to soon be replaced with a Soekris again. Since doing anything while various other packets flew through my gateway was sluggish, it decided to finish the ALTQ setup that I left commented out in my pf.conf.

To start, I seperated everything into various networks. My roommate was given a 4 port switch NIC dedicated to his systems, a single NIC for my switch, and a single NIC for my VoIP converter. So now that I had everything segregated, it was time to split my pipe among these interfaces.

#outbound traffic
altq on $int2 cbq bandwidth 1.25Mb queue {wins_out}
queue wins_out bandwidth 680Kb cbq(default)

altq on $int3 cbq bandwidth 1.25Mb queue {dom2_out}
queue dom2_out bandwidth 1.25Mb cbq(default)

altq on $int4 cbq bandwidth 1.0Mb queue {voip_out}
queue voip_out bandwidth 1.0Mb cbq(default)

#inbound traffic
altq on $ext bandwidth 512Kb cbq queue {voip, dom1. dom2}
queue voip bandwidth 256Kb cbq(default)
queue dom1 bandwidth 128Kb priority 4
quene dom2 bandwidth 128Kb priority 5

Even though this setup seems a bit foolish at first sight, there is always a method to my madness. For my downloading, I had 3Mbps to split, and try to distribute across the 3 interfaces. I went ahead and split 3.5Mbit instead, knowning that the two networks could use the added bandwidth when available, and the VoIP most likely won’t even use 1Mbit. So why did I still use the CBQ? Well, ever though this is a setup for the current task at hand, there is most likely going to be a time when I want to dedicate some bandwidth from one network to one system as a default.

Looking further, the outbound I set low, or so it seems. The doms queue will be used over 2 interfaces, and the VoIP getting half of the bandwidth. I wanted to cap this regardless, since one of the networks likes to run torrents a lot, and really bogs the entire network down.

#queuing download traffic
pass out on $int2 from $net2 to any flags S/SA keep state queue wins_out
pass out on $int3 from $net3 to any flags S/SA keep state queue dom2_out
pass out on $int4 from $voip to any flags S/SA keep state queue voip_out

#queuing upload traffic
pass out on $int4 from $voip to any keep state queue voip
pass out on $int3 from $net3 to any keep state queue dom2
pass out on $int2 from $net2 to any keep state queue dom1

As we see here, the queues have been added for each interface, capping the total bandwidth each can use. The main thing is that the upload bandwidth is now capped, and can no longer be bogged down with torrents except for the network that it is on. The same goes for anything else on any other network. Even though the VoIP company claims to only need 128kb up and down, we have to think of those silly “minimum requirements” stickers that are on Windows based products. Ever since, my phone has not lost connection to the auth server, nor has anything bottlenecked. Frankly, even with the loss of bandwidth, it really hasn’t effected anything I did normally.

No Comments

Add your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.