traceroute from 2 different environments is giving different results. One is passed succesfully, the other one failed. I don't believe that would be our own switch/router - otherwise I would not be able to get in from amazon
Any idea why?
GOOD: (from amazon ec2 instance, linux)
[ec2-user@devops rxprep_php]$ traceroute hg.saritasa.com
traceroute to hg.saritasa.com (208.122.225.186), 30 hops max, 60 byte packets
1 ec2-50-112-0-200.us-west-2.compute.amazonaws.com (50.112.0.200) 0.623 ms 0.790 ms 0.770 ms
2 205.251.232.62 (205.251.232.62) 0.869 ms 0.851 ms 0.874 ms
3 205.251.232.140 (205.251.232.140) 9.020 ms 8.990 ms 0.972 ms
4 205.251.232.91 (205.251.232.91) 19.642 ms 205.251.232.89 (205.251.232.89) 19.945 ms 19.870 ms
5 205.251.226.178 (205.251.226.178) 19.715 ms 205.251.226.224 (205.251.226.224) 19.531 ms 205.251.225.163 (205.251.225.163) 13.149 ms
6 ae-14.r04.sttlwa01.us.bb.gin.ntt.net (129.250.201.169) 13.835 ms ae-13.r04.sttlwa01.us.bb.gin.ntt.net (129.250.201.165) 13.981 ms ae-8.r04.sttlwa01.us.bb.gin.ntt.net (198.104.202.189) 20.264 ms
7 ae-6.r20.sttlwa01.us.bb.gin.ntt.net (129.250.5.42) 45.034 ms ae-7.r20.sttlwa01.us.bb.gin.ntt.net (129.250.5.46) 51.497 ms 13.453 ms
8 ae-5.r21.snjsca04.us.bb.gin.ntt.net (129.250.3.39) 43.423 ms 30.370 ms 37.342 ms
9 ae-0.r20.snjsca04.us.bb.gin.ntt.net (129.250.2.96) 31.042 ms 36.866 ms 30.529 ms
10 ae-4.r21.lsanca03.us.bb.gin.ntt.net (129.250.6.10) 53.771 ms 52.657 ms 45.189 ms
11 ae-2.r05.lsanca03.us.bb.gin.ntt.net (129.250.5.86) 48.797 ms ae-4.r21.lsanca03.us.bb.gin.ntt.net (129.250.6.10) 52.063 ms 57.826 ms
12 10g.ntt.lax01.xfernet.net (198.172.90.2) 40.450 ms 47.377 ms ae-2.r05.lsanca03.us.bb.gin.ntt.net (129.250.5.86) 50.988 ms
13 pc4.ds1.lax01.xfernet.net (67.43.160.70) 39.603 ms 10g.ntt.lax01.xfernet.net (198.172.90.2) 42.272 ms pc4.ds1.lax01.xfernet.net (67.43.160.70) 39.431 ms
14 ge-50.ar8.lax01.xfernet.net (67.43.160.134) 41.007 ms 40.796 ms 40.983 ms
15 ge-50.ar8.lax01.xfernet.net (67.43.160.134) 42.412 ms 208.122.225.186 (208.122.225.186) 43.084 ms !X 47.612 ms !X
16 208.122.225.186 (208.122.225.186) 40.778 ms !X 40.278 ms !X 40.759 ms !X
[ec2-user@devops rxprep_php]$
BAD: (from local mac, through cox.net)
traceroute 208.122.225.186
traceroute to 208.122.225.186 (208.122.225.186), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 150.454 ms 2.254 ms 1.176 ms
2 10.71.96.1 (10.71.96.1) 9.066 ms 8.837 ms 7.916 ms
3 ip68-4-11-190.oc.oc.cox.net (68.4.11.190) 10.616 ms 10.308 ms 9.094 ms
4 ip68-4-11-95.oc.oc.cox.net (68.4.11.95) 13.825 ms
ip68-4-11-231.oc.oc.cox.net (68.4.11.231) 10.319 ms
ip68-4-11-95.oc.oc.cox.net (68.4.11.95) 10.127 ms
5 ip68-4-11-230.oc.oc.cox.net (68.4.11.230) 11.533 ms
ip68-4-11-94.oc.oc.cox.net (68.4.11.94) 8.890 ms
ip68-4-11-230.oc.oc.cox.net (68.4.11.230) 11.588 ms
6 langbprj02-ae2.rd.la.cox.net (68.1.1.19) 14.186 ms 11.401 ms 11.799 ms
7 ethernet11-1.csr1.lax2.gblx.net (159.63.23.21) 14.444 ms 14.192 ms 11.811 ms
8 ae12-90g.scr4.lax1.gblx.net (67.17.75.17) 11.888 ms
ae14-90g.scr3.lax1.gblx.net (67.16.162.21) 12.878 ms
ae12-90g.scr4.lax1.gblx.net (67.17.75.17) 12.678 ms
9 e5-1-40g.ar6.lax1.gblx.net (67.17.111.65) 11.779 ms * 137.418 ms
10 10g.glbx.lax01.xfernet.net (64.208.170.38) 11.817 ms 12.781 ms *
11 pc4.ds1.lax01.xfernet.net (67.43.160.70) 120.354 ms 11.536 ms 12.486 ms
12 ge-50.ar8.lax01.xfernet.net (67.43.160.134) 14.364 ms * 15.378 ms
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * po2.ar4.lax1.gblx.net (67.16.132.214) 15.285 ms
30 * * *
31 * po2.ar4.lax1.gblx.net (67.16.132.214) 20.602 ms *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * po2.ar4.lax1.gblx.net (67.16.132.214) 15.628 ms
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
47 * * *
48 * * *
49 * * *
50 * * *
51 * * *
52 * * *
53 * * *
54 * * *
55 * * *
56 * * *
57 * * *
58 * * *
59 * * *
60 * * *
61 * * *
62 * * *
63 * * *
64 * * *
In fact both of these traceroutes fail (albeit in different fashion)
First of all the first trace is not successfully finished. It just tells you that some wise admin has decided to block communications to the host (!X means "communication adminis‐tratively prohibited").
The second trace seems to not be able to tell you a definitive answer which is usually indication that some wiseass admin has decided to drop ICMP at some point.
Judging from both the traces i would say there are at least 2 asymmetric streches while you are trying to reach your target. It is also known that depending on where you come from you can very easily be routed in some specific way. Although it is a bit troubling to see the difference in traceroutes it is not unexpected (especially since the first one says in the end somebody is actively refusing to serve the connection).