Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Widearea

Widearea

Wide-area Tutorial

Wide-area Tutorial

Wide-area nodes (AUP) are used in a somewhat different manner than local nodes. Wide-area nodes are shared amongst experimentors and projects, and while you have exclusive use of your local nodes, you are most likely sharing your wide-area nodes with others. For that reason, there are a number of features that are not available on wide-area nodes. Note: many of these restrictions will be lifted when we switch to Unix virtual machines on wide-are nodes (eg: jail on Freebsd and vservers on Linux). Planetlab nodes have a slightly different set of features and restrictions. These differences are noted where appropriate.

  • You may not reboot or power cycle a wide-area node. However, you may reboot the virtual node in which you are running.
  • There is no root access for experimentors, except when running inside a virtual node (jail on FreeBSD, vservers on PLab nodes).
  • You may not select the OS; all wide-area nodes run the same version of FreeBSD (currently 4.6 or later) and Linux on PLab nodes.
  • There is no NFS access to your files on users.emulab.net. Instead, we provide access via the Self-certifying File System on FreeBSD nodes. There is no remote file access on PLab nodes.
  • Traffic generators and program objects are not available on widearea nodes. More generally, anything requiring the event system for its control plane is not available. We hope to have the event system working in the widearea real soon now ...

On the other hand, many testbed features are available on wide-area nodes:

  • Wide-area nodes are requested via your NS file, much like local nodes. The difference is that you request virtual nodes on wide-area nodes, not the actual wide-area nodes themselves. This allows the wide-area node to be shared amongst several different experiments. There are several ways to select which wide-area nodes are assigned to your experiment:
    • You can let the system choose a completely random set:
          tb-set-hardware $nodea pcvwa
          tb-set-hardware $nodea pcplab
      
    • You can select a particular node by choosing the physical node, and using the "fix-node" directive. A free virtual node on that physical node will be choosen for you. To aid in that selection, you can use our wide-area info table to determine the bandwidth and latency characteristics of widearea nodes. PlanetLab node metrics are also available. For example:
          tb-fix-node $nodea ron10
      

At present there are a fixed number of virtual nodes per wide-area node. If there are no free virtual nodes on the physical node you have choosen, the experiment will fail to map.

  • Lastly, you can let the system choose the most approriate set of virtual nodes for your toplogy. The system will look at the bandwidth and delay characteristics you have specifed in your link statements, and attempt to match them based on the most recent information that is available. For example:
        set v0 [$ns node]
        set v1 [$ns node]
        tb-set-hardware $v0 pcvwa
        tb-set-hardware $v1 pcvwa
        set l0 [$ns duplex-link $v0 $v1 10Mb 45ms DropTail]
    

If you use this method, an optional overlay network can be created for you so that you can treat your wide-area nodes just like local nodes with respect to network interfaces. However, this only works on the FreeBSD based pcvwa nodes. The PlanetLab nodes do not support overlay networks. For example:

    tb-set-usewatunnels 1

In the above example, IP addresses 10.1.1.1 and 10.1.1.2 will be assigned to ends of the link, and an overlay will be created between the physical nodes so that things like "ping 10.1.1.2" will work normally. Or, you can elect to ignore the overlays we have created for you and use the IP addresses of the physical nodes. You can also create a link between a wide-area node and a local node; an overlay link will be established for this connections as well. Note that overlays are currently implemented using the vtun package (UDP mode, no compression, no encryption).

  • Routing support within experiments that use wide-area nodes with overlay links (see above) is also available. While we do not support NS' Session option when your experiment uses wide-area nodes, we do support the Static and Manual options, although we strongly recommend that you use the Static option so that system sets up all the routes for you. Routing is discussed in more detail in the Emulab Tutorial.

    Note: If you did not establish overlay links (see above) for your wide-area node links, connections between wide-area nodes, and between wide-area nodes and local Emulab nodes, must be to their external network interface. For example, if you set up an experiment called "wa" in project "testbed" using this NS file:
        set v0 [$ns node]
        set n0 [$ns node]
        tb-set-hardware $v0 pcvwa
    
    Then you will be assigned one local node and one wide-area node. If you want to establish network connections between these two nodes, then you should use these names (which are mailed to you when the experiment has completed setting up).
        ping v0.wa.testbed.emulab.net ping n0.wa.testbed.emulab.net
    
  • Once your experiment is running, you can log into your wide-area nodes using ssh. As a security precaution, your account will not accept a password. Instead, your ssh public keys are distributed for you. As long as you have an agent running, and you have added to the agent at least one private key that corresponds to one of the public keys that we have in your ssh key profile, you will be able to log in without needing a password. As mentioned above, you will not have root access on wide-area nodes (although you will have that access on local nodes if your project leader has approved you with root permissions).