amazon server Down in trace route to our EC2 instance
below is a trace showing a request from our office to our EC2 instance. it dies at 52.93.28.78. our EC2 instance is at 54.86.96.175.
aws support states it's a 'freeip.amazon.com' ip address and they cannot support it. We believe it is down. How to report it? How to request service for a dead server?
Any suggestions would be very much appreciated.
Traceroute: Tracing route to 54.86.96.175 over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 2 ms 2 ms 2 ms 96-92-39-30-static.hfc.comcastbusiness.net [96.92.39.30]
3 12 ms 13 ms 13 ms 96.120.40.33
4 14 ms 11 ms 14 ms 96.110.113.85
5 15 ms 18 ms 17 ms be-79-ar02.pontiac.mi.michigan.comcast.net [69.139.255.77]
6 * * * Request timed out.
7 19 ms 24 ms 24 ms be-2212-pe12.350ecermak.il.ibone.comcast.net [96.110.33.214]
8 * * * Request timed out.
9 21 ms 25 ms 20 ms 150.222.212.31
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 43 ms 43 ms 42 ms 52.93.28.78
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace complete.
- Newest
- Most votes
- Most comments
It's not clear to me which server you think is "dead".
I can ping your EC2 instance (54.86.96.175) so it's definitely up and running. That the various router hops along the way don't respond (or "participate" if you like) in the traceroute process is not surprising - it's actually very common.
Traceroute works by sending packets with a lower TTL (Time-to-Live) then usual. The TTL is decremented by every router hop along the path; when it gets to zero what should happen is that the device that expired the packet (where TTL went to zero) emits a "Time Exceeded" ICMP packet and sends it back to the origin. Many devices don't do that (it's extra processing overhead). There could be other devices in the network that block those packets.
In any case, it's quite normal to see traceroute not work quite properly yet have connectivity to the end host - which you do in this case (at least for ICMP - ping).
after review of my notes, I am not certain the ping was successful from the office in question, but the resolve of host file works --leading me to believe that it was. another of our agents will respond back with a ping for me. thank you for any help in the interim.
Relevant content
- asked 7 months ago
- asked 7 months ago
AWS OFFICIALUpdated 8 months ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
in this case though. the server and all websites and services it is hosting cannot be reached nor ping from that location in fort gratiot only.
the traceroute is successful from a sister office and so is visiting the websites and services the ec2 is hosting.
we have an additional ip address on another subnet connected to that same ec2. trace route doesn't complete at hop 21. same 52.93.28.XXX subnet is last to touch it in the list.
we have placed a static host entry at the locations router and it resolves fine -- as the ec2 instance is fine, the route is where we have issue. DNS resolves as it should. just one route from one of our office locations. all other locations, that we have tested work as expected.
If putting a static entry in the hosts file fixes the problem then it's not routing - it's DNS.