Changes between Initial Version and Version 1 of GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopoQuagga/Execute


Ignore:
Timestamp:
06/16/16 17:16:33 (8 years ago)
Author:
sedwards@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopoQuagga/Execute

    v1 v1  
     1[[PageOutline]]
     2
     3'''[wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy#ATutorialonSystematicExperimentalDesign A Tutorial on Systematic Experimental Design]'''
     4
     5'''[wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy/InstallSoftware Step I: Single Node]'''
     6
     7'''[wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo Step II: Small Topology]'''
     8  * Back to: [wiki:PaperOSRMethodology/Design Design Summary]
     9  * Back to: [wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/DesignSetup Design Step-by-Step Instructions]
     10
     11 
     12{{{
     13#!html
     14
     15<div style="text-align:center; width:495px; margin-left:auto; margin-right:auto;">
     16<img id="Image-Maps_5201305222028436" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/Execute.jpg?format=raw" usemap="#Image-Maps_5201305222028436" border="0" width="495" height="138" alt="" />
     17<map id="_Image-Maps_5201305222028436" name="Image-Maps_5201305222028436">
     18<area shape="rect" coords="18,18,135,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/DesignSetup" alt="" title=""    />
     19<area shape="rect" coords="180,18,297,111" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/Execute" alt="" title=""    />
     20<area shape="rect" coords="344,17,460,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/Finish" alt="" title=""    />
     21<area shape="rect" coords="493,136,495,138" href="http://www.image-maps.com/index.php?aff=mapped_users_5201305222028436" alt="Image Map" title="Image Map" />
     22</map>
     23<!-- Image map text links - End - -->
     24
     25</div>
     26
     27}}}
     28
     29
     30
     31= 5. End-to-End Validation =
     32
     33We first validate end-to-end communication between `client` and server by running `ping` and `traceroute` at the `client`, and then run `iperf` on both `client` and `server`. 
     34
     35Open two terminals, and login to `client` and `server`, respectively.
     36
     37== a. End-to-End `traceroute` and `ping` ==
     38
     39 * Run `ping` from `client` (192.168.10.11) to `server` (192.168.20.10).
     40 
     41{{{
     42xuanliu@client:~$ ping 192.168.20.10
     43PING 192.168.20.10 (192.168.20.10) 56(84) bytes of data.
     4464 bytes from 192.168.20.10: icmp_req=1 ttl=61 time=3.28 ms
     4564 bytes from 192.168.20.10: icmp_req=2 ttl=61 time=2.69 ms
     4664 bytes from 192.168.20.10: icmp_req=3 ttl=61 time=2.73 ms
     47^C
     48--- 192.168.20.10 ping statistics ---
     493 packets transmitted, 3 received, 0% packet loss, time 2003ms
     50rtt min/avg/max/mdev = 2.696/2.905/3.282/0.273 ms
     51}}}
     52
     53
     54 * Run `traceroute` from `client` (192.168.10.11) to `server` (192.168.20.10).
     55
     56{{{
     57xuanliu@client:~$ traceroute 192.168.20.10
     58traceroute to 192.168.20.10 (192.168.20.10), 30 hops max, 60 byte packets
     59 1  router-1-lan4 (192.168.10.10)  0.536 ms  0.596 ms  0.562 ms
     60 2  router-2-lan0 (192.168.1.2)  1.048 ms  0.994 ms  0.979 ms
     61 3  router-3-lan1 (192.168.2.2)  1.368 ms  1.328 ms  1.291 ms
     62 4  server-lan5 (192.168.20.10)  1.878 ms  1.790 ms  1.706 ms
     63}}}
     64
     65
     66== b. `iperf` Test ==
     67
     68 * `iperf` End-to-End TCP test
     69
     70   Server Side:
     71{{{
     72xuanliu@server:~$ iperf -s -t 10 -i 1
     73------------------------------------------------------------
     74Server listening on TCP port 5001
     75TCP window size: 85.3 KByte (default)
     76------------------------------------------------------------
     77[  4] local 192.168.20.10 port 5001 connected with 192.168.10.11 port 54611
     78[ ID] Interval       Transfer     Bandwidth
     79[  4]  0.0- 1.0 sec  12.0 MBytes   101 Mbits/sec
     80[  4]  1.0- 2.0 sec  11.9 MBytes  99.6 Mbits/sec
     81[  4]  2.0- 3.0 sec  11.9 MBytes   100 Mbits/sec
     82[  4]  3.0- 4.0 sec  11.9 MBytes   100 Mbits/sec
     83[  4]  4.0- 5.0 sec  12.0 MBytes   101 Mbits/sec
     84[  4]  5.0- 6.0 sec  11.9 MBytes   100 Mbits/sec
     85[  4]  6.0- 7.0 sec  11.9 MBytes   100 Mbits/sec
     86[  4]  7.0- 8.0 sec  12.0 MBytes   101 Mbits/sec
     87[  4]  8.0- 9.0 sec  11.9 MBytes   100 Mbits/sec
     88[  4]  9.0-10.0 sec  12.0 MBytes   101 Mbits/sec
     89[  4]  0.0-10.1 sec   120 MBytes   100 Mbits/sec
     90}}}
     91
     92   Client Side:
     93{{{
     94xuanliu@client:~$ iperf -c 192.168.20.10 -t 10 -i 1
     95------------------------------------------------------------
     96Client connecting to 192.168.20.10, TCP port 5001
     97TCP window size: 23.5 KByte (default)
     98------------------------------------------------------------
     99[  3] local 192.168.10.11 port 54611 connected with 192.168.20.10 port 5001
     100[ ID] Interval       Transfer     Bandwidth
     101[  3]  0.0- 1.0 sec  12.5 MBytes   105 Mbits/sec
     102[  3]  1.0- 2.0 sec  11.8 MBytes  98.6 Mbits/sec
     103[  3]  2.0- 3.0 sec  12.0 MBytes   101 Mbits/sec
     104[  3]  3.0- 4.0 sec  12.0 MBytes   101 Mbits/sec
     105[  3]  4.0- 5.0 sec  11.9 MBytes  99.6 Mbits/sec
     106[  3]  5.0- 6.0 sec  12.0 MBytes   101 Mbits/sec
     107[  3]  6.0- 7.0 sec  11.9 MBytes  99.6 Mbits/sec
     108[  3]  7.0- 8.0 sec  12.0 MBytes   101 Mbits/sec
     109[  3]  8.0- 9.0 sec  12.0 MBytes   101 Mbits/sec
     110[  3]  9.0-10.0 sec  12.0 MBytes   101 Mbits/sec
     111[  3]  0.0-10.0 sec   120 MBytes   101 Mbits/sec
     112}}}
     113
     114
     115 * `iperf` End-to-End UDP Test, where the bandwidth is set as 1Mbps by default.
     116
     117   Server (192.168.20.10) Side:
     118{{{
     119xuanliu@server:~$ iperf -s -t 10 -i 1 -u
     120------------------------------------------------------------
     121Server listening on UDP port 5001
     122Receiving 1470 byte datagrams
     123UDP buffer size:  224 KByte (default)
     124------------------------------------------------------------
     125[  3] local 192.168.20.10 port 5001 connected with 192.168.10.11 port 33345
     126[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
     127[  3]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec   0.090 ms    0/   89 (0%)
     128[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec   0.219 ms    0/   89 (0%)
     129[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec   0.058 ms    0/   89 (0%)
     130[  3]  3.0- 4.0 sec   128 KBytes  1.05 Mbits/sec   0.050 ms    0/   89 (0%)
     131[  3]  4.0- 5.0 sec   128 KBytes  1.05 Mbits/sec   0.038 ms    0/   89 (0%)
     132[  3]  5.0- 6.0 sec   129 KBytes  1.06 Mbits/sec   0.058 ms    0/   90 (0%)
     133[  3]  6.0- 7.0 sec   128 KBytes  1.05 Mbits/sec   0.079 ms    0/   89 (0%)
     134[  3]  7.0- 8.0 sec   128 KBytes  1.05 Mbits/sec   0.030 ms    0/   89 (0%)
     135[  3]  8.0- 9.0 sec   128 KBytes  1.05 Mbits/sec   0.089 ms    0/   89 (0%)
     136[  3]  9.0-10.0 sec   128 KBytes  1.05 Mbits/sec   0.029 ms    0/   89 (0%)
     137[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.028 ms    0/  893 (0%)
     138}}}
     139
     140   Client (192.168.10.11) Side:
     141{{{
     142xuanliu@client:~$ iperf -c 192.168.20.10 -t 10 -i 1 -u
     143------------------------------------------------------------
     144Client connecting to 192.168.20.10, UDP port 5001
     145Sending 1470 byte datagrams
     146UDP buffer size:  224 KByte (default)
     147------------------------------------------------------------
     148[  3] local 192.168.10.11 port 33345 connected with 192.168.20.10 port 5001
     149[ ID] Interval       Transfer     Bandwidth
     150[  3]  0.0- 1.0 sec   129 KBytes  1.06 Mbits/sec
     151[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec
     152[  3]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec
     153[  3]  3.0- 4.0 sec   128 KBytes  1.05 Mbits/sec
     154[  3]  4.0- 5.0 sec   128 KBytes  1.05 Mbits/sec
     155[  3]  5.0- 6.0 sec   128 KBytes  1.05 Mbits/sec
     156[  3]  6.0- 7.0 sec   129 KBytes  1.06 Mbits/sec
     157[  3]  7.0- 8.0 sec   128 KBytes  1.05 Mbits/sec
     158[  3]  8.0- 9.0 sec   128 KBytes  1.05 Mbits/sec
     159[  3]  9.0-10.0 sec   128 KBytes  1.05 Mbits/sec
     160[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
     161[  3] Sent 893 datagrams
     162[  3] Server Report:
     163[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.028 ms    0/  893 (0%)
     164}}}
     165
     166
     167The `ping` and `iperf` results showed that the communication between the `client` and the `server` were good. Since the `client` and the server are not directly connected, they can communicate with each other means that the `OSPF` routing worked properly.
     168
     169The `traceroute` showed the hops from the `client` to the `server`, where the intermediate hops are `router-1`, `router-2` and `router-3`. This information also verified the routing path between the `client` and the `server`.
     170
     171= 6. Tracking Routing Table Updates =
     172
     173From the `traceroute` result above, we know that from `client` to `server`, the path is `client` --> `router-1` --> `router-2` --> `router-3` --> `server`
     174
     175Now let's try some failure events and see how many updates occurs at a particular router, and we select `router-1` to view the updates, and trigger the failures at `router-2`.
     176
     177 * Login to `router-1` and start the script (i.e., `xorp_log.sh`) that periodically tracking the routing table updates. If there is no change, you will see ''No Change'' from the terminal. Here we run the script for 60 seconds. The script captures the routing table every 1 second.
     178 
     179{{{
     180xuanliu@router-1:~$ cd /local/xorp_run
     181xuanliu@router-1:/local/xorp_run$ /bin/bash xorp_log.sh 60 1
     182/local/xorp_run/logs/rt-change.csv
     18307-01-2014-18-28-28
     184Create the folder for routing table logs
     185/local/xorp_run/logs/xorp-rtable_07-01-2014-18-28-28.txt
     18607-01-2014-18-28-28 1404239308
     187
     188No Change
     189
     190No Change
     191
     192No Change
     193
     194......
     195}}}
     196
     197 * Bring down the interface at router-2
     198
     199 We can make the link between `router-1` and `router-2` fail by bringing down the corresponding interface on `router-2`. While running `xorp_log.sh` at `router-1`, we disable the virtual interface at `router-2`, which is associated with the virtual link (`192.168.1.0/24`) to `router-1`. 
     200 Use `/sbin/ifconfig` to find the name of that interface.
     201
     202{{{
     203xuanliu@router-2:~$ /sbin/ifconfig
     204eth0      Link encap:Ethernet  HWaddr 02:6c:4e:0a:be:dc 
     205          inet addr:172.17.1.19  Bcast:172.31.255.255  Mask:255.240.0.0
     206          inet6 addr: fe80::6c:4eff:fe0a:bedc/64 Scope:Link
     207          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
     208          RX packets:1298 errors:0 dropped:0 overruns:0 frame:0
     209          TX packets:1309 errors:0 dropped:0 overruns:0 carrier:0
     210          collisions:0 txqueuelen:1000
     211          RX bytes:153645 (153.6 KB)  TX bytes:116549 (116.5 KB)
     212          Interrupt:25
     213
     214<snip>
     215
     216eth2      Link encap:Ethernet  HWaddr 02:4a:cc:17:60:44 
     217          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
     218          inet6 addr: fe80::4a:ccff:fe17:6044/64 Scope:Link
     219          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
     220          RX packets:3401 errors:0 dropped:0 overruns:0 frame:0
     221          TX packets:2551 errors:0 dropped:0 overruns:0 carrier:0
     222          collisions:0 txqueuelen:1000
     223          RX bytes:127175180 (127.1 MB)  TX bytes:177712 (177.7 KB)
     224          Interrupt:26
     225
     226<snip>
     227
     228lo        Link encap:Local Loopback 
     229          inet addr:127.0.0.1  Mask:255.0.0.0
     230          inet6 addr: ::1/128 Scope:Host
     231          UP LOOPBACK RUNNING  MTU:16436  Metric:1
     232          RX packets:8368 errors:0 dropped:0 overruns:0 frame:0
     233          TX packets:8368 errors:0 dropped:0 overruns:0 carrier:0
     234          collisions:0 txqueuelen:0
     235          RX bytes:895016 (895.0 KB)  TX bytes:895016 (895.0 KB)
     236}}}
     237
     238 For example, in the above the appropriate interface is `eth2`.  So the command to bring down the interface to `router-1` is:
     239{{{
     240xuanliu@router-2:$ sudo ifconfig eth2 down
     241}}}
     242
     243 We can see one routing table update occurred at `router-1`:
     244
     245{{{
     246......
     247
     248No Change
     249
     250No Change
     251Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     252routing table changed!
     253
     254No Change
     255
     256....
     257}}}
     258   
     259 When we bring up `eth2` at `router-2` again, we notice another routing table update at `router-1` immediately.  The command to bring the interface back up is:
     260{{{
     261xuanliu@router-2:$ sudo ifconfig eth2 up
     262}}}
     263
     264  * Make `router-2` fail.
     265   
     266 As we mentioned before, to emulate a node failure, we can kill the `XORP` processes to disable the routing functionality at a router.  We can use the command
     267
     268{{{
     269ps -ef | grep xorp_ | /usr/bin/awk '{ if ( $1 == "root" ) {print "sudo kill -9 " $2}}' | sh
     270}}}
     271
     272 Now start `xorp_log.sh` again at `router-1`, and kill the `XORP` processes at `router-2`, the output from `router-1` is
     273
     274{{{
     275......
     276
     277No Change
     278Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     279routing table changed!
     280
     281No Change
     282
     283No Change
     284......
     285
     286}}}
     287
     288 At this time, we can run `traceroute` from `client` to `server` again, and we see that the path is changed: `client` --> router-1 --> router-4 --> router-3 --> `server`.
     289
     290{{{
     291xuanliu@client:~$ traceroute 192.168.20.10
     292traceroute to 192.168.20.10 (192.168.20.10), 30 hops max, 60 byte packets
     293 1  router-1-lan4 (192.168.10.10)  0.668 ms  0.617 ms  0.584 ms
     294 2  router-4-lan3 (192.168.4.1)  1.279 ms  1.252 ms  1.220 ms
     295 3  router-3-lan2 (192.168.3.2)  1.753 ms  1.733 ms  1.700 ms
     296 4  server-lan5 (192.168.20.10)  2.680 ms  2.656 ms  2.624 ms
     297}}}
     298
     299 Rerun `xorp_log.sh` again at `router-1`, and restart `XORP` on `router-2`  to enable `OSPF` routing at `router-2`.
     300
     301
     302 Start `XORP` by specifying the routing protocol configuration file.
     303{{{
     304xuanliu@router-2:~$ cd /usr/local/xorp/sbin/
     305xuanliu@router-2:/usr/local/xorp/sbin$ sudo ./xorp_rtrmgr -b /etc/xorp/ospfd.conf -l /tmp/xorp_rtrmgr_log -d
     306}}}
     307
     308 Verify the `XORP` process is running
     309{{{
     310xuanliu@router-2:/usr/local/xorp/sbin$ ps -ef | grep xorp
     311root      1972     1  0 13:30 ?        00:00:02 xorp_fea
     312root      1973     1  0 13:30 ?        00:00:00 xorp_rib
     313root      1974     1  0 13:30 ?        00:00:00 xorp_policy
     314root      1975     1  0 13:30 ?        00:00:01 xorp_ospfv2
     315root      1976     1  0 13:30 ?        00:00:00 ./xorp_rtrmgr -b /etc/xorp/ospfd.conf -l /tmp/xorp_rtrmgr_log -d
     316}}}
     317
     318 We see the `OSPF` routing table updates at `router-1` this time! This is because when the `XORP` processes were started again, it sent `OSPF` `hello` messages to other routers to notify that `router-2` was up, and the `OSPF` routing table was updated at each router afterwards.
     319
     320{{{
     321......
     322No Change
     323
     324No Change
     325Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     326routing table changed!
     327
     328No Change
     329Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     330routing table changed!
     331Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     332routing table changed!
     333
     334No Change
     335Files /local/xorp_run/logs/tmp.txt and /local/xorp_run/logs/last_table.txt differ
     336routing table changed!
     337
     338No Change
     339
     340No Change
     341......
     342
     343}}}
     344
     345  * CSV File at router-1
     346
     347  For research purposes, we would like to mark down the timestamp for every second when we capture the routing table. `xorp_log.sh` actually generates a `csv` log file that stores the timestamp (in UTC) and routing table update information. To simplify the log format, we use '''1''' to represent '''There is an Update!  ''', and '''0''' for '''No Update! '''.  These `csv` files live in `/local/xorp_run/logs/rt-change_*.csv`.  A sample `csv` file can be like:
     348
     349{{{
     350router-1,1404240360,0
     351router-1,1404240362,1
     352router-1,1404240363,0
     353router-1,1404240365,1
     354router-1,1404240366,1
     355router-1,1404240368,0
     356router-1,1404240369,1
     357router-1,1404240371,0
     358}}}
     359
     360 In this way, we can plot figures for routing table updates over time.
     361
     362
     363
     364  * Back to:
     365    * [wiki:PaperOSRMethodology/Design Design Summary]
     366    * [wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/DesignSetup Design Step-by-Step Instructions]
     367
     368 * Continue to:
     369    * '''[wiki:GENIExperimenter/Tutorials/SystematicExprCaseStudy/SmallTopo/Finish Small Topology: Finish]'''