wiki:GENIExperimenter/Tutorials/HelloOmni

Version 20 (modified by nriga@bbn.com, 11 years ago) (diff)

--

This page will guide you through running a simple non-IP experiment in GENI, using the Omni command line tool. We are going to take advantage of the Layer 2 links between nodes and run a non-IP experiment. The only thing you will need is a GENI account. If you don't already have one, sign up!

1. Configure Omni with your GENI account

Omni is a command-line tool that will help you reserve resources in GENI. Follow these steps to download and configure Omni.

Omni web page
  1. Download Omni.The Omni client is part of the GENI Control Framework (GCF) software package. Start with downloading GCF .
  2. Install and Configure Omni using these instructions . Unless you have a specific reason not to, please follow the instructions about automatically configuring Omni. For the rest of the instructions, it is assumed that you followed the default configuration of omni. If you have customized it in any way, please adjust the instructions accordingly.
  3. Optional - Add your key to the ssh agent. If there is an ssh agent running on your host add you key to the ssh agent by running:
    ssh-add ~/.ssh/geni_key
  1. Verify that you have the necessary credential and key files . Run:
         ls ~/.ssh ~/.ssl
    
    The output looks like :
    geni@geni-vm:~$ ls ~/.ssh ~/.ssl
    /home/geni/.ssh:
    config  geni_key  geni_key.pub
    
    /home/geni/.ssl:
    geni_cert_enc.pem  geni_cert.pem
    

geni_cert.pem Cleartext certificate, i.e. does not require any passphrase
geni_cert_enc.pem Encrypted certificate
geni_key The private key that you will use to login to the nodes
geni_key.pub The corresponding public key that will be uploaded to the nodes

Note: Depending on the setup of your host you might see more files than the ones listed above.

  1. Optional - Look around the omni_config file Open the file ~/.gcf/omni_config using either vim or emacs. Close to the top of the file you will see two parameters called default_cf and users. Your username should be at least listed in the user section. Look for the sections in the file that are named [pg] and [<username>].

In the [<username>] section, the information need for logging-in to reserved compute resources are provided. It includes your unique user URN and a public key that would be uploaded to the hosts that you reserve.

In the [pg] section you configure Omni to use your personal information. The cert and the key attribute point to files that we have manually downloaded from pgeni.gpolab.bbn.com. This is equivalent to the Download action of Flack.

Another interesting section to look at is the [aggregate-nicknames] sections. Flack already knows the URL for all the AMs and present you a list of AMs to choose from using a short, descriptive name. In Omni a user is required to pass the URL for each call to the GENI AM API. In this section the user gets a chance to provide short descriptive names to the URLs that are easier to memorize and use.

2. Launch your experiment

In this step we are going to setup a simplet Layer 2 GENI experiment, in order to get familiarized with most of the Omni commands.

  1. Create a slice. The first thing to do when preparing to run a GENI experiment is to create a slice. Name your slice something like xxxomni (where xxx are your initials). Type
    omni.py createslice <slicename>
    
  2. Verify that your slice was created. Use the listmyslices command, of omni:
    omni.py listmyslices <username>
    
  3. Renew your slice. To extend the lifetime of your slice type:
    omni.py renewslice <slicename> <YYYYMMDD>
    
  4. See available resources. For this experiment we are going to use the Aggregate manager of ProtoGENI in Utah. In order to see what each AM offers you can use the listresources command. Type:
     omni.py listresources -a pg-utah -o
    
    The -o option will save the output to a file. The filename is chosen by Omni and printed as part of the output. The output will look like :
    geni@geni-VirtualBox:~$ omni.py listresources -a pg-utah -o
    INFO:omni:Loading config file /home/geni/.gcf/omni_config
    INFO:omni:Using control framework pg
    INFO:omni:Saving output to a file.
    INFO:omni:Substituting AM nickname pg-utah with URL https://www.emulab.net/protogeni/xmlrpc/am/2.0, URN unspecified_AM_URN
    INFO:omni:Listed resources on 1 out of 1 possible aggregates.
    INFO:omni:Writing to 'rspec-www-emulab-net-protogeniv2.xml'
    INFO:omni: ------------------------------------------------------------
    INFO:omni: Completed listresources:
    
      Options as run:
    		aggregate: ['pg-utah']
    		framework: pg
    		output: True
    
      Args: listresources
    
      Result Summary: Queried resources from 1 of 1 aggregate(s).
    Wrote rspecs from 1 aggregate(s) to 1 file(s)
    Saved listresources RSpec at 'unspecified_AM_URN' (url 'https://www.emulab.net/protogeni/xmlrpc/am/2.0') to file rspec-www-emulab-net-protogeniv2.xml;  
    INFO:omni: ============================================================
    
    In the last line of the output Omni will tell you the name of the file that output is saved at. In the example above this would be rspec-www-emulab-net-protogeniv2.xml. Open the file that Omni saved and just take a look to see how an advertisement RSpec looks like. In order to see only available resources type:
    omni.py listresources -a pg-utah --available -o
    
  5. Reserve resources. To be able to reserve resources you will need to craft a request rspec. For this example we have created the rspec and made it available for you to use. Type:
      omni.py createsliver -a pg-utah <slicename> http://www.gpolab.bbn.com/experiment-support/HelloOmni/hello-omni.rspec
    
  6. See the reserved resources. You can use the listresources command, to see what resources are reserved at an Aggregate.
     omni.py listresources -a pg-utah <slicename>
    
  7. Optional- Extend the lifetime of your reservation. The lifetime of your reservation can never exceed the lifetime of your slice and is usually set to a default value. For the purpose of this exercise you don't need to renew your reservation. But if you wanted to do this this is what the command would look like:
    omni.py renewsliver -a pg-utah <slicename> <YYYYMMDD>
    
  8. Check the status of your resources. Type:
      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.

3. 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.

  1. Login to your 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. 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.

  1. Login to both nodes by copy-paste the commands from the output of the script.

5b. Send IP traffic

The first simple experiment that we will run is to verify the IP connectivity between our hosts.

  1. 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 usually 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.
  2. Note the name and the MAC address of the control and of the data interface for each node. The data interface is the one that has an IP that starts with 10.
  3. 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.
    64 bytes from 10.10.2.1: icmp_seq=1 ttl=64 time=1.95 ms
    64 bytes from 10.10.2.1: icmp_seq=2 ttl=64 time=2.27 ms
    64 bytes from 10.10.2.1: icmp_seq=3 ttl=64 time=2.04 ms
    64 bytes from 10.10.2.1: icmp_seq=4 ttl=64 time=1.95 ms
    64 bytes from 10.10.2.1: icmp_seq=5 ttl=64 time=1.72 ms
    
    --- 10.10.2.1 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4005ms
    rtt min/avg/max/mdev = 1.728/1.992/2.278/0.179 ms
    

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.

  1. 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.
  2. 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.
  3. Start the Layer 2 ping server: In the server xterm, type:
    sudo /usr/local/bin/pingPlusListener 12345
    
  4. 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.

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.

  1. In the terminal, where you have been running your omni commands do:
    omni.py deletesliver -a  pg-utah <slicename>
    

7. Wrap up

Congratulations, you have finished the tutorial! Now you are ready to design and run your own experiments. Don't hesitate to email us with any questions you might have.

7a. 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 online survey and get a temporary GENI tatoo!

7b. 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 can follow these instructions to get an account and start using GENI.