Network VOIP Testing
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?
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
@CompProbSolv
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.
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.
ASKER
@noci, "So if a network can carry packets in a consistent way...
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.
(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.
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?
ASKER
Doesn't ping at 1470 but does at 1352.
@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).
(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).
If I didn't know any better it looks like there is firewall between you and what your pinging. Am I correct?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@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.
@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?
You demonstrated an MTU issue with pinging 192.168.25.1. That's on the WAN/ISP network and not local?
ASKER
@CompProbSolv read further up the post. I think you're reading the point I made about the LAN,
I wrote prior in this post how the WAN is affected while testing the MTU to Yahoo.com, see here
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.
I wrote prior in this post how the WAN is affected while testing the MTU to Yahoo.com, see here
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).
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.
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.
ASKER
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.
ASKER
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.
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.
What firewall do you have and where are you changing the MTU size at?
ASKER
@mikecr, SonicFirewall TZ400. Changing the MTU size on X1 (WAN) network interface.
@CompProbSolv,
@ComProbSolv,
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
@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
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
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).
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).
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?