VoIP One-way Audio and Voice drops
-
What Linux is the "other" one?
-
@scottalanmiller said:
What Linux is the "other" one?
CentOS 6.6 final. FreePBX runs on CentOS 6.5 final.
This is one running OpenSuse
-
Does a Windows VM on the hyper-V server have the same issue?
Also what about a UEFI linux running in a Generation 2 Hyper-V VM? -
Ping results from the Meraki. All of these are on different ports of the Meraki.
.88 is my deskphone, .121 is the PBX and .116 is a Windows server.
-
@coliver said:
Ping results from the Meraki. All of these are on different ports of the Meraki.
.88 is my deskphone, .121 is the PBX and .116 is a Windows server.
That doesn't make sense your out bound pings where fine on the other devices with no issues.
-
@thecreativeone91 said:
@coliver said:
Ping results from the Meraki. All of these are on different ports of the Meraki.
.88 is my deskphone, .121 is the PBX and .116 is a Windows server.
That doesn't make sense your out bound pings where fine on the other devices with no issues.
Yep, that was pinging the same windows server that had pinged it before. I'm going to try a few different phones and PCs around the network to test this.
-
So even the deskphone is losing a lot of packets? That's very, very fishy. Maybe there is a switch issue or something?
-
@scottalanmiller said:
So even the deskphone is losing a lot of packets? That's very, very fishy. Maybe there is a switch issue or something?
I moved the phone I was testing with off a dumb switch I was using and it is now directly attached to the firewall.
.215 is a PC attached to a different switch, which is directly attached the firewall. The Hyper-V host that the PBX resides on is directly attached as well. The other host goes through a switch.
-
That's a lot of drops for a LAN. Should basically be zero.
-
@scottalanmiller said:
That's a lot of drops for a LAN. Should basically be zero.
It just seems to be the firewall. Pinging anything on a different switch through the firewall results in 0ms response (or less than 1). Which brings it back to maybe the firewall isn't working correctly?
-
@coliver said:
@scottalanmiller said:
That's a lot of drops for a LAN. Should basically be zero.
It just seems to be the firewall. Pinging anything on a different switch through the firewall results in 0ms response (or less than 1). Which brings it back to maybe the firewall isn't working correctly?
The Meraki? I'm not surprised. Their router/firewalls are underpowered.
-
@thecreativeone91 said:
The Meraki? I'm not surprised. Their router/firewalls are underpowered.
But didn't the issue exist with the Ubiquiti too, which should be orders of magnitude more powerful.
-
I know ping isn't the best indicator but it really is the best I have at the moment. Here are two captures taken at almost the same time:
PBX
Meraki
-
Here is the PBX pinging both the Meraki and the remote switch at the same time.
Meraki
Remote Access Switch
-
Sorry, the remote switch is "through" the Meraki?
-
@scottalanmiller said:
Sorry, the remote switch is "through" the Meraki?
Yes, switch isn't the right term. It is the access to the rest of the internet.
-
@scottalanmiller said:
Sorry, the remote switch is "through" the Meraki?
I think he Means Phone Switch.. As in sip provider.
-
I think I agree with Scott.. I wonder if you have a failing switch. Can you replace it.. or for starters.. move the meraki to a different port on that switch?
-
@Dashrender said:
I think I agree with Scott.. I wonder if you have a failing switch. Can you replace it.. or for starters.. move the meraki to a different port on that switch?
Switch? The PBX is directly connected (ok it is going through a hyper-v virtual switch but it is the only on it) to the Meraki firewall which is our internet gateway.
At the suggestion of NTG support I directly connected the PBX server to the internet (which is a bit of a chore here) and there was no packet loss and ping/response times were marginally better. I forgot to grab a screen shot of it though.
That pretty much means it is the firewall correct?
-
Well before jumping to that (hopefully correct) solution, have you tested calls to ensure that packet loss is correlating to bad phone calls?
