====== 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. **[[tutorial1solutions|Solutions]]** ===== Preparation ===== Obtain Click from [[cvs|anonymous CVS]] and compile and install it. Here's a quick rundown of the commands you'll probably use. $ cd ~ $ cvs -z5 -d :pserver:anonymous@read.cs.ucla.edu:22401/git/click co -d click master ... $ cd click $ ./configure --prefix=$HOME --enable-analysis --enable-test ... $ 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. The ''--enable-analysis'' and ''--enable-test'' configuration switches turn on support for two necessary [[packages|sub-packages]], including trace analysis and regression test elements. 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: [[http://www.tcpdump.org|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: - The number of packets with invalid IP headers or checksums; - The number of packets with invalid TCP headers or checksums; - The number of packets with invalid UDP headers or checksums; - The number of packets with invalid ICMP headers or checksums; - The number of packets with expired IP TTLs; and - The number of packets longer than 1500 bytes. Each packet will show up in at most one of these counts. Hint: Check out the [[elements/Script|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 [[elements/script|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!