Traceroute Assignment

1. Measure round trip times using ping

The ping utility uses the ICMP's (Internet Control Message Protocol) mandatory echo request message to elicit an ICMP echo response from a remote host or gateway. If the remote host supports ICMP, the remote host responds by seinding an echo-response. It is often used to check if a host is up (alive) or reachable. For the manual pages for ping, on the Terminal App (in Applications/Utilities folder) on Mac OS,

% man ping

Hit q to exit the man pages.

%man man

for the manual pages for the man command. To ping a remote host:

% ping www.cmu.edu

Some hosts have the response feature turned off. (eg. www.reed.edu). Note that the remote host need not be a web server. It can be any valid IP address (instead of a resolved hostname).

% ping 137.164.50.158

To quit ping, hit Control-C.
UNIX commands such as ping often take flags that changes the behaviour of the command. For example, the -c flag for ping allows you to set the number of echo requests that is sent out. Ping will print out a summary at the end. Below, ping will send out 10 echo requests.

% ping -c 10 www.cmu.edu

You can combine multiple flags (-c and -t in this case) like this:

% ping -c 10 -t 2 www.cmu.edu

Q1.1: ping the following hosts. Speculate on the the success rate if there are failures. Explain the differences in the minimum round trip times (hint use the -c option).

oregonstate.edu
www.pdx.edu
www.cmu.edu
www.sfc.keio.ac.jp
www.nmmu.ac.za
www.ku.edu.np
www.amazon.com
www.apple.com
www.microsoft.com

Q1.2: Send a echo request of different sizes (56 or 2056 bytes) to any of the above two sites and comment on any differences you observe. (Hint use the -c and -s flags).

2. Traceroute

Traceroute is a utility that allows you to trace the path from one machine to another. For details on how this is accomplished, see my lecture notes. On the Terminal, type

%traceroute www.nyu.edu

or if you know the IP address, you can use it instead of a resolved name

%traceroute 172.217.3.196

Traceroute to some hosts may not complete. In order to terminate, hit Control-C.

% traceroute www.nytimes.com
traceroute to www.gtm.nytimes.com (170.149.159.130), 64 hops max, 52 byte packets
 1  10.0.0.1 (10.0.0.1)  1.581 ms  2.591 ms  1.310 ms
 2  96.120.61.153 (96.120.61.153)  8.040 ms  9.942 ms  10.545 ms
 3  xe-5-1-3-sur04.troutdale.or.bverton.comcast.net (162.151.212.233)  12.591 ms  9.194 ms  11.800 ms
 4  ae-52-ar01.troutdale.or.bverton.comcast.net (68.87.216.253)  8.279 ms  9.141 ms  9.010 ms
 5  be-33490-cr01.seattle.wa.ibone.comcast.net (68.86.92.217)  13.577 ms  14.372 ms  12.663 ms
 6  hu-0-14-0-1-pe05.seattle.wa.ibone.comcast.net (68.86.89.118)  12.747 ms  14.603 ms  13.531 ms
 7  ix-xe-0-2-2-0.tcore1.00s-seattle.as6453.net (64.86.123.9)  12.379 ms  19.211 ms
    ix-xe-7-2-2-0.tcore1.00s-seattle.as6453.net (64.86.123.33)  31.673 ms
 8  if-ae-14-2.tcore1.pdi-palo-alto.as6453.net (64.86.123.22)  30.182 ms  30.643 ms  29.349 ms
 9  if-ae-2-2.tcore2.pdi-palo-alto.as6453.net (66.198.127.2)  32.500 ms  30.572 ms  32.694 ms
10  if-ae-5-2.tcore2.sqn-san-jose.as6453.net (64.86.21.1)  33.407 ms  29.788 ms  29.983 ms
11  if-ae-1-2.tcore1.sqn-san-jose.as6453.net (63.243.205.1)  29.077 ms  29.989 ms  35.681 ms
12  63.243.205.62 (63.243.205.62)  31.960 ms
    63.243.205.58 (63.243.205.58)  61.980 ms  30.223 ms
13  209.200.184.202 (209.200.184.202)  28.712 ms
    209.200.184.200 (209.200.184.200)  29.896 ms
    209.200.184.192 (209.200.184.192)  30.944 ms
14  209.200.184.205 (209.200.184.205)  36.980 ms
    209.200.184.197 (209.200.184.197)  31.468 ms  32.673 ms
15  * * *
16  * * *

Q2.1 Look up what these "*" means. Remember, most UNIX commands come with a man page.

%man traceruote

Q2.2. Try traceroute to various public sites. Choose educational institutions and media/public outlets. Use Google or Wikipedia to look for appropriate sites. Do not target any sensitive sites such as military sites or nuclear power plants. What do these "*" mean and speculate on the reasons why traceroutes to some hosts cannot be completed.

3.DNS with DIG

The dig (Domain Information Groper) command performs a DNS lookup.

% dig www.reed.edu

; <<>> DiG 9.8.3-P1 <<>> www.reed.edu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.reed.edu.			IN	A

;; ANSWER SECTION:
www.reed.edu.		8761	IN	A	134.10.2.252

;; Query time: 32 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Wed Aug 10 12:09:35 2016
;; MSG SIZE  rcvd: 46

The answer section

;; ANSWER SECTION:
www.reed.edu.		8761	IN	A	134.10.2.252

tells you that, the result is of type "A" which means it is an address record. The IP address of www.reed.edu is 134.10.2.252. The summary section

;; Query time: 32 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Wed Aug 10 12:09:35 2016
;; MSG SIZE  rcvd: 46

tells you that it took 32 msec for the repsonse and the server that answered was 8.8.4.4.

The following command (somewhat hard to explain so take my word, or you can look it up):

%dig . ns

will give you the list of root servers (something like below)

...

;; ANSWER SECTION:
.		16548	IN	NS	i.root-servers.net.
.		16548	IN	NS	k.root-servers.net.
.		16548	IN	NS	m.root-servers.net.
.		16548	IN	NS	b.root-servers.net.
.		16548	IN	NS	g.root-servers.net.
.		16548	IN	NS	d.root-servers.net.
.		16548	IN NS h.root-servers.net.
.	        16548 IN NS l.root-servers.net.
.		16548 IN NS c.root-servers.net.
.	        16548 IN NS f.root-servers.net.
.		16548 IN NS e.root-servers.net.
.		16548 IN NS a.root-servers.net.
.		16548 IN NS j.root-servers.net.

...

Now that you know the names of the root servers, you can query directly to them using the @servername option. To query the m.root-servers.net directly regarding the host www.reed.edu:


%dig @m.root-servers.net www.reed.edu

The above dig command can be understood as having three parts

dig  [server name]  [host name you are interested in]

It may or may not respond by passing down your request to a name server lower in the hierarchy (this process is called recursion). In this exercise, we'd like it NOT to do recursion so use the +norecurs flag to make sure it doesn't. (Again, don't forget to look up the man page for dig).


%dig +norecurs @m.root-servers.net www.reed.edu


; <<>> DiG 9.8.3-P1 <<>> +norecurs @m.root-servers.net www.reed.edu
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19871
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 7

;; QUESTION SECTION:
;www.reed.edu.			IN	A

;; AUTHORITY SECTION:
edu.			172800	IN	NS	c.edu-servers.net.
edu.			172800	IN	NS	f.edu-servers.net.
edu.			172800	IN	NS	a.edu-servers.net.
edu.			172800	IN	NS	d.edu-servers.net.
edu.			172800	IN	NS	g.edu-servers.net.
edu.			172800	IN	NS l.edu-servers.net.

;; ADDITIONAL SECTION:
a.edu-servers.net.	172800	IN	A	192.5.6.30
c.edu-servers.net.	172800	IN	A	192.26.92.30
d.edu-servers.net.	172800	IN	A	192.31.80.30
f.edu-servers.net.	172800	IN	A	192.35.51.30
g.edu-servers.net.	172800	IN	A	192.42.93.30
l.edu-servers.net.	172800	IN	A	192.41.162.30
g.edu-servers.net.	172800	IN	AAAA	2001:503:cc2c::2:36

;; Query time: 31 msec
;; SERVER: 2001:dc3::35#53(2001:dc3::35)
;; WHEN: Wed Aug 10 12:25:32 2016
;; MSG SIZE  rcvd: 265

You will see from the above result, there is no ANSWER SECTION. The root server does not directly have information on www.reed.edu.
m.root-servers.net responds with the AUHORITY SECTION telling you that the hosts listed (c.edu-servers.net ... g.edu-servers.net) would have more authoritative information. This happens to be the name server responsible for the .edu domain. Then you could repeat this process, manually doing the recursive process by asking the edu domain name server about www.reed.edu as follows.

%dig +norecurs @c.edu-servers.net www.reed.edu

Repeat this process (go downstream from the root server to the name server directly responsible for www.reed.edu). You will most likely go from "edu" name server, then to the "reed" name server.

Q3.1: Start from the root name server and traverse the name server hierarchy until you reach the name server that gives you the ANSWER section for the server www.sfc.keio.ac.jp. List all the name server you queried with the answer.

4. whois

dig queries the DNS servers. The whois utility looks up records in the databases maintained by several Network Information Centers (NICs).

% whois www.reed.edu


This Registry database contains ONLY .EDU domains.
The data in the EDUCAUSE Whois database is provided
by EDUCAUSE for information purposes in order to
assist in the process of obtaining information about
or related to .edu domain registration records.

The EDUCAUSE Whois database is authoritative for the
.EDU domain.

A Web interface for the .EDU EDUCAUSE Whois Server is
available at: http://whois.educause.net

By submitting a Whois query, you agree that this information
will not be used to allow, enable, or otherwise support
the transmission of unsolicited commercial advertising or
solicitations via e-mail.  The use of electronic processes to
harvest information from this server is generally prohibited
except as reasonably necessary to register or modify .edu
domain names.

You may use "%" as a wildcard in your search. For further
information regarding the use of this WHOIS server, please
type: help

Unfortunately, whois frequently does not give out useful information when given resolved names. Try giving it an IP address. (You should know how to convert resolved names such as www.reed.edu into IP address like 134.10.2.252).

  
%whois 134.10.2.252

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#


#
# Query terms are ambiguous.  The query is assumed to be:
#     "n 134.10.2.252"
#
# Use "?" to get help.
#

#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=134.10.2.252?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       134.10.0.0 - 134.10.255.255
CIDR:           134.10.0.0/16
NetName:        REED
NetHandle:      NET-134-10-0-0-1
Parent:         NET134 (NET-134-0-0-0-0)
NetType:        Direct Assignment
OriginAS:
Organization:   Reed College (REEDCO)
RegDate:        1989-04-11
Updated:        2006-03-15
Ref:            https://whois.arin.net/rest/net/NET-134-10-0-0-1


OrgName:        Reed College
OrgId:          REEDCO
Address:        3203 SE Woodstock Boulevard
City:           Portland
StateProv:      OR
PostalCode:     97202
Country:        US
RegDate:        1989-04-11
Updated:        2011-09-24
Ref:            https://whois.arin.net/rest/org/REEDCO


OrgTechHandle: BPO33-ARIN
OrgTechName:   Poliakoff, Ben
OrgTechPhone:  +1-503-788-6674
OrgTechEmail:  benp@reed.edu
OrgTechRef:    https://whois.arin.net/rest/poc/BPO33-ARIN

OrgAbuseHandle: BPO33-ARIN
OrgAbuseName:   Poliakoff, Ben
OrgAbusePhone:  +1-503-788-6674
OrgAbuseEmail:  benp@reed.edu
OrgAbuseRef:    https://whois.arin.net/rest/poc/BPO33-ARIN

RTechHandle: US-ORG-ARIN
RTechName:   Reed College
RTechPhone:  +1-503-771-1112
RTechEmail:  nts@reed.edu
RTechRef:    https://whois.arin.net/rest/poc/US-ORG-ARIN


#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml

5. Open-ended fieldwork:

Use traceroute, ping, dig, and whois (and other tools you may find) to find routes to physical location of sites and post your observations (no longer than a few paragraphs).

Only choose educational institutions and media/public outlets. Use Google or Wikipedia to look for appropriate sites. Do not target any sensitive sites such as military sites or nuclear power plants.

Note that where you initiate the traceroute command makes a difference. If you seem to have problems off-campus, try from within the Reed network. Also, there are sites such as http://www.traceroute.org/ that allows you to initiate the traceroute command from a different location/country. Then you would be able to triangulate and learn information that you may not have been able to otherwise. (eg. traceroute to host A from east coast and the west coast results in a better understanding how host A is situated).

You may also want to take a look at VPN. Some VPN providers give you a limited-time demo.

Your observation can include

How the Reed network is configured. Where its main outlet to the outside world is. Or who Reed’s service provider(s) is/are.
Your guess at where the big internet hub is within the US and outside. Where do packets that go to Asia tend to coalesce? To Europe?
How some countries are well-connected and some countries are not. This may be deduced from the number of hops (and countries) it takes to get to a certain country and also from the physical time it takes to get there. Are there countries that seem to rely heavily on specific countries for their internet traffic, or conversely are there countries that seem to avoid geographically convenient neighbors for internet traffic?
Are there sites that claim to be in one geographical location but seem to be located somewhere else? (Is blip.tv really located in Tuvalu as the top level domain indicates?).

Additional Tools/References: