Context Navigation

Instructions

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

Legend:

: Unmodified
: Added
: Removed
: Modified

GEC15Agenda/IntroToOmni/Instructions

-                      v3
+                      v4
 = Prework =
+In this tutorial we are going to run a simple experiment in GENI, using the
+[http:// Omni command line tool]. We are going to take advantage of the Layer 2
+links between nodes and run a non-IP experiment.
+This is the topology of our experiment:
 Before we start with the Omni tutorial, please follow these steps:
   a. Login to the VM
 …
    || geni_key.pub || The corresponding public key that will be uploaded to the nodes ||
+  '''Note''': You might see more files than the ones listed above, which are
+  probably backup files from configuring omni, or files from other tutorials.
 == 3. Test Omni setup ==
 In order to test that our configuration is correct, you can issue a `getversion`
 …
   For the rest of the tutorial we are going to use aggregate nicknames.
 = 4. Run an experiment using Omni =
 In this step we are going to run through a sample GENI experiment, in order to
+= 4. Create an experiment using Omni =
+In this step we are going to setup a sample GENI experiment, in order to
 get familiarized with most of the Omni commands.
 …
   iv. Check the status of your resources. Type:
   {{{
+  }}}
+== 1e. Logging Into the nodes -- Omni Scripting ==
+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,
+omni gives you the capability of writing scripts and including omni as a library.
+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.
+{{{
+  omni.py sliverstatus -a pg-utah <slicename>
+  }}}
+  The `sliverstatus` command reports the status of your overall GENI slice. When
+  the status is ready we are ready to continue to the next step.
+= 5. Run your experiment =
+Now that resources are ready we can start running our experiment. We will first
+start by logging in to our reserved nodes.
+== 5a. Logging Into the nodes -- Omni Scripting ==
+Depending on the Aggregate the login information are either part of the
+`sliverstatus` call, or as part of the manifest rspec, i.e. returned from the
+`listresources` call. Omni comes with a script that makes it easy to gather all
+this information.
+  i. In the terminal run:
+  {{{
 readyToLogin.py -a pg-utah <slicename>
 }}}
+The script will return the actual command that you would need to use for logging in.
+= 2. Topology used for the tutorial =
+In the first part of the tutorial, each of you created a topology that looks like:
+[[Image(full_topo_sigmetrics.png, 30%)]]
+If you notice under node `R2` there is a hidden link : [[Image(node_link.png)]]
+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:
+[[Image(actual_topo.png)]]
+= 3. Sending IP traffic =
+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.
+== 3a. Login to host `R2` ==
+First login to the R2 host. To do that go to the Flack page and see what is the name of the machine
+[[Image(hostname.png, 20%)]]
+In the terminal copy and paste the line from the readyToLogin.py output that corresponds to this machine.
+[[Image(readytologin_output.png, 40%)]]
+== 3b. Ping `source` ==
+After you login to the R2, try to ping source. Run :
+{{{
+ping source -c 5
+}}}
+Note that you can use the name that is assigned to the host to directly ping the host.
+An example output should look like :
+{{{
+[[inki@r2 ~]$ ping source -c 5
+  The script will return the actual command that you would need to use for logging in.
+  ii. Login to both nodes by copy-paste the commands from the output of the
+  script.
+  [[Image(readytologin_output.png, 40%)]]
+== 5b. Send IP traffic ==
+The first simple experiment that we will run is to verify the IP connectivity
+between our hosts.
+  i. Check the interfaces of your nodes. In the terminal type:
+  {{{
+   /sbin/ifconfig
+  }}}
+  You should see at least two interfaces:
+    * The '''control interface'''. This is the interface from where you access
+    the node, e.g. ssh into your host. The control interface is mainly used for
+    control traffic, i.e. traffic for controlling the node and the experiment.
+    The control interface has a publicly routable IP.
+    * The '''data interface'''. This is the interface that is used for sending
+    experimental traffic. This is the interface that connects to the other hosts
+    of your experiment through GENI. The links between these interfaces are the
+    ones that allow you to run non-IP experiments.
+  i. Note the name and the MAC address of the control and of the data interface for each node.
+  i. From the client ping the server. From the xterm that is logged in to the
+  client type :
+  {{{
+    ping server -c 5
+  }}}
+  '''Note''': You can use the name that is assigned to the host to directly ping
+  the host, you can also ping using the IP of the data interface of the node.
+  An example output should look like :
+  {{{
+[[inki@r2 ~]$ ping server -c 5
 PING 10.10.2.1 (10.10.2.1) 56(84) bytes of data.
 bytes from 10.10.2.1: icmp_seq=1 ttl=64 time=1.95 ms
 …
 }}}
+From R2 you should also be able to ping PC-WashDC. The IP of  PC-WashDC is '''"192.68.44.26"'''.
+{{{
+[uncusr20@r2 ~]$ ping 192.168.44.26 -c 5
+PING 192.168.44.26 (192.168.44.26) 56(84) bytes of data.
+bytes from 192.168.44.26: icmp_req=1 ttl=64 time=52.7 ms
+bytes from 192.168.44.26: icmp_req=2 ttl=64 time=52.7 ms
+bytes from 192.168.44.26: icmp_req=3 ttl=64 time=52.7 ms
+bytes from 192.168.44.26: icmp_req=4 ttl=64 time=52.7 ms
+bytes from 192.168.44.26: icmp_req=5 ttl=64 time=52.7 ms
+--- 192.168.44.26 ping statistics ---
+packets transmitted, 5 received, 0% packet loss, time 4007ms
+rtt min/avg/max/mdev = 52.745/52.754/52.764/0.251 ms
+}}}
+Now let's try and ping the PC-WashDC from source. Login to source the same way you logged in to `R2` and run:
+{{{
+ping 192.168.44.26 -c 5 -w 5
+}}}
+The ping should work. Run a traceroute to see how your packets are routed:
+{{{
+traceroute 192.168.44.26
+}}}
+You see that your packets are routed through R2. This is because IP forwarding
+is enabled at R2. Go back to the terminal of R2 and run :
+{{{
+[inki@r2 ~]$ cat /proc/sys/net/ipv4/ip_forward
+}}}
+Disable IP forwarding:
+{{{
+echo "0" | sudo tee /proc/sys/net/ipv4/ip_forward
+}}}
+Now try to ping again from source. The ping should time out.
+{{{
+[inki@source ~]$ ping 192.168.44.26 -c 5 -w 5
+}}}
+= 4. Sending Layer 2 traffic =
+GENI provides the capability of creating diverse, layer two topologies. The topology you have created includes connection at Layer 2.
+In this exercise we are going to send Layer 2 traffic between the reserved hosts.
+== 4a. Bring Down IP at `R2` ==
+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 :
+{{{
+/sbin/ifconfig
+}}}
+The output should look like :
+{{{
+[uncusr20@r2 ~]$ /sbin/ifconfig
+eth999    Link encap:Ethernet  HWaddr 00:00:AC:13:6D:01
+          inet addr:172.19.109.1  Bcast:172.31.255.255  Mask:255.240.0.0
+          inet6 addr: fe80::200:acff:fe13:6d01/64 Scope:Link
+          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          RX packets:32835 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:14403 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:0
+          RX bytes:47254606 (45.0 MiB)  TX bytes:743825 (726.3 KiB)
+gre3      Link encap:Ethernet  HWaddr 00:18:51:B5:7A:64
+          inet addr:10.20.3.1  Bcast:10.20.3.255  Mask:255.255.255.0
+          inet6 addr: fe80::218:51ff:feb5:7a64/64 Scope:Link
+          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:0
+          RX bytes:296 (296.0 b)  TX bytes:26384 (25.7 KiB)
+lo        Link encap:Local Loopback
+          inet addr:127.0.0.1  Mask:255.0.0.0
+          inet6 addr: ::1/128 Scope:Host
+          UP LOOPBACK RUNNING  MTU:16436  Metric:1
+          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:0
+          RX bytes:336 (336.0 b)  TX bytes:336 (336.0 b)
+mv1.1     Link encap:Ethernet  HWaddr 02:00:9B:48:3E:20
+          inet addr:10.20.1.2  Bcast:10.20.1.255  Mask:255.255.255.0
+          inet6 addr: fe80::9bff:fe48:3e20/64 Scope:Link
+          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          RX packets:1022 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:223 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:0
+          RX bytes:80442 (78.5 KiB)  TX bytes:22537 (22.0 KiB)
+mv1.2     Link encap:Ethernet  HWaddr 02:00:AE:44:FF:E4
+          inet addr:192.168.44.70  Bcast:192.168.255.255  Mask:255.255.0.0
+          inet6 addr: fe80::aeff:fe44:ffe4/64 Scope:Link
+          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
+          TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
+          collisions:0 txqueuelen:0
+          RX bytes:866 (866.0 b)  TX bytes:1406 (1.3 KiB)
+}}}
+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.
+[[Image(linkdetails.png)]]
+To bring them down run :
+{{{
+sudo /sbin/ifconfig mv1.1 0.0.0.0
+sudo /sbin/ifconfig mv1.2 0.0.0.0
+}}}
+Bring down IP alson on the `source` on the interface that connects to `R2`.
+== 4b. Run Layer 2 Ping ==
+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].
+The command is :
+{{{
+sudo /local/tutorial/pingPlus/pingPlus <MAC_ADDRESS> <INTERFACE_NAME> 12345
+}}}
+   * <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.
+   * <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.
+Run :
+The result should look like :
+{{{
+[uncusr20@source ~]$ sudo /local/tutorial/pingPlus/pingPlus 02:00:9B:48:3E:20 mv1.1 12345
+== 5c. Send non-IP traffic ==
+GENI provides the capability of running non-IP experiments, since you can
+connect your hosts at Layer 2. For the purpose of this tutorial we have
+installed in all the hosts a very simple Layer 2 ping program that sends packets
+using a custom ethernet type.
+  i. Disable the IP in your nodes. First of all we are going to completely
+  disable IP on our nodes. In each of the terminals type:
+  {{{
+  sudo /sbin/ifconfig <data i/f name> 0.0.0.0
+  }}}
+  '''Note''': Be extra careful to bring down the IP on the data interface,
+  bringing down the IP on the control interface means that you will lose
+  connectivity to your host.
+  ii. Try again to ping from the client to the server. In the xterm of the
+  client type:
+  {{{
+  ping server -c 5
+  }}}
+  This time the ping should timeout.
+  iii. Start the Layer 2 ping server: In the server xterm, type:
+  {{{
+  sudo /usr/local/bin/pingPlusListener
+  }}}
+  iii. From the client try to ping the server at layer 2. You will need the mac
+  address of the data interface of the server and the name of the data interface
+  of the client. In the xterm of the client, type:
+  {{{
+  sudo /usr/local/bin/pingPlus <server data mac addr> <client data i/f name> 12345
+  }}}
+  The result should look like :
+  {{{
+[uncusr20@client ~]$ sudo /usr/local/bin/pingPlus 02:00:9B:48:3E:20 mv1.1 12345
 RQ:'5582+2067' to 2:0:9b:48:3e:20.
 RQ:5582+2067 from 2:0:3e:15:6c:ab.
 }}}
+== 4c. Enable Layer 2 forwarding at `R2` ==
+If we try to ping PC-WashDC from source, the packets will not get through, since there is no
+router running at `R2` that will forward the packets along. For this tutorial we have installed
+click router on `R2`, and we are going to run a simple learning switch module. However you can
+imagine that you can implement a more complicated routing algorithm.
+Lets generate the click configuration file. In the terminal of `R2` run:
+{{{
+cd
+[inki@r2 ~]$ python /local/tutorial/makeClickConfig.py > switch.click
+}}}
+In order to start the click router, at R2 run :
+{{{
+sudo /usr/local/bin/click switch.click
+}}}
+The MAC address of PC-WashDC is 00:1B:21:3A:D9:C9
+Then from `source`, try to ping PC-WashDC
+{{{
+[inki@source /local/tutorial/pingPlus]$ sudo ./pingPlus 00:1B:21:3A:D9:C9  <INTERFACE_NAME> 12345
+}}}
+The output should look like :
+{{{
+[[uncusr20@source ~]$ sudo /local/tutorial/pingPlus/pingPlus 00:1B:21:3A:D9:C9 mv1.1 12345
+RQ:'35+4503' to 0:1b:21:3a:d9:c9.
+RQ:35+4503 from 2:0:3e:15:6c:ab.
+}}}
+Congratulations you have run a Layer 2 experiment that spans across the United States!
+= 5. Cleanup resources =
+Although all your reservations, have expiration times, its always good practice
+to release the resources after your experiment is over to make them available
+Congratulations you have run a Layer 2 experiment in GENI!
+= 6. Cleanup resources =
+Although all your reservations, have expiration times, you should always release
+your resources once you have completed your experiment to make them available
 to other experimenters.
+=== 5a. Deletesliver with Omni ===
+We are going to use Omni to release our resources, For each AM that you have used
+you should delete your sliver. In the tutorial we used the AMs at Kentucky and at Utah.
+From the terminal that you were using to run your Omni commands, run
+{{{
+omni.py deletesliver -a  pg-utah <slicename>
+  i. In the terminal, where you have been running your omni commands do:
+  {{{
 omni.py deletesliver -a  pg-ky <slicename>
 }}}
-You can not delete your slice. Although this will be cleaned up when it expires,
-it should be an empty container and thus does not hold up any resources.
 Congratulations, you have finished the tutorial! Now you are ready to design and
 …
 any questions you might have.
 = 6. Fill out the tutorial survey =
+= 7. Fill out the tutorial survey =
 We love to hear what you think so that we can improve the tutorials in the future.
 Please complete the [https://docs.google.com/spreadsheet/viewform?formkey=dEpqY1RVOTZQZ3RiVTBDdWdUMjV5RWc6MA#gid=0 online survey] and get a temporary GENI tatoo!
+= 7. Get Your Own Account =
+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.
+= AM URL Table =
+|| AM || Nickname ||URL ||
+|| Utah's ProtoGENI || pg-utah || http://www.emulab.net/protogeni/xmlrpc/am ||
+|| Kentucky's ProtoGENI || pg-ky ||https://www.uky.emulab.net/protogeni/xmlrpc/am ||
+|| OTHER || || ||
+|| !PlanetLab ||plc||http://www.planet-lab.org:12346 ||
+|| GPO's ProtoGENI || pg-gpo ||http://www.pgeni.gpolab.bbn.com/protogeni/xmlrpc/am ||
+= 8. Get Your Own Account =
+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. If you are not a professor and you want to setup your account today,
+please follow these steps:
+   i. In your browser go the www.pgeni.gpolab.bbn.com tab and click `Logout`
+   ii. Press in the .... button.
+   iii. Fill out the information that are requested and for Project name use
+   .....
+   '''Note''': Make sure you use a valid email address and preferably the email
+   address of your institution. You will need to verify your email address
+   before your account can be approved.