How to prioritize traffic on a single interface over others?
-
@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.
-
No errors on the devices (ATA's) when the calls drop, other than ping spikes and packet loss. When these occur, they invariably affect the entire network (all vlans/interfaces) at the same time and all devices lose connectivity simultaneously. I have been working with my ISP to see if there is anything they can fix on their end. Despite multiple tech visits inside and outside my house (including by relatively senior technicians), they have been unable to find a cause for this problem (so they say). My own attempts have included things like: swapping the cable modem, adding a MOCA filter, swapping out ethernet cables for brand new ones, resetting and reformatting my managed switches, simplifying my vlans and interfaces to remove trunks wherever possible and minimize the traffic on my VOIP subnet, and replacing my pfSense device with a brand new SG5100. I am all out of ideas. But the upshot is that none of our voip devices can be relied upon to make calls, due to the frequency of the call drops.
-
@JKnott That was my thinking too. At most, the VOIP traffic is a couple of hundred kb at a time. Hard to imagine that would make a difference on a 1000/30 cable modem connection.
-
Several years ago, I had an intermittent problem with my Internet connection, which also affected my phone, but not TV service. Since I had 2 cable connections to the utility room, I was able to do some testing to confirm the problem was not in my home. I wrote a short script to ping my ISPs gateway every minute or so and log failures. With that I was able to show my ISP the failures and they eventually traced the problem back to a bad connection in the cable going out to the street. So, it's entirely possible the problem is elsewhere and potentially affecting other customers.
-
I have been using PingPlotter to accomplish the same task. I have it running on my computer to constantly ping Google and one of the VOIP servers. Between the gateway monitor and PingPlotter, I have ample evidence that something is going on. But the ISP has "tested everything" - splitters inside and outside the house, all coax cable inside and outside the house (including the connection to the street), modem, etc, etc, etc. And they claim they cannot find the source of the problem. Apparently the next step is they are sending one of their most senior technicians for one more visit inside my space to make sure nothing has been missed. If s/he can't fix the problem, I think I am on my own.
Edit: Here is what things look like when they are particularly bad.
-
@pfguy2018 said in How to prioritize traffic on a single interface over others?:
At most, the VOIP traffic is a couple of hundred kb at a time.
Probably not even that. Years ago, I used to put 8 PBX connections over a 128 Kb ISDN basic rate connection. It used G.729A codec. A toll quality G.711 codec runs 64 Kb.
-
Link congestion is going to present as audio quality issues before anything else so if you don't have that don't worry about it.
If it happens anywhere it's going to be on the 30Mbps upload bandwidth your have. It's relatively easy to saturate that.Actually dropping calls is something else. The only thing it may be potentially in pfSense would be a state timeout. Make sure you have firewall optimisation set to conservative:
https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html#set-conservative-state-table-optimizationSteve
-
@stephenw10 said in How to prioritize traffic on a single interface over others?:
Make sure you have firewall optimisation set to conservative:
Yep. Did that months ago.
-
Then I would be into looking at SIP traffic to see why the calls drops. Is one end closing the call deliberately for example.
Steve
