How to prioritize traffic on a single interface over others?
-
I ran the wizard and landed up with 3 queues on each interface. For WAN, these are qACK, qVOIP, and qDefault, with priorities 6, 7, 3 respectively. For LAN, these are qACK, qVOIP, and qSync, with priorities 6, 7, 2 respectively.
Does that look right?
-
Yeah that will be fine.
If you entered VoIP details in the wizard that may also be fine. You probably want add additional floating match rules for all traffic on the VoIP VLAN that puts it into the VoIP queue to be sure.
Are you actually experiencing VoIP issues currently?
Steve
-
Great point. I will do that. I did add an alias for the voip servers in use and that is being used by a floating match rule also.
Not sure if this will work better than having the switch prioritize the traffic as suggested a couples of posts ago?
-
The switch is probably not WAN side which is almost always where VoIP issues will be. It can prioritise traffic based on the 802.1p tag which VoIP traffic usually has and you can tag the VoIP vlan with that so traffic over the trunk is prioritised. I don't think I've ever had to set that.
Steve
-
Makes sense. I actually have each interface from pfSense connected to the switch by its own Ethernet cable (not trunked) , so not sure if that would help. Although one voip phone is connected to the main switch via a trunk carrying the LAN and VOIP vlans .
-
One more question. I am noticing drops in the WAN qDefault queue - a lot of them after I ran the speedtest at DSL Reports (which rated the connection and bufferbloat at A+ each), and a few others here and there. Is that normal, or do I have to tweak a setting somewhere?
-
You can increase the length of that queue if you wish. That will likely reduce or remove any drops if there is no traffic in the VoIP queue.
That is the expected action though, the scheduler will drop packets from the default or low priority queues in order to pass traffic in high priority queues.Steve
-
What length would be reasonable? 500? 1000?
-
Should I set all queues to same length? (e.g. 500? or something else?) Many of them are at 50
-
Nope only the default.
Increasing the queue length potentially adds lag so, especially for VoIP, the queues should be kept as short as possible.
Steve
-
OK. All the queues are set to 50 except qLinks (all 500, as set by wizard) and qDefault (which I manually set to 500 now). This should work?
-
It should. Test it and see.
-
Should I be aiming for zero drops on the WAN qDefault? (Do I keep lengthening the queue until I stop seeing drops?)
Also, is each drop from the queue going to result in packet loss? -
@stephenw10 said in How to prioritize traffic on a single interface over others?:
The switch is probably not WAN side which is almost always where VoIP issues will be. It can prioritise traffic based on the 802.1p tag which VoIP traffic usually has and you can tag the VoIP vlan with that so traffic over the trunk is prioritised. I don't think I've ever had to set that.
The problem is most of the WAN side, that is the Internet, is beyond our control. Also, 802.1p is an Ethernet spec, not IP, which means it won't make it past the first router. There is diffserv for IP, but I don't know how much it's honoured on the Internet. 802.1p is also part of the QoS spec for Ethernet, which means it needs a VLAN tag, which you will not likely be sending out to the Internet.
-
Traffic is shaped by sending priority traffic first and dropping non-priority traffic as necessary.
Logged drops are normal and expected.
Increasing buffer sizes will lead to buffer bloat.
You can enable codel to eliminate buffer bloat but that just ... drops traffic.
-
@JKnott said in How to prioritize traffic on a single interface over others?:
The problem is most of the WAN side, that is the Internet, is beyond our control.
When you see (hear) issues with VoIP it's almost always WAN side because for almost everyone the WAN is the lowest bandwidth link in the route.
For many users the upload bandwidth is far lower than download so when you see traffic congestion that's where it is.
Traffic shaping can be very effective there, we can control exactly what is sent from the the WAN. What we have no control over is what the ISP sends to us.Steve
-
Since turning on the traffic shaper, I am noticing much more frequent packet loss on the gateway monitor graph. It is occurring briefly several times per hour, even in the absence of significant changes in latency/ping at the same time. Is this a byproduct of the traffic shaper? Or unrelated to the traffic shaper?
-
I would not expect that unless there is congestion on the WAN in which case pings may be dropped to prioritise traffic in the VoIP queue.
Steve
-
Depending on what the problem was you were originally seeing you may be better off implementing a general FQ-CoDel strategy here.
-
This has been happening during a time where the amount of traffic on the VOIP vlan has been nil (no calls, traffic in the order of a few kilobytes maximum) - eg overnight
