WISP Network Troubleshooting

[Bryan_31]

I am a customer of a small market WISP and am trying to track down the problem and sort the bull from the real.

We are subscribed to a WISP that has traditionally been average at best, they operate on 2.4, 3, and 5ghz but during the summer they always switch us to 2.4 for best penetration through the pine trees. Until about 4 months ago we had been averaging 1-3 mbps down and .5 to 1 up, well below their advertised speeds but whatever. Recently we are getting anywhere from nothing to .5 mbps down and about .1 mbps up.

I kept getting standard answers so I decided to investigate myself and see what I could see.

I decided to run a traceroute through the network to the dns server (google's @ 8.8.8.8) and this is what I got. I called up cogent to see if they saw anything inconsistent and once I reached a level 2 tech I was shut down as I didn't work for the WISP.

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 1 ms 1 ms 1 ms 192.168.1.1
2 1 ms 2 ms 1 ms 10.10.200.1
3 10 ms 58 ms 10 ms 172.22.142.254
4 11 ms 13 ms 10 ms 38.114.201.254
5 16 ms 23 ms 12 ms 38.100.66.26
6 296 ms 228 ms 121 ms gi0-0-0-0.nr11.b001056-0.iah01.atlas.cogentco.com [38.100.66.25]
7 130 ms 26 ms 145 ms te0-0-1-1.agr14.iah01.atlas.cogentco.com [154.24.19.193]
8 149 ms 24 ms 50 ms te0-7-0-5.ccr22.iah01.atlas.cogentco.com [154.54.25.229]
9 24 ms 142 ms 32 ms be2443.ccr22.dfw01.atlas.cogentco.com [154.54.44.230]
10 52 ms 140 ms 30 ms be2764.ccr41.dfw03.atlas.cogentco.com [154.54.47.214]
11 * * 3774 ms tata.dfw03.atlas.cogentco.com [154.54.12.106]
12 3122 ms * * 209.85.172.106
13 * * * Request timed out.
14 * * * Request timed out.
15 2656 ms 1695 ms 2373 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

C:\Users\bpatt_000>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


The signal strength to the AP tower is not great but it seems serviceable (It varies from 67-77db).

Second, to further clarify the situation. I am able to perform a reverse ping + trace via Cogent's website (cogentco.com) with their 'looking glass tool' and consistently receive pings in the 20-50ms range which confirms to me that my connection up to that point is solid. Is this accurate?

Finally, on the information side, I was able to further validate that things seem to be working correctly from outside in with a test I had not tried until today (smokeping) http://www.dslreports.com/smokeping?target=951223f42adc0175ee087b08847c41fb

My interpretation of what I am seeing is that on that last hop on cogent's servers the traffic is bottle-necking severely. I attribute this to a lack of bandwidth being purchased by my WISP not any issue in terms of my subscriber module and the connection to their network. Can someone who is an expert help me verify or disprove this theory? It may all be moot as the WISP may not be willing to address the issue. If my theory is correct and they continue to refuse to address it this at least gives me a better understanding.

 

[bill001g]

Assuming they do not have a bad connection your assumption they overloaded the connection would likely be valid. This would especially be true if you get better response say in the middle of the night.

I am surprised you got even that far calling a ISP in the middle. They normally ask you for a circuit or customer number if you do not have that they pretty much hang up on you. Way too many scammers trying to social engineer hacks.

Still your problem looks like it is some point to point connection between hop 5 and hop 6. But hop 4 which appears to be farther away....the latency is slightly less is also cogent. So does your ISP hook to cogent at hop 4,5 or 6. If they are at 4 or 5 then the problem is 100% withing cogents network.

Now the very bad thing is traceroute only shows the path to the servers the path coming back may be different. Since you have been playing with the looking glass stuff you can run tracert in both direction to the same device...ie the cogent router.. and see if it is symetic.

Still it may just be a waste of time. What you need to do is find a tech at your ISP that can take what you found and present it to cogent since they are the actual customer. Be happy they don't have multiple upsteam ISP it gets much harder when only some traffic follows the path and others use other paths.

...edit Looking a little further the problem in the later hops is the connection between googles network (they are a actual ISP) and cogent. There may be 2 problem but the large jump in latency that is inconsistent in hop 5/6 may hide some of it. Try 4.2.2.2 which is level 3 dns it should follow a different path later in the trace.