Packet loss or high ping

We hope that you are really enjoying using our servers and are having good time with our services. However, communication over the Internet network is always a subject to many factors influencing your connectivity. As a result, some issues may occur and in order to investigate and resolve it, we need to understand which end causes the issue.

So, in case you ping a server and some of the packets are lost, or it takes too much time to receive a response (more than 110 milliseconds), it may indicate a network issue.

Please, note that this article is for those whose server is available, despite the network issue. If the server does not return any packets at all, please, refer to our guide for the case when a server does not respond to ping.

Cases

1. If you are using a proxy or VPN, disable it and ping the server again. If it helps, the problem was caused by an intermediate server. You can continue to connect without using it, or consider changing the VPN/proxy.

2. If you have recently changed network settings, restore the previous settings and try to ping the server again. If it helps, it means the issue was caused by the network configuration, and you should consider whether to continue with the old one or edit your network settings.

To reset your network settings to the default parameters automatically, you may reinstall the OS of your server. Please, note that OS re-installation will cause the loss of all the data on the server.

In order to reinstall the OS, you may use one of the following guides:

1. https://gcore.com/docs/hosting/virtual-servers/manage/operating-system/install-a-linux-os-from-a-template
2. https://gcore.com/docs/hosting/virtual-servers/manage/operating-system/install-an-os-from-a-template-in-vmmanager-6
3. https://gcore.com/docs/hosting/dedicated-servers/manage/operating-system/install-a-linux-os-from-a-template 

3. If the steps above are not applicable to you, or they don’t help, please, contact our technical support. Please, provide the following information in your request:

• Whether you are using a VPN/proxy and whether you have recently changed the network settings. If so, please, specify if disabling the VPN/proxy or reverting to the old settings helped.
• The IP address of your server.
• The IP address which experiences poor connectivity with the server.
• The country and the city where you are located. If you are a reseller and your client is experiencing a network issue, please, specify the country and the city of your client.
• The date and time in UTC+0 when the problem occurred.
• The output of ping and tracert (Windows) / ping and traceroute (Linux) / mtr (UNIX system) from the client to the server.
• The output of ping and tracert (Windows) / ping and traceroute (Linux) / mtr (UNIX system) from the server to the client.

The most important information from all the mentioned above is mtr outputs. We also have an article on how to run mtr in case you need it: https://support.gcore.com/hc/en-us/articles/19864311353105-How-to-run-MTR-on-Windows-and-Linux

But why is it so important for analysing networking issues? It is so because it allows us to understand which end is causing the issue.

Let's take a look at some examples and check how it can help.

So, we have a virtual private server purchased at Gcore's Hosting with the IP 185.105.3.226 and here is the first case:

When checking the mtr output, first of all, you should pay attention to Loss% column, it is marked on the screenshot above.

So, here we can see that there are packet losses occurring on the server's IP, but it is more important where the losses start occurring. In this case they first appear on the 3rd hop with the IP 184.185.64.201 which belongs to the ISP named Hurricane Electric LLC. Since the issue starts on their network, all the losses shown after this hop are just inheriting it, and it is them whom you will need to contact in order to resolve the issue.

P.S. In order to receive the info on the ISP behind any IP, you can use whois command line example (you will need to install it) or any third-party service based on it. Here is how it looks like in the terminal:

For comparison, here is another case towards our server with the IP 185.105.3.226:

From the first glance, we see the same here: there are packet losses occurring on the server's IP. But it originates on a different side here. It starts on the first hop (in your case it will be your IP/your client's IP) and then packet loss spreads to the next hosts on the path as well. In our example, the ISP called Bamboozle Web Services Inc. should be contacted and asked for the resolution. In your case, the origin (the machine used for connecting the server purchased with us) should be checked, or your local ISP should be contacted in order to resolve the issue.

And here is the third situation with the same server:

In this case we still see that losses occur on Gcore side, but here for the first time there are no preceding packet losses. A similar result will mean that the issue originates on our equipment, and you will need to contact us in order to resolve it.

However, it is crucial for us to get the reverse mtr (the one made vice versa - not from you/your client to the server, but from the server to you/your client) as well. It is so because checking the reverse path will allow us to verify 100% if the losses originate on our equipment or not, and in any case it will allow anybody to view a more complete picture of what's going on between you/your client and the server.

All the mentioned data will help us to assess the situation in more details and will speed up the investigation on the root-cause of the issue.