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).


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.