Network VOIP Testing

WORKS2011
WORKS2011 used Ask the Experts™
on
Is there software that tests noise on CAT5e and CAT6  cabling? I hired a company to test the cables and they said everything is above 1G and for the most part I believe them as I witnessed them test drops and make repairs on several damaged jacks. My concern is they didn't include a report with their invoice. Extremely disappointed as I mentioned the report was imperative for us to decide if VOIP is an option for my client.

I've insisted they put a report together and I'm aware the Fluke they used provides the one needed. While waiting on the report, and my suspicion is they forgot to turn reporting on, is there any software available that can give an indication of noise or how well VOIP will work on my clients network. Everything tested above 1G but there are still concerns I would like to eliminate. One being noise.

I've tried Solorwinds and wasn't impressed. Any other options available?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
IT Architect/Technology Delivery Manager
Commented:
Here is a free tool that I use that works very well and will help you test to make sure that your network is capable of voice.

https://www.tamos.com/products/throughput-test/
Without a hardware device of some sort, I don't think you'll be able to measure noise.  What you CAN measure, though, is whether or not it matters, at least while you do your test.  I've not used it, but the tool that mikecr mentioned should give you good answers that apply during the test time.  If the noise level doesn't impact the success of packets getting through, then it doesn't matter.

The caveat here is that all of these have limited test times.  Noise levels (or other issues) can be very inconsistent.  If you happen to test when the noise levels are low, you'll not know about high noise level times.  That's where it's useful to do multi-day tests, when possible.

Do you have specific concerns that there may be noise issues?  Also, you are making a distinction between noise on the cable and noise within that audio of a VoIP call, aren't you?
nociSoftware Engineer
Distinguished Expert 2018

Commented:
For measuring Cross-talk or Noise you need hardware support.
Normal switches can't measure that as such.
(One needs to send specific paterns on a single contact and measure another contact to see if that signal is noticable and how much the delay is.
giving a hint where a problem might be).
This needs to be done for each of the leads as a single carrier where each of the other leads are tested to see if signal is visible.
Note that X-talk etc. is noticable for humans on analogue phones. (POTS).

Signal noise is not very important for VOIP as all data is digitized in the phone and converted back in the other phone.
All data is sent in data packets to between the phones.
So if a network can carry packets in a consistent way (no/low jitter, constant latency,  not dropping packets  even under load,) are important properties.
Those are the properties that the software mikecr advices measures.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
@CompProbSolv
If the noise level doesn't impact the success of packets getting through, then it doesn't matter.
I noticed after testing the default MTU settings at 1500 they fail so I adjust the MTU and they pass. Concern is I have to keep lowering the MTU setting. I've never seen this before and believe it's part of the problem. Note this is only on the WAN and not the LAN.

In the image below you can see I test the MTU at 1400 and it fails, 1350 it passes, test in between at 1375 and it fails. Once the limit is determined I change the firewall MTU setting to  1350. When I do this the MTU test then fails at 1350, this loop is continuous so I end up leaving the MTU setting at 1400. Any feedback why this happens I appreciate as well it elaborates on your quote above "impact the success of packets getting through..." I would like to know what's causing this.
cmd
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
@noci, "So if a network can carry packets in a consistent way...
(no/low jitter, constant latency,  not dropping packets  even under load,)
...are important properties."

In other words...noise :-)

Maybe I need to clarify this point. We don't currently use VOIP we're trying to determine if the current network will support it.

All devices 1G NICs, switch is 1G, CAT5e and CAT6 cabling tested with a Fluke meeter.
mikecrIT Architect/Technology Delivery Manager

Commented:
On an Ethernet network the maximum frame size is 1518 bytes. So, with that in mind, every IP packet is encapsulated in a frame, and depending on it's header size and packet type will never theoretically be 1500 bytes due to the overhead. Normally about 1470 is normal. Do you get a reply if you ping anything on the network, other than through the firewall, with a 1470 mtu?
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
Doesn't ping at 1470 but does at 1352.
1352
nociSoftware Engineer
Distinguished Expert 2018

Commented:
@WORK2011,    packets are 20ms of sound.   that sound will not change during transport. It will be exactly received as it was sent.
(No hissing which actualy is noise) etc. are added to the signal.
Packet loss & jitter (packet jitter, not sound jitter) will become specs of silence or a voice sounding "metalic"..  (mostly because of the compression used on the sound data).

Packets are sent at 20ms intervals, but may not arrive at 20ms intervals  a small variation is no problem but large variation will cause packets become lost. (or ignored).  You will not immediatly notice 1ms . You may be able notice a packet drop , you will notice a 50% packet drop,
(sound will become gapped, stammering)   and surely near 100% drop (silence).
mikecrIT Architect/Technology Delivery Manager

Commented:
If I didn't know any better it looks like there is firewall between you and what your pinging. Am I correct?
I think you'll have better success troubleshooting this if you get away from it being related to VoIP or "noise".  From your comments, it appears that you are using the term "noise" very generically where it tends to have a more specific meaning in the contest of wired Ethernet connections.  It doesn't really matter, though, as the problem appears to be unrelated to either use of the term.

As you have identified, the issue is that some device between the computer doing the pinging and 192.168.25.1 has a MTU set less than 1378 and equal to or more than 1352.  When a packet is sent through it with DF (Don't Fragment) set, the packet won't get through because it is too large.  THAT is the issue, not noise or VoIP.  Identifying that device should be a good start to resolving this issue.

It would be helpful to have some more details about the physical part of the network here:
1)  What is the IP address of the device used to ping to 192.168.25.1 above?
2)  What sort of device is at 192.168.25.1?
3)  What devices are between the one doing the pinging and 192.168.25.1?
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
@mikecr, correct. ISP is in bridge mode and all data is wide open to the firewall.

@CompProbSolv: I can't provide more info regarding the failing network because the failing network is on the WAN/ISP network. The LAN doesn't fail the way the WAN network does. After running MTU tests and configuring the MTU remains constant on the LAN.

My thinking all along is the ISP (Spectrum) is the issue because of old coax lines that haven't been managed well. When I call Spectrum they say it's not them it's the "Old Time Warner Business" group, when I contact them they say they were bought out by Charter and so on. Nobody takes responsibility for the network. I've been told by Charter, Time Warner Business, and Spectrum that they don't manage and care for this equipment the same way they do new routes, like fiber. They're either being brutally honest or just trying to get me to move to their fiber. Ultimately this is their final answer, "move to fiber and you won't experience this anymore."

My job is to report exactly what's going on to my clients. My only concern outside of all the testing mentioned is the NIC on the firewall and I opened a ticket with the Sonic Firewall team as this device is under contract.

I'm scheduled to speak with them this evening or tomorrow, waiting to hear from them and I will keep everyone posted.

Thank you for the input, much appreciated.
"the failing network is on the WAN/ISP network"
You demonstrated an MTU issue with pinging 192.168.25.1.  That's on the WAN/ISP network and not local?
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
@CompProbSolv read further up the post. I think you're reading the point I made about the LAN,
Doesn't ping at 1470 but does at 1352.
I'm fine the LAN MTU is constant at 1352 and all other hardware tests pass.
13252
I wrote prior in this post how the WAN is affected while testing the MTU to Yahoo.com, see here
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Many Firewalls/Routers allow a setting for ClampMSS or something along that way which at least should help TCP.
Where MSS is adjusted for the amount of data that can be sent. as a message. (mostly 1412 ).
 Problem will still be with systems that still assume 1500 Bytes ethernet packets with Don't fragment set. It actualy is the Don't fragment that hurts.
I have been a victim of that as well on a few occasions. with PPPoE  f.e. (The raw packet + PPP info needs to fit in the ethernet frame).
I'm missing something here.  On the LAN, you have problems pinging when the MTU is above (about) 1352.  Your concern appears to be that you can't ping yahoo.com with the MTU above 1352.  Wouldn't the LAN limitation on MTU size have the same effect on pinging yahoo.com?

Do you have the ability to ping yahoo.com from your firewall and set the MTU?  That would tell you if there is a problem over the WAN also.
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
On the LAN, you have problems pinging when the MTU is above (about) 1352.
Yes.

Your concern appears to be that you can't ping yahoo.com with the MTU above 1352.  
No, this is not my concern and not the case.  

The problem is I constantly have to change the MTU setting on the WAN to a lower setting in order for it to be consistent. Take the example above, MTU test fails at 1400 for obvious reasons. I then test it at 1350 and it works so I adjust the firewall MTU to 1350. After I make the change in the firewall it then fails at 1350 so I test again and it passes at 1300. I make another change on the firewall changing the MTU setting to 1300 and then MTU tests fail. Pattern is I test, find the correct MTU ceiling, once I configure this into the firewall it then fails.
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
I should probably open another post about the other issue which is DNS or ISP causing latency issues while going to the internet. I already have a post open regarding this you can read here.
I'm not seeing data here that indicates that pinging works with an MTU of 1350 but fails when you set that on the firewall, but I'll take your word for it.

It sounds as if you are equating the number after "-l" in the ping command (buffer size) with the full size of the packet that must fit in the MTU.  If I understand correctly, there are 28 header bytes in addition to the buffer size.  The MTU must accommodate both.  If this is correct, when you set an MTU of 1350, for example, you won't be successful with a buffer size greater than 1322.

To confirm, when you change the MTU, identify the largest buffer size that passes.  If it's 28 bytes (or some other consistent number) smaller than the MTU, then this is very likely the issue.
I can consistently ping yahoo.com with a buffer size of 1472, but it fails at 1473.  That would fit with an MTU of 1500 and 28 bytes in the header.
mikecrIT Architect/Technology Delivery Manager

Commented:
What firewall do you have and where are you changing the MTU size at?
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
@mikecr, SonicFirewall TZ400. Changing the MTU size on X1 (WAN) network interface.

@CompProbSolv,
"I can consistently ping yahoo.com with a buffer size of 1472, but it fails at 1473.  That would fit with an MTU of 1500 and 28 bytes in the header."
The same goes for me now. I found that X0 (LAN) interface was at 1400 which explains the 1372. I adjusted this to 1500 as well as X1 (WAN) and now I get the proper results of 1472.

@ComProbSolv,
"It sounds as if you are equating the number after "-l" in the ping command (buffer size) with the full size of the packet that must fit in the MTU.  If I understand correctly, there are 28 header bytes in addition to the buffer size.  The MTU must accommodate both.  If this is correct, when you set an MTU of 1350, for example, you won't be successful with a buffer size greater than 1322."
This helped tremendously, thank you. I read this before but thought it was included in the MTU and not left out.

What I was trying to explain before was I had to continuously lower the MTU setting on X1 on the firewall after making a change to the MTU size. All I can gather is when the MTU settings are different between X1 and X0 this happens. Once I adjusted X0 to 1500 and it moved the testing from 1372 to 1472 I did the same to X1. With both X1 and X0 set to 1500 I then tested internal and external and it remained constant at 1472.

Seriously appreciate all the efforts here. This thread started out how to test a network to be suitable for VOIP to work. The firewall came up and what was affecting MTU from maxing out. What I thought was packets being dropped, noise, a bad device, the network encountering bottlenecks appears to be the difference in the X0 and X1 networks MTU setting being different on the firewall. As explained above now that they're both at 1500 the results are correct at 1472. If someone feels the firewall and MTU is still a concern happy to still discuss.

How to carry this conversation into a new post? Is it alright to create a post and point to it from here? The other question I had about this same network is this, is DNS or the ISP the culprit why websites are slow to open, 10 seconds of a white page like this
slow internet
mikecrIT Architect/Technology Delivery Manager
Commented:
Absolutely! Sometimes if you hit a web page that has multiple imbedded links to other content it can take the page a while to load as DNS resolves it. Are you using a local DNS server or are you using public DNS server? If you are using public and have this problem then check your firewall so see if it is doing any type of DNS checking policy. I know Cisco firewalls used to do it and sometimes it can cause a problem with loading websites but they have since fixed their issues. What happens is the firewall makes sure the command being used to resolve names has not been modified so that it doesn't do a dns stack lookup. In other words everything in the dns zone. This causes the loading of the page to take a bit longer than usual.

Other things that can cause it is mtu size, not being able to fragment packets, and using a proxy server, to name a few.
I'd suggest setting up Wireshark on one of the workstations and watch what packets go back and forth.  That should give you a good clue as to which part of the process is the issue.

If you've not used WIreshark before, it takes a bit to filter what you need, but your effort will be well worth it in the long run.
WORKS2011Managed IT Services, Cyber Security, Backup

Author

Commented:
Appreciate the knowledge everyone shared.

mikecr, I used the throughput tester and gained valuable insight on this network.

CompProbSolv, wireshark helped defining where I found the issue. I sniffed the packets and found they were bring dropped by 50% at what first seemed to be the firewall. After completely reseting and bringing back up problems still remained. Turns out at the Spectrum cable modem it looked like some sort of mad scientist deal and coax was split going to devices that weren't even powered up. I have no idea what Spectrum was doing. I pulled the coax splitter out and noticed brittle connections. These were ones that weren't needed anymore so I removed them and cleaned up this point in the network. After doing so where Wireshark previously showed 100's of dropped packets now only showed 4-6. Of course website resolution is far better now as well. Somewhat concerned with the rest of the network on Spectrums side but happy to have located a bottleneck I could repair and see websites load normal as apposed to a 10 second wait.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Severe packet loss will cause all sorts of network failures. So it usually is a good hint of trouble.
A coax cable should have a fixed impendance & resistance, That can be measured. And a cable tester can be used (but it needs to be done at both sides).

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial