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:

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

• Locations are cities closest to your users.
• Edge server IPs are from the Get Domain Details (DIG) tool results.

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 source	Multiple 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 your destination is a hostname, select the IP version and Port number you want to use for the test.

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

6. 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 > 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. Note that TCP could be less reliable; we recommend submitting another request for the ICMP packet type when TCP fails.
7. Click Submit.

Submit a request for Site Shield

Learn how to submit a Test Network Connectivity (MTR) request for a Site Shield hostname. Currently, ZAM hostnames are not supported.

1. Go to ☰ > SUPPORT > Edge Diagnostics.

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

3. Open the Site Shield tab.

4. Enter your Hostname protected by Site Shield.

   📘

   ZAM hostnames

   The tool doesn't support site shield hostnames that are zone apex mapped (ZAM) hostnames.

5. Follow the steps for the preferred option:

   1 source	Multiple 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. Note that TCP could be less reliable; we recommend submitting another request for the ICMP packet type when TCP fails.

7. Click Submit.

Results

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

Click your request’s row to check the results. If you see in the Actions column, it means, that your request could not be processed and you need to retry. If you submitted a request for TCP packet type and it failed, we recommend submitting another request for the ICMP type.

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.

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.

You may also see an empty table. This means that the Test Network Connectivity (MTR) tool was not able to find any hops. In this case, try resubmitting the request but with another packet type. Note that it may happen that the tool won't be able to get data because of server issues or network condition, for example firewall.

How do I diagnose an issue with the results?

Follow the decision tree to identify the issue.

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.