Changes between Version 3 and Version 4 of GEC15Agenda/IntroToOmni/Instructions


Ignore:
Timestamp:
10/16/12 08:50:46 (7 years ago)
Author:
nriga@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC15Agenda/IntroToOmni/Instructions

    v3 v4  
    22
    33= Prework =
     4In this tutorial we are going to run a simple experiment in GENI, using the
     5[http:// Omni command line tool]. We are going to take advantage of the Layer 2
     6links between nodes and run a non-IP experiment.
     7
     8This is the topology of our experiment:
     9
    410Before we start with the Omni tutorial, please follow these steps:
    511  a. Login to the VM
     
    106112   || geni_key.pub || The corresponding public key that will be uploaded to the nodes ||
    107113
     114  '''Note''': You might see more files than the ones listed above, which are
     115  probably backup files from configuring omni, or files from other tutorials.
     116
    108117== 3. Test Omni setup ==
    109118In order to test that our configuration is correct, you can issue a `getversion`
     
    122131  For the rest of the tutorial we are going to use aggregate nicknames.
    123132
    124 = 4. Run an experiment using Omni =
    125 In this step we are going to run through a sample GENI experiment, in order to
     133= 4. Create an experiment using Omni =
     134In this step we are going to setup a sample GENI experiment, in order to
    126135get familiarized with most of the Omni commands.
    127136
     
    194203  iv. Check the status of your resources. Type:
    195204  {{{
    196   }}}
    197 
    198 == 1e. Logging Into the nodes -- Omni Scripting ==
    199 
    200 After reserving the nodes, you are ready to login. The login name and port are listed as part of the sliverstatus call, so you can figure out where to login. For common functionality like this that is expected to be used often,
    201 omni gives you the capability of writing scripts and including omni as a library.
    202 Omni comes with a set of examples (under gcf/examples). One script that is available is the ''readyToLogin.py'' script that will return the exact command for logging-in to the nodes in your sliver.
    203 {{{
     205  omni.py sliverstatus -a pg-utah <slicename>
     206  }}}
     207  The `sliverstatus` command reports the status of your overall GENI slice. When
     208  the status is ready we are ready to continue to the next step.
     209
     210= 5. Run your experiment =
     211Now that resources are ready we can start running our experiment. We will first
     212start by logging in to our reserved nodes.
     213
     214== 5a. Logging Into the nodes -- Omni Scripting ==
     215Depending on the Aggregate the login information are either part of the
     216`sliverstatus` call, or as part of the manifest rspec, i.e. returned from the
     217`listresources` call. Omni comes with a script that makes it easy to gather all
     218this information.
     219  i. In the terminal run:
     220  {{{
    204221readyToLogin.py -a pg-utah <slicename>
    205222}}}
    206 
    207 The script will return the actual command that you would need to use for logging in.
    208 
    209 = 2. Topology used for the tutorial =
    210 In the first part of the tutorial, each of you created a topology that looks like:
    211 
    212 [[Image(full_topo_sigmetrics.png, 30%)]]
    213 
    214 If you notice under node `R2` there is a hidden link : [[Image(node_link.png)]]
    215 
    216 Try and drug the link behind the node. This is a link on a shared VLAN that connects all of your nodes `R2` with a node that is in Washington DC. The connection between your hosts in Utah and the node in Washington is at Layer 2, i.e. you can send non-IP traffic between your hosts. The actual topology looks more like this:
    217 
    218 [[Image(actual_topo.png)]]
    219 
    220 = 3. Sending IP traffic =
    221 For the rest of the tutorial we are going to use the whole topology that has been setup. We will start testing our setup by sending IP traffic between our hosts.
    222 
    223 == 3a. Login to host `R2` ==
    224 First login to the R2 host. To do that go to the Flack page and see what is the name of the machine
    225 
    226 [[Image(hostname.png, 20%)]]
    227 
    228 In the terminal copy and paste the line from the readyToLogin.py output that corresponds to this machine.
    229 
    230 [[Image(readytologin_output.png, 40%)]]
    231 
    232 == 3b. Ping `source` ==
    233 After you login to the R2, try to ping source. Run :
    234 {{{
    235 ping source -c 5
    236 }}}
    237 
    238 Note that you can use the name that is assigned to the host to directly ping the host.
    239 
    240 An example output should look like :
    241 {{{
    242 [[inki@r2 ~]$ ping source -c 5
     223  The script will return the actual command that you would need to use for logging in.
     224  ii. Login to both nodes by copy-paste the commands from the output of the
     225  script.
     226  [[Image(readytologin_output.png, 40%)]]
     227
     228== 5b. Send IP traffic ==
     229The first simple experiment that we will run is to verify the IP connectivity
     230between our hosts.
     231  i. Check the interfaces of your nodes. In the terminal type:
     232  {{{
     233   /sbin/ifconfig
     234  }}}
     235  You should see at least two interfaces:
     236    * The '''control interface'''. This is the interface from where you access
     237    the node, e.g. ssh into your host. The control interface is mainly used for
     238    control traffic, i.e. traffic for controlling the node and the experiment.
     239    The control interface has a publicly routable IP.
     240    * The '''data interface'''. This is the interface that is used for sending
     241    experimental traffic. This is the interface that connects to the other hosts
     242    of your experiment through GENI. The links between these interfaces are the
     243    ones that allow you to run non-IP experiments.
     244  i. Note the name and the MAC address of the control and of the data interface for each node.
     245  i. From the client ping the server. From the xterm that is logged in to the
     246  client type :
     247  {{{
     248    ping server -c 5
     249  }}}
     250  '''Note''': You can use the name that is assigned to the host to directly ping
     251  the host, you can also ping using the IP of the data interface of the node.
     252  An example output should look like :
     253  {{{
     254[[inki@r2 ~]$ ping server -c 5
    243255PING 10.10.2.1 (10.10.2.1) 56(84) bytes of data.
    24425664 bytes from 10.10.2.1: icmp_seq=1 ttl=64 time=1.95 ms
     
    253265}}}
    254266
    255 From R2 you should also be able to ping PC-WashDC. The IP of  PC-WashDC is '''"192.68.44.26"'''.
    256 {{{
    257 [uncusr20@r2 ~]$ ping 192.168.44.26 -c 5
    258 PING 192.168.44.26 (192.168.44.26) 56(84) bytes of data.
    259 64 bytes from 192.168.44.26: icmp_req=1 ttl=64 time=52.7 ms
    260 64 bytes from 192.168.44.26: icmp_req=2 ttl=64 time=52.7 ms
    261 64 bytes from 192.168.44.26: icmp_req=3 ttl=64 time=52.7 ms
    262 64 bytes from 192.168.44.26: icmp_req=4 ttl=64 time=52.7 ms
    263 64 bytes from 192.168.44.26: icmp_req=5 ttl=64 time=52.7 ms
    264 
    265 --- 192.168.44.26 ping statistics ---
    266 5 packets transmitted, 5 received, 0% packet loss, time 4007ms
    267 rtt min/avg/max/mdev = 52.745/52.754/52.764/0.251 ms
    268 
    269 }}}
    270 
    271 Now let's try and ping the PC-WashDC from source. Login to source the same way you logged in to `R2` and run:
    272 {{{
    273 ping 192.168.44.26 -c 5 -w 5
    274 }}}
    275 
    276 The ping should work. Run a traceroute to see how your packets are routed:
    277 {{{
    278 traceroute 192.168.44.26
    279 }}}
    280 
    281 You see that your packets are routed through R2. This is because IP forwarding
    282 is enabled at R2. Go back to the terminal of R2 and run :
    283 {{{
    284 [inki@r2 ~]$ cat /proc/sys/net/ipv4/ip_forward                               
    285 1
    286 }}}
    287 
    288 Disable IP forwarding:
    289 {{{
    290 echo "0" | sudo tee /proc/sys/net/ipv4/ip_forward
    291 }}}
    292 
    293 Now try to ping again from source. The ping should time out.
    294 {{{
    295 [inki@source ~]$ ping 192.168.44.26 -c 5 -w 5
    296 }}}
    297 
    298 = 4. Sending Layer 2 traffic =
    299 GENI provides the capability of creating diverse, layer two topologies. The topology you have created includes connection at Layer 2.
    300 
    301 In this exercise we are going to send Layer 2 traffic between the reserved hosts.
    302 
    303 == 4a. Bring Down IP at `R2` ==
    304 First of all lets bring down the IP configuration from our hosts. At the terminal  of `R2` first run the `ifconfig` command to figure out which are the dataplane interfaces. Run :
    305 {{{
    306 /sbin/ifconfig
    307 }}}
    308 
    309 The output should look like :
    310 {{{
    311 [uncusr20@r2 ~]$ /sbin/ifconfig
    312 eth999    Link encap:Ethernet  HWaddr 00:00:AC:13:6D:01 
    313           inet addr:172.19.109.1  Bcast:172.31.255.255  Mask:255.240.0.0
    314           inet6 addr: fe80::200:acff:fe13:6d01/64 Scope:Link
    315           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    316           RX packets:32835 errors:0 dropped:0 overruns:0 frame:0
    317           TX packets:14403 errors:0 dropped:0 overruns:0 carrier:0
    318           collisions:0 txqueuelen:0
    319           RX bytes:47254606 (45.0 MiB)  TX bytes:743825 (726.3 KiB)
    320 
    321 gre3      Link encap:Ethernet  HWaddr 00:18:51:B5:7A:64 
    322           inet addr:10.20.3.1  Bcast:10.20.3.255  Mask:255.255.255.0
    323           inet6 addr: fe80::218:51ff:feb5:7a64/64 Scope:Link
    324           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    325           RX packets:8 errors:0 dropped:0 overruns:0 frame:0
    326           TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
    327           collisions:0 txqueuelen:0
    328           RX bytes:296 (296.0 b)  TX bytes:26384 (25.7 KiB)
    329 
    330 lo        Link encap:Local Loopback 
    331           inet addr:127.0.0.1  Mask:255.0.0.0
    332           inet6 addr: ::1/128 Scope:Host
    333           UP LOOPBACK RUNNING  MTU:16436  Metric:1
    334           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
    335           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
    336           collisions:0 txqueuelen:0
    337           RX bytes:336 (336.0 b)  TX bytes:336 (336.0 b)
    338 
    339 mv1.1     Link encap:Ethernet  HWaddr 02:00:9B:48:3E:20 
    340           inet addr:10.20.1.2  Bcast:10.20.1.255  Mask:255.255.255.0
    341           inet6 addr: fe80::9bff:fe48:3e20/64 Scope:Link
    342           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    343           RX packets:1022 errors:0 dropped:0 overruns:0 frame:0
    344           TX packets:223 errors:0 dropped:0 overruns:0 carrier:0
    345           collisions:0 txqueuelen:0
    346           RX bytes:80442 (78.5 KiB)  TX bytes:22537 (22.0 KiB)
    347 
    348 mv1.2     Link encap:Ethernet  HWaddr 02:00:AE:44:FF:E4 
    349           inet addr:192.168.44.70  Bcast:192.168.255.255  Mask:255.255.0.0
    350           inet6 addr: fe80::aeff:fe44:ffe4/64 Scope:Link
    351           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    352           RX packets:10 errors:0 dropped:0 overruns:0 frame:0
    353           TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
    354           collisions:0 txqueuelen:0
    355           RX bytes:866 (866.0 b)  TX bytes:1406 (1.3 KiB)
    356 }}}
    357 
    358 The two interfaces that are connected to `source` and `PC-WashDC` are `mv1.1` and `mv1.2` respectively. To figure out which interfaces to bring down, you can inspect the properties of  a link in Flack and see which IP corresponds to each link and find the interface with this IP address.
    359 
    360 [[Image(linkdetails.png)]]
    361 
    362 To bring them down run :
    363 {{{
    364 sudo /sbin/ifconfig mv1.1 0.0.0.0
    365 
    366 sudo /sbin/ifconfig mv1.2 0.0.0.0
    367 }}}
    368 
    369 Bring down IP alson on the `source` on the interface that connects to `R2`.
    370 == 4b. Run Layer 2 Ping ==
    371 From source try to ping `R2`. To perform a Layer 2 ping we are going to use a program that is installed on all the nodes (pingPlus) that can be downloaded [http://www.gpolab.bbn.com/local-sw/ here].
    372 The command is :
    373 {{{
    374 sudo /local/tutorial/pingPlus/pingPlus <MAC_ADDRESS> <INTERFACE_NAME> 12345
    375 }}}
    376 
    377    * <MAC_ADDRESS> is the mac address of the destination host. You can figure out the mac address of `R2` the same way as we found the interface names in the previous step.     
    378    * <INTERFACE_NAME> is the interface on `source` that corresponds to the link with `R2`; it is the interface we removed the IP from on the previous step.
    379 
    380 Run :
    381 
    382 The result should look like :
    383 {{{
    384 [uncusr20@source ~]$ sudo /local/tutorial/pingPlus/pingPlus 02:00:9B:48:3E:20 mv1.1 12345
     267== 5c. Send non-IP traffic ==
     268GENI provides the capability of running non-IP experiments, since you can
     269connect your hosts at Layer 2. For the purpose of this tutorial we have
     270installed in all the hosts a very simple Layer 2 ping program that sends packets
     271using a custom ethernet type.
     272  i. Disable the IP in your nodes. First of all we are going to completely
     273  disable IP on our nodes. In each of the terminals type:
     274  {{{
     275  sudo /sbin/ifconfig <data i/f name> 0.0.0.0
     276  }}}
     277  '''Note''': Be extra careful to bring down the IP on the data interface,
     278  bringing down the IP on the control interface means that you will lose
     279  connectivity to your host.
     280  ii. Try again to ping from the client to the server. In the xterm of the
     281  client type:
     282  {{{
     283  ping server -c 5
     284  }}}
     285  This time the ping should timeout.
     286  iii. Start the Layer 2 ping server: In the server xterm, type:
     287  {{{
     288  sudo /usr/local/bin/pingPlusListener
     289  }}}
     290  iii. From the client try to ping the server at layer 2. You will need the mac
     291  address of the data interface of the server and the name of the data interface
     292  of the client. In the xterm of the client, type:
     293  {{{
     294  sudo /usr/local/bin/pingPlus <server data mac addr> <client data i/f name> 12345
     295  }}}
     296
     297  The result should look like :
     298  {{{
     299[uncusr20@client ~]$ sudo /usr/local/bin/pingPlus 02:00:9B:48:3E:20 mv1.1 12345
    385300RQ:'5582+2067' to 2:0:9b:48:3e:20.
    386301RQ:5582+2067 from 2:0:3e:15:6c:ab.
    387302}}}
    388303
    389 == 4c. Enable Layer 2 forwarding at `R2` ==
    390 If we try to ping PC-WashDC from source, the packets will not get through, since there is no
    391 router running at `R2` that will forward the packets along. For this tutorial we have installed
    392 click router on `R2`, and we are going to run a simple learning switch module. However you can
    393 imagine that you can implement a more complicated routing algorithm.
    394 
    395 Lets generate the click configuration file. In the terminal of `R2` run:
    396 {{{
    397 cd
    398 [inki@r2 ~]$ python /local/tutorial/makeClickConfig.py > switch.click
    399 }}}
    400 
    401 In order to start the click router, at R2 run :
    402 {{{
    403 sudo /usr/local/bin/click switch.click
    404 }}}
    405 The MAC address of PC-WashDC is 00:1B:21:3A:D9:C9
    406 
    407 Then from `source`, try to ping PC-WashDC
    408 {{{
    409 [inki@source /local/tutorial/pingPlus]$ sudo ./pingPlus 00:1B:21:3A:D9:C9  <INTERFACE_NAME> 12345
    410 }}}
    411 
    412 The output should look like :
    413 {{{
    414 [[uncusr20@source ~]$ sudo /local/tutorial/pingPlus/pingPlus 00:1B:21:3A:D9:C9 mv1.1 12345
    415 RQ:'35+4503' to 0:1b:21:3a:d9:c9.
    416 RQ:35+4503 from 2:0:3e:15:6c:ab.
    417 }}}
    418 
    419 Congratulations you have run a Layer 2 experiment that spans across the United States!
    420 
    421 = 5. Cleanup resources =
    422 Although all your reservations, have expiration times, its always good practice
    423 to release the resources after your experiment is over to make them available
     304Congratulations you have run a Layer 2 experiment in GENI!
     305
     306= 6. Cleanup resources =
     307Although all your reservations, have expiration times, you should always release
     308your resources once you have completed your experiment to make them available
    424309to other experimenters.
    425 
    426 === 5a. Deletesliver with Omni ===
    427 We are going to use Omni to release our resources, For each AM that you have used
    428 you should delete your sliver. In the tutorial we used the AMs at Kentucky and at Utah.
    429 
    430 From the terminal that you were using to run your Omni commands, run
    431 
    432 {{{
    433 omni.py deletesliver -a  pg-utah <slicename>
     310  i. In the terminal, where you have been running your omni commands do:
     311  {{{
    434312omni.py deletesliver -a  pg-ky <slicename>
    435313}}}
    436 
    437 
    438 You can not delete your slice. Although this will be cleaned up when it expires,
    439 it should be an empty container and thus does not hold up any resources.
    440314
    441315Congratulations, you have finished the tutorial! Now you are ready to design and
     
    443317any questions you might have.
    444318
    445 = 6. Fill out the tutorial survey =
     319= 7. Fill out the tutorial survey =
    446320We love to hear what you think so that we can improve the tutorials in the future.
    447321Please complete the [https://docs.google.com/spreadsheet/viewform?formkey=dEpqY1RVOTZQZ3RiVTBDdWdUMjV5RWc6MA#gid=0 online survey] and get a temporary GENI tatoo!
    448322
    449 
    450 = 7. Get Your Own Account =
    451 The accounts, that you used in the above steps will be deactivated after the tutorial. If you do not already have an account at GPO's ProtoGENI cluster, you should [wiki:SignMeUp get your own account] so that you can further experiment with GENI.
    452 
    453 = AM URL Table =
    454 || AM || Nickname ||URL ||
    455 || Utah's ProtoGENI || pg-utah || http://www.emulab.net/protogeni/xmlrpc/am ||
    456 || Kentucky's ProtoGENI || pg-ky ||https://www.uky.emulab.net/protogeni/xmlrpc/am ||
    457 || OTHER || || ||
    458 || !PlanetLab ||plc||http://www.planet-lab.org:12346 ||
    459 || GPO's ProtoGENI || pg-gpo ||http://www.pgeni.gpolab.bbn.com/protogeni/xmlrpc/am ||
     323= 8. Get Your Own Account =
     324The accounts, that you used in the above steps will be deactivated after the
     325tutorial. If you do not already have an account at GPO's ProtoGENI cluster, you
     326should [wiki:SignMeUp get your own account] so that you can further experiment
     327with GENI. If you are not a professor and you want to setup your account today,
     328please follow these steps:
     329   i. In your browser go the www.pgeni.gpolab.bbn.com tab and click `Logout`
     330   ii. Press in the .... button.
     331   iii. Fill out the information that are requested and for Project name use
     332   .....
     333   '''Note''': Make sure you use a valid email address and preferably the email
     334   address of your institution. You will need to verify your email address
     335   before your account can be approved.
     336
     337