Old Well

Department of Computer Science
College of Arts and Sciences
University of North Carolina at Chapel Hill

COMP 290-042: Advanced Networking -- Internet Architecture & Performance

Frequently Asked Questions

How do I get help from the TA?
You can stop by during the TA's office hours (T,Th 1:30-2:30) or send e-mail. I'll often be in the lab working on my own research. While I'm happy to help answer your questions I'd like to avoid being "interrupt-driven" when I'm working in the lab. I'd appreciate receiving your questions by e-mail (even when I'm in the lab if it's not my office hours) so that I can answer when I take a break. Also, be sure to check the FAQ and Tips pages first. I'll post most of the questions I receive and their answers there.
How do I change my shell?
Use chpass to change your info. This would change your shell to bash:
	chpass -s bash userid
Or just use chpass and fill in all of your information.
How do I switch kernels?
First use "w" to make sure no one else is logged on to the machine. Once other users have logged off, use the shutdown command to shutdown the machine:
	shutdown -r now 
You will need to monitor the machine as it reboots when it prints the line "boot:" you should be ready to type in the name of your kernel. (Note: this prompt will time out quickly and proceed to boot with /kernel if you do not type something when it appears.) For instance, to boot with /kernel.1000:
boot: /kernel.1000
You can test to see if you are using the kernel you want by using the 'uname -a' command.
How do I put up an xterm from bennett under XWin32?
First, note that Xwin32 is the X-windows package for Win95 or WinNT. If you are on a UNIX machine things should work the same for bennett as for any other machine. There are just a few differences if you are using XWin32 to connect to a FreeBSD machine so I wanted to document it here.
I'm assuming you already know how to set up a connection for a departmental machine. Use X-util to add a new session. For connect mode, specify "rsh"; for hostname, specify "bennett"; specify your login; and the login command is "/usr/X11/bin/xterm -ls". Be sure to add the display option in whatever format you usually use. I usually just hardcode the machine that I'm working from. You'll also need to have a .rhosts file in your home directory on bennett with the machine name and then your id for the machine you want to connect from. And, if you have any xhost entries in your X-Win32 you will need to add one for bennett. Good luck.
How do I set up my environment under FreeBSD?
Now that you have your account you should do several things.
  • Change your passwd on all the machines - sorry you have to do this on each machine.
  • Set your shell. See the note above.
  • Set up your shell environment. My environment dates from 1990 so you probably don't want it. Be sure to keep the path, etc. that are set up in your initial environment, especially /usr/home/bin. That's where I'll install some of the tools you'll use.
  • You'll probably want an X environment for when you're working in lab. I encourage you to consider starting with the default environment and just making minor changes; you won't use it often.

Where can I find man pages on the commands used in the homework?
The man pages you need should all be on bennett. If not, mail parris@cs.unc.edu.
Which compilers are supported in the colab machines?
cc, c++, gcc, and g++ are all available. The expectation is that coding for assignments will be done in C. Perl5 is also available in /usr/local/bin in addition to many other standard UNIX packages (e.g. awk) if you want to use them for quick data processing. Don't spend too much time on data parsing, etc. though.
Where should I store and process data?
The comp290 network now has 2 file-servers/compute-servers. bennett remains your connection to the experimental network and the location of your home directories (which are mounted on all machines). In addition, a new machine, granny is available as a file and compute-server. It has connections to both the department network (as granny) and to the experimental network (as grannyP137). Granny's /playpen is mounted on bennett (but not the other machines) and has 8GB of available space. You should create a directory (e.g. /playpen/parris) to use when working with data. Do not consider this infinite space! We will be placing traces of the campus up-link to the internet there that may be 1GB each and you will generate your own files as you extract data from these traces. Use tar and gzip often when you need to retain data but won't be working with it for a while. TIP: While you can access /playpen on bennnett, you will probably get noticably better performance if you are logged into granny when you are working with large datasets in /playpen since you will avoid network overhead on NFS.
How can I share files with my partner
To aid you in working together on your assignments we have set up the following unix groups on the comp290 machines. If you want to share files in a directory you should be able to use the commands "chgrp" and "chmod" to set permissions to share the files with your partner as you wish. The groups:
group0 - ott,harjono
group1 - sellappa,paramesw
group2 - dwyer,sain
group3 - weissd,xiao
group4 - clark,mattes
group5 - sunku,mundhra

How can I access class file-systems from UNIX?
We have mounted granny:/playpen and bennett:/usr as read-only file-systems on buzzard. They are available as '/net/bennett/usr' and '/net/granny/playpen'. This was mainly done for one group that needs to use a tool that isn't available on FreeBSD to process their data.
How is the lab configured?
The network reconfiguration is complete (I think). I have posted diagrams of the new network configuration above the whiteboard in the lab. Quite a lot has changed. Please let me know if you discover any problems. It is entirely likely I missed something in the reconfiguration.

There are pdf and Word versions of the lab diagram available.

There are now 4 logical networks: P134, P136, P137, and P138.

P134 and P138 are the "end-system networks". Each of these networks has 4 "traffic generator" machines attached. They are bollellaP138, gomerP138, stoneP138, and poirierP138 on the P138 network and otisP134, beckerP134, earnesttP134, and neeP134 on the 134 network. Each of these machines has a 10Mb uplink to a 100Mb switch. Each of the 100Mb switches are connected via an uplink to a 100Mb Hub. The hubs are used to connect the router (chenP138 and borgP134) and a monitor machine (talleyP134 and talleyP138). This allows talley to monitor all traffic that will be passing through the routers. Talley is also attached to the P136 network.

P136 and P137 are 10Mb hubs used to provide a full-duplex connection between the two routers (borg and chen). The connection is 10Mb to create a bottleneck. All data passing through chen destined for the 134 network goes to borg over the 137 network while all data passing through borg destined for the 138 network goes to chen over the 136 network. Keep this in mind when analyzing data collected from the P136 or P137 networks. We encourage you to configure your experiment so the data flow is from P134 to P138 so you can capture packets on the P136 network with talley.

P137 is also the connection to bennettP137 and grannyP137. Both of these machines also have their usual connections to the department as "bennett" and "granny".

Finally, there is an additional machine, "krishnan" with appearances on the P134 and P138 networks. This machine will be used exclusively by Greg Mattes and Michele Clark for their project as they will be rebooting the machine often as they recompile and test changes to the kernel. Michele and Greg: there is more configuration that needs to be done for this machine. See me so we can set it up.

talley and krishan use borgP134 as their default router so while they do have P138 addresses, you will not be able to contact them when borg is down.

Let me know of any problems. Remember the network is a shared resource; check to see if others are logged on (they have to come through bennett or granny) before starting experiments.

How do I set the delays for different flows?
There are two programs you can use to do this. But for either one: First verify you are running a kernel with delaybox. Use uname -a to verify the kernel is from /usr/src/sys-altq-delay (in the path). A 1000 HZ kernel is preferred as well. Next determine the device name for the ethernet device you want to create delays on. Use ifconfig -a for this.

One program is "set_flows". Finally use the program "set_flows" in /usr/local/bin to set the delays. Specify the interface name without the interface number (e.g. ep, not ep0) for the first response, then the number in response to the next query. Then you can specify up to 5 (0-4) source IP addresses and different delay times for each. Simply enter the ip address and then enter the delay (in milliseconds) for each. Flow 5 is the "default" flow which represents all other flows. Setting a delay for flow 5 will add a delay to all packets that don't match flow 0-4. You will need to run set_flows again and reconfigure to set the delays back to 0 when you are done.

The other program is "setdelay" in /usr/local/bin. It is an argument driven version of set_flows. It is an interface to the same set of queues, etc. as set_flows but may be easier to use from inside of scripts. Type setdelay with no arguments to see the arguments. This program was written by Mikkel Christiansen.

Turning off delays:If setdelay is called only with a -q option, then the delaybox for this host is deactivated. NOTE: This does not set the delay values to zero. It turns off the delaybox entirely. However, the settings remain in place and will be used when delaybox is reactivated. You should always set the values for ALL the queues to avoid accidentally using delays you did not intend to use.

These programs are NOT on bennett or granny as they are not to be used for experiments. Should be on all others though.

How do I use tcpdump?
For the most part, just read the man page. But here are a few tips for this and any other data collection you do.
  • Always dump data to a local disk and copy it to your NFS space later. You can make a directory in /usr/tmp/. Use your login as the name. I'll leave it to you to consider why you would always want to dump to the local disk. Note: You should NOT store data for more than a few hours on the local disks. We may periodically wipe any old files from the local disks to maintain free space for others to work. Always move your data to your NFS space after you collect it.
  • Dump the data to a file in binary format (the -w option).
  • Use reasonable filtering when monitoring the network to limit the amount of data you collect.
  • Use more filtering when you examine the binary file to find the flows, etc. you are interested in.

Where is the tcpdump source?
You should be able to find the source and makefile for tcpdump in:
The makefile structure and separate locations for the *.[ch] vs. *.o files is a bit odd but you should be able to figure it out.
How can I get check to see if a machine is up?
Since the machines aren't connected to the department we use a If you ever have what you believe might be network connectivity problems in the lab, you can check things out with the script "/usr/home/bin/check".

It simply does 1 ping to all of the machines at their current locations (I will do my best to keep it updated as I reconfigure the network). So, it may also be a useful tool to discover the current network configuration as well.
How can I change the TCP window size on a machine?
'/usr/local/bin/setwindow' should do the trick. Arguments are "-R recv_window" and/or "-S send_window". NOTE: The machine must be running an ALTQ kernel (as that includes a bug fix for window sizes). This program is NOT on bennett or granny as they are not to be used for experiments. Should be on all others though.
  • How can I synchronize clocks on the experimental machines?

  • How can I synchronize clocks on the experimental machines?
    On bennett run /usr/home/bin/rrdate. This program will set the clocks on all of the machines. Warning: this is not the same as synchronized clocks. It just brings clocks closer to being in sync.
    How can I find documentation on ttcp?
    The man page for ttcp is available on bennett in /usr/local/man. 'man ttcp' should work. I don't know why the page is so poorly formatted but at least the information is there. Most of what you need can probably be found in the "usage" message by typing ttcp without any arguments.
    How can I find local documentation on AltQ?
    AltQ documentation exists in /usr/src/altq-1.1.1/docs. The *.ps and *.txt files should be obvious. However the *.8 files are nroff files ready for the "man" command. I have copied those files to /usr/local/man on bennett so you should be able to simply type, for example, 'man cbqd' and see the appropriate man page. However, you can also type this command: 'nroff -man cbqd.8 | more' to view the page if you are on some other machine. You can print to hplj156 from granny and bennett.
    How can I find out about libpcap?
    Man pcap.
    Where are some sample tcpdumps to work with?
    /usr/home/dumps has one with more to come. These are binary tcpdump files with the name indicating the date and approximate time they were collected. Note: the bigger files represent longer traces. I encourage you to start out by debugging your programs with smaller traces. Possibly consider using the -r and -w options and tcpdump filtering to generate very small trace files that include only a few packets that you are interested in to ease debugging/verification.
    How can I plot tcpdump info graphically?
    'tcptrace' is a great tool. The main web page has a lot of info. We also have our own version in /usr/home/bin/tcptrace-dirt which includes a few bug fixes Michele Clark added. You probably won't even notice them. Just use tcptrace-dirt. To view the resulting files you should use xplot. We have a modified version in /usr/home/bin/xplot-dirt. There is documentation for xplot, including the additions, on a web page. (Michele wrote the web page, not me.)
    NOTE: Michele provides these notes on the new version of tcptrace. You may find them extrememely useful in doing your traffic analysis.
    Where are the plots from class on 10/20/98? (TCP traffic to Orange High School)
    In /usr/home/dumps/class_samples you can find the orange high school plots. They are named: tcpx1t1a_seg.xpl, tcpx3t1-a_seg.xpl, tcpx3t1-b_seg.xpl, tcpx3t1-c_seg.xpl. "tcpx1t1a_seg.xpl" is a plot of one flow to Orange High school. The bottleneck link is 1.55Mbps. The other three plots are three flows sharing the link.
    Where are the plots from class on 10/22/98? (TCP traffic in the lab exploring window-size & delay)
    In /usr/home/dumps/class_samples/window-size you can find the window-size & delay data. You can find a NOTES file in that directory and a README file in each subdirectory (comp290-dump[456]) that outline the set-up, the issue being considered, and which files are the interesting ones. The "tcp" and "tsg" scripts in each directory will display the plots of interest. You may want to change the geom though as it is set for the lower resolution used by the projectors in class.
    How can I parse tcpdump output?
    There are a few sample programs available.

    See the sample program in /usr/home/src/tcpdump_samples/udp for a sample program that reads in a tcpdump binary file. Make a copy of the code, compile and run without arguments to get usage information.

    The sample program (ifmon) illustrates how to modify tcpdump so that it invokes a user-supplied function for each packet found in a live trace or when reading a file with the [-r filename] option. It is in /usr/home/src/tcpdump_samples/ifmon . Note: this program is slightly different than, but based on the ifmon provided in /usr/home/bin.

    ifmon and thruput - more tools for processing dumps.
    In '/usr/home/bin', the program 'ifmon' takes a binary tcpdump file as input (the -r argument), examines the packets matching the filter specifications (same as tcpdump filtering), and calculates the average load over N ms intervals (the -I argument). 'thruput' takes the output of ifmon and outputs an xplot file with the specified title (the -t argument). The following would sample the tcp packets in tcpdump.out over 100ms intervals and pass the results to thruput which would generate an xplot file with the title "tcp" in ifmon.xpl.
    ifmon -I 100 -r tcpdump.out tcp | thruput -t "tcp" > ifmon.xpl 

    What is OC3MON anyway?
    In a nutshell, OC3MON is a PC with two ATM interface cards that have the ability to monitor Internet-1 traffic as it flows across OC3 optical fiber pair to the ATM switch connecting the UNC campus to the internet.

    An optical splitter carries a fraction of the light from from each fiber to the receive port of the ATM NICs. One of the OC3MON NICs is able to see all inbound traffic received by the switch and the other NIC all outbound traffic.

    Customized firmware is used with each ATM NIC. Software distributed with the package includes tools for monitoring traffic in "flow analysis" and "trace" modes. Our traces are taken using the latter and converted to tcpdump format using another tool called "mon2dump".

    For more information see:

    as well as the paper given out in class

    K. Thompson, G. Miller, and R. Wilder. "Wide-Area Internet Traffic Patterns and Characteristics". IEEE Network. November December 1997.

    How do I interpret the timestamp format for OC3MON traces that I look at using tcpdump?
    Timestamps for OC3MON traces tell you when a given IP packet arrives at the ATM interface it was received on. This value is relative to the time when the trace began and not the time of day. An example timestamp is given below:
    The first two fields (00:00:) are unused and have simply been initialized to zero. The field (02.000728) gives the number of seconds since the trace began, or to be even more specific the number of seconds (02) and the number of microseconds (000728).
    Why do timestamps for some adjacent packets entries have the same value when looking at OC3MON traces using tcpdump?
    The clock used in OC3MON trace dumps has a 25MHz precision which is finer in granularity than the microseconds unit used in tcpdump. Hence, while you can be sure the ordering of packet entries is correct, packet timestamps will sometimes appear the same when the interval between them is less than a microsecond. You may simply consider the interval between them to be zero if that becomes an issue in your project.
    How do I interpret OC3MON trace filenames?
    An example is given below:
    The first field (981031) gives you the date of the trace using the format YYMMDD (this allows you to sort by date of file generation). The second field (1400) gives you the approximate time the trace was started using a 24-hour clock. The third field (1800) gives you the number of seconds that the trace ran for (1800 sec = 30 min in our example.) The interface, 'if1' or 'if2' indicates which atm interface the trace was taken from. This means that trace files always come in pairs--the oc3mon tracing mechanism captures packet headers from both atm interfaces simultaneously. Afterward, we separate them and perform format conversions and filtering. The .udp suffix indicates this data has already been filtered for udp data only.
    Why is tcpdump running so slow when viewing OC3MON traces?
    The tcpdump binary format stores source and destination fields in IP address format (ex. When running tcpdump, however, it does a lookup on each address to obtain host and port names which are easier for people to recognize. Running tcpdump with the -n option will prevent this conversion and thus make things run a lot (!) faster. Considering the size of the traces we will be using in this class, this is definitely the recommended mode of operation for all parts of your projects.
    What should I do about tcpdump entries which include hex dumps?
    If you find that a few IP packet entries in your tcpdump trace contain a lot of unintelligible gobbly-gook after the timestamp like the following
    00:00:00.178225 82 00 10 30-82-00 0030: 30:30:30:30:30:30 sap 02 >
    30:30:30:30:30:30 sap 15 I (s=0,r=0,C) len=19517
                             0201 0030 8200 1030 8200 0c06 082b 0601
                             0201 0103 0005 000c
    chances are you're either seeing something that is not an IP packet or is an IP packet corrupted such that tcpdump can no longer recognize its format. Since this will likely cause problems for programs parsing tcpdump format files, the recommended course of action is to filter the unwanted entries out by running tcpdump as follows:
    	tcpdump -r filename -w newfilename ip
    As you will find on the tcpdump man page, ip is short for the "ether proto ip" option which simply filters out anything that is not an ip packet. In general, we will attempt to do this for you before making traces available to the class.
    Gethostbyname and nslookup don't work. What should I do?
    Since the machines aren't connected to the department we use a non-standard name resolution configuration. For some reason gethostbyname and nslookup don't seem to work. However, some programs (e.g. ping) can resolve names from /etc/hosts as they are supposed to. In the meantime, simply user ip address numbers without name resoultion in your programs. You can resolve the names using nslookup on bennett to get the ip addresses to use.


    Page maintained by: Department of Computer Science, UNC-Chapel Hill
    Server Manager:
    Content Manager: parris@cs.unc.edu