OpenBSD ALTQ

OpenBSD ALTQ

When I took in a roommate, and then started using a VoIP service, I learned that even with a decent home broadband solution, it wasn’t enough for my network. Many nights I would spend time trying to talk to someone via VoIP and realize the connection was interrupted. 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. This is when I introduced OpenBSD ALTQ to my firewall.

OpenBSD ALTQ Setup

I’ve always put off any further tweaking of my OpenBSD firewall/gateway, knowing that relocation was soon to happen. 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 OpenBSD ALTQ setup that I left commented out in my pf.conf.

To start, I separated everything into various networks. My roommate was given a 4 port switch NIC dedicated to his systems. Then 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
queue dom2 bandwidth 128Kb priority 5

Splitting the Pipe

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, knowing that the two networks could use the added bandwidth when available. The VoIP most likely won’t even use 1Mbit. So why did I still use the CBQ? Even 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 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. This 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

The queues have been added for each interface, capping the total bandwidth each can use. The upload bandwidth is now capped, which is most important, meaning it 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. The VoIP company claims to only need 128kb up and down. Still, 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.