Agenda: exercises-network-metrics-and-analysis.txt

File exercises-network-metrics-and-analysis.txt, 12.7 KB (added by admin, 8 years ago)
Line 
1Network Performance Definitions and Measurement Exercises
2=========================================================
3
4Notes:
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
15Exercises Part I
16================
17
180. Log in to your PC/VM or open a terminal window as the sysadm user.
19
20Network Performance Metrics
21---------------------------
22
231. ping
24-------
25
26ping is a program that sends ICMP echo request packets to target hosts and
27waits for an ICMP response from the host. Depending on the operating system
28on which you are using ping you may see the minimum, maximum, and the mean
29round-trip times, and sometimes the standard deviation of the mean for the
30ICMP responses from the target host. For more details see:
31
32http://en.wikipedia.org/wiki/Ping
33
34Blocking ping is generally a bad idea.
35
36With all this in mind, try using ping in a few different ways:
37
38    $ ping localhost
39
40Press ctrl-c to stop the process. Here is typical output from the above
41command:
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
56Question: why did the first ICMP response take 20ms while the remaining
57responses were much quicker? This is a type of delay. What kind is it?
58
59
602. traceroute
61-------------
62
63You may have used traceroute before, but have you really looked at what it is
64doing? If not, read this:
65
66http://en.wikipedia.org/wiki/Traceroute
67
68You may need to install the traceroute command first. To do this do:
69
70        $ sudo apt-get install traceroute
71
72Once installed try:
73
74        $ traceroute nsrc.org
75
76Here'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
96Do you understand what each item means? If not, see the Wikipedia page and type:
97
98    $ man traceroute
99
100for more information. What does it mean if you see lines like this?
101
102    15  * * *
103    16  * * *
104    17  * * *
105
106Again, read "man traceroute" for details.
107
108As you can see traceroute can be used to determine where problems are taking place
109between two endpoints on a network.
110
111Try running traceroute again to the same host (nsrc.org). It will likely take considerably
112less time.
113
114
1153. mtr
116------
117
118The mtr tool combines ping and traceroute in to a single, dynamically updating display.
119Before using mtr you may need to first install it:
120
121        $ sudo apt-get install mtr
122
123Now give it a try:
124
125        $ mtr nsrc.org
126
127The output of the command looks different on different Linux and UNIX flavors, but in
128general you'll see a summary of packet loss to each node on the path to the remote
129target host, number of ICMP echo request packets sent, last rtt (round-trip-time) to
130the host, average, best and worst rtt as well as the standard deviation of rtt's.
131
132By showing the percent loss of packets in this format it makes it much easier to see
133where you may be having network issues.
134
135
1364. ping with variable packet size
137---------------------------------
138
139By 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
145However, 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
147most networks before fragmentation takes place (MTU = Maximum Transmission
148Unit)
149
150This simple mechanism can be used to debug all sorts of problems, and even
151distinguish between transmission delay and propagation delay.
152
153For this exercise, first determine your default gateway, which is the first
154hop in a traceroute, or use `netstat -rn` for destination 0.0.0.0
155
156Send 20 standard pings to that address:
157
158        $ ping -c20 10.10.NNN.254
159
160Make a note of the *minimum* round-trip time seen (t1).
161
162Now send 20 maximum-sized pings:
163
164        $ ping -c20 -s1472 10.10.NNN.254
165
166Again, make a note of the *minimum* round-trip time seen (t2).
167
168The propagation delay is the same in both cases, so the larger round-trip
169time must be due to transmission delay.
170
171You can now estimate the transmission delay and hence the bandwidth of
172the 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
179Divide the bits by time to get an estimate of bits per second. Remember to
180convert milliseconds to seconds first.
181
182Example:
183       
184t2 = 1.71
185t1 = 1.14
186
187t2-t1 = 0.57
188
1890.57 ms = 0.00057 sec
190
19122656 bits / 0.00057 sec = 39747368.42 bps
192
193You could then convert this to Kbps, Mbps, etc.
194
195By doing this for subsequent hops, it's possible to estimate the bandwidth
196on each hop, even those remote from you. There is a tool available which
197does this automatically - it's called "pathchar" but you have to build it
198from source. A few OS-specific binaries are available at:
199
200ftp://ftp.ee.lbl.gov/pathchar/
201
202The web page, including documentation is available here:
203
204http://www.caida.org/tools/utilities/others/pathchar/
205
206
207---------------------------------------------------------------------------
208
209
210Exercises Part II
211=================
212
213Network Analysis
214----------------
215
2161. lsof and netstat
217-------------------
218
219See what services are running on your machine. You can use the
220presentation as a reference.
221
222Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see
223the available options (there are a lot!). Remember to use
224sudo when using lsof and netstat to give yourself necessary permissions
225to view everything.
226
227You 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
2352. tcpdump and tshark
236---------------------
237
238First we need to install both these programs:
239
240        $ sudo apt-get install tcpdump tshark
241
242Use tcpdump like this:
243
244        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log
245
246Now, generate some traffic on your lo interface in another terminal.
247
248For example:
249
250        $ ping localhost
251        $ ssh localhost
252 
253etc. Afterwords press CTRL-C to terminate the tcpdump session.
254
255Note: ssh generates much more "interesting" output. Now let's read the
256output from tcpdump using tshark:
257
258        $ sudo tshark -r /tmp/tcpdump.log | less
259
260What do you see? Can you follow the SSH session you initiated earlier?
261
262Next we'll use ftp. First we need to install an ftp client:
263
264        $ sudo apt-get install ftp
265
266Now try something like this:
267
268        $ sudo rm /tmp/tcpdump.log
269        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log
270
271In 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
281End the tcpdump session in the other terminal (CTRL-C). Now view the
282contents of the log file:
283
284        $ sudo tshark -r /tmp/tcpdump.log | less
285
286Can you see your password? If you have a lot of traffic on  your network, then
287the tcpdump.log file may be fairly large. You can search for your FTP session
288by typing:
289
290        "/FTP"
291
292in the output screen. Since you piped your shark command output to the "less"
293command 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
298Sniffing unencrypted passwords on wireless lans is very easy with a tool like
299this.
300
301Rememer to clean up after yourself:
302
303        $ rm /tmp/tcpdump.log
304
305
3063. tcpdump part II
307-------------------
308
309You can use tcpdump as a forensic tool in real-time as well. To completely cover tcpdump would
310take several hours of class time, but let's get started with another practical example.
311
312Let's watch a dhcp request from your PC and the responses that it receives.
313
314First connect to your PC image and become root:
315
316    $ sudo bash
317   
318Next we are going to use a utility called screen:
319
320    # apt-get install screen
321   
322Now run screen:
323
324    # screen
325   
326At this point you can have multiple terminal sessions open in a single ssh window. Let's start
327the tcpdump process listening for dhcp requests:
328
329    # tcpdump -s0 -ni eth0 port 67 or port 68
330
331Now use screen to open another "screen" in your ssh terminal window.
332
333        Press ctrl-a c
334   
335To figure out what "-s0", "-n" and "-i" are doing you can read the tcpdump man page:
336
337        # man tcpdump
338       
339Search for "-s" by typing a "/" and then "-s" and then press ENTER. Press "n" to see the next
340occurrence of the string "-s".
341
342Now make a dhcp request for a new address for eth0 on your machine:
343
344        # dhcpclient
345       
346Return to the previous screen to see what tcpdump displays:
347
348        Press "ctrl-a p"                ("p" for previous, "n" for next" to cycle through screens)
349
350You should see some output like this:
351
352tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
353listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
35418:03:05.003190 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:4a:5e:68:77, length 300
35518:03:05.004349 IP 10.10.0.241.67 > 10.10.0.250.68: BOOTP/DHCP, Reply, length 300
35618:03:05.004364 IP 10.10.0.242.67 > 10.10.0.250.68: BOOTP/DHCP, Reply, length 300
357
358        To stop the tcpdump session type "ctrl-c"
359
360Do you know what this means? Why did we specify to listen on ports 67 and 68? If you look in the
361file /etc/services you will find the following defintions for ports 67 and 68
362
363bootps           67/udp     # Bootstrap Protocol Server
364bootps           67/tcp     # Bootstrap Protocol Server
365bootpc           68/udp     # Bootstrap Protocol Client
366bootpc           68/tcp     # Bootstrap Protocol Client
367
368You can return the screen where you ran dhcpclient and exit from the screen if you wish:
369
370        ctrl-a-n
371       
372Then type:
373
374        # exit
375       
376If you are interested in the screen utility and how it works see:
377
378        http://www.howtoforge.com/linux_screen
379
380for more information or ask your instructor.
381
382
3834. Using iperf
384--------------
385
386First we need to install iperf:
387
388        $ sudo apt-get install iperf
389
390Use "man iperf" or "iperf -h" for help.
391
392Ask your neighbor to run:
393
394        $ iperf -s
395
396Connect to your neighbor's machine using:
397
398        $ iperf -c ipNeighbor
399
400How much throughput is there between your machines? You can repeat this
401exercise with any remote machine where iperf is installed and you have
402an account. This is a quick way to see what bandwidth looks like between
403two points.
404
405To stop the iperf server where you ran "iperf -s" press CTRL-c.
406
407If you have time continue playing with iperf options. If you have a
408remote PC running UNIX or Linux you might want to try installing iperf
409and testing your connection from the workshop lab to your remote
410machine.
411
412Some more things to try...
413
414* Test TCP using various window sizes (-2).
415
416* Verify TCP MSS (-m). How does this affect throughput? What is
417  Path MTU discovery?
418
419* Test with two parallel threads (-P) and compare the totals. Is
420  there any difference? Why?
421
422* Test with different packet sizes and the TCP_NODELAY (-N) option.