Weird traceroute result

I had to change my Internet connection to a another (temporary) link, in order to be able to access my server.

I'll raise a support ticket regarding this problem.

@sufehmi:

I have problems accessing my Linode this morning, so I ran traceroute. It timed out :

traceroute to 66.160.141.215 (66.160.141.215), 30 hops max, 38 byte packets
 1  ipcop (192.168.0.1)  9.215 ms  2.745 ms  4.465 ms
 2  10.75.0.1 (10.75.0.1)  92.059 ms  28.557 ms  18.304 ms
 3  gsr01-pb.blueyonder.co.uk (62.30.192.33)  18.295 ms  16.074 ms  13.065 ms
 4  tele2-witt-pos.telewest.net (194.117.136.18)  21.136 ms  18.697 ms  13.327 ms
 5  ge-0-1-0.ipr1.lon2.uk.insnet.cw.net (195.66.226.21)  15.467 ms  58.505 ms  91.278 ms
 6  pos8-0.br1.nyc.he.net (216.218.200.101)  139.450 ms  83.521 ms  98.698 ms
 7  pos7-0.gsr12012.sjc.he.net (216.218.254.153)  168.660 ms  161.299 ms  164.548 ms
 8  pos1-2.gsr12416.fmt.he.net (64.71.128.182)  171.965 ms  238.072 ms  166.762 ms
 9  10.199.199.2 (10.199.199.2)  211.748 ms  159.599 ms  154.270 ms
10  * * *
11  * * *

But also it's a bit weird that the ninth result went into some sort of private network.

Is there anything I can do about it ?

Thanks,

Harry

For the record, I get a timed out hop after 64.71.128.182 when tracerouting to your server, but it then manages to get to the server:

> …

13 pos7-0.gsr12012.sjc.he.net (216.218.254.153) 157.543 ms 157.953 ms 158.852 ms

14 pos1-2.gsr12416.fmt.he.net (64.71.128.182) 157.232 ms 167.624 ms 158.240 ms

15 * * *

16 www.harrysufehmi.com (66.160.141.215) 166.451 ms 160.827 ms 157.089 ms

I get the same result on my own server, 66.220.1.230. I'm not seeing the 10.x.x.x address, though - I agree, it's weird that a traceroute would show that. It looks like some sort of routing issue at either Linode's end or HE themselves. Are you still getting the private IP in your traceroutes from the other connection?

@Ciaran:

For the record, I get a timed out hop after 64.71.128.182 when tracerouting to your server, but it then manages to get to the server:

Thanks for it Ciaran.

I trimmed my output though in the first post - actually I waited until traceroute finished (until the thirtieth loop), but still it can't reach my server.

> > …

13 pos7-0.gsr12012.sjc.he.net (216.218.254.153) 157.543 ms 157.953 ms 158.852 ms

14 pos1-2.gsr12416.fmt.he.net (64.71.128.182) 157.232 ms 167.624 ms 158.240 ms

15 * * *

16 www.harrysufehmi.com (66.160.141.215) 166.451 ms 160.827 ms 157.089 ms

I get the same result on my own server, 66.220.1.230. I'm not seeing the 10.x.x.x address, though - I agree, it's weird that a traceroute would show that. It looks like some sort of routing issue at either Linode's end or HE themselves. Are you still getting the private IP in your traceroutes from the other connection?

Unfortunately I can't do traceroute from this connection, so I can't compare it. But at least I can SSH from it.

Thanks again,

Harry

Some ISPs use 10.0.0.0/8 addresses internally. I remember @home did that extensively.

Please check your iptable rules – it looks to me like one of them is catching (from your console logs):

IN-internet:IN=eth0 OUT= MAC=fe:fd:42:a0:8d:d7:00:30:71:f0:1e:53:08:00 SRC=66.220.1.6 DST=66.160.141.215 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=31328 PROTO=UDP SPT=35832 DPT=33438 LEN=18

IN-internet:IN=eth0 OUT= MAC=fe:fd:42:a0:8d:d7:00:30:71:f0:1e:53:08:00 SRC=64.35.99.205 DST=66.160.141.215 LEN=38 TOS=0x00 PREC=0x00 TTL=1 ID=59217 PROTO=UDP SPT=59195 DPT=33456 LEN=18

I'm still checking into things, but I will ask HE about the blank/missing hop…

-Chris

Another good test to see if it is a route-wide routing problem, try tracing to IPs near yours (that is, if they have Linodes running on them and aren't blocking ICMP)…

-Chris

It looks okay now, traceroute is now able to reach my server, thanks; and indeed connectivity is stable now. I'll close the support ticket soon.

However, if I do traceroute from one of my linux box at home (in the same LAN), it will still time out. Go figure :roll:

Thanks,

Harry

Check the netmask on any/all of your eth0 aliases. Although, I guess that doesn't really make sense if your starting point for both working and non-working traces is from the same LAN…

-Chris

@caker:

Check the netmask on any/all of your eth0 aliases. Although, I guess that doesn't really make sense if your starting point for both working and non-working traces is from the same LAN…

wow… actually, I was just wondering to myself, you don't need to reply to that ;)

But thanks anyway - regarding that particular linux box, I can ping and access my Linode server from it, so I don't mind if traceroute doesn't work properly for now.

Thanks again,

Harry