How to prioritize traffic on a single interface over others?
-
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
-
@stephenw10 the original issue was dropped voip calls. Trying to target that
-
Hers an example of what I am seeing. This is the last hour. No voip calls (or much traffic of any kind) during that time.
-
Prior to turning on the traffic shaper, I was not seeing this frequency of packet loss on the gateway
-
You were seeing calls dropped entirely not audio quality issues?
That's probably not a traffic congestion issue then. Traffic shaping probably won't help id that is the case.
Steve
-
Do you mean congestion on my internal networks/pfSense? Or congestion on the WAN/ISP network?
So traffic shaping to prioritize VOIP traffic will not help with the dropped calls? Am I better off turning it off or leaving it in place in the hope that it will make some small difference?
-
It's unlikely it will help with calls being dropped entirely. The line conditions would have to be exceptionally bad. You would be having catastrophic audio quality issues first.
You can test it with the shaping but I would be looking at the SIP traffic to see why the calls are dropped. Do you see any errors on the phones or PBX when it drops?Steve
-
I have been working with VoIP at business customers for many years and never worried about congestion. Compared to the bandwidth available on modern LANs, VoIP is trivial. If congestion is an issue, it's more likely to be on the WAN side, where most people have less bandwidth than on their LAN. Regardless, you could configure your switches to give priority to the VoIP packets, so they get to the router ahead of other traffic. However, even that has limits.
