| 1 | Network Performance Definitions and Measurement Exercises |
|---|
| 2 | ========================================================= |
|---|
| 3 | |
|---|
| 4 | Notes: |
|---|
| 5 | ------ |
|---|
| 6 | * Commands preceded with "$" imply that you should execute the command as |
|---|
| 7 | a general user - not as root. |
|---|
| 8 | * Commands preceded with "#" imply that you should be working as root. |
|---|
| 9 | * Commands with more specific command lines (e.g. "GW-RTR>" or "mysql>") |
|---|
| 10 | imply that you are executing commands on remote equipment, or within |
|---|
| 11 | another program. |
|---|
| 12 | * If a command line ends with "\" this indicates that the command continues |
|---|
| 13 | on the next line and you should treat this as a single line. |
|---|
| 14 | |
|---|
| 15 | Exercises Part I |
|---|
| 16 | ================ |
|---|
| 17 | |
|---|
| 18 | 0. Log in to your PC/VM or open a terminal window as the sysadm user. |
|---|
| 19 | |
|---|
| 20 | Network Performance Metrics |
|---|
| 21 | --------------------------- |
|---|
| 22 | |
|---|
| 23 | 1. ping |
|---|
| 24 | ------- |
|---|
| 25 | |
|---|
| 26 | ping is a program that sends ICMP echo request packets to target hosts and |
|---|
| 27 | waits for an ICMP response from the host. Depending on the operating system |
|---|
| 28 | on which you are using ping you may see the minimum, maximum, and the mean |
|---|
| 29 | round-trip times, and sometimes the standard deviation of the mean for the |
|---|
| 30 | ICMP responses from the target host. For more details see: |
|---|
| 31 | |
|---|
| 32 | http://en.wikipedia.org/wiki/Ping |
|---|
| 33 | |
|---|
| 34 | Blocking ping is generally a bad idea. |
|---|
| 35 | |
|---|
| 36 | With all this in mind, try using ping in a few different ways: |
|---|
| 37 | |
|---|
| 38 | $ ping localhost |
|---|
| 39 | |
|---|
| 40 | Press ctrl-c to stop the process. Here is typical output from the above |
|---|
| 41 | command: |
|---|
| 42 | |
|---|
| 43 | PING localhost (127.0.0.1) 56(84) bytes of data. |
|---|
| 44 | 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms |
|---|
| 45 | 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.006 ms |
|---|
| 46 | 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006 ms |
|---|
| 47 | 64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.006 ms |
|---|
| 48 | 64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.006 ms |
|---|
| 49 | 64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.009 ms |
|---|
| 50 | 64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.007 ms |
|---|
| 51 | ^C |
|---|
| 52 | --- localhost ping statistics --- |
|---|
| 53 | 7 packets transmitted, 7 received, 0% packet loss, time 5994ms |
|---|
| 54 | rtt min/avg/max/mdev = 0.006/0.008/0.020/0.005 ms |
|---|
| 55 | |
|---|
| 56 | Question: why did the first ICMP response take 20ms while the remaining |
|---|
| 57 | responses were much quicker? This is a type of delay. What kind is it? |
|---|
| 58 | |
|---|
| 59 | |
|---|
| 60 | 2. traceroute |
|---|
| 61 | ------------- |
|---|
| 62 | |
|---|
| 63 | You may have used traceroute before, but have you really looked at what it is |
|---|
| 64 | doing? If not, read this: |
|---|
| 65 | |
|---|
| 66 | http://en.wikipedia.org/wiki/Traceroute |
|---|
| 67 | |
|---|
| 68 | You may need to install the traceroute command first. To do this do: |
|---|
| 69 | |
|---|
| 70 | $ sudo apt-get install traceroute |
|---|
| 71 | |
|---|
| 72 | Once installed try: |
|---|
| 73 | |
|---|
| 74 | $ traceroute nsrc.org |
|---|
| 75 | |
|---|
| 76 | Here's sample output from traceroute to nsrc.org (lines wrapped due to length): |
|---|
| 77 | |
|---|
| 78 | traceroute to nsrc.org (128.223.157.19), 64 hops max, 52 byte packets |
|---|
| 79 | 1 gw.ws.nsrc.org (10.10.0.254) 1.490 ms 1.069 ms 1.055 ms |
|---|
| 80 | 2 192.248.5.2 (192.248.5.2) 2.741 ms 2.450 ms 3.182 ms |
|---|
| 81 | 3 192.248.1.126 (192.248.1.126) 2.473 ms 2.497 ms 2.618 ms |
|---|
| 82 | 4 mb-t3-01-v4.bb.tein3.net (202.179.249.93) 26.324 ms 28.049 ms 27.403 ms |
|---|
| 83 | 5 sg-so-06-v4.bb.tein3.net (202.179.249.81) 103.321 ms 91.072 ms 91.674 ms |
|---|
| 84 | 6 jp-pop-sg-v4.bb.tein3.net (202.179.249.50) 168.948 ms 168.712 ms 168.903 ms |
|---|
| 85 | 7 tpr5-ge0-0-0-4.jp.apan.net (203.181.248.250) 172.789 ms 170.367 ms 188.689 ms |
|---|
| 86 | 8 losa-tokyo-tp2.transpac2.net (192.203.116.145) 579.586 ms 284.736 ms 284.202 ms |
|---|
| 87 | 9 abilene-1-lo-jmb-702.lsanca.pacificwave.net (207.231.240.131) 303.736 ms |
|---|
| 88 | 284.884 ms 530.854 ms |
|---|
| 89 | 10 vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65) 328.082 ms |
|---|
| 90 | 305.800 ms 533.644 ms |
|---|
| 91 | 11 vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92) 336.680 ms 617.267 ms |
|---|
| 92 | 495.685 ms |
|---|
| 93 | 12 vl-3.uonet2-gw.uoregon.edu (128.223.3.2) 310.552 ms 421.638 ms 612.399 ms |
|---|
| 94 | 13 nsrc.org (128.223.157.19) 309.548 ms 612.151 ms 611.505 ms |
|---|
| 95 | |
|---|
| 96 | Do you understand what each item means? If not, see the Wikipedia page and type: |
|---|
| 97 | |
|---|
| 98 | $ man traceroute |
|---|
| 99 | |
|---|
| 100 | for more information. What does it mean if you see lines like this? |
|---|
| 101 | |
|---|
| 102 | 15 * * * |
|---|
| 103 | 16 * * * |
|---|
| 104 | 17 * * * |
|---|
| 105 | |
|---|
| 106 | Again, read "man traceroute" for details. |
|---|
| 107 | |
|---|
| 108 | As you can see traceroute can be used to determine where problems are taking place |
|---|
| 109 | between two endpoints on a network. |
|---|
| 110 | |
|---|
| 111 | Try running traceroute again to the same host (nsrc.org). It will likely take considerably |
|---|
| 112 | less time. |
|---|
| 113 | |
|---|
| 114 | |
|---|
| 115 | 3. mtr |
|---|
| 116 | ------ |
|---|
| 117 | |
|---|
| 118 | The mtr tool combines ping and traceroute in to a single, dynamically updating display. |
|---|
| 119 | Before using mtr you may need to first install it: |
|---|
| 120 | |
|---|
| 121 | $ sudo apt-get install mtr |
|---|
| 122 | |
|---|
| 123 | Now give it a try: |
|---|
| 124 | |
|---|
| 125 | $ mtr nsrc.org |
|---|
| 126 | |
|---|
| 127 | The output of the command looks different on different Linux and UNIX flavors, but in |
|---|
| 128 | general you'll see a summary of packet loss to each node on the path to the remote |
|---|
| 129 | target host, number of ICMP echo request packets sent, last rtt (round-trip-time) to |
|---|
| 130 | the host, average, best and worst rtt as well as the standard deviation of rtt's. |
|---|
| 131 | |
|---|
| 132 | By showing the percent loss of packets in this format it makes it much easier to see |
|---|
| 133 | where you may be having network issues. |
|---|
| 134 | |
|---|
| 135 | |
|---|
| 136 | 4. ping with variable packet size |
|---|
| 137 | --------------------------------- |
|---|
| 138 | |
|---|
| 139 | By default, ping sends out IP datagrams of size 84 bytes: |
|---|
| 140 | |
|---|
| 141 | * 20 bytes IP header |
|---|
| 142 | * 8 bytes ICMP header |
|---|
| 143 | * 56 bytes data padding |
|---|
| 144 | |
|---|
| 145 | However, you can send out larger packets using the -s option. Using |
|---|
| 146 | `-s 1472` will give you a 1500-byte IP datagram, which is the maximum for |
|---|
| 147 | most networks before fragmentation takes place (MTU = Maximum Transmission |
|---|
| 148 | Unit) |
|---|
| 149 | |
|---|
| 150 | This simple mechanism can be used to debug all sorts of problems, and even |
|---|
| 151 | distinguish between transmission delay and propagation delay. |
|---|
| 152 | |
|---|
| 153 | For this exercise, first determine your default gateway, which is the first |
|---|
| 154 | hop in a traceroute, or use `netstat -rn` for destination 0.0.0.0 |
|---|
| 155 | |
|---|
| 156 | Send 20 standard pings to that address: |
|---|
| 157 | |
|---|
| 158 | $ ping -c20 10.10.0.254 |
|---|
| 159 | |
|---|
| 160 | Make a note of the *minimum* round-trip time seen (t1). |
|---|
| 161 | |
|---|
| 162 | Now send 20 maximum-sized pings: |
|---|
| 163 | |
|---|
| 164 | $ ping -c20 -s1472 10.10.0.254 |
|---|
| 165 | |
|---|
| 166 | Again, make a note of the *minimum* round-trip time seen (t2). |
|---|
| 167 | |
|---|
| 168 | The propagation delay is the same in both cases, so the larger round-trip |
|---|
| 169 | time must be due to transmission delay. |
|---|
| 170 | |
|---|
| 171 | You can now estimate the transmission delay and hence the bandwidth of |
|---|
| 172 | the link. |
|---|
| 173 | |
|---|
| 174 | increase in transmission time = t2 - t1 |
|---|
| 175 | increase in bits sent = (1500-84) * 8 * 2 = 22656 |
|---|
| 176 | |
|---|
| 177 | (multiply by 2 because the round-trip time involves sending the packet twice) |
|---|
| 178 | |
|---|
| 179 | Divide the bits by time to get an estimate of bits per second. Remember to |
|---|
| 180 | convert milliseconds to seconds first. |
|---|
| 181 | |
|---|
| 182 | Example: |
|---|
| 183 | |
|---|
| 184 | t2 = 1.71 |
|---|
| 185 | t1 = 1.14 |
|---|
| 186 | |
|---|
| 187 | t2-t1 = 0.57 |
|---|
| 188 | |
|---|
| 189 | 0.57 ms = 0.00057 sec |
|---|
| 190 | |
|---|
| 191 | 22656 bits / 0.00057 sec = 39747368.42 bps |
|---|
| 192 | |
|---|
| 193 | You could then convert this to Kbps, Mbps, etc. |
|---|
| 194 | |
|---|
| 195 | By doing this for subsequent hops, it's possible to estimate the bandwidth |
|---|
| 196 | on each hop, even those remote from you. There is a tool available which |
|---|
| 197 | does this automatically - it's called "pathchar" but you have to build it |
|---|
| 198 | from source. A few OS-specific binaries are available at: |
|---|
| 199 | |
|---|
| 200 | ftp://ftp.ee.lbl.gov/pathchar/ |
|---|
| 201 | |
|---|
| 202 | The web page, including documentation is available here: |
|---|
| 203 | |
|---|
| 204 | http://www.caida.org/tools/utilities/others/pathchar/ |
|---|
| 205 | |
|---|
| 206 | |
|---|
| 207 | --------------------------------------------------------------------------- |
|---|
| 208 | |
|---|
| 209 | |
|---|
| 210 | Exercises Part II |
|---|
| 211 | ================= |
|---|
| 212 | |
|---|
| 213 | Network Analysis |
|---|
| 214 | ---------------- |
|---|
| 215 | |
|---|
| 216 | 1. lsof and netstat |
|---|
| 217 | ------------------- |
|---|
| 218 | |
|---|
| 219 | See what services are running on your machine. You can use the |
|---|
| 220 | presentation as a reference. |
|---|
| 221 | |
|---|
| 222 | Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see |
|---|
| 223 | the available options (there are a lot!). Remember to use |
|---|
| 224 | sudo when using lsof and netstat to give yourself necessary permissions |
|---|
| 225 | to view everything. |
|---|
| 226 | |
|---|
| 227 | You may need to install lsof. To do this type: |
|---|
| 228 | |
|---|
| 229 | $ sudo apt-get install lsof |
|---|
| 230 | |
|---|
| 231 | * Using lsof, what IPv4 services are listening on your machine? |
|---|
| 232 | * Using netstat, what IPv4 and IPv6 services are listening on your machine? |
|---|
| 233 | |
|---|
| 234 | |
|---|
| 235 | 2. tcpdump and tshark |
|---|
| 236 | --------------------- |
|---|
| 237 | |
|---|
| 238 | First we need to install both these programs: |
|---|
| 239 | |
|---|
| 240 | $ sudo apt-get install tcpdump tshark |
|---|
| 241 | |
|---|
| 242 | Use tcpdump like this: |
|---|
| 243 | |
|---|
| 244 | $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log |
|---|
| 245 | |
|---|
| 246 | Now, generate some traffic on your lo interface in another terminal. |
|---|
| 247 | |
|---|
| 248 | For example: |
|---|
| 249 | |
|---|
| 250 | $ ping localhost |
|---|
| 251 | $ ssh localhost |
|---|
| 252 | |
|---|
| 253 | etc. Afterwords press CTRL-C to terminate the tcpdump session. |
|---|
| 254 | |
|---|
| 255 | Note: ssh generates much more "interesting" output. Now let's read the |
|---|
| 256 | output from tcpdump using tshark: |
|---|
| 257 | |
|---|
| 258 | $ sudo tshark -r /tmp/tcpdump.log | less |
|---|
| 259 | |
|---|
| 260 | What do you see? Can you follow the SSH session you initiated earlier? |
|---|
| 261 | |
|---|
| 262 | Next we'll use ftp. First we need to install an ftp client: |
|---|
| 263 | |
|---|
| 264 | $ sudo apt-get install ftp |
|---|
| 265 | |
|---|
| 266 | Now try something like this: |
|---|
| 267 | |
|---|
| 268 | $ sudo rm /tmp/tcpdump.log |
|---|
| 269 | $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log |
|---|
| 270 | |
|---|
| 271 | In another terminal do: |
|---|
| 272 | |
|---|
| 273 | $ ftp limestone.uoregon.edu |
|---|
| 274 | |
|---|
| 275 | Connected to limestone.uoregon.edu. |
|---|
| 276 | 220 FTP Server ready. |
|---|
| 277 | Name (limestone.uoregon.edu:sysadmin): anonymous |
|---|
| 278 | Password: <anything you want> |
|---|
| 279 | ftp> exit |
|---|
| 280 | |
|---|
| 281 | End the tcpdump session in the other terminal (CTRL-C). Now view the |
|---|
| 282 | contents of the log file: |
|---|
| 283 | |
|---|
| 284 | $ sudo tshark -r /tmp/tcpdump.log | less |
|---|
| 285 | |
|---|
| 286 | Can you see your password? If you have a lot of traffic on your network, then |
|---|
| 287 | the tcpdump.log file may be fairly large. You can search for your FTP session |
|---|
| 288 | by typing: |
|---|
| 289 | |
|---|
| 290 | "/FTP" |
|---|
| 291 | |
|---|
| 292 | in the output screen. Since you piped your shark command output to the "less" |
|---|
| 293 | command using the "/" to search for strings works. Now press the "n" key for |
|---|
| 294 | "n"ext to follow the FTP session. You should see a line with the string: |
|---|
| 295 | |
|---|
| 296 | "FTP Request: PASS PasswordYouTypedIn" |
|---|
| 297 | |
|---|
| 298 | Sniffing unencrypted passwords on wireless lans is very easy with a tool like |
|---|
| 299 | this. |
|---|
| 300 | |
|---|
| 301 | Rememer to clean up after yourself: |
|---|
| 302 | |
|---|
| 303 | $ rm /tmp/tcpdump.log |
|---|
| 304 | |
|---|
| 305 | |
|---|
| 306 | 3. Using iperf |
|---|
| 307 | -------------- |
|---|
| 308 | |
|---|
| 309 | First we need to install iperf: |
|---|
| 310 | |
|---|
| 311 | $ sudo apt-get install iperf |
|---|
| 312 | |
|---|
| 313 | Use "man iperf" or "iperf -h" for help. |
|---|
| 314 | |
|---|
| 315 | Ask your neighbor to run: |
|---|
| 316 | |
|---|
| 317 | $ iperf -s |
|---|
| 318 | |
|---|
| 319 | Connect to your neighbor's machine using: |
|---|
| 320 | |
|---|
| 321 | $ iperf -c ipNeighbor |
|---|
| 322 | |
|---|
| 323 | How much throughput is there between your machines? You can repeat this |
|---|
| 324 | exercise with any remote machine where iperf is installed and you have |
|---|
| 325 | an account. This is a quick way to see what bandwidth looks like between |
|---|
| 326 | two points. |
|---|
| 327 | |
|---|
| 328 | To stop the iperf server where you ran "iperf -s" press CTRL-c. |
|---|
| 329 | |
|---|
| 330 | If you have time continue playing with iperf options. If you have a |
|---|
| 331 | remote PC running UNIX or Linux you might want to try installing iperf |
|---|
| 332 | and testing your connection from the workshop lab to your remote |
|---|
| 333 | machine. |
|---|
| 334 | |
|---|
| 335 | Some more things to try... |
|---|
| 336 | |
|---|
| 337 | * Test TCP using various window sizes (-2). |
|---|
| 338 | |
|---|
| 339 | * Verify TCP MSS (-m). How does this affect throughput? What is |
|---|
| 340 | Path MTU discovery? |
|---|
| 341 | |
|---|
| 342 | * Test with two parallel threads (-P) and compare the totals. Is |
|---|
| 343 | there any difference? Why? |
|---|
| 344 | |
|---|
| 345 | * Test with different packet sizes and the TCP_NODELAY (-N) option. |
|---|