The Background: I originally got the RB951 to play with and most likely replace my current infrastructure (pfSense) with, but in trying to leafn ROS, I found that my needs are far too complex for me to figure out how to replace my firewalls with Routerboards - The chains have me totally lost in the weeds. I was able to get it set up with some basic chains that a user here posted up, so I have a decent, functional router/AP for the average home/home office that doesn't need anything special. This takes me to the current 'venture'.

The Avaya IP Phones we use at my job work pretty well, but based on my testing, the VPN implementation is a bit flaky. Every now and then the phone will just drop the call. moving the VPN off to a separate device seems to have solved that issue completely. Enter the RB951.

I set up a dynamic Site to Site VPN connection on our ASA to allow me to not need the users to have static addresses, or for me to need a separate VPN entry for each user in the ASA. I set up the VPN in the RB and everything is working beautifully. Even through a NAT firewall, provided IPsec passthrough is enabled.

The last thing I want to do with this, which is where I'm lost again, is setting up a way to prioritize the VoIP traffic. I figure there are two ways to try to identify the traffic: Either do it based on Ethernet port and specify that the phone must be plugged into that port, or identify the traffic and go from there. I've spent a LOT of time searching around and I'm still not clear on how to do this.

I figure identifying the traffic would be the better approach, so I went down the path, which is where things are starting to get fuzzy. First, I was going to set up a 'mangle' entry that would tag any traffic with a destination of the phone system. The problem there is the returning packets would not be prioritized. I found that Avaya is using DSCP 46, but apparently not ALL traffic is tagged that way. I set up a rule to tag packets with a DSCP 46, destination of the phone system and source as on the local network with 'VoIP-Out', and a reciprocal rule as 'VoIP-In'. So far so good it seems, but with the phone off hook, the port is showing ~30kbps in and out, the mangle rules show ~24kbps.

Now, here's where I'm lost. I tried setting up simple queues, and initially, I could not get the queues to show any traffic. I then changed the type from 'default-small' to 'default' and I suddenly see them registering traffic. However, the VoIP-In queue shows ~24kbps when the phone is off hook, just like the mangle rule shows. The VoIP-Out Queue, however, shows 75kbps when I take the phone off the hook. This number is not possible unless the queue is grabbing both inbound and outbound traffic and combining the statistics. The question is why is it doing this? Both of the mangle rules show roughly the proper amount of bandwidth use.

The other thing with the queues is I only see options to LIMIT bandwidth. What about Guarantee bandwidth? Such as I want to guarantee that this VoIP traffic will be granted 60kbps, rather than set a rule that says 'All else is limited to X' as 'X' would be variable, wheras the phones needs are fixed. 60k (or 64) is technically twice what the phone really needs.

Obviously, if the connection quality sucks, prioritizing the VoIP traffic isn't going to help. But if the problem is bandwidth, such as one report from a user with DSL where his outbound voice was braking up during a webex, prioritizing the VoIP traffic should help.

Am I approaching this the right way, or is there a better way to do it?

I think you are looking for this: http://wiki.mikrotik.com/wiki/DSCP_based_QoS_with_HTB

As I understand it the DSCP prioritization would only really happen if you are hitting a bandwidth limit (either imposed by your connection speed or self imposed by queueing). Also, the QOS you are trying to accomplish does not really work for ingress traffic.

Is the routerboard "the" router or is it behind another one. I'm asking because you mentioned Nat behind a firewall.

If it is behind another firewall and traffic can go around the router board I to the same router, then QoS on the rb might be a moot point.



Sent from my Nexus 7 using Tapatalk

Well, IDEALLY, it would be THE router. In my testing, I've found there to be about a 50/50 shot it'll actually work through a NAT router (Did work through a linksys, did not work through the uVerse HG NAT), so my preference will be for the users to replace whatever router they have with the Mikrotiks. As you said, if it had to be placed behind another router and connect out through NAT, any potential benefit to be had by the QOS would be negated if there was traffic going out the connection but not by way of the Mikrotik.