I am having loops in my network and Call Quality is degraded

FreePBX Networking
1

hi guys,

We are having loops on our network due to single broadcast domain.

Calls are degraded. we are unable to identify the loop.

Axis Cameras, IP Phones and PCs are on the same broadcast network. No VLANs deploy.

Any suggestions on how we can identify the loop and Is there any way that we can improve the quality of our calls ?

Some Examples of IP Phones

Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=5ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Request timed out.
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Request timed out.
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=6ms TTL=64
Request timed out.
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Request timed out.
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Reply from 172.16.23.114: bytes=32 time=9ms TTL=64
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Reply from 172.16.23.114: bytes=32 time=7ms TTL=64
Reply from 172.16.23.114: bytes=32 time=8ms TTL=64
Reply from 172.16.23.114: bytes=32 time=7ms TTL=64

Reply from 172.16.23.8: bytes=32 time=4ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Request timed out.
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=6ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=13ms TTL=64
Request timed out.
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=10ms TTL=64
Reply from 172.16.23.8: bytes=32 time=10ms TTL=64
Reply from 172.16.23.8: bytes=32 time=10ms TTL=64
Request timed out.
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=7ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=7ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Request timed out.
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=8ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Reply from 172.16.23.8: bytes=32 time=9ms TTL=64
Request timed out.
2

This is way outside our scope, but I’ll give it a single shot. If this doesn’t help, I’m out.

The network outages you are describing don’t look like loops to me. It looks like you have a failing switch. The reason I say that is because your RTT is so consistent, when it works. If it fails, it doesn’t degrade - it just fails.

If this is looping, I’m afraid the only way you’re going to find it is the old-fashioned way: just start unplugging stuff until it works and slowly plug stuff back in until it fails. There are tools you can use, but it’s honestly been a million years since I’ve had to troubleshoot a network problem like this.

Good luck.

3

If you had experienced the real L2 loop you would have noticed that nothing worked.
So, if you have RTT like 10ms, the network is maybe congested but it is not a pure loop.
Get Wireshark and check what kind of traffic and level you have in your network. Maybe there’s damaged NIC which is pushing tons of bogus traffic. And then check what kind of security features you can utilize on your switches.

1 Like
4

Thanks @cynjut.

yes this is a considerable suggestion.

however we have identified that there are Cameras on the same network and when we unplug the NVR everything gets to 1 ms but as we plug the NVRs voice network get’s messy.

what we are thinking is like they are choking the upstream.

1 Like
5

Two choices: separate the NVRs to a new network and switch, or implement VLANs to subdivide the collision domain. Note that it you are saturating the network, VLANs will not help.

6

network saturation means flooding the uplinks beyond their capacity ?

1 Like
7

You need to get more info on the network traffic so have actual data to base decisions on.

8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.