wiki:GEC15Agenda/IntroToOmni/Instructions

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

--

Prework

Before we start with the Omni tutorial, please follow these steps:

  1. Login to the VM
  2. Run Firefox
  3. Open all bookmarks under the Intro to Omni bookmark folder
  4. Open a terminal window

1. Configure Omni

Omni is a tool that will help you reserve resources in GENI, using your GENI account. The first step is to load into Omni your account information. Omni uses a configuration file, and there is a script that will automatically generate the file with some default options and place it in the default place of ~/.gcf/. Follow these steps:

  1. In the web browser login to www.pgeni.gpolab.bbn.com using the information in the paper slip
  2. On the menu on the left, press Download your cert No image "download_cert.png" attached to GEC15Agenda/IntroToOmni/Instructions
  3. Select the option about downloading as a pem file.
  4. Press Ctrl-s to save this page. Type ~/.ssl/geni_cert.pem No image "save_cert.png" attached to GEC15Agenda/IntroToOmni/Instructions
  5. In the terminal type:
    omni-configure.py
    
    This should configure your Omni, with your downloaded certificate and create an ssh key pair for logging in to nodes.

When prompted for a passphrase, type the passphrase in your slip. You might be asked for a passphrase multiple times. Note: If you have taken other tutorials, you might have configured omni with other accounts, select to overwrite existing setting if asked

The output should look like:

geni@geni-vm:~$ omni-configure.py 
{'framework': 'pg', 'configfile': '~/.gcf/omni_config', 'plkey': '~/.ssh/geni_pl_key', 'cert': '~/.ssl/geni_cert', 'verbose': False}
INFO:omniconfig:Using configfile: /home/geni/.gcf/omni_config
INFO:omniconfig:Using certfile /home/geni/.ssl/geni_cert.pem
INFO:omniconfig:

	CREATING SSH KEYPAIR
INFO:omniconfig:Private key stored at: /home/geni/.ssh/geni_key
Enter passphrase: 
INFO:omniconfig:Public key stored at: /home/geni/.ssh/geni_key.pub
INFO:omniconfig:Added to /home/geni/.ssh/config this line:
	'IdentityFile /home/geni/.ssh/geni_key
'
INFO:omniconfig:Wrote omni configuration file at: /home/geni/.gcf/omni_config

OPTIONAL

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. Clear the passphrase from your cert

When Omni talks to different authorities in GENI, it will need to identify you as a valid GENI user, so it will ask you for your passphrase multiple times. Omni will ask you for the phrase multiple times per command. To save time during the tutorial, we are going to remove the passphrase from your cert and your ssh key. There is a script to clear the passphrases.

  1. In the terminal run
    clear-passphrases.py 
    

Use the passphrase given to you in the paper slip, you might be prompted for a passphrase multiple times make sure you always use the same passphrase.

The output should look like

geni@geni-vm:~$ clear-passphrases.py 
Do you want to remove the passphrase from your cert (/home/geni/.ssl/geni_cert.pem) [Y,n]?y
INFO:clearcert:
	THIS SCRIPT WILL REPLACE /home/geni/.ssl/geni_cert.pem WITH AN UNENCREPTED CERT. A BACKUP OF THE ORIGINAL CERT WILL BE CREATED

INFO:clearcert:The encoded certificate file is backed up at /home/geni/.ssl/geni_cert_enc.pem
INFO:clearcert:Removing passphrase from cert...
Enter pass phrase for /home/geni/.ssl/geni_cert.pem:
writing RSA key
INFO:clearcert:Change permissions of /home/geni/.ssl/geni_cert.pem to 0600
Do you want to remove the passphrase from you ssh-key (/home/geni/.ssh/geni_key, key used to login to compute resources) [Y,n]?y
INFO:clearcert:
	THIS SCRIPT WILL REMOVE THE PASSPHRASE FROM YOUR SSH KEY. NO COPY OF THE ORIGINAL PRIVATE KEY WILL BE KEPT
Enter PEM pass phrase:
Enter passphrase:
geni@geni-vm:~$ 
  1. Verify that you have the necessary credential and key files
    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

3. Test Omni setup

In order to test that our configuration is correct, you can issue a getversion command. For this step we have used PlanetLab's AM, but you can use any Aggregate Manager(AM).

  1. In the terminal type:
    omni.py getversion -a plc
    
    In GENI each AM can be contacted using a specific URL. In order to make it easier to talk to AMs, Omni uses nicknames; i.e. it maps each URL into an easy to remember nickname. For example the PlanetLab AM listens for requests at http://www.planet-lab.org:12346, however you can use the nickname plc to refer to that URL. Nicknames are defined in each user's omni_config file.

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 get familiarized with most of the Omni commands.

4a. Create and renew a slice

The first thing to do when preparing to run a GENI experiment is to create a slice.

  1. To create a slice type, use the <slicename> given in your paper slip:
    omni.py createslice <slicename>
    
  2. To verify that your slice has been created and in general to keep track of your slices, use the list_my_slices command. use the <username> given in your paper slip. Type:
    omni.py list_my_slices <username>
    
  3. Renew your slice. To extend the lifetime of your slice type:
    omni.py renewslice <slicename> 20121025
    

4b. Reserve resources, a.k.a create a sliver

The next step in a GENI experiment is to actually reserve resources. For this experiment we are going to use the Aggregate manager of ProtoGENI in Utah.

  1. In Omni 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-vm:~$ 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, URN unspecified_AM_URN
    INFO:omni:Listed resources on 1 out of 1 possible aggregates.
    INFO:omni:Writing to 'rspec-www-emulab-net-protogeni.xml'
    INFO:omni: ------------------------------------------------------------
    INFO:omni: Completed listresources:
    
      Options as run:
    		aggregate: pg-utah
    		framework: pg
    		native: True
    		output: True
    
      Args: listresources
    
      Result Summary: Retrieved resources from 1 aggregates.
    Wrote rspecs from 1 aggregates to 1 files
    Saved listresources RSpec at 'unspecified_AM_URN' to file rspec-www-emulab-net-protogeni.xml; . 
    INFO:omni: ============================================================
    
    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 resources type
    omni.py listresources -a pg-utah --available -o
    
  2. To be able to reserve resources you will need to craft a request rspec. For this example we have created the rspecs for you, use the rspec URL given in your paper slip. Type :
    omni.py createsliver -a pg-utah <slicename> <rspec_url>
    
  3. Look at your reserved resources. Type:
    omni.py listresources -a pg-utah <slicename>
    
  4. 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.

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:

No image "full_topo_sigmetrics.png" attached to GEC15Agenda/IntroToOmni/Instructions

If you notice under node R2 there is a hidden link : No image "node_link.png" attached to GEC15Agenda/IntroToOmni/Instructions

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:

No image "actual_topo.png" attached to GEC15Agenda/IntroToOmni/Instructions

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

No image "hostname.png" attached to GEC15Agenda/IntroToOmni/Instructions

In the terminal copy and paste the line from the readyToLogin.py output that corresponds to this machine.

No image "readytologin_output.png" attached to GEC15Agenda/IntroToOmni/Instructions

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

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.
64 bytes from 192.168.44.26: icmp_req=1 ttl=64 time=52.7 ms
64 bytes from 192.168.44.26: icmp_req=2 ttl=64 time=52.7 ms
64 bytes from 192.168.44.26: icmp_req=3 ttl=64 time=52.7 ms
64 bytes from 192.168.44.26: icmp_req=4 ttl=64 time=52.7 ms
64 bytes from 192.168.44.26: icmp_req=5 ttl=64 time=52.7 ms

--- 192.168.44.26 ping statistics ---
5 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                                
1

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.

No image "linkdetails.png" attached to GEC15Agenda/IntroToOmni/Instructions

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 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
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 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>
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 run your own experiments. Don't hesitate to email us with any questions you might have.

6. 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!

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 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 plchttp://www.planet-lab.org:12346
GPO's ProtoGENI pg-gpo http://www.pgeni.gpolab.bbn.com/protogeni/xmlrpc/am