1 | Advanced Registry Operations Curriculum |
---|
2 | Network Performance Definitions and Measurement Exercises |
---|
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. "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 | |
---|
15 | Exercises Part I |
---|
16 | ---------------- |
---|
17 | |
---|
18 | 0. Log in to your PC or open a terminal window as the tladmain 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 | Let's create some processing delay in an artificial manner. In one terminal |
---|
60 | window type: |
---|
61 | |
---|
62 | $ ping localhost |
---|
63 | |
---|
64 | In another terminal window (on the same machine) type: |
---|
65 | |
---|
66 | $ cd |
---|
67 | $ vi cpu.sh |
---|
68 | |
---|
69 | Add the following lines to this file: |
---|
70 | |
---|
71 | #!/bin/sh |
---|
72 | sh $0 |
---|
73 | or in c |
---|
74 | while ( 1 ) |
---|
75 | fork(); |
---|
76 | |
---|
77 | Save the file, then make it executable: |
---|
78 | |
---|
79 | $ chmod a+x cpu.sh |
---|
80 | |
---|
81 | Now run the looping script: |
---|
82 | |
---|
83 | $ ./cpu.sh |
---|
84 | |
---|
85 | You should see the ping results in your other window start to take more time. |
---|
86 | One you are done press ctrl-c in both terminal windows to stop both processes. |
---|
87 | |
---|
88 | |
---|
89 | 2. traceroute |
---|
90 | ---------- |
---|
91 | |
---|
92 | You may have used traceroute before, but have you really looked at what it is |
---|
93 | doing? If not, read this: |
---|
94 | |
---|
95 | http://en.wikipedia.org/wiki/Traceroute |
---|
96 | |
---|
97 | Now try: |
---|
98 | |
---|
99 | $ traceroute nsrc.org |
---|
100 | |
---|
101 | Here's sample output from traceroute to nsrc.org (lines wrapped due to length): |
---|
102 | |
---|
103 | traceroute 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 |
---|
113 | 10 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 |
---|
115 | 11 xe-0-1-0.0.rtr.atla.net.internet2.edu (64.57.28.6) 258.151 ms 258.384 ms 258.618 ms |
---|
116 | 12 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 |
---|
118 | 13 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 |
---|
120 | 14 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 |
---|
123 | 15 vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92) 330.660 ms 330.891 ms 229.940 ms |
---|
124 | 16 vl-3.uonet2-gw.uoregon.edu (128.223.3.2) 331.359 ms 229.748 ms 229.727 ms |
---|
125 | 17 nsrc.org (128.223.157.19) 229.458 ms 229.460 ms 330.862 ms |
---|
126 | |
---|
127 | Do you understand what each item means? If not, see the Wikipedia page and type: |
---|
128 | |
---|
129 | $ man traceroute |
---|
130 | |
---|
131 | for more information. What does it mean if you see lines like this? |
---|
132 | |
---|
133 | 15 * * * |
---|
134 | 16 * * * |
---|
135 | 17 * * * |
---|
136 | |
---|
137 | Again, read "man traceroute" for details. |
---|
138 | |
---|
139 | As you can see traceroute can be used to determine where problems are taking place |
---|
140 | between two endpoints on a network. |
---|
141 | |
---|
142 | |
---|
143 | 3. mtr |
---|
144 | --- |
---|
145 | |
---|
146 | The mtr tool combines ping and traceroute in to a single, dynamically updating display. |
---|
147 | Give it a try: |
---|
148 | |
---|
149 | $ mtr nsrc.org |
---|
150 | |
---|
151 | The output of the command looks different on different Linux and UNIX flavors, but in |
---|
152 | general you'll see a summary of packet loss to each node on the path to the remote |
---|
153 | target host, number of ICMP echo request packets sent, last rtt (round-trip-time) to |
---|
154 | the host, average, best and worst rtt as well as the standard deviation of rtt's. |
---|
155 | |
---|
156 | By showing the percent loss of packets in this format it makes it much easier to see |
---|
157 | where you may be having network issues. |
---|
158 | |
---|
159 | |
---|
160 | Exercises Part II |
---|
161 | ----------------- |
---|
162 | |
---|
163 | Network Analysis |
---|
164 | ---------------- |
---|
165 | |
---|
166 | 1. lsof and netstat |
---|
167 | ---------------- |
---|
168 | |
---|
169 | See what services are running on your machine. You can use the |
---|
170 | presentation as a reference. |
---|
171 | |
---|
172 | Or, utilize "man lsof", "man netstat", "lsof -h" and "netstat -h" to see |
---|
173 | the available options (there are a lot!). Remember to use |
---|
174 | sudo when using lsof and netstat to give yourself necessary permissions |
---|
175 | to 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 | |
---|
182 | 2. tcpdump and tshark |
---|
183 | ------------------ |
---|
184 | |
---|
185 | To use tcpdump you need to use sudo, or be root. To use wireshark you need |
---|
186 | to open a terminal and use sudo as a normal user (i.e., userid "tldadmin"): |
---|
187 | |
---|
188 | Use tcpdump like this: |
---|
189 | |
---|
190 | $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log |
---|
191 | |
---|
192 | Now, generate some traffic on your lo interface in another terminal. |
---|
193 | |
---|
194 | For example: |
---|
195 | |
---|
196 | $ ping localhost |
---|
197 | $ ssh localhost |
---|
198 | |
---|
199 | etc. Afterwords press CTRL-C to terminate the tcpdump session. |
---|
200 | |
---|
201 | Note: ssh generates much more "interesting" output. Now let's read the |
---|
202 | output from tcpdump using shark: |
---|
203 | |
---|
204 | $ sudo tshark -r /tmp/tcpdump.log | less |
---|
205 | |
---|
206 | What do you see? Can you follow the SSH session you initiated earlier? |
---|
207 | |
---|
208 | Now try something like this: |
---|
209 | |
---|
210 | $ sudo rm /tmp/tcpdump.log |
---|
211 | $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log |
---|
212 | |
---|
213 | In 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 | |
---|
223 | End the tcpdump session in the other terminal (CTRL-C). Now view the |
---|
224 | contents of the log file: |
---|
225 | |
---|
226 | $ sudo tshark -r /tmp/tcpdump.log | less |
---|
227 | |
---|
228 | Can you see your password? If you have a lot of traffic on your network, then |
---|
229 | the tcpdump.log file may be fairly large. You can search for your FTP session |
---|
230 | by typing: |
---|
231 | |
---|
232 | "/FTP" |
---|
233 | |
---|
234 | in the output screen. Since you piped your shark command output to the "less" |
---|
235 | command 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 | |
---|
240 | Sniffing unencrypted passwords on wireless lans is very easy with a tool like |
---|
241 | this. |
---|
242 | |
---|
243 | 3. Using iperf |
---|
244 | ----------- |
---|
245 | |
---|
246 | Use "man iperf" or "iperf -h" for help. |
---|
247 | |
---|
248 | Ask your neighbor to run: |
---|
249 | |
---|
250 | $ iperf -s |
---|
251 | |
---|
252 | Connect to your neighbor's machine using: |
---|
253 | |
---|
254 | $ iperf -c ipNeighbor |
---|
255 | |
---|
256 | How is the throughput between your machines? |
---|
257 | |
---|
258 | Consider connecting both your PCs directly together (one cable, |
---|
259 | no switch). Use a private IP address on both machines, verify |
---|
260 | you can ping each other, then repeat the previous steps with |
---|
261 | your new connection. Has your throughput improved? |
---|
262 | |
---|
263 | If you have time continue playing with iperf options. If you have a |
---|
264 | remote PC running UNIX or Linux you might want to try installing iperf |
---|
265 | and testing your connection from the workshop lab to your remote |
---|
266 | machine. |
---|
267 | |
---|
268 | Some 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. |
---|