I'm having trouble connecting to an Amazon EC2 Windows 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 – Windows implements a HOSTS file where host-to-IP mappings can be statically defined. On Windows operating systems this file is located in "%SystemRoot%\system32\drivers\etc\hosts", where %SystemRoot% is the environment variable that references the location of the Windows installation drive letter and folder. Windows HOSTS file entries use the following format:
        1.2.3.4    hostname
    Where 1.2.3.4 is the physical IP address used when referencing hostname.
    Default behavior for all versions of Windows is to check the HOSTS file before attempting other methods of host name resolution, such as DNS. Therefore, if the IP address assigned to a host name in the local HOSTS file of a Windows client is incorrect, the host name will resolve to the incorrect IP address until the HOSTS file entry is corrected or Windows network name resolution order is changed as described in How to change name resolution order on Windows 95 and Windows NT.

Note: The Microsoft KB article incorrectly states that "By default, Windows 2000 and later versions try to resolve a name through DNS before they try to resolve it through the earlier-version node-type configuration."

  • 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:

C:\WINDOWS\system32>ping www.amazon.com

Pinging www.amazon.com [205.251.242.54] with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

 

Ping statistics for 205.251.242.54:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

Many publicly accessible servers deprioritize incoming ICMP packets. As a result, it is not uncommon for a ping request to return a "Request timed out" response. 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 205.251.242.54 even though all ping requests timed out. If a different host name had been used, say www.bamazon.com, name resolution would fail and no ping requests would be attempted:
           C:\WINDOWS\system32>ping www.bamazon.com
           Ping request could not find host www.bamazon.com. Please check the name and try again.
  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 TCP port 80.
  3. If the ping request is successful and a reply is returned, verify that 4 replies were returned within a reasonable time (<250 ms). Use the -c switch to specify the number of ping requests. If fewer than 4 replies are returned or if the 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 -t switch.
  4. Does the IP address resolve to a hostname? To test address-to-hostname resolution, use the -a switch and specify the IP address of the destination. For example, the following ping request tests address-to-hostname resolution for one of the IP addresses associated with www.ubuntu.org:
           C:\WINDOWS\system32>ping -a 82.98.134.233
           Pinging hl231.dinaserver.com [82.98.134.233] with 32 bytes of data:
           Reply from 82.98.134.233: bytes=32 time=166ms TTL=49
           Reply from 82.98.134.233: bytes=32 time=184ms TTL=49
           Reply from 82.98.134.233: bytes=32 time=176ms TTL=49
           Reply from 82.98.134.233: bytes=32 time=165ms TTL=49
           Ping statistics for 82.98.134.233:
               Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
           Approximate round trip times in milli-seconds:
               Minimum = 165ms, Maximum = 184ms, Average = 172ms

    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 Windows tracert 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 tracert 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 tracert requests depend on responses to ICMP requests, some hops on the route may drop requests in favor of higher-priority network traffic.

The following output was created using the default Windows tracert command. A "Request timed out" message is returned in hops 1, 2, 3, and 15 in this example:

C:\Users\Administrator>tracert www.ubuntu.org

Tracing route to www.ubuntu.org [82.98.134.233]

over a maximum of 30 hops:

  1     *        *        *     Request timed out.

  2     *        *        *     Request timed out.

  3     *        *        *     Request timed out.

  4     1 ms    <1 ms    <1 ms  100.64.16.13

  5     1 ms     1 ms     1 ms  205.251.232.254

  6     2 ms     3 ms     2 ms  205.251.232.148

  7     9 ms     9 ms     9 ms  205.251.232.91

  8     9 ms     8 ms     8 ms  205.251.226.188

  9    10 ms     9 ms     9 ms  ae-14.r04.sttlwa01.us.bb.gin.ntt.net [129.250.201.169]

 10    10 ms     9 ms     7 ms  ae-6.r21.sttlwa01.us.bb.gin.ntt.net [129.250.5.44]

 11    75 ms    76 ms    91 ms  ae-3.r22.nycmny01.us.bb.gin.ntt.net [129.250.2.50]

 12   145 ms   145 ms   145 ms  ae-5.r22.londen03.uk.bb.gin.ntt.net [129.250.3.127]

 13   170 ms   168 ms   172 ms  ae-6.r01.mdrdsp03.es.bb.gin.ntt.net [129.250.4.138]

 14   171 ms   171 ms   168 ms  dinahosting-0.r01.mdrdsp03.es.bb.gin.ntt.net [62.73.183.78]

 15     *        *        *     Request timed out.

 16   176 ms   165 ms   179 ms  hl231.dinaserver.com [82.98.134.233]

Trace complete.

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 Windows tracert 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.

  • Tracetcp (http://simulatedsimian.github.io/tracetcp.html), provides ability to specify TCP ports for purposes of obtaining trace information. This is of particular use if several routers between a source and destination deprioritize or block ICMP altogether.
  • Winmtr (http://winmtr.net/), the Windows equivalent of the Linux mtr utility.

Amazon Elastic Compute Cloud, Windows, network troubleshooting, ping, tracert

In addition to using ping and tracert, 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 the following information:


Did this page help you? Yes | No

Back to the AWS Support Knowledge Center

Need help? Visit the AWS Support Center

Published: 2015-12-05
Updated: 2016-02-18