How to prioritize traffic on a single interface over others?
-
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.
-
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.
