How to prioritize traffic on a single interface over others?
-
It can do that yes. But what you want here is VoIP to get priority on the WAN over other traffic also on the WAN.
It will only really be effective outbound but that's usually where you see issues anyway.Steve
-
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.
