Hmmm.
So are you seeing packet loss at hops 14 and 15 too? Unfortunately, since that target IP doesn't respond to ICMP echo replies, we can't see if there are packet loss periods matching.
I will assume that you are seeing packet loss at hops 14 and 15 too, because if you're not, this analysis becomes more more complicated. Since you're only looking at 10 samples on the trace graph, I can't tell for sure. If you're not seeing any packet loss at hop 14 or 15, then you can't call hop 13 as guilty in the problem, since hop 13 is passing on packets just fine to hop 14 and 15, and we don't have any additional information about what might be happening further downstream. Even if the packet loss at hop 13 exactly matches your symptoms / drops, the lack of packet loss at hop 14 makes the data at hop 13 unusable without any additional information about matching packet loss at other downstream hops. (Sorry - we'd love to tell you otherwise!).
So, we'll assume you're seeing matching loss at hop 14 and 15.
Your route goes from Bigpond to Telstra to Reach.com to Alter.net to NCSoft. The return route is something we don't have access to, but would be really interesting. There may be additional players, and I think there's some possibility that it's actually the return route that's causing problems.
If you can send a .pp2 save file to us at
support@pingplotter.com, we may be able to see some other symptoms that have meaning. Ideally, this would encompass at least 24 hours, but 48 hours would be even better. There's a lot of nuanced clues we might be able to recognize, but it's not in the screenshot - digging would be necessary (route changes, for example, or time-based problems, or other hops with data that gives clues).
You are in a tough spot for solutions. Alter.net is a huge distance from your ISP - it's almost certain they can't help you solve this at all. It's more likely that NCSoft would be able to do something (basically, "something" in this case is applying pressure to their connection point, which appears to be Alter.net).
If the return route is actually the problem, then it might be another network provider that we can't see in the one-way route that's displayed here. The only way to find that out would be to trace the other direction from an ncsoft server, and that's a pretty unlikely scenario.
You might query around to some of your friends that use services other than bigpond to see if they get routes to ncsoft that's different than yours (especially if it excludes the hops you're seeing problems with). Maybe you could try out Lineage on their connections to see if it's any different. I know that's a bit of a stretch, but I'm just trying to think of any ideas that might leave you with options. If you do find that another ISP works (because they are using peering points that don't route through the problem area), then maybe you'd have an option to switch ISPs as a solution to your problem.
Another thing you can do is continue pressing on NCSoft for a solution. They'd then press on Alter.net, who may be able to find a solution to the problem. This is usually a slow procedure, but it can be effective. One of our connections here had a problem that was 2 providers away from us. We pushed on one provider, who pushed on the problem provider, and the problem did solve itself after about 4 weeks.
I do have to stress, though, that based on the data I see here, the picture is not compelling to me that the problem is a hop 13 problem. If it's not compelling to me (who trusts PingPlotter a lot), then it's certainly not going to be compelling to someone else. I would recommend trying to make the pictures a bit more compelling by including the right data. Sending us a .pp2 will give us an opportunity to look for a good picture in the data that might help convince of problems.
Sorry I don't have better news for you here.
- Pete
Previous Topic
Index