Network Fieldwork: ping, traceroute, whois, dig

This exercise uses command-line tools to investigate the physical and logical structure of the internet. Use the Terminal app on Mac (Applications → Utilities → Terminal).

If you live off campus, try each command from both on-campus (via VPN or in class) and off-campus. The results will differ, and that difference is itself interesting.

Important: traceroute is often blocked.

Many networks filter the packets that traceroute depends on. You will frequently see rows of * * *, this does not mean the route has failed, it means a router along the way is silently ignoring the probe. Section 2 below covers the TCP traceroute and web-based alternatives.

Ping can be blocked too. A few hosts in the Q1 list may show 100% packet loss, that's the host (or a firewall in front of it) ignoring ICMP, not a problem with your setup. If a host doesn't respond, note that as a finding rather than assuming something's wrong.

Do not target sensitive infrastructure. Only use educational institutions and media/public outlets.




1. ping: measuring round-trip time

ping sends a small request to a host asking for a response ("are you there?"). It uses ICMP echo request/reply messages. It is commonly used to check if a host is reachable and to measure latency.

% ping www.mit.edu
Hit Control-C to stop. ping will print statistics when you quit. 
% ping www.mit.edu
PING www.mit.edu (92.122.15.121): 56 data bytes
64 bytes from 92.122.15.121: icmp_seq=0 ttl=58 time=91.203 ms
64 bytes from 92.122.15.121: icmp_seq=1 ttl=58 time=88.417 ms
64 bytes from 92.122.15.121: icmp_seq=2 ttl=58 time=89.552 ms
^C
--- www.mit.edu ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 88.417/89.724/91.203/1.146 ms
For the man pages: % man ping


Q1. ping the following hosts. Pay attention to the minimum round-trip times. 
oregonstate.edu
www.pdx.edu
www.mit.edu
www.sfc.keio.ac.jp
www.nmmu.ac.za
www.nast.gov.np
cuni.cz
www.uni-heidelberg.de
www.unifiji.ac.fj
www.amazon.com
www.apple.com
What do the differences in minimum round-trip time tell you about where these servers are physically located? Why might a server with a geographically close name have a surprisingly high latency?





2. traceroute: tracing the path

traceroute shows each router ("hop") a packet passes through on its way to a destination. It works by sending packets with increasing TTL values and collecting the ICMP "time exceeded" messages sent back by routers along the way.



Run on the command line on Terminal: 
% traceroute www.mit.edu
You will likely see * * * at some point, this means a router is dropping the probe without replying. That is normal and expected today. 
% traceroute www.mit.edu
traceroute to www.mit.edu (92.122.15.121), 64 hops max, 52 byte packets
 1  router.local (10.0.0.1)         1.2 ms   1.1 ms   1.0 ms
 2  isp-gateway (96.120.61.1)       9.4 ms   9.2 ms   9.1 ms
 3  * * *
 4  * * *
 ...
Even partial results are informative. The first few hops show your local network; named hops often include geography in the hostname (eg. seattle.wa, san-jose).



If traceroute is completely blocked, try TCP mode (on a Mac you have administrative password to):
macOS doesn't have a simple -T flag for this, use tcptraceroute instead (requires sudo): 
% sudo tcptraceroute www.mit.edu          # requires: brew install tcptraceroute
TCP uses port 80, which servers must accept for ordinary web traffic, so it can get a reply from the destination even when plain traceroute gets nothing back. This isn't hypothetical, here is a real side-by-side run against amazon.com: 
% traceroute www.amazon.com
traceroute to e15316.dsca.akamaiedge.net (2.18.102.138), 64 hops max, 40 byte packets
 1  10.0.0.1 (10.0.0.1)  13.893 ms  4.476 ms  4.232 ms
 ...
 8  50.222.131.142 (50.222.131.142)  25.716 ms *  76.173 ms
 9  * * *
10  * * *
11  * * *
12  *^C
% sudo tcptraceroute www.amazon.com
Tracing the path to www.amazon.com (3.163.152.189) on TCP port 80 (http), 30 hops max
 1  10.0.0.1  4.637 ms  5.521 ms  3.935 ms
 ...
 7  be-36221-cs02.seattle.wa.ibone.comcast.net (68.86.93.53)  21.109 ms * *
 8  be-2211-pe11.seattle.wa.ibone.comcast.net (96.110.32.230)  23.483 ms * 22.540 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  server-3-163-152-189.sea90.r.cloudfront.net (3.163.152.189) [open]  20.288 ms  22.731 ms  25.910 ms


Same target, same network. Plain traceroute dies completely after hop 8, not even the destination answers. tcptraceroute reaches all the way to Amazon's edge server and confirms the TCP handshake succeeded ([open]). The middle hops still show * * * in both runs, those routers won't reply no matter what kind of probe you send, but now you know your packets are actually getting through to the destination.

Caveat: tcptraceroute isn't a guarantee either. It defaults to a 30-hop limit (plain traceroute defaults to 64), so a longer real path, or a temporary routing hiccup somewhere in the middle, can still end in "Destination not reached" even when the site itself is completely fine. If that happens, try sudo tcptraceroute -m 64 hostname to rule out the hop limit, and try again in a few minutes, backbone routing hiccups like this are often transient.


Q2.1. Try traceroute to several hosts from the list in Q1. Note which hops you can see and where the * * * begin. Using the hostname labels in the output, try to reconstruct the geographic path.
Q2.2. Web-based traceroute: initiating from a different location.
Use one of these tools to run traceroute to the same hosts from a different city or country: Compare the result to your local traceroute. What changes? Where do the paths converge?



3. Open-ended fieldwork

Using the tools above, and any others you find, investigate a specific question about internet routing and infrastructure. Write a few paragraphs of observations. Aim for curiosity over completeness.

Possible directions:
Additional tools and references:


Supplementary: exploring IP addresses (dig & whois)

The tools above work directly on hostnames, so none of sections 1-3 require this. These two commands let you dig deeper: dig resolves a hostname to the IP address(es) behind it, and whois tells you who owns that IP range. Useful if you want to know exactly which network or organization you're actually talking to.

dig: DNS lookup

dig (Domain Information Groper) queries the DNS system to find out what IP address a hostname resolves to, and which servers are authoritative for that domain. Unlike traceroute, dig is almost never blocked and gives reliable results.

% dig www.reed.edu
Look for the ANSWER SECTION, it shows the IP address the hostname resolves to. 
% dig www.reed.edu

; <<>> DiG 9.10.6 <<>> www.reed.edu
;; ANSWER SECTION:
www.reed.edu.		300	IN	A	134.10.2.252

;; Query time: 12 msec
;; SERVER: 134.10.8.8#53(134.10.8.8)
Try with a CDN-backed site to see multiple IPs returned: 
% dig www.amazon.com
To see the full DNS chain (which servers are authoritative): 
% dig +trace www.reed.edu
For the man pages: % man dig

SQ1. Use dig to find the IP address of several hosts from the list in Q1. Record the IP addresses, you'll use them below with whois.
SQ2. Run dig www.amazon.com or dig www.google.com multiple times. Do you always get the same IP address? What does it mean if you get different addresses each time? (Hint: look up "content delivery network" or "anycast routing".)

whois: IP address ownership

whois looks up the organization registered to a domain name or IP address in public NIC (Network Information Center) databases.

Domain names sometimes give vague results. IP addresses are more useful: 
% whois reed.edu
% whois 134.10.2.252
(Use the IP addresses you found with dig above.)

The output will tell you who owns the IP range, their organization, and contact information.

SQ3. Use whois on the IP addresses you found with dig. Who owns those IP ranges? Are any hosted in unexpected locations? Does knowing the registered owner of an IP range tell you anything interesting?