When it is ok to contact an ISP about ping?

[Bubbleawsome]

We signed up for the base 3/1 plan and are getting pings between 22ms for a server chosen by pingtest and 1800ms for a server on the east coast. (I'm in Alabama) I don't think that's ok, but they can just say it's on the other guy's end. Any way I can test that?

EDIT: Did a tracert to the game in question (lp.soe.com) and turns out I'm being routed through an ISP they have problems with. (Level3)

*sigh*

 

[nsafreak]

From the looks of that traceroute it looks like it's occuring after their handoff to a Tier 1 provider, not something that's their responsibility.

 

[Elixer]

From the looks of that traceroute it looks like it's occuring after their handoff to a Tier 1 provider, not something that's their responsibility.

Unless of course they didn't pay enough for the handoff, then, it IS their fault, since it is saturated at that node.

 

[Lifted]

On a residential account? Basically never.

Even with business accounts on a typical ISP they won't do much unless you're a very large client and they already have options in place to make some routing changes. Higher end Tier 2's will have more routing options and be more responsive, but you're looking at paying $5 - $10/Mbit on a minimum 100Mb transit (not counting any local loop charges for the circuit itself) for that level of service.

 

[Bubbleawsome]

Seems to be a major problem with Level3. Anything that runs through Alanta4.Level3 anywhere pings out on the next one. (if that's how you say it, I don't do networks) This is from me and people all over.

EDIT: Anything that's on the US east coast or around Germany seems to have a problem. I also tried to ping my old IP and ended up pinging an adsl at Packard bell. :awe:

 

[_Rick_]

Peering agreements need to be regulated, or it'll be more extortion, and backbones will turn into the next-gen mafia....
I'm not sure if Orange ever got their peering agreement with cogent settled. They wanted money off them since they were "sending a huge amount of packets into their network"....
What they didn't say, was that those packets were obviously being requested by the very people they were already charging for access.
It's crooks all the way down.

 

[zCypher]

Depends who you get. If it comes to me I actually investigate if there's a legitimate concern, even if it's not something the company explicitly guarantees. Ping times are not something that any ISP I know of guarantees, and 20ms is absolutely not something that you'd have any grounds to complain about - but 1800ms would obviously be another story, if it's to a host who isn't obviously broken or at the other end of a ridiculous route on the other side of the world (and even then...).

tier2 has access to check the route from the last hop on their network to the destination host. if it can be reasonably determined that one of the providers in their route is problematic, a ticket can be opened with that provider, or at the very least, an email can be sent advising that subscribers are having problems through that device. i've sent such emails myself at work, and i've had issues like that resolved before often enough. i've done this for ordinary residential subscribers. business support doesn't care more about ping times than residential support at all, lol.

if you call frontline tech support and complain about 20ms ping - yeah, good luck with that... but if you can convince them to send your ticket to tier2, you might get someone who cares to actually check. maybe. if you've already determined with any certainty that the issues lie with devices/hops outside of your ISP's network, you likely have equal chances of bringing up your concern with whoever the last working hop belongs to.

your tests aside, have you been experiencing an actual problem?

 

[Bubbleawsome]

Depends who you get. If it comes to me I actually investigate if there's a legitimate concern, even if it's not something the company explicitly guarantees. Ping times are not something that any ISP I know of guarantees, and 20ms is absolutely not something that you'd have any grounds to complain about - but 1800ms would obviously be another story, if it's to a host who isn't obviously broken or at the other end of a ridiculous route on the other side of the world (and even then...).

tier2 has access to check the route from the last hop on their network to the destination host. if it can be reasonably determined that one of the providers in their route is problematic, a ticket can be opened with that provider, or at the very least, an email can be sent advising that subscribers are having problems through that device. i've sent such emails myself at work, and i've had issues like that resolved before often enough. i've done this for ordinary residential subscribers. business support doesn't care more about ping times than residential support at all, lol.

if you call frontline tech support and complain about 20ms ping - yeah, good luck with that... but if you can convince them to send your ticket to tier2, you might get someone who cares to actually check. maybe. if you've already determined with any certainty that the issues lie with devices/hops outside of your ISP's network, you likely have equal chances of bringing up your concern with whoever the last working hop belongs to.

your tests aside, have you been experiencing an actual problem?

Wow, nice post. I seem to have some pretty random pings going on.

First is the normal ping. It looks like it is around 20-70ms. That's not bad. Most websites are getting this. (Like google and these forums.)

Second is the redirected ping you see above with the timeouts. I'm not a network guy but I've been informed that's normal. It is routing through a host that sony online has had issues with though. (Level3) Any ping that ends up going through there times out like I said.

Third is the problematic ping. The server Emerald on planetside 2. My pings vary from sub 20 to 4000+. The most part of the pings end up in the 100-1800ms range though. I've pinged the server's IP though and gotten sub 100 ping times.

These are two tracerts I did about 4 hours apart.

They look fine. I'll try and get a picture from in-game showing the crazing pings.

 

[drebo]

Unless you pay for an SLA, there's nothing they will do for you.

Also, just because a hop doesn't respond to ICMP doesn't mean there's a problem.

 

[ThinClient]

Keep in mind that those hops that do not respond to pings in your trace route may be set up not to respond.

 

[Red Squirrel]

Those actual screenshots look fine to me, but if you do get random 1000ms then there definitely could be an intermittent problem, the issue with those is as a customer it will be very hard to prove that it's their problem unless their network techs or NOC sees it and acts on it. It could be anything from an actual router issue or a transport issue.

I just pinged it from here and there does seem to be some oddity going on where some of Level 3's routers don't always respond. Though maybe it's just selectively not responding to ping based on load, or some other factor.

[root@appdev ~]# traceroute lp.soe.com
traceroute to lp.soe.com (64.37.171.24), 30 hops max, 60 byte packets
 1  internet.firewall.loc (10.1.1.1)  0.253 ms  0.267 ms  0.250 ms
 2  gw.fibreop.loc (192.168.2.1)  0.685 ms  0.847 ms  1.004 ms
 3  nrbaon0436w-047055016001.dhcp-dynamic.FibreOp.on.fibreop.ca (47.55.16.1)  8.499 ms  8.769 ms  8.932 ms
 4  te-0-0-0-2-82.dr01.nrba.on.aliant.net (142.166.129.209)  8.066 ms  12.159 ms  12.282 ms
 5  ae10.bx01.toro.on.aliant.net (142.166.149.65)  16.026 ms  15.856 ms  15.748 ms
 6  38.88.240.53 (38.88.240.53)  16.470 ms  16.314 ms  16.283 ms
 7  be2373.ccr21.yyz02.atlas.cogentco.com (154.54.46.33)  15.795 ms  15.703 ms  15.668 ms
 8  level3.yyz02.atlas.cogentco.com (154.54.11.210)  14.865 ms  11.877 ms  25.746 ms
 9  ae-13-13.bar1.Toronto1.Level3.net (4.69.200.233)  15.883 ms * *
10  * ae-0-11.bar1.Toronto1.Level3.net (4.69.151.241)  16.002 ms  16.141 ms
11  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  72.763 ms * *
12  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  72.984 ms * *
13  * * *
14  * * ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  72.054 ms
15  ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  72.509 ms ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  70.843 ms  70.858 ms
16  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  73.530 ms ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  72.533 ms  71.342 ms
17  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  71.575 ms *  73.002 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@appdev ~]# traceroute lp.soe.com
traceroute to lp.soe.com (64.37.171.24), 30 hops max, 60 byte packets
 1  internet.firewall.loc (10.1.1.1)  0.246 ms  0.240 ms  0.252 ms
 2  gw.fibreop.loc (192.168.2.1)  0.641 ms  0.783 ms  0.937 ms
 3  nrbaon0436w-047055016001.dhcp-dynamic.FibreOp.on.fibreop.ca (47.55.16.1)  8.639 ms  8.797 ms  8.941 ms
 4  te-0-0-0-2-82.dr01.nrba.on.aliant.net (142.166.129.209)  8.486 ms  8.593 ms  8.742 ms
 5  ae10.bx01.toro.on.aliant.net (142.166.149.65)  12.281 ms  16.076 ms  16.076 ms
 6  38.88.240.53 (38.88.240.53)  17.017 ms  16.883 ms  16.680 ms
 7  be2373.ccr21.yyz02.atlas.cogentco.com (154.54.46.33)  16.827 ms  16.271 ms  16.246 ms
 8  level3.yyz02.atlas.cogentco.com (154.54.11.210)  15.252 ms  11.835 ms  11.164 ms
 9  * ae-13-13.bar1.Toronto1.Level3.net (4.69.200.233)  11.893 ms  15.540 ms
10  ae-0-11.bar1.Toronto1.Level3.net (4.69.151.241)  15.679 ms *  13.275 ms
11  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  69.746 ms  69.513 ms  70.721 ms
12  * * *
13  * * *
14  * * *
15  ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  68.739 ms ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  72.949 ms  86.226 ms
16  ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  83.399 ms  80.484 ms  75.319 ms
17  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  72.961 ms  74.266 ms *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# 
[root@appdev ~]# traceroute lp.soe.com
traceroute to lp.soe.com (64.37.171.24), 30 hops max, 60 byte packets
 1  internet.firewall.loc (10.1.1.1)  0.244 ms  0.272 ms  0.262 ms
 2  gw.fibreop.loc (192.168.2.1)  0.668 ms  0.879 ms  0.964 ms
 3  nrbaon0436w-047055016001.dhcp-dynamic.FibreOp.on.fibreop.ca (47.55.16.1)  17.048 ms  17.198 ms  17.544 ms
 4  te-0-0-0-2-82.dr01.nrba.on.aliant.net (142.166.129.209)  16.553 ms  16.672 ms  16.810 ms
 5  ae10.bx01.toro.on.aliant.net (142.166.149.65)  20.149 ms  20.376 ms  20.380 ms
 6  38.88.240.53 (38.88.240.53)  21.582 ms  21.625 ms  22.489 ms
 7  be2373.ccr21.yyz02.atlas.cogentco.com (154.54.46.33)  20.731 ms  22.098 ms  20.040 ms
 8  level3.yyz02.atlas.cogentco.com (154.54.11.210)  19.539 ms  29.874 ms  29.790 ms
 9  ae-13-13.bar1.Toronto1.Level3.net (4.69.200.233)  28.103 ms  27.675 ms  27.437 ms
10  * ae-0-11.bar1.Toronto1.Level3.net (4.69.151.241)  24.531 ms  24.503 ms
11  * ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  81.181 ms *
12  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  80.973 ms * *
13  * * *
14  ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  73.233 ms *  98.452 ms
15  ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  71.320 ms  72.000 ms ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  98.422 ms
16  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  73.322 ms  72.992 ms  70.350 ms
17  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  73.795 ms *  71.517 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[root@appdev ~]# traceroute lp.soe.com
traceroute to lp.soe.com (64.37.171.24), 30 hops max, 60 byte packets
 1  internet.firewall.loc (10.1.1.1)  0.248 ms  0.247 ms  0.246 ms
 2  gw.fibreop.loc (192.168.2.1)  0.687 ms  0.951 ms  0.981 ms
 3  nrbaon0436w-047055016001.dhcp-dynamic.FibreOp.on.fibreop.ca (47.55.16.1)  14.321 ms  14.492 ms  14.685 ms
 4  te-0-0-0-2-82.dr01.nrba.on.aliant.net (142.166.129.209)  14.269 ms  14.290 ms  14.462 ms
 5  ae10.bx01.toro.on.aliant.net (142.166.149.65)  19.271 ms  19.410 ms  19.410 ms
 6  38.88.240.53 (38.88.240.53)  18.924 ms  18.023 ms  17.535 ms
 7  be2373.ccr21.yyz02.atlas.cogentco.com (154.54.46.33)  19.507 ms  18.789 ms  17.467 ms
 8  level3.yyz02.atlas.cogentco.com (154.54.11.210)  16.686 ms *  10.984 ms
 9  * * *
10  * ae-0-11.bar1.Toronto1.Level3.net (4.69.151.241)  12.725 ms  12.301 ms
11  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  72.302 ms * *
12  ae-6-6.ebr1.Chicago2.Level3.net (4.69.140.190)  71.986 ms * *
13  * * *
14  * ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  73.481 ms *
15  ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  83.736 ms  71.055 ms ae-1-6.bar2.LasVegas1.Level3.net (4.69.148.1)  72.241 ms
16  ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  72.162 ms SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  72.962 ms ae-0-11.bar1.LasVegas1.Level3.net (4.69.148.125)  71.644 ms
17  SWITCH-COMM.bar1.LasVegas1.Level3.net (205.129.16.50)  72.698 ms *  72.862 ms
18  * * *

Don't mind my double NAT, I know that's dirty. Can't easily bypass my ISP's router due to how the IPTV works.

 

[Bubbleawsome]

Unless you pay for an SLA, there's nothing they will do for you.

Also, just because a hop doesn't respond to ICMP doesn't mean there's a problem.

Keep in mind that those hops that do not respond to pings in your trace route may be set up not to respond.

Yeah, but I'm not 100% sure that's where the problem is. It seems to be so random. ¯\_(&#12484_/¯

@redsquirrel I think I've been recording when I hit 2k ping so I have/will have proof. Don't know what they would/could do. Oh well. I've got double NAT too because the built in wifi from their router freaked out so I just added our router to it.

 

[zCypher]

It's true that the asterisks do not automatically denote a point of failure. It's very common for devices to be configured not to respond to external pings. Unless you're seeing an explicit error such as "Destination host unreachable" or something along those lines, simply not getting a response doesn't necessarily mean anything at all. It could mean something, or nothing, you can't really say.

Assuming the last reporting hop in your first traceroute is our best bet to check from, here are the WHOIS results from that IP: https://who.is/whois-ip/ip-address/4.53.233.25. In there you have phone number email addresses for IP addressing and NOC support. Again, people have already mentioned that without paying for an SLA they don't care -- not really untrue, but like I said, it really does depend who you get. Life in these support roles can be sometimes quite boring during slow times, and helping someone who's asking nicely and the right way, isn't really all that impossible of an occurrence.

I would definitely have at the ready, screenshots (or preferably, copy/pastes from command prompt into a text file, so that they can simply copy/paste instead of manually typing IP addresses) of the poor ping times, and documented times/dates for those. It wouldn't hurt if you could have someone at a different location test pings/traces to the same host at the same time.

Every once in a while we get reports of people having issues with certain game servers, and 99% of the time it never has anything to do with the ISP side. Having said that, it is sometimes within the capability of the ISP to modify the route if it is bad. It really depends what it is about the route that is bad, and what's required to fix it. I've seen some pretty weird stuff before. I just wouldn't bother going to any of these support groups empty-handed, that would be a waste of time for sure.

Out of curiosity, have you seen the same behavior happen across multiple IP leases? What I mean by that is, you likely have a dynamic IP lease assigned to you by your ISP if it's a residential service, which means that your IP address will change from time to time. Some weird things can happen at the end of an IP lease cycle, and i'm just wondering whether the same issue has persisted across more than one lease (different IP address of yours). A different IP can also, under some circumstances, be taking a different route to a given host. I have seen this (just getting a new IP lease) resolve, in certain cases, issues browsing to a single website. If you do get assigned a new IP lease, check the route again to that host and see if it has changed at all and whether you're still seeing the same thing happening.