Test Network Connectivity (MTR)

The Test Network Connectivity (MTR) tool uses MTR to provide information about the packets’ loss and latency between a source (location, edge server IP, or Site Shield map) and a remote destination (hostname or IP). The results show the route, number of hops, and time that Internet traffic packets took to reach the destination.

You can use this tool to verify:

  • The connectivity between source and destination.
  • Packets loss.
  • Network latency. If and where network delays occur.

Supported packet types

You can submit the request for two types of packets send as test:

  • ICMP. The Internet Control Message Protocol, used by default. These packets don’t carry any application data, just information about other protocols. In most cases, submitting a request with this packet type is enough to diagnose issues and start troubleshooting.
  • TCP. Transmission Control Protocol. These packets carry actual application data. The difference between TCP and ICMP is that the ICMP traffic for MTR may be subjected to ICMP traffic rate limiting by your service provider and firewalls.

Submit a request

Learn how to submit a request in the Test Network Connectivity (MTR) tool. To submit a request for GTM, check Submit a request for GTM.

📘

Currently, Test Network Connectivity (MTR) doesn't support requests for origin hostnames. We're working on enabling these requests soon.

There are three combinations in which you can submit the request:

CombinationDiagram
1 source and 1 destination.
This verifies a request from a location or an edge server IP request the destination.
1 URL for IPs1 URL for IPs
Multiple sources and 1 destination.
This verifies if a request from different locations or edge server IPs reaches the destination and if there are any delays on the way.
1 URL for Locations1 URL for Locations
1 source and multiple destinations.
This verifies if a request from a location or an edge server IP reaches multiple destinations and if there are any delays on the way.
URLs for IPURLs for IP

The source is either a location or an edge server IP and the destination is a hostname or an IP address, where:

To submit a request:

  1. Go to > SUPPORT > Edge Diagnostics.

  2. In the side menu, select > Test Network Connectivity (MTR).

  3. Follow the steps for the preferred option:

    1 sourceMultiple sources
    a) Select whether you want the source of the route to be specific Locations or Edge server IPs. Enter one value.
    b) Select whether you want the destination of the route to be specific Hostnames or Destination IPs. Enter up to 10 values.
    a) Select whether you want the source of the route to be specific Locations or Edge server IPs. Enter up to 10 values.
    b) Select whether you want the destination of the route to be specific Hostnames or Destination IPs. Enter one value.
  4. If you want to run MTR using the Site Shield map, select the Run from site shield map checkbox. When selected, Edge Diagnostics uses the entered location or edge server IP to find its Site Shield map and runs the tool using the map.

  5. If your destination is a hostname, select the IP version and Post number you want to use for the test.

  6. Select the Packet type to use during the test, either TCP or ICMP. For more details, check Supported packet types.

  7. Click Submit.

Submit a request for GTM

Learn how to submit a Test Network Connectivity (MTR) request for GTM hostnames and Test IP as the source and Target IP as the destination.

  1. Go to > SUPPORT > Edge Diagnostics.
  2. In the side menu, select Tools iconTools icon > Test Network Connectivity (MTR).
  3. Open the GTM hostnames tab.
  4. For Source:
    1. Select a GTM hostname you want to make the test for.
    2. Select Test IP to use as the source of the route.
  5. For Destination, select Target IP of the route.
  6. Select Packet type to use during the test, either TCP or ICMP. For more details, check Supported packet types.
  7. Click Submit.

Submit a request for Site Shield

Learn how to submit a Test Network Connectivity (MTR) request for a Site Shield hostname.

  1. Go to > SUPPORT > Edge Diagnostics.

  2. In the side menu, select Tools iconTools icon > Test Network Connectivity (MTR).

  3. Open the Site Shield tab.

  4. Enter your Hostname protected by Site Shield.

  5. Follow the steps for the preferred option:

    1 sourceMultiple sources
    a) Select whether you want the source of the route to be specific Locations or Edge server IPs. Enter one value.
    b) Enter up to 10 Destination IPs.
    a) Select whether you want the source of the route to be specific Locations or Edge server IPs. Enter up to 10 values.
    b) Enter one Destination IPs.
  6. Select Packet type to use during the test, either TCP or ICMP. For more details, check Supported packet types.

  7. Click Submit.

Results

Edge Diagnostics adds requests to the Recent requests table. GTM requests have the GTM label. Click Username iconUsername icon in the table's corner to see only your requests.

Click your request’s row to check the results. If you see Wrong iconWrong icon in the Actions column, it means, that your request could not be processed and you need to retry.

MTR response

The results of the Test Network Connectivity (MTR) tool are displayed as a table with details about each packet.
Each line of the report represents a hop - journey between one point and another - of a packet between the source and the destination of your request.

TagDescription
Loss%Percentage of packets lost at the hop. The expected result is 0%. All non-zero values are highlighted.
SntNumber of packets sent.
LastLatency of the last packet sent, in milliseconds.
AvgAverage latency of all packets, in milliseconds.
BestBest round trip time of a packet to a host, in milliseconds.
WrstWorst round trip time of a packet to a host, in milliseconds.
StDevStandard deviation of latency to a host.

Instead of the host name and its IP address on the packets route you may see ???. Hostnames are results of the reverse DNS lookup request on the host’s IP address. The ??? means that no additional information about the route could be gathered.

How do I diagnose an issue with the results?

Follow the decision tree to identify the issue.
MTR decision treeMTR decision tree

Packets loss

All Loss% values should be 0. If a value on a host is different from 0 there are two possible issues:

  • There is a rate limit of the ICMP traffic from a service provider. Applies only if you run the request with the ICMP packet type. The hop is most likely affected by the ICMP rate limiting, if only one hop shows the loss and the subsequent hop shows 0%.
  • There is a real packet loss. If the loss affects more than one hop, there may be packets loss occurring on the route.
    For ICMP packets the loss may be accompanied by the ICMP rate limiting.

Network latency

Network latency is the time it takes the packets to reach its destination and come back to the source. The latency depends not only on the host's connections but also their physical distance.
The latency may differ between hops but the increase should be consistent and linear. To verify if the results show any issues it’s good to compare them with the correct results.

If the latency values are much higher only for one host but the packets still reach their destination, it means that either there is a problem with the router of the next host or the distance between these two routers, source and destination, is significant.

If the high latency values appear on multiple hosts, but you clearly see an increase between the two of them, it’s very likely that there’s a problem with the router of the host with the first high latency value.

Network latency can be also affected by the ICMP rate limiting. If you see latency increase on one host and decrease for the next host, you may suspect that the spike was caused by the limiting. It applies only for requests submitted with the ICMP packets.

Timeout

Timeouts are usually represented as ??? instead of the hostname. They don’t necessarily imply packets loss or latency. If packets still reach the final destination, timeout may indicate packets being dropped by routers to improve the quality of service. If the packets didn’t reach the final destination, there may be a problem with the Internet Service Provider (ISP) router configuration.


Did this page help you?