How to prioritize traffic on a single interface over others?
-
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
-
@stephenw10 How should I go about doing that? I feel like I have tried everything, but I want to make sure I have not missed anything important.
-
Run a packet capture for SIP traffic against a phone IP unless it fails. It might be large so filter for just the SIP traffic.
Is it dropping the call due to some timeout or is one side intentionally closing it.
Steve
-
@stephenw10 Will do, and hope to be lucky enough to catch one of the call drops. Like I said, the call drops inevitably are accompanied by loss of connection for everything on the network, and gateway time outs/packet loss. So I am not sure how productive this will be, although I am certainly willing to give it a shot at this point.
-
@pfguy2018 said in How to prioritize traffic on a single interface over others?:
Like I said, the call drops inevitably are accompanied by loss of connection for everything
Well, that's your problem. Dropped calls is just the symptom. When I had that problem the way I often first noticed it was the Internet radio station I was listening to would stop. I'd then pick up my phone to verify I had lost dial tone. You have a problem somewhere between you and the ISP. It could be a bad cable as I had. It took the cable company a while to locate the problem, but they eventually did.
-
Ah yes I missed that nugget of information!
Then, yes, forget traffic shaping. If everything loses connectivity then check the system, gateway, resolver, firewall logs at that point and see what's happening.
Reviewing the thread I don't see if we've confirmed you're running 2.4.5p1?
Because 2.4.5 has a known bug that presents like this.Steve
-
Yes, running 2.4.5 p1.
Looks like another call to the ISP is in order -
One more curious thing, that I was hoping one of you could explain for me:
The pfSense gateway monitor is showing frequent packet loss (see pics that I posted earlier in this thread). However, I have noticed that in the last few days, at the same moment where pfSense gateway monitor is displaying packet loss, PingPlotter (being run on my computer) is often NOT displaying packet loss at the same time and pings are occurring as expected. (but sometimes there is packet loss on PingPlotter at the same moment as on the pfSense gateway monitor). How to account for this discrepancy?
-
Are ping plotter and the pfSense gateway monitoring using the same target?
pfSense uses the gateway IP be default but it looks like you may not be since it's logging ~10ms which would be high for that.
Steve
-
@stephenw10 pfSense is using the the gateway IP. PingPlotter is pinging Google and one of my VOIP provider's servers.
-
Ah well they could respond differently then. ISP gateways in particular can be poor at responding to ping under load. They are not obliged to respond at all.
Steve
