Pingplotter not responding download#
For Windows, you can download it from a specific website.
Pingplotter not responding install#
You can install MTR via the package manager of the Linux distribution or MacOS. Please do a trace (in both directions) with at least 1000 packets with a tool like MTR or WinMTR. Simple statements such as "my ping is bad" or "there is packet loss to my server" are unfortunately not enough for an error analysis. If you are experiencing packet loss, then we will need some evidence of this. Go to the correct server, click on "Support" and then choose "Server Problems" -> "Server is not reachable". If you are still have the problem, please send us a ticket via Robot. For more information about such situation, please also see our Guideline for server locking. If that doesn't work, it is possible that we blocked your server. To do this, go to Robot and then to the correct server, and click on the "Reset" tab. If your server is not reachable, you can try to restart it yourself. Make sure to select the affected server in your support request.ĭepending on the problem you are experiencing, you can choose one of two request types. If you are experiencing network problems with your server, then please send us a support request via your Robot account. but again, not getting a TTL expired back is not an indication of an issue.Instructions for an error report with Hetzner network problems Last change on You can set your TTL to whatever if you want to test TTL 0 replies from a router. You can also do that yourself, want to test hop 5, set the TTL to 5 and that router should respond with a TTL expired. Packet capture is a good start)īecause it sends ICMP packets out and starting with a TTL of 1 the reply of that TTL form a router will be used to indicate "packet loss" at a certain hop if not all of them comes back.īasically means you need to use more tools check for real packet loss. (Oh, and if they do suspect something is wrong PingPlotter could help identify if there is an issue, but you would need to dig a little deeper to proof anything. I quickly did a packet capture of both, so if you look at their capture, you will see a lot more requests from my internal IP to google dns each with a different TTL value, once the TTL value reaches 0 it obviously gets discarded, and TTL is reduced by 1 every hop. It's likely that there's not enough bandwidth between those two locations" This is a strong clue that it's actually the connection between hop 8 and 9 that's causing the problem.
Also, the IP addresses show decidedly different ranges. A little bit more troubleshooting is needed for this.ĭigging deeper, we can see (from the domain names) that hop 8 is in the rr.com domain, while hop 9 is in the domain. We don't know if it actually happens because of CPU overloading in hop 9, a router problem in hop 9 (or even on the exit side of hop 8), or if it's the connection between hop 8 and 9. Now, all we know from this is that the problem happens after hop 8.
This is a huge indication of where the problem lies. Hop 9, however, shows 9% packet loss, and this packet loss is carried on through to the final destination. Hop 4 is likely just a router using a different CPU path for TTL=0 packets than it does for routing data through. Hop 5 doesn't show packet loss, though, so you know that the problem in hop 16 isn't because of hop 4. There's a problem someplace in the route, but we need to determine where. "First off, the final destination (hop 16) shows 9% packet loss.
0 kommentar(er)
