SIGN IN / UP
    opened image

    Service availability check via MTR

     

    MTR is a utility for checking the availability of a server or site, showing the route of packets to the service and losses at intermediate nodes.  MTR is a simple network (service, server, site) diagnostic tool from the command line or shell (WinMTR). It combines the functionality of the traceroute and ping programs. Similar to traceroute, the mtr command prints information about the route, shows a list of hosts, routers through which the packet passes. However, mtr shows more information than traceroute: it determines the path to the remote server, displays the percentage of response and loss, and the response time of all network hops in the route between your local system and remote servers. When should it be applied? When packet loss is suspected. By MTR, you can see if there are packet losses, check on which IP node the packets are lost, after which you can find and determine the regional or backbone provider through which this situation arose.

    Availability check.
    First, we will perform a parallel check of the availability of a site or server from different countries of the world.

        Checking on Windows OS.
    If there are situations with an RDP connection such as: brakes, freezes, lags, freezes and periodic ejection from the server, a break or a bad RDP connection, you need to check through WinMTR, because. there may be packet loss on the route from you to the server. WinMTR displays information about the route, shows a list of routers through which the packet passes. Run the WinMTR utility for Windows on your computer.
    Download: https://sourceforge.net/projects/winmtr/
    Where in the program, for verification, specify the IP address of your server or domain name (only the site name without www or https). After at least 1000 packets have been sent, save the result by clicking Export Text. Please provide technical support in the ticket system with the result of the check to the server to analyze the situation. Or you can analyze it yourself according to the recommendations below.

         Checking on Linux OS.
    If you are using Linux, then run the command:

    mtr --report -n -c 1000 IP

    Where IP is your IP or domain name.  After execution, save a screenshot with the results of the command execution, and attach it to the technical support ticket request for analysis by us. Or try to analyze yourself.

     
    Explanation of WinMTR values and results

    •      Hostname - domain name or host IP address
    •      Nr - serial number of the node in the route
    •      Loss % - percentage of lost requests-responses from this node
    •      Sent - requests sent to this node
    •      Recv - replies received from him
    •      Best - the smallest (best) delay time
    •      Avrg - average delay time
    •      Worst - longest (worst) delay time
    •      Last - delay time of the last received packet

    The parameter is important to us - Loss, the percentage of lost packets from the node. WinMTR uses the same ICMP protocol as the ping, tracert, pathping utilities. Reasons for concern may be losses when Loss = 2-5% or more.

    Analysis and results.

    Option 1. Packet loss 30-50% at intermediate nodes.
    For example, the results show that there were losses in the IP range 217.161.68.33-217.161.68.34. Then, according to the check performed through MTR, there are packet losses only on some of the specified nodes at the backbone Internet provider, this is Vodafone Group PLC. But on the service itself (server or site) there are no packet losses. We believe that the situation is related to the overloaded channels of some providers in Europe - Vodafone Group PLC and others. We believe that ISPs are aware of this situation, but we do not have information when they will resolve this issue. Perhaps in a few hours or days the situation will change. Perhaps this provider is carrying out technically planned or unscheduled work to change the routing or install new equipment. Because this is a third party, we cannot influence their work. In this situation, we can advise you to try using a VPN or another connection device (computer, laptop, phone) that uses a different provider, for which the packet route to your server may differ from your current one.

    Option 3: Packet loss on end nodes.
    With high losses on several end nodes and on the server (site), the possible reasons are high server load, lack of server resources, or DDoS on the site / server in order to put it down. In this case, you need to perform checks on the server itself. You can perform the checks yourself or contact our technical support for help.


    Option 3: Packet loss on one or more hosts.
    If you perform packet loss checks on the Loss column, only one host has losses (for example, 95% -100%), then this provider probably decided to protect its router from DDoS attacks and configured it so that it does not respond to most of the ICMP requests. If there were really 95% losses, then these losses would be reflected in subsequent jumps and in the Loss column, after it, we would see not 0%, but a value with a spread from 85% to 95%, then these would really be losses. But with a parallel check of the availability of the site / server from other countries, they are available.

    Option 4: Not available in only one region.

    In this case, we believe that the situation is related to technical work and / or blocking of the site by the backbone or regional Internet provider. In this situation, we can also advise you to try using a VPN or another connection device (computer, laptop, phone) that uses a different provider, for which the route to your server may differ from your current one.

    Conclusions.
    WinMTR tracing displays only network level devices, that is, they can be: servers, routers / routers, L3 switches, on the interfaces of which IP addresses and servers are registered. There are no link and physical layer devices of the OSI 7 model in the trace, since they do not need IP addresses to work, although these devices, as well as low-quality communication lines, are usually the causes of loss in the communication channel.