Checking service availability using MTR. MTR is a utility for checking the availability of a server or website, showing the route of packets to the service and losses at intermediate nodes. MTR is a simple network diagnostic tool (for services, servers, or websites) from the command line or shell (WinMTR). It combines the functionality of traceroute and ping programs. Similar to traceroute, the mtr command provides information about the route, showing a list of nodes and routers through which the packet passes. However, MTR shows more information than traceroute: it identifies the path to the remote server, displays response and loss percentages, as well as response times for all network hops in the route between your local system and remote servers. When should you use it? When there are suspicions of packet loss. MTR allows you to see if there are packet losses, check at which IP node the packet losses occur, and then identify the regional or backbone provider responsible for the situation.
Pre-check for availability. First, perform a parallel check of the availability of the website or server from different countries around the world - see the article.
Checking on Windows OS. If you encounter RDP connection issues such as delays, freezes, lags, disconnects, interruptions, or poor RDP connection, you need to perform a check using WinMTR, as there may be packet losses on the route from you to the server. WinMTR provides information about the route, showing a list of routers through which the packet passes. Run the WinMTR utility for Windows on your computer. Download: https://sourceforge.net/projects/winmtr/ In the program, specify the IP address of your server or the domain name (only the site name without www or https) for the check. After sending at least 1000 packets, save the result by clicking Export Text. Please provide the results of the check to the support team in the ticket system for analysis. Alternatively, you can analyze it yourself according to the recommendations below.
Checking on Linux OS. If you are using Linux, execute the command:
mtr --report -n -c 1000 IP
Where IP is your IP or domain name. After execution, save a screenshot with the command execution results and attach it to the support ticket for our analysis. Alternatively, try to analyze it yourself.
Explanation of WinMTR values and results
- Hostname: the domain name or IP address of the node
- Nr: the serial number of the node in the route
- Loss %: the percentage of lost request-response pairs from this node
- Sent: the number of requests sent to this node
- Recv: the number of responses received from it
- Best: the minimum (best) delay time
- Avrg: the average delay time
- Worst: the maximum (worst) delay time
- Last: the delay time of the last received packet The important parameter is Loss, the percentage of packet loss from the node. WinMTR uses the same ICMP protocol as ping, tracert, pathping utilities. Losses when Loss = 5% or more may be a cause for concern.
Analysis and results.
Scenario 1: Packet losses of 30-50% on intermediate nodes. For example, the results show losses in the range of IP 217.161.68.33-217.161.68.34. According to the MTR check, there are packet losses only at some specified nodes of the backbone internet provider, Vodafone Group PLC. However, there are no packet losses on the actual service (server or website). We assume that the situation is related to overloaded channels of some European providers - Vodafone Group PLC, etc. We assume that internet providers are aware of this situation, but we do not have information about when they will resolve this issue. Perhaps the situation will change over the next few hours or days. It is also possible that this provider is conducting planned or unplanned technical work to change routing or install new equipment. Since this is a third party, we cannot influence their work. In this situation, we can advise you to try using a VPN or another device for connection (computer, laptop, phone) that uses a different provider, for which the packet route to your server may differ from your current one.
Scenario 3: Packet losses on end nodes. In case of packet losses on several end nodes and on the server (website), possible reasons include high server load, insufficient server resources, or DDoS on the site/server to bring it down. In such a case, checks need to be performed on the actual server. You can perform checks yourself or contact our support for assistance.
Scenario 3: Packet losses on one or more nodes. If, during the checks, packet loss occurs only on one node in the Loss column (e.g., 95%-100%), then it is likely that this provider has decided to protect its router from a DDoS attack and configured it not to respond to most ICMP requests. If there were indeed 95% losses, these losses would be reflected in subsequent jumps and in the Loss column after it, we would see not 0% but a value ranging from 85% to 95%, then these would be actual losses. However, during parallel checks of the site/server availability from other countries, they are accessible.
In this case, we assume that the situation is related to the blocking of the site by a backbone or regional internet provider, due to a complaint, for example, from Roskomnadzor. Since this is a third party, we cannot influence their work. If your domain is not in the Roskomnadzor database, you can contact them yourself to resolve the situation. In this situation, we also advise you to try using a VPN or another device for connection (computer, laptop, phone) that uses a different provider, for which the packet route to your server may differ from your current one. It is also possible to move the site to another domain name or try moving the site to a subdomain (if it is not blocked at the domain registrar level).
Conclusions. WinMTR trace only displays network-level devices, meaning these can be: servers, routers/routers, L3 switches with IP addresses configured on their interfaces, and servers. Devices at the channel and physical level of the OSI 7 model are not shown in the traces because they do not need IP addresses to function, although these devices and poor communication lines are usually the causes of losses in the communication channel.