Strange traceroute result to VM in EC2, Singapore

Hi,

I have two internet connections and can reach the VM in EC2, Singapore over
either connection.

I am doing an experiment for which I traceroute to this VM from the two
different internet connections (to really get an idea of the number of hops
between my local machine and the VM over the 2 different connections)

I have attached the output of my two traceroute's.

While i am able to reach the exact VM when i am on one internet connection,
i am not able to do the same, when am over the other internet connection.

Both are broadband connections out of the same office premises.

Any idea what could be happening?

Thanks, Glen

No trace attached.

Ooops. The attachment was dropped last time. This time its inline:

When my traceroute works:

[image: Inline image 1]

When it doesnt:

[image: Inline image 2]

Thanks, Glen

Text or it never happened.

--p

You, sir, owe me some monitor cleaner. You also win the internets for today.

Really sorry. Didnt realize that this is a text-only forum.

When my traceroute to 52.74.124.136 works:

~$ traceroute 52.74.124.136
traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
1 xxxxxxx xxxxxxx 0.412 ms 0.472 ms 0.439 ms
2 xxxxxxx xxxxxxx 2.98 ms 2.971 ms 2.999 ms
3 xxxxxxx xxxxxxx 5.345 ms 5.546 ms 5.519 ms
4 xxxxxxx xxxxxxx 3.172 ms 3.051 ms 3.010 ms
5 if-6-2.tcore2.SVW-Singapore.as6543.net (180.87.37.14) 56.751 ms 56.285 ms
54.592 ms
6 180.87.15.206 (180.87.15.206) 73.468ms 66.993 ms 66.734 ms
7 203.83.223.58 (203.83.223.58) 43.737 ms 43.513 ms 44.029 ms
8 203.83.223.15 (203.83.223.15) 47.239 ms 46.382 ms 203.83.223.74
(203.83.223.74) 44.144 ms
9 203.83.223.231 (203.83.223.231) 44.431 ms 203.83.223.233 (203.83.223.233)
45.699 ms 46.158 ms
10 ec2-52-74-124-136.ap-southeast-1.compute.amazon.com (52.74.124.136)
44.067 ms 43.492 ms 43.499 ms

When it doesnt:

~$ traceroute 52.74.124.136
traceroute to 52.74.124.136 (52.74.124.136), 30 hops max, 60 byte packets
1 xxxxxxx xxxxxxx 23.272 ms 25.011 ms 26.072 ms
2 xxxxxxx xxxxxxx 27.058 ms 28.971 ms 29.999 ms
3 xxxxxxx xxxxxxx 33.025 ms 33.996 ms 38.822 ms
4 p38895.sgw.equinix.com (202.79.197.87) 78.964 ms 60.051 ms 83.010 ms
5 203.83.223.4 (203.83.223.4) 63.682 ms 64.610 ms 65.837 ms
6 203.83.223.17 (203.83.223.17) 67.271 ms 203.83.223.23 (203.83.223.23)
68.521 ms 203.83.223.17 (203.83.223.17) 70.526 ms
7 203.83.223.233 (203.83.223.233) 71.624 ms 72.805 ms 74.471 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

I find this bizzare because even when the traceroute doesnt work, I am
actually able to ping and access the machine.

I know that the VM responds to traceroutes, since it did respond to my
traceroute when i was on the other broadband network.

So i really fail to understand why the traceroute on the other network
failed.

Any pointers on this would be very helpful.

Thanks, GLen

the las hop reported in the 'fails' traceroute is an amazon ip
address, I suspect some miscarriage of packet-justice inside AWS is
happening. You asked them already I guess?

Presumably you're doing this from a Linux host. You might try these
flags to see what you get:

       -T, --tcp
            Use TCP SYN for probes

       -e, --extensions
              Show ICMP extensions (rfc4884). The general form is CLASS/TYPE: followed by a hexadecimal dump. The MPLS (rfc4950) is shown
              parsed, in a form: MPLS:L=label,E=exp_use,S=stack_bottom,T=TTL (more objects separated by / ).

and a good general reference for the netop:

  <http://cluepon.net/ras/traceroute.pdf>

John

Traceroute on Linux/Unix boxes is generally using UDP by default. Try
using ICMP, by adding the -I (capital i) option to traceroute:

traceroute -I 52.74.124.136