Click Tutorial Problem Set 1

Working through this tutorial will teach you how to write a Click configuration, introduce you to many of Click's elements, and show you how Click configurations can be made scriptable.

Solutions

Preparation

Obtain Click and compile and install it. Here's a quick rundown of the commands you'll probably use.

$ cd ~
$ git clone git://github.com/kohler/click.git
...
$ cd click
$ ./configure --prefix=$HOME
...
$ make install
$ ~/bin/click conf/test.click
ok:   40 | 45000028 00000000 401177c3 01000001 02000002 13691369
ok:   40 | 45000028 00000000 401177c3 01000001 02000002 13691369
ok:   40 | 45000028 00000000 401177c3 01000001 02000002 13691369
ok:   40 | 45000028 00000000 401177c3 01000001 02000002 13691369
ok:   40 | 45000028 00000000 401177c3 01000001 02000002 13691369

The --prefix=$HOME configuration switch causes Click to install into your home directory. To run the Click driver and read its manual pages, you'll need to add $HOME/bin and $HOME/man to your PATH and MANPATH environment variables, respectively. Alternatively, if you have root privilege on your machine, you can install Click in /usr/local, /usr/local/click, or wherever you'd like.

If you get a bus error when running Click on a Solaris or other non-x86 machine, try running your configuration through click-align: “click-align config.click | click”.

Now, download and unpack click-tutorial1.tar.gz. You will do your work in the click-tutorial1 directory.

Problems

You can check your work on most of the problems by running make grade.

1. Trace files [2 points]. Create a router configuration file called prob1.click that reads packets from the tcpdump trace file ‘f1a.dump’ and writes those packets unchanged to the tcpdump trace file ‘f1b.dump’. The Click driver should exit when f1a.dump is out of packets.

Notes and hints: tcpdump is the canonical program for reading and storing packet traces. It can store packets read from Ethernets, ATM networks, and many other types of links. A tcpdump file’s link type is called its encapsulation. We will be dealing only with raw IP encapsulation, where the files have no link-level headers: the first bytes in each packet will be an IPv4 header.

2. Routing [2 points]. Create a router configuration file called prob2.click that reads packets from the tcpdump trace file ‘f2a.dump’ and routes those packets using the following routing table:

Destination prefix Output trace file
131.0.0.0/8 f2b.dump
131.179.0.0/16 f2c.dump
18.0.0.0/8 f2d.dump
All others f2e.dump

3. Error checking [3 points]. Create a router configuration file called prob3.click, based on prob2.click. The configuration should read from ‘f3a.dump’ and write to ‘f3*.dump’. But this time, you should check for the following six kinds of errors, in this order.

Problem Action
Invalid IP header or checksum Discard packet
Invalid TCP header or checksum Discard packet
Invalid UDP header or checksum Discard packet
Invalid ICMP header or checksum Discard packet
Expired IP TTL Generate appropriate ICMP error message, send message to ‘f3f.dump
Packet longer than 1500 bytes Discard packet

4. Handlers [2 points]. Create a router configuration file called prob4.click, based on prob3.click. It should read from ‘f4a.dump’ and write to ‘f4*.dump’. But this time, in addition to checking for errors, running the configuration should generate a file ‘f4.drops’ containing the following 6 lines:

  1. The number of packets with invalid IP headers or checksums;
  2. The number of packets with invalid TCP headers or checksums;
  3. The number of packets with invalid UDP headers or checksums;
  4. The number of packets with invalid ICMP headers or checksums;
  5. The number of packets with expired IP TTLs; and
  6. The number of packets longer than 1500 bytes.

Each packet will show up in at most one of these counts.

Hint: Check out the Script element.

5. Compound elements [3 points]. Create a partial router configuration file called prob5.click. This file should define a compound element named ‘ErrorChecker’ with one input and one output that implements all the error checks from Problem 3. All erroneous packets should be dropped (not written to a file).

6. Compound element overloading [3 points]. Create a partial router configuration file called prob6.click, based on prob5.click. This time, the ErrorChecker compound element should support three different use patterns. If it is used with one input and one output, it should behave like in Problem 5. If it is used with one input and two outputs, then all erroneous packets should be emitted on the second output (not dropped). If it is used with one input and seven outputs, then the first output is for correct packets, and the following six outputs are used for the six different errors.

7. Scheduling [5 points]. Create a router configuration file called prob7.click. It should read packets from ‘f7a.dump’, maintaining the timing of the dump file. (This means that if two adjacent packets in the dump file have timestamps that are 0.5 seconds apart, the packets will be emitted into the configuration 0.5 seconds apart.) The packets should be written into ‘f7b.dump’, except that:

  • Packets should be written to the dump at a maximum rate of 384 Kb/s. Since the input rate might be more than 384 Kb/s, this means you will need queuing and traffic shaping in your configuration.
  • TCP should always get up to 75% of the bandwidth (up to 288 Kb/s). This means that if the TCP input rate is 288 Kb/s and the UDP input rate is also 288 Kb/s, TCP’s output rate will equal 288 Kb/s and UDP’s output rate will be limited to 96 Kb/s. If the TCP input rate is less than 288 Kb/s, UDP and other kinds of traffic can take up the remainder.
  • Similarly, 25% of the bandwidth should be reserved for UDP and other traffic, if there is enough UDP and other traffic to take up the slack.

Packet timestamps in the output file should reflect the 384 Kb/s rate limit.

8. More error handling [2 points]. Add error handling à la Problem 4 to the configuration of Problem 7. The router configuration file should be called prob8.click, it should read from ‘f8a.dump’ and write to ‘f8b.dump’, it should discard IP TTL-expired packets rather than generate errors, and ‘f8.drops’ should report any packets dropped from queues after the errors already mentioned.

9. Trace analysis [6 points]. Write an executable script called prob9 that takes a single command line argument, a trace file; reads that trace file; and writes the following information about the trace to the standard output:

1. Total number of packets.
2. Average packet size (rounded down to the nearest integer).
3. Average TCP packet size (rounded down to the nearest integer).
4. Average UDP packet size (rounded down to the nearest integer).
5–261. Number of bytes sent to each of the 256 8-bit prefixes. (For example, packets sent to any IP address “169.x.y.z” should be counted towards the 8-bit prefix “169”.) Don’t print lines where the count is zero.
262–518. Number of bytes sent by each of the 256 8-bit subnets.

Packet sizes should include IP headers, but not link-level headers. Use an output format like this (don’t include the parenthetical comments):

10                 (Packet count)
765                (Average packet size)
1500               (Average TCP packet size)
30                 (Average UDP packet size)
dst 169 7650       (Prefix 169 received 7650 bytes)
src 18 7500        (Prefix 18 sent 7500 bytes)
src 19 150         (Prefix 19 sent 150 bytes)

This problem is easiest if you combine a Click script with another script (Perl, Python, or what-have-you) that massages the output into the correct form, but may be possible to do the whole thing with a Script element.

10. Element implementation [EXTRA CREDIT up to 6 points]. Create an element of your own. For example, implement a scheduler, such as a Smoothed Round Robin scheduler (Guo Chuanxiong, “SRR: An O(1) Time Complexity Packet Scheduler for Flows in Multi-Service Packet Networks”, Proc. SIGCOMM 2001); or an active queue management scheme, such as FPQ (Robert Morris, “Scalable TCP Congestion Control”, Proc. INFOCOM 2000); or a packet source, such as an element that reads a file, then sends 1500-byte TCP packets containing that file’s contents as if TCP had sent them; or a packet sink, such as an element that sends the corresponding TCP acknowledgement for each TCP packet received. (The TCP packet source and sink examples can be made pretty interesting if you implement more-or-less-correct TCP behavior.) Be creative!

 
tutorial1.txt · Last modified: 2013/01/17 13:51 by kohler
 
Recent changes RSS feed Driven by DokuWiki