faq.html 27.6 KB
Newer Older
1 2 3 4 5 6 7 8
<html>
<head>
	<title>Emulab.Net - Frequently Asked Questions</title>
	<link rel='stylesheet' href='tbstyle-plain.css' type='text/css'>
</head>
<body>
<basefont size=4>

9
<center>
10
<h2>Frequently Asked Questions</h2>
11 12 13
</center>

<h2>Contents</h2>
14
<ul>
15 16
<li> <a href="#GS">Getting Started</a>
     <ul>
17
     <li> <a href="#GS-Eligible">Who is Eligible to use Emulab.Net?</a>
18 19
     <li> <a href="#GS-1">How do I start a project?</a>
     <li> <a href="#GS-2">How do I join a project?</a>
20
     <li> <a href="#GS-3">I have an Emulab account. Now what?</a>
21
     <li> <a href="#GS-PATH">Do I need to change my PATH variable?</a>
22 23
     <li> <a href="#GS-4">Can I be in more than one project?</a>
     <li> <a href="#GS-5">Can I change my Emulab password?</a>
24 25
     <li> <a href="#GS-6">I'm a project leader. Can I designate TAs?</a>
     <li> <a href="#GS-7">Where do I get help?</a>
26 27 28 29 30
     </ul>

<li> <a href="#UTT">Using the Testbed</a>
     <ul>
     <li> <a href="#UTT-1">Is there a tutorial?</a>
31
     <li> <a href="#UTT-NODES">How many nodes can I ask for?</a>
32
     <li> <a href="#UTT-2">Do I get root access on my nodes?</a>
33
     <li> <a href="#UTT-3">Do my nodes have consoles I can look at?</a>
34
     <li> <a href="#UTT-4">Can I reboot (power cycle) my nodes?</a>
35
     <li> <a href="#UTT-SCROGGED">I've scrogged my disk! Now what?</a>
36 37
     <li> <a href="#UTT-5">Where do I store files needed by my experiment?</a>
     <li> <a href="#UTT-6">Are my files on <b>users.emulab.net</b>
38
                           backed up (filesaved)?</a>
39
     <li> <a href="#UTT-7">Are the nodes in my experiment backed up
40
                           (filesaved)?</a> 
41
     <li> <a href="#UTT-Swapping">What is Swapping?</a> 
42 43 44 45 46
     </ul>

<li> <a href="#HDS">Hardware setup</a>
     <ul>
     <li> <a href="#HDS-1">How many nodes are there?</a>
47 48
     <li> <a href="#HDS-2">How many nodes are currently available?</a>
     <li> <a href="#HDS-3">How many ethernet cards are on each node?</a>
49 50
     <li> <a href="#HDS-4">How many nodes are currently available (free)?</a>
     <li> <a href="#HDS-5">Can I do traffic shaping on my links?</a>
Jay Lepreau's avatar
Jay Lepreau committed
51
     <li> <a href="#HDS-6">Can I modify the traffic shaping
52
                           parameters on my links?</a>
Jay Lepreau's avatar
Jay Lepreau committed
53
     <li> <a href="#HDS-7">Are there other traffic shaping parameters
54
                           besides latency, bandwidth, and PLR?</a>
55 56 57 58 59
     </ul>

<li> <a href="#SWS">Software setup</a>
     <ul>
     <li> <a href="#SWS-1">What OS do the nodes run?</a>
60 61 62
     <li> <a href="#SWS-2">How do I select which OS to run on each node?</a>
     <li> <a href="#SWS-3">Can I load my own software (RPMs) on my nodes?</a>
     <li> <a href="#SWS-4">Can I schedule programs to run
63 64 65 66
                           automatically when a node boots?</a>
     <li> <a href="#SWS-5">How can I turn on routing or set up routes
			   automatically in my nodes?</a>
     <li> <a href="#SWS-6">How does my software determine when other
67
                           nodes in my experiment are ready?</a>
68
     <li> <a href="#SWS-7">Can I run my own Operating System?</a>
69
     </ul>
70 71 72 73 74

<li> <a href="#SEC">Security Issues</a>
     <ul>
     <li> <a href="#SEC-1">Is Emulab Firewalled?</a>
     </ul>
75 76 77 78 79 80

<li> <a href="#TR">Troubleshooting</a>
     <ul>
     <li> <a href="#TR-1">My experiment is setup, but I cannot
     			  send packets between some of the nodes, why?</a>
     </ul>
81 82 83
</ul>

<hr>
84

85 86 87
<a NAME="GS"></a>
<h3>Getting Started</h3>
<ul>
88 89 90 91 92 93 94 95 96 97 98 99 100
<li><a NAME="GS-Eligible"></a>
    <h3>Who is Eligible to use Emulab.Net?</h3>
    <p>
    Emulab.Net is an NSF/DARPA sponsored project, with additional
    support from these <a href =
    "docwrapper.php3?docname=sponsors.html"> sponsors</a>. As such,
    eligibility to use Emulab is primarily granted to other NSF/DARPA
    sponsored projects, as well as current university research
    projects. There are exceptions of course. If you are unsure about
    your eligibility to use Emulab, please feel free to send us an email
    inquiry.
    </p>

101
<li><a NAME="GS-1"></a>
102
    <h3>How do I start a project?</h3>
103 104
    <p>
    If you are new to the Testbed, simply click on the "Start Project"
105
    link on the Emulab <a href="http://www.emulab.net">Home
106 107 108 109
    Page</a>. You will need to fill in the forms with your personal
    information and information about the project. Then click on the
    "Submit" button. Within a few days you will be contacted via email
    with an approval message. More information about starting projects
110 111
    can be found in <a href="docwrapper.php3?docname=auth.html">
    Authorization Page</a>.
112
    </p>
113 114 115 116 117 118 119
    <p>
    If you already have an Emulab account, and wish to start a second
    project, first log into the Web Interface. Then select the "Start
    Project" link; all of the personal information will already be
    filled in. You will need to complete just the project information
    section. 
    </p>
120

121
<li><a NAME="GS-2"></a>
122
    <h3>How do I join a project?</h3>
123 124
    <p>
    If you are new to the Testbed, simply click on the "Join Project"
125
    link on the Emulab <a href="http://www.emulab.net">Home
126 127 128
    Page</a>. You will need to fill in the form with your personal
    information, and provide the name of the project you are trying to
    join (typically, the <i>Project Leader</i> will have told you the
129
    name of the project). Then click on the "Submit" button, and wait
130 131 132
    for the project leader to approve you.  When approved you will
    receive an email message saying so, and you can then log into the
    Testbed.
133 134 135 136 137 138 139 140 141 142
    </p>

<li><a NAME="GS-3"></a>
    <h3>I have an Emulab account. Now what?</h3>
    <p>
    Once you have been approved to start (or join) your first project,
    you will be able to log into Emulab's user machine,
    <b>users.emulab.net</b>. We require that all Emulab users use ssh. For
    example, if your Emulab account name is "joe", then you would do:
    <pre>
143
	ssh users.emulab.net -l joe		</pre>
144 145 146
    </p>
    <p>
    Your password starts out the same as the password you initially
147 148 149 150 151 152 153 154
    supplied to the Start (or Join) web page.

<li><a NAME="GS-PATH"></a>
    <h3>Do I need any special directories in my PATH variable?</h3>
    <p>
    There are several useful (although not required) programs installed on
    <tt>users.emulab.net</tt> in <tt>/usr/testbed/bin</tt>. You should edit
    your dot files to include that directory in your search path. 
155 156 157 158 159 160
    </p>

<li><a NAME="GS-4"></a>
    <h3>Can I be in more than one project?</h3>
    <p>
    Yes. You may join (and/or start) as many projects as you like,
161 162
    subject to Emulab <a href="docwrapper.php3?docname=policies.html">
    administrative policies</a>.
163 164 165 166 167 168 169 170 171 172 173 174 175 176 177
    </p>

<li><a NAME="GS-5"></a>
    <h3>Can I change my Emulab password?</h3>
    <p>
    Yes. You can change your Emulab Web password and your Emulab login
    password (the password you use to log into <b>users.emulab.net</b>, as
    well as nodes in your experiments). To change your Web password,
    simply click on the "Update User Information" in the menu to your
    left, and then enter your new password in the location provided. 
    To change your login password, use the unix <tt>passwd</tt>
    utility when logged into <b>users.emulab.net</b>. 
    </p>

<li><a NAME="GS-6"></a>
178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
    <h3>I'm a project leader. Can I designate TAs?</h3>
    <p>
    Yes. To designate a TA, you must first create a project
    <em>group</em>. A project group is a lot like a unix group, and
    in fact unix groups is the mechanism used to protect members of
    one group from members of another group. When you create a group,
    you designate a <em>group leader</em> who is responsible for
    approving users who apply to join the group. Group leaders may
    also terminate experiments that have been created by members of
    the group. As Project Leader, you may also shift members of your
    project in and out of your project's groups as you like, and you
    are automatically a member of all groups within your project. As a
    convenience, all new projects are created with one new group,
    termed the <em>default group</em>. As its name implies, whenever
    the group is left unspecified in a form, it defaults to the
    project group (this allows you to create a project without any sub
    groups at all; new members join the default group, new experiments
    are created in the default group, etc.).
    </p>

    <p>
    Project groups are created via the Project Information link at
    your left. Simply go to the project page in which you want to
    create a group, and look for the "Create New Group" link. More
    information on project groups is available via the <a
    href="doc.php3">Emulab Documentation</a> page in the
    <a href="docwrapper.php3?docname=groups.html">Groups Tutorial</a>.
    </p>

<li><a NAME="GS-7"></a>
208 209 210
    <h3>Where do I get help?</h3>
    <p>
    If you cannot find an answer to your question in the
211
    <a href="doc.php3">Emulab Documentation</a>, then you can
212
    send us an <a href="emailus.php3">email message</a>. We will try
213 214
    to answer your question as quickly as we can.
    </p>
215
</ul>
216

Leigh B. Stoller's avatar
Leigh B. Stoller committed
217
<hr>
218 219 220 221 222

<a NAME="UTT"></a>
<h3>Using the Testbed</h3>
<ul>
<li><a NAME="UTT-1"></a>
223
    <h3>Is there a tutorial?</h3>
224
    <p>
225
    Yes, we have an extensive <a href="tutorial/tutorial.php3">tutorial</a>
226 227 228
    on using the Testbed.
    </p>

229
<li><a NAME="UTT-NODES"></a>
230 231 232 233 234 235
    <h3>How many nodes can I ask for?</h3>
    <p>
    You can ask for as many nodes as are currently available! You can
    click on the "Node Reservation Status" link at your left to see
    how many nodes are currently free. If you ask for more than are
    currently available, your experiment will be rejected (you
Jay Lepreau's avatar
Jay Lepreau committed
236
    will receive email notification shortly after you submit your NS
237 238 239 240 241 242 243 244 245
    file to the web interface).
    </p>

    <p>
    <em>We urge all new Emulab users to begin with a small 3-4 node
    experiment so that you will become familiar with NS syntax and the
    practical aspects of Emulab operation.</em>
    </p>

246
<li><a NAME="UTT-2"></a>
247
    <h3>Do I get root access on my nodes?</h3>
248 249 250 251 252 253
    <p>
    Yes. Project leaders get root access to all of the nodes in all of
    the experiments that are running in their project. Project members
    get root if their project leader grants them root access, when the
    leader approves the group <a href="#GS-1">membership request</a>.
    Root privileges are granted via the <code>sudo</code> command. The
254
    <a href="tutorial/tutorial.php3#RootAccess">tutorial</a> describes
255 256
    this in more detail.
    </p>
257 258 259 260 261 262

<li><a NAME="UTT-3"></a>
    <h3>Do my nodes have consoles I can look at?</h3>
    <p>
    Yes. Each of the PCs has its own serial console line that you can
    interact with using the unix <tt>tip</tt> utility. To "tip" to
Mike Hibler's avatar
Mike Hibler committed
263 264
    "pc1" in your experiment, ssh into <b>users.emulab.net</b>, and
    then type <tt>tip pc1</tt> at the unix prompt. You may then
265 266 267 268
    interact with the serial console. The console output is also saved
    for each node so that you may look at it it later. For each node,
    the console log is stored as <tt>/var/log/tiplogs/pcXXX.run</tt>.
    This <em>run</em> file is created when nodes are first allocated
Leigh B. Stoller's avatar
Leigh B. Stoller committed
269
    to an experiment, and the unix permissions of the run files permit
270 271 272
    just members of the project to view them. When the nodes are
    deallocated, the run files are cleared, so if you want to save
    them, you must do so before terminating the experiment. 
273 274 275 276 277 278 279 280 281 282 283 284 285
    </p>
    <p>
    The Sharks also have serial console lines, but because of the
    limited number of serial ports available on <b>users.emulab.net</b>, only
    one Shark, the last or "eighth", on each shelf has a console line
    attached. To tip to that shark, you would type <tt>tip shXX</tt>
    at the unix prompt, where "XX" is the shark shelf number. The
    shark shelf number is the first digit in the name. Using shark
    sh16-8 as an example, the shelf number is sixteen, and the number
    of the node on the shelf is eight.
    </p>

<li><a NAME="UTT-4"></a>
286 287 288 289 290 291 292 293 294 295 296 297 298 299 300
    <h3>Can I reboot (power cycle) my nodes?</h3>
    <p>
    Yes. Each of the PCs is independently power controlled. If your
    node becomes wedged, or otherwise unresponsive, you can use the
    <tt>node_reboot</tt> command, as discussed in the
    <a href="tutorial/tutorial.php3#Wedged">Emulab Tutorial.</a>
    </p>
    <p>
    The Sharks are also power controlled, but because of the limited
    number of power ports available, the entire shelf of 8 sharks is
    on a single controller. The <tt>node_reboot</tt> does its best to
    cleanly reboot individual sharks, but if a single shark is
    unresponsive, the entire shelf will be power cycled.
    </p>

301 302 303 304 305 306 307 308 309 310 311 312
<li><a NAME="UTT-SCROGGED"></a>
    <h3>I've scrogged my disk! Now what?</h3>
    <p>
    If you manage to corrupt a disk (or slice), no worries. You can easily
    repair the damage yourself by reloading a fresh copy of the default
    disk image. You will of course lose anything you have stored on that
    disk; it is a good idea to store only data that can be easily recreated, 
    or else store it in your project directory in <tt>/proj</tt>. Disk
    reloading is covered in more detail in the
    <a href="tutorial/tutorial.php3#Scrogged">Emulab Tutorial</a>.
    </p>

313
<li><a NAME="UTT-5"></a>
314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330
    <h3>Where do I store files needed by my experiment?</h3>
    <p>
    Each project has its own directory, rooted at <tt>/proj</tt>,
    which is available via NFS to all of the nodes in experiments
    running in that project. For example, when the "RON" project was
    created, a directory called /proj/RON was also created. This
    directory is owned by the project creator, and is in the unix
    group "RON." Its permission (mode) is 770; read/write/execute
    permitted by the project creator and by all of the members of the
    project RON, but protected against all access by people outside
    the RON project.
    </p>
    <p>
    Project members are encouraged to store any files needed by their
    experiments in the corresponding /proj project directory. 
    </p>

331
<li><a NAME="UTT-6"></a>
332 333 334 335 336 337 338 339 340
    <h3>Are my files on <b>users.emulab.net</b> backed up (filesaved)?</h3>
    <p>
    Yes. All of the files in your home directory on /users, and all of
    the files in your project directory in /proj are filesaved. While
    we can restore lost files in an emergency, we encourage you to
    back up critical data on your own to avoid (possibly long) delays
    in conducting your experiments.
    </p>
    
341
<li><a NAME="UTT-7"></a>
342 343 344 345 346 347 348 349 350 351 352 353 354 355
    <h3>Are the nodes in my experiment backed up (filesaved)?</h3>
    <p>
    No! The nodes in your experiment are not filesaved. Any changes
    you make to the local filesystems will be lost if the event of a
    disk failure. We plan to provide a mechanism for experimenters to
    create snapshots of their node state, but that is not done yet. In
    the meantime, any files that must not be lost should be stored in
    the project directory (/proj/<project_name>), which is available
    via NFS to all of the nodes in your experiment. You may also store
    files in your home directory (/users/<login>), also available via
    NFS to all of your nodes, but that is not the preferred location
    since quotas on /users are relatively small.
    </p>
    
356 357 358
<li><a NAME="UTT-Swapping"></a>
    <h3>What is Swapping</h3>
    <p>
Jay Lepreau's avatar
Jay Lepreau committed
359
    Swapping is when you (or we) temporarily swap your experiment out,
360 361 362 363 364
    releasing all of the nodes in the experiment. Your experiment is
    still resident in the Emulab database, and you can see its status
    in the web interface, but no nodes are allocated. Once an
    experiment is swapped out, you can swap it back in via the web
    interface by going to the Experiment Information page for your
365
    experiment, and clicking on the swapin option. 
366 367
    </p>

368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384
    <p>
    The <tt>swappable</tt> checkbox in the Begin Experiment web page
    is used to determine what experiments can be <em>automatically</em>
    swapped by the testbed scheduling system. Note that all experiments are
    capable of being swapped; even if you do not check the swappable box,
    you are free to swap your own experiments as you like. The only
    difference is that the testbed scheduling system will not consider your
    experiment when looking for experiments to swap out. You will sometimes
    notice that the Experiment Information page does not contain the swap
    link. That is because experiments cannot be swapped when they are in
    transition. For example, when the experiment is being swapped in (say,
    after first being created) the link will disappear until the experiment
    is fully swapped in, and it is capable of being swapped out. You will
    need to occasionally reload the page so that the updated state is
    recognized and the swap link appears. 
    </p>
    
385 386 387 388 389 390 391 392
    <p>
    Be aware that we do not currently save any files that you may have
    placed on your nodes. When your experiment is swapped back in, you
    will likely get different nodes, and with fresh copies of the disk
    images. For that reason, you should not swap your experiment out
    unless you make arrangements to save and restore any state you need.
    </p>
    
393 394 395 396 397 398 399 400 401 402 403 404 405 406 407
</ul>

<hr>


<a NAME="HDS"></a>
<h3>Hardware Setup</h3>
<ul>
<li><a NAME="HDS-1"></a>
    <h3>What kind of computers are used for my nodes?
<li><a NAME="HDS-2"></a>
    How many nodes are there?
<li><a NAME="HDS-3"></a>
    How many ethernet cards are on each node?</h3>
    <p>
408 409 410
    Please see the <a href="docwrapper.php3?docname=hardware.html">
    Hardware Overview</a> page for a description and count of the
    computers that comprise the Testbed.
411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432
    </p>
    
<li><a NAME="HDS-4"></a>
    <h3>How many nodes are currently available (free)?</h3>
    <p>
    If you click on the "Node Reservation Status" link in the menu to
    your left, you will see a summary of the number of nodes (by type)
    that are currently available, followed by a listing of the
    reservation status of each individual node.
    </p>
    
<li><a NAME="HDS-5"></a>
    <h3>Can I do traffic shaping on my links?</h3>
    <p>
    Yes! You can specify the delay, bandwidth, and packet loss rate
    between any two nodes in your topology. Bandwidth and delay are
    specified in the NS <tt>duplex-link</tt> statement, while packet
    loss rate is specified with the Emulab <tt>tb-set-link-loss</tt>
    extension to NS. You may also specify delay, bandwidth, and packet
    loss rate between nodes in a regular LAN.
    </p>
    <p>
433
    Please see the
434
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
435
    page for a summary of all Emulab NS extensions, and the
436
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
437 438
    example. 
    </p>
439 440 441 442 443 444 445 446 447 448 449 450 451

<li><a NAME="HDS-6"></a>
    <h3>Can I modify the traffic shapping parameters on my links?</h3>
    <p>
    Yes! If your NS file specified traffic shaping on a link, then you
    can subsequently modify those parameters after the experiment has
    been swapped in. Note that you cannot <em>convert</em> a non shaped
    link into a shaped link; you can only modify the traffic shaping
    parameters of a link that is already being shaped.  To modify the
    parameters, log into <b>users.emulab.net</b> and use the
    <tt>delay_config</tt> program. This program requires that you know
    the symbolic names of the individual links. This information is
    available via the web interface on the Experiment Information
452 453
    page. The command line syntax for <tt>delay_config</tt> will be
    displayed when the <tt>-h</tt> option is given.
454
    </p>
455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481

<li><a NAME="HDS-7"></a>
    <h3>Are there other traffic shapping parameters besides latency,
    bandwidth, and packet loss rate?</h3>
    <p>
    Yes! However, access to those other parameters is slightly more
    difficult since you cannot specify them in your NS file. First
    off, you should log into <tt>users.emulab.net</tt> and read the
    man page for
    <a href='http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+4.3-RELEASE'>
    <tt>ipfw</tt></a>. Refer to the section on <tt>dummynet</tt>; ipfw
    is the user interface for the <tt>Dummynet</tt> traffic shaper.
    As noted in previous section above, you can alter the traffic
    shapping parameters of any delayed link (one in which you have
    specified a bandwidth, delay, or PLR that causes a delay node to
    be inserted). However, you will need to log into the delay node
    for the link you wish to modify and interact with <tt>ipfw</tt>
    directly. The easiest approach would be to make a copy of
    </tt>/etc/testbed/rc.delay</tt> and edit the pipe commands as
    desired (or replace the pipe commands with "queue" commands).  The
    pipe commands are indexed by number; the mapping from pipe number
    to virtual link is available via the web interface on the
    Experiment Information page for your experiment.  Be sure to leave
    the rest of the contents of the file as is. Once you have your
    changes made, simply execute the file using the <a href="#UTT-2">
    sudo</a> command.
    </p>    
482 483 484 485 486 487 488 489 490 491
</ul>

<hr>

<a NAME="SWS"></a>
<h3>Software Setup</h3>
<ul>
<li><a NAME="SWS-1"></a>
    <h3>What OS do the nodes run?</h3>
    <p>
492 493 494
    Please see the <a href="docwrapper.php3?docname=software.html">
    Software Overview</a> page for a description of the Operating
    Systems that can be run on each of the Testbed nodes.
495 496 497 498 499 500 501 502 503 504 505 506
    </p>

<li><a NAME="SWS-2"></a>
    <h3>How do I select which OS to run on each node?</h3>
    <p>
    When a choice of OS is available, you may specify which one you
    prefer for each node in the NS file using the Emulab
    <tt>tb-set-node-os</tt> extension to NS. When your experiment is
    configured, the appropriate disk image will be loaded on your
    nodes, and the selected operating system will boot up on each.
    </p>
    <p>
507
    Please see the
508
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
509
    page for a summary of all Emulab NS extensions, and the
510
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527
    example. 
    </p>    
    
<li><a NAME="SWS-3"></a>
    <h3>Can I load my own software (RPMs) on my nodes?</h3>
    <p>
    Yes! If have an RPM (or more than one) that is appropriate for
    loading on the OS you have selected, you can arrange to have them
    loaded automatically when your experiment is configured. The
    Emulab NS extension <tt>tb-set-node-rpms</tt> is used in the NS
    file to specify a list of RPMS to install. You may specify a
    different list for each node in the experiment. When the node
    first boots after the experiment is configured, each of the RPMs
    will be installed (but only RPMs that have not already been
    installed). 
    </p>
    <p>
528
    Please see the
529
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
530
    page for a summary of all Emulab NS extensions, and the
531
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
532 533
    example. 
    </p>    
534
    
535 536 537 538 539 540 541 542 543 544 545 546 547 548
<li><a NAME="SWS-4"></a>
    <h3>Can I schedule programs to run automatically when a node boots?</h3>
    <p>
    Yes! You can arrange to run a single program or script when your
    node boots. The script is run as the UID of the experiment
    creator, and is run after all other node configuration (including
    RPM installation) has completed. The exit status of the script (or
    program) is reported back and is made available for you to view in
    Experiment Information link in the menu at your left. The Emulab
    NS extension <tt>tb-set-node-startup</tt> is used in the NS file
    to specify the path of the script (or program) to run. You may
    specify a different program for each node in the experiment.
    </p>
    <p>
549
    Please see the
550
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
551
    page for a summary of all Emulab NS extensions, and the
552
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
553 554
    example.
    </p>    
555

556
<li><a NAME="SWS-5"></a>
557 558 559
    <h3>How can I turn on routing or set up routes automatically 
    in my nodes?</h3>
    <p>
560 561 562 563 564
    By default, we do not setup any static routes or run any routing daemon
    on nodes in an experiment.  However, we do provide an option for
    those experimentors who do not want to manage routing themselves and
    who are using one of our provided FreeBSD or Linux disk images.
    Simply adding:
565
<pre>
566
tb-set-ip-routing ospf
567
</pre>
568 569
    to your NS file will enable <code>gated</code> running the OSPF
    protocol on all nodes in the experiment.
570
    </p>
571
    <p>
572 573 574 575 576
    Please see
    "Setting up IP routing between nodes"
    in the
    <a href="tutorial/tutorial.php3">Emulab Tutorial</a>
    for more information about IP routing setup options.
577 578 579
    </p>
    
<li><a NAME="SWS-6"></a>
580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595
    <h3>How does my software determine when other nodes in my
    experiment are ready?</h3>
    <p>
    If your application requires synchronization to determine when all
    of the nodes in your experiment have started up and are ready to
    proceed, then you can use the Testbed's <i>ready bits</i>
    mechanism. The ready bits are really just a way of determining how
    many nodes have issued the <b>ready</b> command, and is returned
    to the application as a simple N of M string, where N is the
    number that have reported in, and M is the total number of nodes
    in the experiment. Applications can use this as a very simplistic
    form of barrier synchronization, albeit one that can be used just
    once and one that does not actually block!
    </p>
    <p>
    Use of the ready bits is described in more detail in the <a href =
596
    "tutorial/tutorial.php3">Emulab Tutorial</a> and in the <a href =
597
    "doc/docwrapper.php3?docname=tmcd.html"> Testbed Master Control
598
    Daemon</a> documentation.
599 600
    </p>
    
601
<li><a NAME="SWS-7"></a>
602 603 604 605 606 607 608 609 610 611 612
    <h3>Can I run my own Operating System?</h3>
    <p>
    Yes! You can run your own OS on any of the PCs (the Sharks do not
    support custom operating systems as this time, however you can run
    <a href = "http://www.cs.utah.edu/flux/oskit/">OSKit</a> kernels
    on the PCs or the Sharks). Each of the PCs is partitioned so that
    the 4th DOS slice (about 6GB) is unused and available to be loaded
    with whatever OS you want to run. The only requirement is that
    your image contain a proper DOS boot record in the first sector
    (first sector of the 4th DOS slice) which can be invoked by the
    DOS Master Boot Record in the first sector of the disk. There are
613 614 615 616
    other minor requirements which are detailed in the <a
    href="tutorial/tutorial.php3#CustomOS">Custom OS</a> documentation
    page. The procedure for creating and installing your custom OS are
    also described in this document.
617
    </p>
618 619
</ul>

620 621 622 623 624 625 626 627
<hr>

<a NAME="SEC"></a>
<h3>Security Issues</h3>
<ul>
<li><a NAME="SEC-1"></a>
    <h3>Is Emulab Firewalled?</h3>
    <p>
628 629
    Yes. Emulab blocks all of the <i>low numbered</i> ports (ports below 1024),
    with the exception of ports 20 and 21 (FTP), 22 (Secure Shell), and 80
Jay Lepreau's avatar
Jay Lepreau committed
630
    (HTTP). This is for the protection of experimenters, as well as to ensure
631 632 633 634
    that an errant application cannot become the source of a Denial of Service
    attack to sites outside of Emulab. If your application requires external
    access to other low numbered ports, please contact us to make special
    arrangements.
635 636
    </p>
</ul>
637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658

<hr>

<a NAME="TR"></a>
<h3>Troubleshooting</h3>
<ul>
<li><a NAME="TR-1"></a>
    <h3>My experiment is setup, but I cannot
	send packets between some of the nodes, why?</h3>
    <p>
    The most common reason is that your topology
    includes nodes which are not directly connected, and you have
    not setup any routing.  Refer to
    "<a href="#SWS-5">How can I turn on routing or set up routes
    automatically in my nodes?</a>" for details.  If you cannot
    send packets between two machines which are directly connected
    (via a link or a lan), then there are two possibilities:
    either the nodes did not properly negotiate their speed and
    duplex with the Cisco switch, or the physical wire is loose
    or bad.  In these cases, you should contact us for help.
    </p>
</ul>