Introduction§

This lab is all about common Unix networking tools. We've seen several in class already, so we will dive in a bit deeper here. The primary goal is to become familiar with the tools, their common uses, and the underlying networking concepts that they make visible.

Acknowledgments§

This assignment borrows from several of Janet Davis' CSC 364 labs. Specifically, it draws on Labs 6, 7, and 8 from that course. Some of those, in turn, borrow from other sources.

Goals§

Assignment§

Important: All of these parts should be completed when logged into sun.iwu.edu via SSH (your IWU username and password should work), unless otherwise noted. sun.iwu.edu has the most interesting network configuration and activity of any host to which we have easy access. The manpages to which this lab refers are those on sun.iwu.edu, and they may differ on other hosts.

sun.iwu.edu is currently very out of date, and it is running an SSH server that modern clients will not connect to by default (specifically, the SSH server uses old, deprecated encryption methods). If you get a response saying no matching host key type found. Their offer: ssh-rsa,ssh-dss, then you need to first run the following three commands (just once) to make your SSH client comfortable with the deprecated encryption:

$ echo "Host sun.iwu.edu" >> ~/.ssh/config
$ echo "  HostKeyAlgorithms +ssh-rsa" >> ~/.ssh/config
$ echo "  PubkeyAcceptedKeyTypes +ssh-rsa" >> ~/.ssh/config

As always, come see me, post to the discussion forum, or send an email if anything is unclear.

Part A: ifconfig and ip addr§

  1. Read the manpage for ifconfig, focusing on the Description section. What is it used for? What does it do if it is invoked without any arguments?

  2. Run ifconfig with no arguments. Include the result in your lab report.

  3. Choose an interface other than the local loopback:

  4. What is the maximum transmission unit (MTU) for this interface?

  5. Using the number of packets and bytes received and transmitted, compute the average size of packets received and the average size of packets transmitted. How do these compare to the MTU?

  6. Use the uptime command to determine how long the host has been running since it last booted. What are the average RX and TX rates (in bytes per second) for this host?

  7. How many collisions have been reported for this interface? It is most likely 0, but do check. How could there have been zero collisions, given how many packets have been transmitted over this interface?

  8. On modern Linux systems, ifconfig has been deprecated in favor of the ip command. The ip command is part of the iproute2 suite of utilities, which is intended to be a more powerful and consistent replacement for the older net-tools package (which includes ifconfig, netstat, arp, and others). While sun.iwu.edu is an older system where ifconfig is still standard, it is best to know and use the modern tools on most systems.

Update: It turns out that while sun.iwu.edu is modern enough to have ip installed, its version does not support ip -s addr. Strangely, the manpage for ip on sun does describe the -s flag, but possibly it isn't implemented yet for the addr command in that version. In any case, you can skip this part, because it doesn't work on sun at the moment.

  1. Run ip -s -s addr. This is the modern equivalent of running ifconfig with no arguments.
  2. Compare the output of ip -s -s addr with that of ifconfig. What information is the same? What is different? In your opinion, which tool presents the information more clearly?
  3. Run ip -s addr and ip addr. What does the addition and/or repetition of the -s flag change?

Part B: netstat and ss§

  1. Read the manpage for netstat, focusing on the Description section. What is it used for?
  2. Run netstat -i. Include the result in your lab report. How do these results compare with what you learned from ifconfig?
  3. Run netstat -t -u. Include the result in your lab report (if there are more than ten lines, just copy the first ten or so lines and any you mention in the text).
    1. What do those two options, -t and -u, do?
    2. What services have active TCP connections on this host?

    Xtreme Unix Shell Tricks
    netstat -t -u | grep ESTABLISHED | cut -d ':' -f 2 | cut -d ' ' -f 1 | sort | uniq

    Commands can be combined and composed to do all sorts of handy things quickly on the command line. Run this one to see what it does.

    The | operator is called "pipe", and it's the character above the backslash on your keyboard. In the shell, it redirects the output of one command into the input of another. Try to build up this line one command at a time, from left to right, to learn what each additional command does. Check out the explanation from explainshell.com for more details in a fancy interface.

  4. Run netstat -t -u -l. Include the result in your lab report (if there are more than ten lines, just copy the first ten or so lines).
    1. What does the added -l option mean?
    2. What network servers are running on this host? (Server software, that is; for example an HTTP server or an SMTP server. Realize that a single host may be running many servers at once, as they all can coexist on one machine without interfering with each other.) If there are more than ten, just list ten or so.
  5. Like ifconfig, netstat has also been superseded. Its modern replacement for viewing socket information is ss. The ss command is generally faster than netstat because it gets its information directly from the kernel, whereas netstat has to parse files in /proc/net/. While this may not be noticeable on sun.iwu.edu, it can make a large difference on a system with many connections.
    1. Run ss with no arguments. What does it show you, and what netstat command lists the same items?
    2. Using the manpage for ss, figure out what arguments to give it to see the same items as netstat -t -u -l. Run that command and compare its output to the similar netstat command. How do they compare?
  6. Investigate the output of running netstat -r. Interpret and briefly describe the information it produces. (Do interpret and explain the output; don't simply report what you see. See the Output section of man route or ask me if you're not sure what you're seeing.)
  7. The modern equivalent of this command is ip route. Run it and compare the output. Which do you find easier to read?

Part C: arp and ip neigh§

  1. Read the manpage for arp, focusing on the Description section. What is it used for?
  2. Run arp -n to see the contents of the host's ARP cache. Copy this into your lab report (up to 10 lines, if there are more than 10).
  3. What is the range of IP addresses seen in the ARP cache? Pick an IP within that range that does not show up in the list, and use ping to ping that host. This will send one or more packets to that host, and of course it will need the host's MAC address to do so. Run arp -n again. Describe how running the ping command did or did not change the ARP cache, and explain why.
  4. Connect to www.example.com using the command links www.example.com. (Text-based web browsers are awesome!) You just connected to a new host that wasn't in the ARP cache before, so see if an entry appears in the arp cache. (It shouldn't.) Explain why no arp cache entry appeared.
  5. The modern equivalent of arp is ip neigh. As with the other commands, arp is part of the older net-tools package, and ip neigh is part of the modern iproute2 suite. Run ip neigh and compare its output to arp -n. What is different? Which do you find easier to read?

Part D: ping§

  1. Read the manpage for ping, focusing on the Description section. What is it used for? Make sure you figure out 1) what type of information the program reports and 2) how you can control the ping "count" and packet size.

  2. Experiment with pinging each of the following hosts 20 times using the count option:

    1. sun.iwu.edu   (the same host you're logged in to)
    2. hyperion.iwu.edu   (on campus)
    3. www.illinoisstate.edu   (across town)
    4. www.cs.cmu.edu   (in Pittsburgh, PA)
    5. www.cs.hmc.edu   (on the West Coast)
    6. www.ucd.ie   (in Dublin, Ireland)
    7. io.tudelft.nl   (in Delft, of course (in the Netherlands))
    8. www.oxford.ac.uk   (in Oxford, UK?)
    9. mail.iwu.edu   (???)
    10. courses.iwu.edu   (???)
    11. What are the minimum, average, and maximum RTTs for each host? What information can you deduce about the distance to the hosts from this information?
    12. What are the reported TTLs on the echo_reply packets you received? What information, if any, can you deduce from these TTLs? (Hint: See man ping for information on the TTLs.)
    13. You might not have received any replies from a few of the hosts. Are those hosts down (broken)?

  3. Ping hyperion.iwu.edu using packets of different sizes, from 30-byte packets to 1000-byte packets. Does the RTT vary with the size of the packet? What do you think accounts for the differences?

  4. Ping a host farther away using packets of different sizes, again from 30B to 1KB. Does the RTT vary with the size of the packet? What do you think accounts for the differences?

Part E: traceroute§

  1. Read the manpage for traceroute, focusing on the Description section and the last few paragraphs of the Options section. What is it used for, and how does it work?

  2. Use traceroute to determine the routes to the hosts listed in Part D above.

  3. What are the hop counts for each?

  4. What are the common hosts traversed by all paths taken to hosts outside IWU's network?

  5. For which hosts can you determine a physical/geographical location from the traceroute results? [hint: ISPs and backbone providers often their networks and routers using airport codes, city codes, and/or state abbreviations.]

  6. And where is www.oxford.ac.uk? If the traceroute doesn't give you a definite answer, use the timing of its final reported hops and the timing of your ping from before and formulate a reasonable hypothesis.

  7. How can traceroute find at least partial paths to some hosts that you couldn't ping?

  8. Public traceroute servers allow Internet users to learn about network routes from sources that are outside their own networks. KeyCDN has a traceroute page with a directory of public traceroute servers. Using this website, find at least four geographically dispersed public traceroute servers and trace the route from each of them back to sun.iwu.edu. (Personally, I think Kyrgyzstan is a good choice for one of them.) Don't use the "Traceroute Test" offered at the top of the page -- it is not as detailed as the tools linked in the list below.

  9. What would you guess is the average RTT between any two hosts on the Internet? The longest RTT? Explain your reasoning.

  10. What would you guess is the average number of hops between any two hosts on the Internet? The greatest number of hops? Explain your reasoning.

Part F: Pulling it All Together§

Describe in detail how you could use all of these utilities to explore and learn about an unknown network on which you had login access to a single Unix server. How would you use each one independently or in conjunction with others to probe the network, study its characteristics, learn about other hosts on the network, and so on? One way to approach this is to write a detailed procedure you could follow on any Unix host.

Extra credit (5pts): Create a single-node Cloudlab experiment, and use your ideas to learn everything you can about the network to which it is connected. Record your collected data in your lab report alongside your analysis.

Further Questions§

  1. Based on your experiments with ping and traceroute, what conclusions would you draw about the relationships between RTT, number of hops, and geographic distance? (Are there any relationships?)
  2. Did you discover anything else interesting while working on this lab?
  3. How long did you spend on this assignment? What problems, if any, did you run into?

Lab Report§

In general, write enough about each part so that I know what you did (e.g., what commands you ran), what you saw (e.g., the output of a particular command), and what you thought (answers to any questions and other analysis). Please do not copy everything into your lab report, however. I do not need to see each individual ping command, for example; one example is enough. And it would take a rare breed of passive-aggressive to copy every single line of ping output into the lab report; please don't do that. Use your judgment about what to include and what to simply describe or discuss, and please ask me if you're unsure about anything.