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

File exercises-network-metrics-and-analysis.txt, 10.3 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
68Now try:
69
70        $ traceroute nsrc.org
71
72Here's sample output from traceroute to nsrc.org (lines wrapped due to length):
73
74    traceroute to nsrc.org (128.223.157.19), 30 hops max, 60 byte packets
75     1  192.168.5.129 (192.168.5.129)  4.291 ms  5.757 ms  6.725 ms
76     2  192.168.17.2 (192.168.17.2)  1.933 ms  1.932 ms  2.150 ms
77     3  192.168.0.1 (192.168.0.1)  2.140 ms  2.127 ms  2.598 ms
78     4  10.0.0.129 (10.0.0.129)  2.586 ms  2.576 ms  4.548 ms
79     5   (168.234.72.1)  4.792 ms  4.786 ms  4.750 ms
80     6  200.0.204.69 (200.0.204.69)  7.456 ms  5.665 ms  5.890 ms
81     7  panama-salvador.core.redclara.net (200.0.204.185)  64.651 ms  64.884 ms  64.870 ms
82     8  panama-santiago.core.redclara.net (200.0.204.22)  124.865 ms  124.853 ms  124.841 ms
83     9  saopaulo-santiago.core.redclara.net (200.0.204.38)  172.008 ms  171.793 ms  172.019 ms
84    10  ge-7-1-0.0.rtr.chic.net.internet2.edu (64.57.28.114)  172.006 ms
85        xe-2-2-0.88.rtr.wash.net.internet2.edu (198.32.11.105)  244.441 ms  244.675 ms
86    11  xe-0-1-0.0.rtr.atla.net.internet2.edu (64.57.28.6)  258.151 ms  258.384 ms  258.618 ms
87    12  xe-0-0-0.0.rtr.salt.net.internet2.edu (64.57.28.24)  207.383 ms 
88        207.602 ms xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  282.040 ms
89    13  xe-2-0-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  314.004 ms
90        xe-1-0-0.0.rtr.seat.net.internet2.edu (64.57.28.105)  224.293 ms  224.527 ms
91    14  vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.948 ms
92        vl-102.xe-1-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.163.69)  227.015 ms
93        vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.184 ms
94    15  vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92)  330.660 ms  330.891 ms  229.940 ms
95    16  vl-3.uonet2-gw.uoregon.edu (128.223.3.2)  331.359 ms  229.748 ms  229.727 ms
96    17  nsrc.org (128.223.157.19)  229.458 ms  229.460 ms  330.862 ms
97
98Do you understand what each item means? If not, see the Wikipedia page and type:
99
100    $ man traceroute
101
102for more information. What does it mean if you see lines like this?
103
104    15  * * *
105    16  * * *
106    17  * * *
107
108Again, read "man traceroute" for details.
109
110As you can see traceroute can be used to determine where problems are taking place
111between two endpoints on a network.
112
113
1143. mtr
115------
116
117The mtr tool combines ping and traceroute in to a single, dynamically updating display.
118Give it a try:
119
120    $ mtr nsrc.org
121
122The output of the command looks different on different Linux and UNIX flavors, but in
123general you'll see a summary of packet loss to each node on the path to the remote
124target host, number of ICMP echo request packets sent, last rtt (round-trip-time) to
125the host, average, best and worst rtt as well as the standard deviation of rtt's.
126
127By showing the percent loss of packets in this format it makes it much easier to see
128where you may be having network issues.
129
130
1314. ping with variable packet size
132---------------------------------
133
134By default, ping sends out IP datagrams of size 84 bytes:
135
136* 20 bytes IP header
137*  8 bytes ICMP header
138* 56 bytes data padding
139
140However, you can send out larger packets using the -s option. Using
141`-s 1472` will give you a 1500-byte IP datagram, which is the maximum for
142most networks before fragmentation takes place (MTU = Maximum Transmission
143Unit)
144
145This simple mechanism can be used to debug all sorts of problems, and even
146distinguish between transmission delay and propagation delay.
147
148For this exercise, first determine your default gateway, which is the first
149hop in a traceroute, or use `netstat -rn` for destination 0.0.0.0
150
151Send 20 standard pings to that address:
152
153    $ ping -c20 nsrc.org
154
155Make a note of the *minimum* round-trip time seen (t1).
156
157Now send 20 maximum-sized pings:
158
159    $ ping -c20 -s1472 nsrc.org
160
161Again, make a note of the *minimum* round-trip time seen (t2).
162
163The propagation delay is the same in both cases, so the larger round-trip
164time must be due to transmission delay.
165
166You can now estimate the transmission delay and hence the bandwidth of
167the link.
168
169    increase in transmission time   =  t2 - t1
170    increase in bits sent           =  (1500-84) * 8 * 2  = 22656
171
172(x2 because the round-trip time involves sending the packet twice)
173
174Divide the bits by time to get an estimate of bits per second. Remember to
175convert milliseconds to seconds first.
176
177By doing this for subsequent hops, it's possible to estimate the bandwidth
178on each hop, even those remote from you. There are a number of tools available
179which do this automatically, such as "pathchar" and "bing".
180
181http://www.caida.org/tools/utilities/others/pathchar/
182http://linux.maruhn.com/sec/bing.html
183
184---------------------------------------------------------------------------
185
186
187Exercises Part II
188=================
189
190Network Analysis
191----------------
192
1931. lsof and netstat
194-------------------
195
196See what services are running on your machine. You can use the
197presentation as a reference.
198
199Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see
200the available options (there are a lot!). Remember to use
201sudo when using lsof and netstat to give yourself necessary permissions
202to view everything.
203
204* Using lsof, what IPv4 services are listening on your machine?
205* Using netstat, what IPv4 and IPv6 services are listening on your machine?
206
207
2082. tcpdump and tshark
209---------------------
210
211To use tcpdump you need to use sudo, or be root. To use wireshark you need
212to open a terminal and use sudo as a normal user (i.e. userid "sysadmin"):
213
214Use tcpdump like this:
215
216        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log
217
218Now, generate some traffic on your lo interface in another terminal.
219
220For example:
221
222        $ ping localhost
223        $ ssh localhost
224 
225etc. Afterwords press CTRL-C to terminate the tcpdump session.
226
227Note: ssh generates much more "interesting" output. Now let's read the
228output from tcpdump using shark:
229
230        $ sudo tshark -r /tmp/tcpdump.log | less
231
232What do you see? Can you follow the SSH session you initiated earlier?
233
234Now try something like this:
235
236        $ sudo rm /tmp/tcpdump.log
237        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log
238
239        ... or if tcpdump complains that eth0 doesn't exist, use eth1:
240
241        $ sudo tcpdump -i eth1 -A -s1500 -w /tmp/tcpdump.log
242
243In another terminal do:
244
245        $ ftp limestone.uoregon.edu
246 
247        Connected to limestone.uoregon.edu.
248        220 FTP Server ready.
249        Name (limestone.uoregon.edu:sysadmin): anonymous
250        Password: <anything you want>
251        ftp> exit
252
253End the tcpdump session in the other terminal (CTRL-C). Now view the
254contents of the log file:
255
256        $ sudo tshark -r /tmp/tcpdump.log | less
257
258Can you see your password? If you have a lot of traffic on  your network, then
259the tcpdump.log file may be fairly large. You can search for your FTP session
260by typing:
261
262        "/FTP"
263
264in the output screen. Since you piped your shark command output to the "less"
265command using the "/" to search for strings works. Now press the "n" key for
266"n"ext to follow the FTP session. You should see a line with the string:
267
268        "FTP Request: PASS PasswordYouTypedIn"
269
270Sniffing unencrypted passwords on wireless lans is very easy with a tool like
271this.
272
2733. Using iperf
274--------------
275
276Use "man iperf" or "iperf -h" for help.
277
278Ask your neighbor to run:
279
280        $ iperf -s
281
282Connect to your neighbor's machine using:
283
284        $ iperf -c ipNeighbor
285
286How is the throughput between  your machines?
287
288Consider connecting both your PCs directly together (one cable,
289no switch). Use a private IP address on both machines, verify
290you can ping each other, then repeat the previous steps with
291your new connection. Has your throughput improved?
292
293If you have time continue playing with iperf options. If you have a
294remote PC running UNIX or Linux you might want to try installing iperf
295and testing your connection from the workshop lab to your remote
296machine.
297
298Some more things to try...
299
300* Test TCP using various window sizes (-2).
301
302* Verify TCP MSS (-m). How does this affect throughput? What is
303  Path MTU discovery?
304
305* Test with two parallel threads (-P) and compare the totals. Is
306  there any difference? Why?
307
308* Test with different packet sizes and the TCP_NODELAY (-N) option.