Traceroute is a utility that allows one (approximately) to determine the ROUTE (sequence of routers) a flow takes ``from here to there''. Traceroute send a sequence of UDP packets with TTL 1, 2, 3, etc to the destination, and thus gets ``TTL expired'' ICMP error messages back from the router 1, 2, 3, etc hops in the direction of the destination. For security reasons, NJIT has disabled traceroute from inside NJIT to outside NJIT, as well as traceroute from outside NJIT to inside NJIT. ---- bloch-53 fall02>: traceroute ftp.eu.uu.net traceroute: Warning: ftp.eu.uu.net has multiple addresses; using 195.129.111.8 traceroute to ftp.eu.uu.net (195.129.111.8), 30 hops max, 40 byte packets 1 128.235.204.6 (128.235.204.6) 0.535 ms 0.439 ms 0.407 ms 2 * * * 3 * * * 4 ^C bloch-54 fall02>: We see that for every TTL level 1, 2, 3, ... three packets are sent and ``returns'' (of the ICMP error messages) are timed. However, at TTL level 2 or larger, there are no returning error messages. ---- There is a large number of ``public'' traceroute sites. Go to Google and search for ``traceroute''. I had a quick look at a few. ---- http://visualroute.visualware.com/ Comment: Makes it possible to see the geographic location of both the starting point (Dulles, VA) and the endpoint of the search. Nice visual output. But I could not get a hardcopy of the output. Does not tell me size of packets. ---- http://www.opus1.com/www/traceroute.html The following (opus1) allowed me (with some trouble) to get a hardcopy of the output, but not of the original commandline. ``visualroute'' above shows that opus1 is located in Tucson, Arizona. Opus1 seems not to allow packets of other than 40 bytes. opus1 gives the following output (example): traceroute to ftp.eu.uu.NET (195.129.111.8), 30 hops max, 40 byte packets 1 66-162-41-17.gen.twtelecom.net (66.162.41.17) 1474.615 ms 2 66-162-41-1.gen.twtelecom.net (66.162.41.1) 1476.568 ms 3 216-136-127-9.gen.twtelecom.net (216.136.127.9) 1474.615 ms 4 core-02-so-0-0-0-0.lsag.twtelecom.net (168.215.53.73) 1483.403 ms 5 tran-02-ge-0-3-0-0.lsag.twtelecom.net (168.215.54.102) 1485.356 ms 6 sl-gw15-ana-0-1.sprintlink.net (144.232.192.33) 1490.239 ms 7 sl-bb22-ana-3-3.sprintlink.net (144.232.1.217) 1491.215 ms 8 sl-bb20-ana-15-0.sprintlink.net (144.232.1.178) 1491.216 ms 9 sl-bb24-sj-10-0.sprintlink.net (144.232.20.101) 1500.981 ms 10 sl-bb21-rly-14-1.sprintlink.net (144.232.20.22) 1563.477 ms 11 sl-bb20-tuk-0-0.sprintlink.net (144.232.20.123) 1570.312 ms 12 sl-bb21-tuk-15-0.sprintlink.net (144.232.20.133) 1571.289 ms 13 sl-bb21-lon-14-0.sprintlink.net (144.232.19.70) 1640.620 ms 14 sl-gw10-lon-15-0.sprintlink.net (213.206.128.46) 1640.620 ms 15 213.232.65.181 (213.232.65.181) 1641.596 ms 16 i-194-106-32-34.freedom2surf.net (194.106.32.34) 1643.549 ms 17 i-194-106-56-222.freedom2surf.net (194.106.56.222) 1645.502 ms 18 * * * 19 * * * 20 195.137.29.227 (195.137.29.227) 1777.330 ms The * * * signs mean that the packets with TTL 18 and 19 did not generate an ICMP error message: The packets simply disappear. Probably, the cause is that the routers in question do not generate ICMP error messages in response to ``TTL expired''. More serious: the last computer (TTL 20) is NOT 195.129.111.8 . It looks like there is a firewall ``around'' ftp.eu.uu.NET that does not allow traceroute to get to ftp.eu.uu.NET . Note that opus1 reports only 1 RTT per TTL level. They say they send 3 UDP packets per TTL level. Would they report the mean? The first? There is something strange with these RTTs. Better repeat this experiment: traceroute to 195.129.111.8 (195.129.111.8), 30 hops max, 40 byte packets 1 manny.Firewall.Opus1.COM (192.245.12.95) 4.882 ms 2 Opus-GW (207.182.35.49) 22.459 ms 3 610.ATM1-0.GW3.PHX2.ALTER.NET (157.130.235.181) 19.530 ms 4 109.ATM3-0.XR1.LAX2.ALTER.NET (152.63.114.138) 21.483 ms 5 0.so-0-0-0.XL1.LAX2.ALTER.NET (152.63.115.217) 22.459 ms 6 0.so-7-0-0.TL1.LAX2.ALTER.NET (152.63.2.70) 23.436 ms 7 0.so-7-0-0.IL1.DCA6.ALTER.NET (152.63.9.193) 97.650 ms 8 so-1-0-0.IR1.DCA4.Alter.Net (146.188.13.38) 97.650 ms 9 so-1-0-0.TR2.AMS2.Alter.Net (146.188.3.106) 177.723 ms 10 so-6-0-0.xr1.ams6.alter.net (146.188.8.81) 178.699 ms 11 195.atm6-0-0.hr1.ams6.alter.net (212.136.184.13) 179.676 ms At least we get to Amsterdam! Also, the RTTs look more plausible. But we did not get to the target machine. It looks like the first time we tried to get to 195.129.111.8 from opus1, there was a serious routing problem somewhere. ---- Let's check traceroute does not work from outside NJIT to inside NJIT. bloch-41 ott>: nslookup afs10 Server: dns1.njit.edu Address: 128.235.251.10 Name: cerulean.njit.edu Address: 128.235.204.72 Aliases: afs10.njit.edu ---- From opus1: traceroute to 128.235.204.72 (128.235.204.72), 30 hops max, 40 byte packets 1 manny.Firewall.Opus1.COM (192.245.12.95) 5.859 ms 2 Opus-GW (207.182.35.49) 17.577 ms 3 610.ATM1-0.GW3.PHX2.ALTER.NET (157.130.235.181) 20.507 ms 4 109.ATM2-0.XR2.LAX2.ALTER.NET (152.63.114.150) 24.412 ms 5 0.so-0-0-0.XL2.LAX2.ALTER.NET (152.63.115.229) 23.436 ms 6 0.so-7-0-0.TL2.LAX2.ALTER.NET (152.63.2.82) 21.483 ms 7 0.so-6-0-0.TL2.NYC9.ALTER.NET (152.63.13.10) 98.627 ms 8 0.so-1-0-0.XL2.NYC9.ALTER.NET (152.63.23.130) 99.603 ms 9 0.so-0-0-0.XR2.NYC9.ALTER.NET (152.63.9.89) 100.580 ms 10 180.ATM7-0.XR2.EWR1.ALTER.NET (152.63.17.241) 102.532 ms 11 192.ATM6-0.GW5.EWR1.ALTER.NET (152.63.20.245) 100.579 ms 12 njit.customer.ALTER.NET (157.130.11.86) 104.485 ms (No response from inside NJIT ). Note we got close to NJIT, but not even to the adress space 128.235.0.0/16 . ---- Homework for 11/07/02: Try to find a computer across an ocean that IS reachable by traceroute. Find the route to that computer. Check this a couple of times. Is the route always the same? How does the RTT break down into components?