Microsoft tracert wtf
-
For some reason, Microsoft's tracert has a wtf in it. It appears to take a location's IP from what it says it is rather than what its actual Internet IP is.
Check out hop 14 between my ISP and bengoodger.com (the chief engineer of Firefox's site).
1 <1 ms <1 ms <1 ms 192.168.1.1
2 21 ms 51 ms 13 ms 10.1.0.1
3 9 ms 9 ms 13 ms c-24-56-220-113.chrlmi.cablespeed.com [24.56.220.113]
4 16 ms 22 ms 15 ms POS2-2.GW1.DET5.ALTER.NET [157.130.111.221]
5 15 ms 13 ms 13 ms 0.so-0-0-0.CL1.DET5.ALTER.NET [152.63.69.118]
6 21 ms 25 ms 19 ms 0.so-3-0-0.XL1.CHI2.ALTER.NET [152.63.64.121]
7 20 ms 21 ms 23 ms 0.so-6-1-0.BR6.CHI2.ALTER.NET [152.63.64.49]
8 36 ms 44 ms 42 ms at&t-oc48-private [204.255.174.10]
9 39 ms 36 ms 81 ms tbr2-p012201.cgcil.ip.att.net [12.123.6.38]
10 38 ms 37 ms 42 ms tbr2-cl3641.phlpa.ip.att.net [12.122.10.94]
11 37 ms 43 ms 36 ms gbr1-p80.phlpa.ip.att.net [12.122.12.106]
12 50 ms 38 ms 37 ms gar1-p360.phlpa.ip.att.net [12.123.137.21]
13 55 ms 54 ms 63 ms 12.118.191.18
14 54 ms 52 ms 61 ms 192.168.1.202
15 57 ms 60 ms 59 ms bengoodger.com [216.92.115.12]
-
Looks like a router screwed up.. but somehow the data got to point B anyway..
I ran my own Traceroute from a unix system:traceroute to bengoodger.com (216.92.115.12), 30 hops max, 40 byte packets
1 centralplexus (10.0.0.1) 0.275 ms 0.234 ms 0.225 ms
2 64.230.197.16 (64.230.197.16) 193.504 ms 239.145 ms 189.424 ms
3 dis8-hamilton14_Vlan101.net.bell.ca (64.230.236.229) 182.073 ms 175.883 ms 176.873 ms
4 core2-hamilton14_GE2-0.net.bell.ca (64.230.236.249) 169.060 ms 156.207 ms 189.217 ms
5 core1-toronto12_POS6-1.net.bell.ca (64.230.203.109) 165.578 ms 169.948 ms 155.944 ms
6 core3-toronto12_POS0-1.net.bell.ca (64.230.242.194) 94.400 ms 113.608 ms 111.320 ms
7 core1-chicago23_pos13-0-0.net.bell.ca (64.230.147.18) 133.562 ms 83.808 ms 93.338 ms
8 bx4-chicago23_POS3-0.net.bell.ca (64.230.203.50) 96.072 ms 68.746 ms 81.791 ms
9 rtp629573rts (64.230.186.138) 93.858 ms 72.009 ms 84.477 ms
10 so7-0-0-622M.ar2.CLE1.gblx.net (67.17.68.126) 119.746 ms 121.160 ms 93.871 ms
11 PAIR-NETWORKS.ge-3-2-0.ar2.cle1.gblx.net (146.82.33.170) 115.271 ms 120.444 ms 134.494 ms
12 192.168.1.202 (192.168.1.202) 131.622 ms 103.779 ms 133.069 ms
13 bengoodger.com (216.92.115.12) 138.192 ms 143.385 ms 155.960 ms
it isn't traceroute
-
not a wtf,
it's normal to see 1918 space in traceroutes
-
Actually, I think that there's a possibility that this is right, or at least it is possible.
Imagine two networks, A (12.118.*) and B (216.92.*), both connected to the internet, but also linked via a private network using the 192.* range. The net connection to network B goes down. Routers do their magic, and you can still connect to network B, albeit over the private network between A and B.
The router you then see on hop 14 is the one sitting between the two that only has an IP address in the 192.* range,and it rightly reports itself as that. What else could it report itself as?
-
You don't need a global address to be a router. The IP addresses in a IP packet are not touched by routers, they only change the link level MAC addresses to forward the packet to the next router. Thence, they only need to know the MAC address of their neighbours, and as such, private network addresses are perfectly sufficient for routers.
[quote user="powerlord"]It appears to take a location's IP from what it says it is rather than what its actual Internet IP is.[/quote]I'm not at all sure how ICMP packets are routed through the internet, but they are probably similar to IP in that they have a source and a destination IP address (plus the first 64 bits of the origional data, containing the TCP port etc). So what else does tracert have to go on than the source address field of the ICMP reply packet? And that 192.168.x.x is probably all that router has for an ip address, it's it's "actual" IP address.
-
The ICMP packets containing the response contain the router's own idea of its IP address. If it's behind a NAT, it has no way of knowing what address will be seen the other side of the NAT.
-
Hmm, this is interesting...
It seems reasonable for a router to only be accessible via a private network,
thus giving the router's private ip in the traceroute.
However, does anyone know how he managed to get the ping results?
By my understanding, the ping packets sent to 192.168.1.202 should have
been routed to his local subnet, so unless there is a local .202 (with a slow ping),
the ping should have failed.Why am I wrong?
Harun
-
[quote user="aihtdikh"]
Hmm, this is interesting...
It seems reasonable for a router to only be accessible via a private network,
thus giving the router's private ip in the traceroute.
However, does anyone know how he managed to get the ping results?
By my understanding, the ping packets sent to 192.168.1.202 should have
been routed to his local subnet, so unless there is a local .202 (with a slow ping),
the ping should have failed.Why am I wrong?
Harun
[/quote]
IIRC
tracert doesn't try to actually ping the router itself but rather
the remote host, but increasing the TTL (time to live) on the ping each
time so that the ping gets one step further along the route
beforereaching the limit. the router that it dies on then replies with
an error.TTL=1 - first router along the route replies
TTL=2 - second router along the route replies
.......
TTL=n, remote host replies.
-
Ooh wow, thanks! I hadn't thought of that! :)
Harun
-
The first two hops show non-routable IPs. Why shouldn't the 14th?
-
[quote user="RFC 1918"]Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error.[/quote]
So it's not absolutely forbidden (and that RFC's a BCP anyway, not Standards Track) but it is discouraged.
-
[quote user="merreborn"]
The first two hops show non-routable IPs. Why shouldn't the 14th?
[/quote]
The first two hops have routable IPs on their other interfaces: 24.56.x.y and 24.56.x.1 (anonymized so you can't figure out my IP).
