Network Performance Definitions and Measurement Exercises ========================================================= Notes: ------ * Commands preceded with "$" imply that you should execute the command as a general user - not as root. * Commands preceded with "#" imply that you should be working as root. * Commands with more specific command lines (e.g. "GW-RTR>" or "mysql>") imply that you are executing commands on remote equipment, or within another program. * If a command line ends with "\" this indicates that the command continues on the next line and you should treat this as a single line. Exercises Part I ================ 0. Log in to your PC/VM or open a terminal window as the afnog user. Network Performance Metrics --------------------------- 1. ping with variable packet size --------------------------------- By default, ping sends out IP datagrams of size 84 bytes: * 20 bytes IP header * 8 bytes ICMP header * 56 bytes data padding However, you can send out larger packets using the -s option. Using `-s 1472` will give you a 1500-byte IP datagram, which is the maximum for most networks before fragmentation takes place (MTU = Maximum Transmission Unit) This simple mechanism can be used to debug all sorts of problems, and even distinguish between transmission delay and propagation delay. For this exercise, first determine your default gateway, which is the first hop in a traceroute, or use `netstat -rn` for destination 0.0.0.0 Send 20 standard pings to that address: $ ping -c20 10.10.nnn.254 Make a note of the *minimum* round-trip time seen (t1). Now send 20 maximum-sized pings: $ ping -c20 -s1472 10.10.nnn.254 Again, make a note of the *minimum* round-trip time seen (t2). The propagation delay is the same in both cases, so the larger round-trip time must be due to transmission delay. You can now estimate the transmission delay and hence the bandwidth of the link. increase in transmission time = t2 - t1 increase in bits sent = (1500-84) * 8 * 2 = 22656 (multiply by 2 because the round-trip time involves sending the packet twice) Divide the bits by time to get an estimate of bits per second. Remember to convert milliseconds to seconds first. Example: t2 = 1.71 t1 = 1.14 t2-t1 = 0.57 0.57 ms = 0.00057 sec 22656 bits / 0.00057 sec = 39747368.42 bps You could then convert this to Kbps, Mbps, etc. By doing this for subsequent hops, it's possible to estimate the bandwidth on each hop, even those remote from you. There is a tool available which does this automatically - it's called "pathchar" but you have to build it from source. A few OS-specific binaries are available at: ftp://ftp.ee.lbl.gov/pathchar/ The web page, including documentation is available here: http://www.caida.org/tools/utilities/others/pathchar/ --------------------------------------------------------------------------- Exercises Part II ================= Network Analysis ---------------- 1. lsof and netstat ------------------- See what services are running on your machine. You can use the presentation as a reference. Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see the available options (there are a lot!). Remember to use sudo when using lsof and netstat to give yourself necessary permissions to view everything. You may need to install lsof. To do this type: $ sudo portmaster -P sysutils/lsof Using these two packages can you figure out? * What IPv4 services are listening on your machine? * What IPv4 and IPv6 services are listening on your machine? 2. tcpdump and tshark --------------------- First we need to install both these programs: $ sudo portmaster -P net/tshark-lite We get the lite version of the package as even that is quite large. Reply "yes" when asked if you wish to proceed with install the multiple pacakges needed. Installation may take some time. If so, Use tcpdump like this: $ sudo tcpdump -i eth0 -w /tmp/tcpdump.log There should be quite a bit of traffic on the network. Let this command run for about a minute and then press CTRL-c to terminate the command. Now let's read the output from tcpdump using tshark: $ sudo tshark -r /tmp/tcpdump.log | less Now try something like this: $ sudo rm /tmp/tcpdump.log $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log In another terminal do: $ ftp limestone.uoregon.edu Connected to limestone.uoregon.edu. 220 FTP Server ready. Name (limestone.uoregon.edu:sysadmin): anonymous Password: ftp> exit End the tcpdump session in the other terminal (CTRL-C). Now view the contents of the log file: $ sudo tshark -r /tmp/tcpdump.log | less Can you see your password? If you have a lot of traffic on your network, then the tcpdump.log file may be fairly large. You can search for your FTP session by typing: "/FTP" in the output screen. Since you piped your shark command output to the "less" command using the "/" to search for strings works. Now press the "n" key for "n"ext to follow the FTP session. You should see a line with the string: "FTP Request: PASS PasswordYouTypedIn" Sniffing unencrypted passwords on wireless lans is very easy with a tool like this. Rememer to clean up after yourself: $ sudo rm /tmp/tcpdump.log 4. Using iperf -------------- First we need to install iperf: $ sudo portmaster -P benchmarks/iperf Use "man iperf" or "iperf -h" for help. Ask your neighbor to run: $ iperf -s Connect to your neighbor's machine using: $ iperf -c ipNeighbor If you don't know the IP address of your neighbor's machine ask them to do: $ ifconfig eth0 and tell you what IP address their machine is using. The test may take a few moments to complete. How much throughput is there between your machines? You can repeat this exercise with any remote machine where iperf is installed and you have an account. This is a quick way to see what bandwidth looks like between two points. To stop the iperf server where you ran "iperf -s" press CTRL-c. If you have time continue playing with iperf options. If you have a remote PC running UNIX or Linux you might want to try installing iperf and testing your connection from the workshop lab to your remote machine. Some more things to try... * Test TCP using various window sizes (-2). * Verify TCP MSS (-m). How does this affect throughput? What is Path MTU discovery? * Test with two parallel threads (-P) and compare the totals. Is there any difference? Why? * Test with different packet sizes and the TCP_NODELAY (-N) option.