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

File exercises-network-metrics-and-analysis.txt, 8.8 KB (added by hervey, 9 years ago)

Exercises for Network Performance Metrics and Local Analysis text

Line 
1Advanced Registry Operations Curriculum
2Network Performance Definitions and Measurement Exercises
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. "RTR-GW>" 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 or open a terminal window as the tladmain 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
43PING localhost (127.0.0.1) 56(84) bytes of data.
4464 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms
4564 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.006 ms
4664 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006 ms
4764 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.006 ms
4864 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.006 ms
4964 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.009 ms
5064 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.007 ms
51^C
52--- localhost ping statistics ---
537 packets transmitted, 7 received, 0% packet loss, time 5994ms
54rtt 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
59Let's create some processing delay in an artificial manner. In one terminal
60window type:
61
62        $ ping localhost
63
64In another terminal window (on the same machine) type:
65
66        $ cd
67        $ vi cpu.sh
68       
69Add the following lines to this file:
70
71        #!/bin/sh
72        sh $0
73        or in c
74        while ( 1 )
75        fork();
76
77Save the file, then make it executable:
78
79        $ chmod a+x cpu.sh
80
81Now run the looping script:
82
83        $ ./cpu.sh
84
85You should see the ping results in your other window start to take more time.
86One you are done press ctrl-c in both terminal windows to stop both processes.
87
88
892. traceroute
90   ----------
91
92You may have used traceroute before, but have you really looked at what it is
93doing? If not, read this:
94
95http://en.wikipedia.org/wiki/Traceroute
96
97Now try:
98
99        $ traceroute nsrc.org
100
101Here's sample output from traceroute to nsrc.org (lines wrapped due to length):
102
103traceroute to nsrc.org (128.223.157.19), 30 hops max, 60 byte packets
104 1  192.168.5.129 (192.168.5.129)  4.291 ms  5.757 ms  6.725 ms
105 2  192.168.17.2 (192.168.17.2)  1.933 ms  1.932 ms  2.150 ms
106 3  192.168.0.1 (192.168.0.1)  2.140 ms  2.127 ms  2.598 ms
107 4  10.0.0.129 (10.0.0.129)  2.586 ms  2.576 ms  4.548 ms
108 5   (168.234.72.1)  4.792 ms  4.786 ms  4.750 ms
109 6  200.0.204.69 (200.0.204.69)  7.456 ms  5.665 ms  5.890 ms
110 7  panama-salvador.core.redclara.net (200.0.204.185)  64.651 ms  64.884 ms  64.870 ms
111 8  panama-santiago.core.redclara.net (200.0.204.22)  124.865 ms  124.853 ms  124.841 ms
112 9  saopaulo-santiago.core.redclara.net (200.0.204.38)  172.008 ms  171.793 ms  172.019 ms
11310  ge-7-1-0.0.rtr.chic.net.internet2.edu (64.57.28.114)  172.006 ms
114    xe-2-2-0.88.rtr.wash.net.internet2.edu (198.32.11.105)  244.441 ms  244.675 ms
11511  xe-0-1-0.0.rtr.atla.net.internet2.edu (64.57.28.6)  258.151 ms  258.384 ms  258.618 ms
11612  xe-0-0-0.0.rtr.salt.net.internet2.edu (64.57.28.24)  207.383 ms 
117    207.602 ms xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  282.040 ms
11813  xe-2-0-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  314.004 ms
119    xe-1-0-0.0.rtr.seat.net.internet2.edu (64.57.28.105)  224.293 ms  224.527 ms
12014  vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.948 ms
121    vl-102.xe-1-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.163.69)  227.015 ms
122    vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.184 ms
12315  vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92)  330.660 ms  330.891 ms  229.940 ms
12416  vl-3.uonet2-gw.uoregon.edu (128.223.3.2)  331.359 ms  229.748 ms  229.727 ms
12517  nsrc.org (128.223.157.19)  229.458 ms  229.460 ms  330.862 ms
126
127Do you understand what each item means? If not, see the Wikipedia page and type:
128
129        $ man traceroute
130
131for more information. What does it mean if you see lines like this?
132
13315  * * *
13416  * * *
13517  * * *
136
137Again, read "man traceroute" for details.
138
139As you can see traceroute can be used to determine where problems are taking place
140between two endpoints on a network.
141
142
1433. mtr
144   ---
145
146The mtr tool combines ping and traceroute in to a single, dynamically updating display.
147Give it a try:
148
149        $ mtr nsrc.org
150
151The output of the command looks different on different Linux and UNIX flavors, but in
152general you'll see a summary of packet loss to each node on the path to the remote
153target host, number of ICMP echo request packets sent, last rtt (round-trip-time) to
154the host, average, best and worst rtt as well as the standard deviation of rtt's.
155
156By showing the percent loss of packets in this format it makes it much easier to see
157where you may be having network issues.
158
159
160Exercises Part II
161-----------------
162
163Network Analysis
164----------------
165
1661. lsof and netstat
167   ----------------
168
169See what services are running on your machine. You can use the
170presentation as a reference.
171
172Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see
173the available options (there are a lot!). Remember to use
174sudo when using lsof and netstat to give yourself necessary permissions
175to view everything.
176
177* Using lsof, what IPv4 services are listening on your machine?
178
179* Using netstat, what IPv4 and IPv6 services are listening on your machine?
180
181
1822. tcpdump and tshark
183   ------------------
184
185To use tcpdump you need to use sudo, or be root. To use wireshark you need
186to open a terminal and use sudo as a normal user (i.e., userid "tldadmin"):
187
188Use tcpdump like this:
189
190        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log
191
192Now, generate some traffic on your lo interface in another terminal.
193
194For example:
195
196        $ ping localhost
197        $ ssh localhost
198 
199etc. Afterwords press CTRL-C to terminate the tcpdump session.
200
201Note: ssh generates much more "interesting" output. Now let's read the
202output from tcpdump using shark:
203
204        $ sudo tshark -r /tmp/tcpdump.log | less
205
206What do you see? Can you follow the SSH session you initiated earlier?
207
208Now try something like this:
209
210        $ sudo rm /tmp/tcpdump.log
211        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log
212
213In another terminal do:
214
215        $ ftp limestone.uoregon.edu
216 
217        Connected to limestone.uoregon.edu.
218        220 FTP Server ready.
219        Name (limestone.uoregon.edu:sysadmin): anonymous
220        Password: <anything you want>
221        ftp> exit
222
223End the tcpdump session in the other terminal (CTRL-C). Now view the
224contents of the log file:
225
226        $ sudo tshark -r /tmp/tcpdump.log | less
227
228Can you see your password? If you have a lot of traffic on  your network, then
229the tcpdump.log file may be fairly large. You can search for your FTP session
230by typing:
231
232        "/FTP"
233
234in the output screen. Since you piped your shark command output to the "less"
235command using the "/" to search for strings works. Now press the "n" key for
236"n"ext to follow the FTP session. You should see a line with the string:
237
238        "FTP Request: PASS PasswordYouTypedIn"
239
240Sniffing unencrypted passwords on wireless lans is very easy with a tool like
241this.
242
2433. Using iperf
244   -----------
245
246Use "man iperf" or "iperf -h" for help.
247
248Ask your neighbor to run:
249
250        $ iperf -s
251
252Connect to your neighbor's machine using:
253
254        $ iperf -c ipNeighbor
255
256How is the throughput between  your machines?
257
258Consider connecting both your PCs directly together (one cable,
259no switch). Use a private IP address on both machines, verify
260you can ping each other, then repeat the previous steps with
261your new connection. Has your throughput improved?
262
263If you have time continue playing with iperf options. If you have a
264remote PC running UNIX or Linux you might want to try installing iperf
265and testing your connection from the workshop lab to your remote
266machine.
267
268Some more things to try...
269
270* Test TCP using various window sizes (-2).
271
272* Verify TCP MSS (-m). How does this affect throughput? What is
273  Path MTU discovery?
274
275* Test with two parallel threads (-P) and compare the totals. Is
276  there any difference? Why?
277
278* Test with different packet sizes and the TCP_NODELAY (-N) option.