How to prioritize traffic on a single interface over others?
-
Does that mean I should enable the traffic shaper on the WAN interface and disable it for other interfaces?
-
You would usually have queues on all interfaces that you want to limit traffic on.
So if you have queues on LAN and a client there starts downloading a massive file the shaper can drop packets leaving the LAN to slow the TCP session and prioritise VoIP traffic.
Otherwise is has no control on download since it cannot affect what arrives inbound on WAN.
Steve
-
I think I get it. So this means that voip traffic on any interface will be prioritized by pfSense (even though it will only be on my VOIP interface)? So I apply traffic shaping to every interface, such that voip is prioritized and everything else is lower priority?
-
That's usually a switch function. Generally, you can assign priority to a specific VLAN, by port or by type of traffic.
-
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
