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. |
---|