I'm having trouble connecting to an Amazon EC2 Linux instance. Are there tools for troubleshooting the network connection?

Connectivity problems between nodes of a TCP/IP network are usually the result of incorrect routing information caused by, but not limited to, the following:

  • Rogue DNS server(s) – If a client requests information from an unauthorized DNS server that is incorrectly configured, the information returned is not reliable.
  • Incorrect HOSTS file entries – Most operating systems implement a HOSTS file where host-to-IP mappings can be statically defined. On Linux operating systems this file is usually kept in /etc/hosts and has the following format:
        1.2.3.4    hostname
    Where 1.2.3.4 is the physical IP address that will be used when referencing hostname.
  • Hardware failure – If a DNS server has a hardware failure, the DNS records maintained by the DNS server(s) are not updated as expected, potentially causing incorrect host-to-IP mappings to be sent to clients.
  • Blocked TCP/IP ports – If a port required by an application layer protocol or service is blocked, network communications are blocked.
  • Incorrect client TCP/IP configuration – If a client is not configured correctly, the client can have varying degrees of connectivity problems. This can happen when a client is configured to use automatic TCP/IP configuration and is unable to retrieve configuration information or receives incorrect configuration information.

The ping utility sends an Internet Control Message Protocol (ICMP) packet from a client to the specified network name or IP address:

ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.amazon.com

PING www.amazon.com (54.239.19.16) 56(84) bytes of data.

--- www.amazon.com ping statistics ---

1 packets transmitted, 0 received, 100% packet loss, time 0ms

Many publicly accessible servers deprioritize incoming ICMP packets. As a result, it is not uncommon for a ping request to return a 100% packet loss statistic. When initiating a ping request, it is important to check the following:

  1. Does the ping request resolve the name to an IP address? For example, in the preceding example, the name www.amazon.com resolved to the IP address 54.239.19.16 even though no ping response was returned. If a different host name had been used, say www.bamazon.com, name resolution would fail and no ping requests would be attempted:
           ubuntu@ip-10-0-0-252:~$ sudo ping -c 1 www.bamazon.com
           ping: unknown host www.bamazon.com
  2. If the name resolves to an IP address, there is a good chance that the destination is accessible via another application layer protocol or service. For example, even if a ping request to www.amazon.com times out, connectivity to http://www.amazon.com typically succeeds because this destination is a web server that accepts browser requests over port 80.
  3. If the ping request is successful and a reply is returned, verify that replies were returned within a reasonable time (<250 ms). Use the -c switch to specify the number of ping requests. If less than one half of the specified ping requests are returned or if the average response time exceeds 250 ms, additional troubleshooting steps may be required. To specify the timeout for a ping request in milliseconds, use the -W switch. To continually ping the destination until stopped, use the -W switch with a value of 0; for example:
           sudo ping –W 0 www.ubuntu.org
    Press the Ctrl+C key combination to stop generating ping requests.
  4. Does the address resolve to a hostname? To test address-to-hostname resolution, use the Linux nslookup command and specify the IP address of the destination. For example, the following non-interactive mode nslookup request tests address-to-hostname resolution for one of the IP addresses associated with www.ubuntu.org:
           ubuntu@ip-10-0-0-252:~$ nslookup 82.98.134.233
           Server:      10.0.0.2
           Address:    10.0.0.2#53

           Non-authoritative answer:
           233.134.98.82.in-addr.arpa      name = hl231.dinaserver.com.

    Note that the response returned the name hl231.dinaserver.com, which is one of the load-balanced web servers handling requests for http://www.ubuntu.org.

For more information about the ICMP protocol, see Understanding the ICMP Protocol (Part 1) and Understanding the ICMP Protocol (Part 2).

The Linux traceroute utility identifies the path that is taken from a client node to a specified destination node and the time in milliseconds for each router identified in the path to respond to a request. By default, the traceroute utility uses a default maximum value of 30 hops; if the path between the client and destination requires more than 30 routers or hops, you can increase the maximum number of hops with the -h switch. Because traceroute requests depend on responses to ICMP requests, some hops on the route may drop requests in favor of higher-priority network traffic.

The following traceroute command was issued from an Amazon Web Services EC2 instance of Ubuntu Linux 14.04. The arguments -T -p 80 -n perform a TCP-based trace on port 80 and return IP addresses rather than hostnames. The Linux traceroute option to specify a TCP-based trace rather than relying on ICMP is useful because most Internet devices deprioritize ICMP-based trace requests. The Linux traceroute option to retrieve only IP addresses is useful when the hostnames that are returned are wrong or misleading:

ubuntu@ip-10-0-0-252:~$ sudo traceroute -T -p 80 -n www.ubuntu.org

traceroute to www.ubuntu.org (82.98.134.233), 30 hops max, 60 byte packets

1  * * *

2  * * *

3  * * *

4  100.64.16.75    1.176 ms

   100.64.16.129   1.059 ms

   100.64.16.209   0.923 ms

5  54.239.48.178   3.958 ms

   54.239.48.184   1.200 ms

   54.239.48.178   1.805 ms

6  205.251.232.204 1.198 ms

   205.251.232.154 1.793 ms

   205.251.232.142 1.549 ms

7  205.251.232.76  6.341 ms

   205.251.232.78  6.546 ms

   205.251.232.76  7.611 ms

8  205.251.226.230 6.220 ms  7.418 ms

   205.251.226.192 8.096 ms

9  198.104.202.189 9.178 ms

   129.250.201.165 9.006 ms

   198.104.202.181 9.001 ms

10 129.250.5.44    8.746 ms

   129.250.5.48    8.912 ms

   129.250.5.44    27.57 ms

11 * 129.250.2.50  86.83 ms  *

12 129.250.3.127   153.9 ms  144.401 ms  161.867 ms

13 129.250.4.138   176.5 ms  165.466 ms  181.772 ms

14 62.73.183.78    166.5 ms  166.834 ms  169.297 ms

15 * * *

16 82.98.134.233   177.9 ms  164.656 ms  169.607 ms

A few timed-out requests is typically not an issue to be concerned about. Instead, watch for packet loss to the destination or in the last hop of the route. Packet loss that accumulates over several hops can also indicate a problem.

Important: When troubleshooting network connectivity using the traceroute utility, it is often beneficial to run the command in both directions, from the client to the server and then from the server back to the client. If there are significant latency discrepancies in either path, consider reviewing the excellent article Traceroute (http://cluepon.net/ras/traceroute.pdf), by Richard A Steenbergen. The author goes into considerable depth describing the intricacies of proper trace analysis.

The Linux mtr command provides continually updated output which allows you to analyze network performance over time.

Note: If mtr is not installed on Ubuntu Linux, get it by running the following command:
       sudo apt-get install mtr

For a list of mtr command-line options, run mtr -h

ubuntu@ip-10-0-0-252:~$ mtr www.ubuntu.org

                                  My traceroute  [v0.85]

ip-10-0-0-252 (0.0.0.0)                                            Sat Nov 22 18:54:13 2014

Keys:  Help   Display mode   Restart statistics   Order of fields  quit

                                                    Packets               Pings

Host                                             Loss%   Snt   Last   Avg  Best  Wrst StDev

 1. ???

 2. ???

 3. ???

 4. 100.64.16.139                                 0.0%    64    2.4   2.3   0.6  32.6   5.4

 5. 54.239.48.186                                 0.0%    64    0.9   2.2   0.8  19.8   4.0

 6. 205.251.232.210                               0.0%    64    1.5   2.4   0.7  17.7   3.7

 7. 205.251.232.76                                0.0%    64   37.6  11.1   6.1  47.2   7.9

 8. 205.251.225.165                               0.0%    64   14.2   7.1   5.6  28.4   4.2

 9. ae-8.r05.sttlwa01.us.bb.gin.ntt.net           0.0%    63    7.7   9.3   7.3  26.7   4.9

10. ae-7.r21.sttlwa01.us.bb.gin.ntt.net           0.0%    63    7.4  10.2   7.2  35.4   6.1

11. ae-3.r22.nycmny01.us.bb.gin.ntt.net          22.2%    63   73.7  82.2  73.1 101.7   8.8

12. ae-5.r22.londen03.uk.bb.gin.ntt.net           0.0%    63  153.1 159.2 142.1 223.3  17.7

13. ae-6.r01.mdrdsp03.es.bb.gin.ntt.net           0.0%    63  174.9 176.1 165.4 193.2   6.3

14. dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net  0.0%    63  174.6 182.7 164.1 263.1  21.3

15. ???

16. hl231.dinaserver.com                          0.0%    63  175.5 178.4 166.1 200.4   7.4

 

mtr also provides a --report option that summarizes the results of sending 10 ping packets to each hop:

ubuntu@ip-10-0-0-252:~$ mtr --report www.ubuntu.org

Start: Sat Nov 22 19:06:10 2014

HOST: ip-10-0-0-252               Loss%   Snt   Last   Avg  Best  Wrst StDev

  1.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

  2.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

  4.|-- 100.64.16.139              0.0%    10    0.8   0.8   0.5   1.4   0.0

  5.|-- 54.239.48.186              0.0%    10    1.0   1.1   0.8   2.0   0.0

  6.|-- 205.251.232.210            0.0%    10    0.8   1.3   0.8   2.9   0.5

  7.|-- 205.251.232.76             0.0%    10    6.1   8.3   6.1  18.2   3.4

  8.|-- 205.251.225.165            0.0%    10    6.3   5.8   5.6   6.3   0.0

  9.|-- ae-8.r05.sttlwa01.us.bb.g  0.0%    10    7.5   7.5   7.4   7.6   0.0

 10.|-- ae-7.r21.sttlwa01.us.bb.g  0.0%    10    8.8  10.2   7.3  33.4   8.1

 11.|-- ae-3.r22.nycmny01.us.bb.g  0.0%    10   73.8  78.2  73.3 108.2  10.9

 12.|-- ae-5.r22.londen03.uk.bb.g 10.0%    10  151.6 154.8 145.4 169.5   6.5

 13.|-- ae-6.r01.mdrdsp03.es.bb.g  0.0%    10  175.0 174.1 165.7 178.3   3.5

 14.|-- dinahosting-0.r01.mdrdsp0  0.0%    10  173.8 172.2 165.1 176.4   4.3

 15.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

 16.|-- hl231.dinaserver.com      10.0%    10  183.1 177.9 168.1 192.4   7.5

Note: Because the path between nodes on a TCP/IP network can change when the direction is reversed, it is important to obtain trace route results in both directions.

Amazon Elastic Compute Cloud, Linux, network troubleshooting, ping, traceroute, tracert, mtr

In addition to using ping, traceroute, and mtr, consider one of the many publicly available utilities provided by Internet service providers as "looking glass" servers. For more information, see the Wikipedia Looking Glass Server article.

For more information about troubleshooting TCP/IP issues, see Traceroute.

What are the most commonly used Linux commands?


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center.