Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Wi-Fi Router Charts

Click for Wi-Fi Router Charts

Mesh System Charts

Click for Wi-Fi Mesh System Charts

My World Of Imperfection

My installation still has the dregs of the magic shaper process in a couple of ways. There is a "hated" outbound priority #5 that I don't use. Since it is assigned only 1% of the available bandwidth, I just left it in place. There's also a low priority download queue that goes unused.

Both of these are aspects of the magic shaper process that are part of a strategy for handling P2P programs. I don't use any P2P file sharing programs, so this goes unused. The queue is directed at the sole download pipe so its presence does not cost me any loss of download speed. The two higher priority queues access the same pipe and can fully saturate it when required.

Local Asterisk & Hosted PBX

My office may be a little unusual in that I have my own Asterisk server (several actually) and I rely upon an externally hosted IP-PBX. I also have a number of SIP hard phones and ATAs around the office and house.

Given the number of VOIP devices and services, I found the easiest way to direct VOIP traffic to the high priority outbound pipe was on the basis of IP address. I let each SIP device gets its IP address from the routers DHCP server. I then use MAC reservations to set all those IP addresses into and higher. The traffic shaper rule for VOIP outbound traffic specifies that this address range connects to the high priority outbound pipe.

This arrangement also makes it very easy for me to add VOIP devices under test and know that they fit into my bandwidth management scheme. As long as they have IP address in the upper range, call quality is assured.

The only circumstance that isn't well handled by the arrangement is when I use a soft phone on my desktop. Since the desktop PC is in the lower IP address range, its traffic is not treated the same as the VOIP devices. Happily, I don't need to do this very often. Plus it's kind of gratifying to think that my VOIP traffic get priority even over Skype, which I use only reluctantly.

Within m0n0wall, dealing with things like IP address ranges uses CIDR notation. This was not something that I was familiar with previously. I posted a inquiry to the m0n0wall user list, which met with a great response from one of the project's lead developers. He posted some provisional documentation here.

m0n0wall CIDR notation example
Click to enlarge image

m0n0wall CIDR notation example

It is also possible to assign priorities based upon ports & protocols. I've done this in the past, but I have no need of this any longer.


There is a lot of VOIP oriented information available online regarding virtual LANs, a.k.a. VLANs. VLANs are a means of separating network traffic over the same wire as if there were physically separate networks.

Each VLAN is treated as a separate segment on the LAN, even thought the traffic is all on one wire. With the traffic virtually separate there is then a means of establishing varying priorities for VOIP traffic by giving preference to traffic on the VOIP specific segment. This requires a router capable of VLAN functionality and some depth of knowledge in its configuration.

Much of the recent attention paid to VLANs in the VOIP space has been highlighting the fact that VLANs should not be considered a security mechanism. This is a little contrary to the common practice.

In my office, I've managed to avoid the complexity of using VLANs. I am of the opinion that such solutions are more appropriate for enterprise installations than SOHO circumstances.

Alternatives to m0n0wall

While I've been using m0n0wall, you might also consider pfsense. m0n0wall is intended for small format hardware like the Soekris boards and its author has been very careful to avoid code bloat resulting from adding a myriad of features. pfsense is based on m0n0wall, but has a larger feature set and targets more capable hardware.

Astlinux is another interesting alternative. Astlinux is a full Linux & Asterisk distro build from the ground up for small form factor hardware. It runs happily on a Soekris Net 4801, booting from a CF card and storing the system config and voicemail on a USB key. Astlinux includes a built-in routing capability based upon iptables. Thus, using Astlinux, your phone server can actually be your router. The built-in router includes QoS and traffic shaping.

Some time ago, I wrote an article describing building an Astlinux server using a Net4801. While a little dated now, that article can be found here.

As stated at the outset, these articles describe my home office setup where every call placed or taken is handled over IP. It's not uncommon for me to have three simultaneous calls on the go (one on the home line, two in the office) and occasionally four or five.

By using G.729a when possible, combining QoS and traffic shaping I no longer have any trouble with call quality due to non-VOIP network activity. I can upload files via FTP or send and receive email while making calls without any problems at all.

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Don't Miss These

  • 1
  • 2