faq.html 52.7 KB
Newer Older
Leigh B. Stoller's avatar
Leigh B. Stoller committed
1 2
<!--
   EMULAB-COPYRIGHT
3
   Copyright (c) 2000-2002 University of Utah and the Flux Group.
Leigh B. Stoller's avatar
Leigh B. Stoller committed
4 5
   All rights reserved.
  -->
6
<center>
7
<h2>Frequently Asked Questions</h2>
8 9 10
</center>

<h2>Contents</h2>
11
<ul>
12 13
<li> <a href="#GS">Getting Started</a>
     <ul>
14
     <li> <a href="#GS-Eligible">Who is Eligible to use Emulab.Net?</a>
15 16
     <li> <a href="#GS-1">How do I start a project?</a>
     <li> <a href="#GS-2">How do I join a project?</a>
17 18 19 20
     <li> <a href="#GS-2b">I'm a project leader, and someone applied
	                   to join my project, but they're not on the 
	                   list to be approved.</a>
     <li> <a href="#GS-2c">Will Emulab send me email messages?</a>
21
     <li> <a href="#GS-3">I have an Emulab account. Now what?</a>
22
     <li> <a href="#GS-PATH">Do I need to change my PATH variable?</a>
23 24
     <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>
25 26
     <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>
27 28 29 30 31
     </ul>

<li> <a href="#UTT">Using the Testbed</a>
     <ul>
     <li> <a href="#UTT-1">Is there a tutorial?</a>
32 33
     <li> <a href="#UTT-NETBUILD">Do you have a <b>GUI</b> to help me
                                   create experiments?</a>
34
     <li> <a href="#UTT-TOPO">Are there any constraints on my topology?</a>
35
     <li> <a href="#UTT-NODES">How many nodes can I ask for?</a>
36
     <li> <a href="#UTT-HOWLONG">How long can I keep using my nodes?</a>
37
     <li> <a href="#UTT-TOOFEW">What if I need more nodes than are free?</a>
38
     <li> <a href="#UTT-2">Do I get root access on my nodes?</a>
39
     <li> <a href="#UTT-3">Do my nodes have consoles I can look at?</a>
Chad Barb's avatar
Chad Barb committed
40 41
     <li> <a href="#UTT-TUNNEL">How do I connect directly to node consoles, 
                                without going through <b>users</b>?</a>
42
     <li> <a href="#UTT-4">Can I reboot (power cycle) my nodes?</a>
43
     <li> <a href="#UTT-SCROGGED">I've scrogged my disk! Now what?</a>
44 45
     <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>
46
                           backed up (filesaved)?</a>
47
     <li> <a href="#UTT-7">Are the nodes in my experiment backed up
48
                           (filesaved)?</a> 
49
     <li> <a href="#UTT-Swapping">What is Swapping?</a> 
50
     <li> <a href="#UTT-Restart">What is Experiment Restart?</a> 
Robert Ricci's avatar
Robert Ricci committed
51 52
     <li> <a href="#UTT-8">How can I get switch statistics (such as packet
                           counts) for my experiment?</a> 
53 54
     <li> <a href="#UTT-Naming">What names should I use to refer to the
			   nodes in my experiment?</a>
55 56 57 58 59
     </ul>

<li> <a href="#HDS">Hardware setup</a>
     <ul>
     <li> <a href="#HDS-1">How many nodes are there?</a>
60 61
     <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>
62 63
     <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
64
     <li> <a href="#HDS-6">Can I modify the traffic shaping
65
                           parameters on my links?</a>
Jay Lepreau's avatar
Jay Lepreau committed
66
     <li> <a href="#HDS-7">Are there other traffic shaping parameters
67
                           besides latency, bandwidth, and PLR?</a>
68 69 70 71 72
     </ul>

<li> <a href="#SWS">Software setup</a>
     <ul>
     <li> <a href="#SWS-1">What OS do the nodes run?</a>
73 74 75
     <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
76 77 78 79
                           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
80
                           nodes in my experiment are ready?</a>
81
     <li> <a href="#SWS-7">Can I run my own Operating System?</a>
82
     <li> <a href="#SWS-8">What if I need more disk space on my nodes?</a>
83 84
     <li> <a href="#SWS-9">Are there testbed-specific daemons that could
                           interfere with my experiment?</a>
Mac Newbold's avatar
Mac Newbold committed
85
     <li> <a href="#SWS-10">Does Emulab support IP Multicast?</a>
86
     </ul>
87 88 89 90 91

<li> <a href="#SEC">Security Issues</a>
     <ul>
     <li> <a href="#SEC-1">Is Emulab Firewalled?</a>
     </ul>
92 93 94

<li> <a href="#TR">Troubleshooting</a>
     <ul>
95
     <li> <a href="#TR-1">My experiment is set up, but I cannot
96 97 98 99 100 101 102 103
     			  send packets between some of the nodes. Why?</a>
     <li> <a href="#TR-2">I asked for traffic shaping, but everything
			  seems to be going at full LAN speeds. 
			  What's wrong?</a>
     <li> <a href="#TR-3">I set a non-zero packet-loss (or delay) but 'ping'
                          shows no packet-loss (or delay). Why?</a>
     <li> <a href="#TR-4">I set a non-zero packet-loss (or delay) but 'ping'
                          shows a different packet-loss (or delay). Why?</a>
104
     </ul>
105 106 107
</ul>

<hr>
108

109 110 111
<a NAME="GS"></a>
<h3>Getting Started</h3>
<ul>
112 113 114
<li><a NAME="GS-Eligible"></a>
    <h3>Who is Eligible to use Emulab.Net?</h3>
    <p>
115 116 117 118 119 120 121 122
    In principle, almost any research or educational use
    by those that have a need for it is appropriate and encouraged.
    This includes use by universities, industrial research labs, and both
    US and non-US institutions.   With some provisos, use for development
    and evaluation is also acceptable, even by companies.
    See our <a href ="docwrapper.php3?docname=policies.html">posted policies</a>
    for more detail.  If you are unsure about your eligibility to use
    Netbed/Emulab, please just send us an email inquiry.
123 124
    </p>

125
<li><a NAME="GS-1"></a>
126
    <h3>How do I start a project?</h3>
127 128
    <p>
    If you are new to the Testbed, simply click on the "Start Project"
129
    link on the Emulab <a href="http://www.emulab.net">Home
130 131 132 133
    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
134 135
    can be found in <a href="docwrapper.php3?docname=auth.html">
    Authorization Page</a>.
136
    </p>
137 138 139 140 141 142 143
    <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>
144

145
<li><a NAME="GS-2"></a>
146
    <h3>How do I join a project?</h3>
147 148
    <p>
    If you are new to the Testbed, simply click on the "Join Project"
149
    link on the Emulab <a href="http://www.emulab.net">Home
150 151 152
    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
153
    name of the project). Then click on the "Submit" button, and wait
154 155 156
    for an email with your new user key. When that email arrives, use
    the link in it (or the key itself), and use it with your password 
    to log into the web site and verify your account. Then just wait
157 158 159
    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.
160 161
    </p>

162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 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 208 209 210 211 212 213
<li><a NAME="GS-2b"></a>
    <h3>I'm a project leader, and someone applied to join my project,
    but they're not on the list to be approved.</h3>    
    <p>
      Joining a project has 3 stages. The first two are done by
      the person trying to join, and they both must be completed
      before you can approve their application. The first two are
      outlined <a href="#GS-2">in the previous question</a>, where the
      user fills out the "Join Project" form, and performs account
      verification. After these two steps are both complete, the
      project leader and any group leaders in the group 
      (<a href="#GS-6">More info here</a>) will get an email saying
      the account is ready to be approved, and it will appear on the
      list of new users waiting to be approved.
    <p>
      If someone says they've applied, but you haven't received an
      email from Emulab about it, and they don't show up on your
      list, the most likely cause is that they haven't finished the
      verification step.
    </p>

<li><a NAME="GS-2c"></a>
    <h3>Will Emulab send me email messages?</h3>
    <p>
      Yes! Emulab uses email notifications to you in several different
      ways. Often it will send you a copy of information regarding
      experiments you set up, applications to projects, and other
      things you do at Emulab. Sometimes (like with account
      verification) the email is a critical part of being able to use
      Emulab.
    <p>
      For those reasons it is <b>critical</b> that any spam filtering
      software you have accept email from Emulab itself (anything
      coming from the emulab.net domain) and from Emulab staff (from
      the cs.utah.edu or flux.utah.edu domains). In many cases, it may
      also say that is from a specific machine in those domains. Our
      messages usually do not get flagged as spam by most filters, but
      in certain cases it can be a problem. It is also important that
      it not require manual intervention or confirmation to get emails
      through to you, so programs like SpamKiller can cause problems.
    <p>
      It is also important to read your email often while you are
      using Emulab, especially while you have machines reserved in 
      an experiment. A few emails may be the only notification you'll
      get before we swap out an experiment that appears to be idle,
      and if you don't respond, you may lose important work. Email is
      also our method for informing you about problems we may be
      experiencing, downtimes, or other important announcements. Your
      experience with Emulab (and ours with you) will be much more
      pleasant if everyone is responsive to email.
    </p>

214 215 216 217 218 219 220 221
<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>
222
	ssh users.emulab.net -l joe		</pre>
223 224 225
    </p>
    <p>
    Your password starts out the same as the password you initially
226 227 228 229 230 231 232 233
    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. 
234 235 236 237 238 239
    </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,
240 241
    subject to Emulab <a href="docwrapper.php3?docname=policies.html">
    administrative policies</a>.
242 243 244 245 246 247 248 249 250 251 252 253 254 255 256
    </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>
257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286
    <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>
287 288 289
    <h3>Where do I get help?</h3>
    <p>
    If you cannot find an answer to your question in the
290
    <a href="doc.php3">Emulab Documentation</a>, then you can
291
    send us an <a href="emailus.php3">email message</a>. We will try
292 293
    to answer your question as quickly as we can.
    </p>
294
</ul>
295

Leigh B. Stoller's avatar
Leigh B. Stoller committed
296
<hr>
297 298 299 300 301

<a NAME="UTT"></a>
<h3>Using the Testbed</h3>
<ul>
<li><a NAME="UTT-1"></a>
302
    <h3>Is there a tutorial?</h3>
303
    <p>
304
    Yes, we have an extensive <a href="tutorial/tutorial.php3">tutorial</a>
305 306 307
    on using the Testbed.
    </p>

Chad Barb's avatar
Chad Barb committed
308
<li><a NAME="UTT-NETBUILD"></a>
309 310 311 312 313 314 315 316 317 318 319 320 321 322 323
    <h3>Do you have a GUI to help me create experiments?</h3>
    <p>
    Yes, we provide a GUI that gives you an easy to use drawing
    palette on which you can place nodes, lans, and links. Testbed
    specific attributes such as operating system, hardware type, and
    link/lan characteristics, may be attached to each object. With a
    single click, you can instantiate your new topology on the Testbed
    as an experiment in one of your projects. Alternatively, you can
    save the auto-generated NS file on your machine, edit as required,
    and then submit it later when creating an experiment.
    </p>
    
    <p>
    To access the GUI, please log in and go to the Begin Experiment page.
    <em>Note: you need a Java compliant browser.</em>
Chad Barb's avatar
Chad Barb committed
324 325
    </p>

326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341
<li><a NAME="UTT-TOPO"></a>
    <h3>Are there any constraints on my topology?</h3>
    <p>
    Yes, but only those imposed by the physical hardware that is
    currently available in our testbed. The constraints that people
    most commonly run into are the maximum speed of our links
    (100Mbps) and the maximum number of network interface cards (NICs)
    in our machines. You can't get any links faster than 100Mbps,
    since we don't yet have gigabit links for experimenters to
    use. Our nodes each have 4 experimental network interfaces, so
    each node can be a member of up to 4 links or LANs. A good
    strategy for making your topology fit within those limits is to
    replace multiple links to a node with a LAN or with a router
    node. Ask Testbed Operations if you need further assistance.
    </p>

342
<li><a NAME="UTT-NODES"></a>
343 344 345 346 347 348
    <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
349
    will receive email notification shortly after you submit your NS
350 351 352 353 354 355 356 357 358
    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>

359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374
<li><a NAME="UTT-HOWLONG"></a>
    <h3>How long can I keep using my nodes?</h3>
    <p>
    You can keep them as long as you need them, subject to our <a
    href="docwrapper.php3?docname=swapping.html">Node Usage
    Policies</a>.  In general, you should do your work, and then
    terminate your experiment as soon as you're done with it. If
    you're not done with it, but are through for a while, you should
    probably "swap out" your experiment (See the question <a
    href="#UTT-Swapping">What is Swapping</a> in this FAQ). It is
    especially important to swap out your experiment if you're through
    with it for the weekend. Emulab usually gets heavy use on the
    weekends by users who need to make very large experiments, so it
    is important to leave as many nodes available as possible.
    </p>

375 376 377 378 379
<li><a NAME="UTT-TOOFEW"></a>
    <h3>What if I need more nodes than are free?</h3>
    <p>
    For example, say you need 50 nodes but there are only 40 free. In
    general, getting this many nodes is going to require intervention
Jay Lepreau's avatar
spello  
Jay Lepreau committed
380
    from Testbed Operations, if only so we can ask other experimenters
381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396
    to free up nodes, if possible. Please send us email if you are not
    able to able to get the number of nodes you need for your experiment.
    </p>

    <p>
    Another alternative is to use the
    <a href="tutorial/tutorial.php3#BatchMode">Batch System.</a> 
    If your experiment is amenable to being batched (does not require
    human intervention to start and stop), then you can submit a batch
    request, which will be serviced when enough nodes become
    available.  Typically, you would start out with a few nodes,
    getting used to the batch system and creating whatever scripts are
    needed to make the experiment batchable. Then scale up to larger
    numbers of nodes. Thats the easiest way of getting a lot of nodes!
    </p>    
    
397
<li><a NAME="UTT-2"></a>
398
    <h3>Do I get root access on my nodes?</h3>
399 400 401 402 403 404
    <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
405
    <a href="tutorial/tutorial.php3#RootAccess">tutorial</a> describes
406 407
    this in more detail.
    </p>
408 409 410 411

<li><a NAME="UTT-3"></a>
    <h3>Do my nodes have consoles I can look at?</h3>
    <p>
412 413 414 415
    Yes. Each of the PCs has its own serial console line with which you can
    interact, either directly from your desktop (see next FAQ entry),
    or by hopping through the "users" machine,
    using our <tt>console</tt> program. To connect over serial line to
Mike Hibler's avatar
Mike Hibler committed
416
    "pc1" in your experiment, ssh into <b>users.emulab.net</b>, and
417 418 419 420 421 422
    then type <tt>console pc1</tt> at the Unix prompt. You may then
    interact with the serial console (hit "enter" to elicit output from
    the target machine).
    </p><p>
    In any case, all console output from each node is saved
    so that you may look at it it later. For each node,
423 424
    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
425 426
    to an experiment, and the Unix permissions of the run files permit
    only members of the project to view them. When the nodes are
427 428
    deallocated, the run files are cleared, so if you want to save
    them, you must do so before terminating the experiment. 
429 430 431 432 433
    </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
434 435
    attached. To connect to that shark, you would type <tt>console shXX</tt>
    at the Unix prompt, where "XX" is the shark shelf number. The
436 437 438 439 440
    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>

Chad Barb's avatar
Chad Barb committed
441 442 443 444 445 446
<li><a NAME="UTT-TUNNEL"></a>
    <h3>How do I connect directly to node consoles, 
        without going through <b>users</b>?</h3>
    <p>
    Clicking "Connect to Serial Line"
    in the Node Options page will send your browser a "text/x-testbed-acl"
Chad Barb's avatar
 
Chad Barb committed
447 448 449 450 451 452 453
    ".tbacl" file. 
    In windows, if you have installed <code>tiptunnel</code>, available
    below, you can save this file in a folder and double-click it
    to launch a tunneled connection to your node.
    In FreeBSD or Linux, you can save the file and pass it as an argument
    to <code>tiptunnel</code>, or associate it with
    <code>tiptunnel</code> in your web browser.
454 455
    Upon connection you typically first have to hit "enter" to
    elicit output from the target machine.
Chad Barb's avatar
 
Chad Barb committed
456 457 458

<!--
    If you have downloaded <code>tiptunnel</code> and set it as the 
Chad Barb's avatar
Chad Barb committed
459 460 461 462 463
    handler for that MIME type, <code>tiptunnel</code> will launch a new 
    telnet running in a new xterm (this may take a few seconds.) 
    That telnet will be connected to a local port, 
    which is tunneled through SSL to your node's console. 
    Closing the xterm, exiting telnet, or killing <code>tiptunnel</code>
Chad Barb's avatar
 
Chad Barb committed
464 465
    itself will end the connection. -->
    
Chad Barb's avatar
Chad Barb committed
466
    </p>
Chad Barb's avatar
 
Chad Barb committed
467 468 469
    <ul>
    <li>
    You can download the <code>tiptunnel</code>
470
    <a href="downloads/tiptunnel-win32.exe">installer for Windows here</a>.
Chad Barb's avatar
 
Chad Barb committed
471 472
    </li>
    <li>
Chad Barb's avatar
 
Chad Barb committed
473 474
    You can download the <code>tiptunnel</code> statically-linked x86
    <a href="downloads/tiptunnel-freebsd.tar.gz">binary for FreeBSD here</a>.
Chad Barb's avatar
 
Chad Barb committed
475 476
    </li>
    <li>
Chad Barb's avatar
 
Chad Barb committed
477 478
    You can download the <code>tiptunnel</code> statically-linked x86
    <a href="downloads/tiptunnel-linux.tar.gz">binary for Linux here</a>.
Chad Barb's avatar
 
Chad Barb committed
479 480 481 482 483
    </li>   
    <li>
    A source distribution will be available soon.
    </li>
    </ul>
484

Chad Barb's avatar
 
Chad Barb committed
485 486 487 488 489 490 491 492 493 494 495
    <h3>Instructions for Windows:</h3>
    <ul>
      <li>Run the installer executable, and successfully complete the installation.</li>
      <li>In the Web Interface Node view, 
          click on the "Connect to serial line" link.</li>
      <li><b>Save</b> the resulting .tbacl file in an appropriate place.
          (for instance a folder off the desktop.)</li>
      <li>For the lifetime of your experiment, you can simply double-click
          these .tbacl files to connect.</li>
    </ul> 

Chad Barb's avatar
 
Chad Barb committed
496
    <h3>Instructions for Linux/FreeBSD:</h3>
497 498 499
    <ul>
    <li>Use <code>gunzip</code>, then <code>tar xvf</code> on the downloaded file.</li>
    <li>Move the resulting <code>tiptunnel</code> binary into 
Chad Barb's avatar
 
Chad Barb committed
500
    a directory of your choice (<code>/usr/local/bin</code>, 
501 502 503
    or <code>~/bin</code> are two good places.)</li>
    <li>Set up your browser to handle MIME type "text/x-testbed-acl"
    as outlined below.</li>
Chad Barb's avatar
 
Chad Barb committed
504 505 506 507 508 509 510 511 512 513
    <li>In the Web Interface Node view, 
        click on the "Connect to serial line" link.</li>
    <li>If your browser is properly configured to use <code>tiptunnel</code>,
        a new xterm window with a telnet session open to your node
        should emerge.</li>
    <li>(Alternately, you can tell your browser to save "text/x-testbed-acl"
        files in a directory and you can run them with <code>tiptunnel</code> directly;
        this may be more convenient than using the web interface every time you wish
        to connect to a node in your experiment.
        Note that these files are valid for the lifetime of your experiment.)</li>
514
    </ul>
515

Chad Barb's avatar
 
Chad Barb committed
516
    <h3>Linux/FreeBSD and Netscape 4.7:</h3>
517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537
    <ul>
    <li>Choose <code>preferences</code> from the <code>edit</code> menu.</li>
    <li>Select <code>Navigator</code>, then <code>Applications</code> under
        it.</li>
    <li>Click the <code>New...</code> button.</li>
    <li>In the <code>MIMEType</code> box, type <code>text/x-testbed-acl</code>
    </li>
    <li>In the <code>Suffixes</code> box, type <code>tbacl</code></li>
    <li>Choose <code>Application</code> in the <code>Handled by</code>
        box</li>
    <li>Next to <code>Application</code>, either type the path to the
        <code>tiptunnel</code> binary, or use <code>Choose...</code> to find
        it.</li>
    <li>Now, <b>be sure to</b> put a space, then <code>%s</code> after the
        path to the application in the box. This tells netscape to actually
        pass the aclfile into tiptunnel (Mozilla does not require this;
        see below.)</li>
    <li>Click <code>OK</code>, then <code>OK</code> again.</li>
    <li>Clicking a "connect to serial line" link should now
        bring up a connection in an xterm window.</li>
    </ul> 
538

Chad Barb's avatar
 
Chad Barb committed
539
    <h3>Linux/FreeBSD and Mozilla:</h3>
540 541 542 543 544
    <ul>
    <li>Choose <code>preferences</code> from the <code>edit</code> menu.</li>
    <li>Select <code>Navigator</code>, then <code>Helper Applications</code> 
        under it.</li>
    <li>Click the <code>New Type...</code> button.</li>
545
    <li>In the <code>MIMEType</code> box, type <code>text/x-testbed-acl</code></li>
546 547 548
    <li>In the <code>File extension</code> box, type <code>tbacl</code></li>
    <li>For <code>Application to use</code>, either type the path to the
        <code>tiptunnel</code> binary, or use <code>Choose...</code> to find
549
	it.</li>
550 551 552 553 554
    <li>In Mozilla do <b>not</b> add a <code>%s</code>.</li>
    <li>Click <code>OK</code>, then <code>OK</code> again.</li>
    <li>Clicking a "connect to serial line" link should now
        bring up a connection in an xterm window.</li>
    </ul> 
555
    </p>
556

557
<li><a NAME="UTT-4"></a>
558 559 560 561 562 563 564 565 566 567 568 569 570 571 572
    <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>

573 574 575 576 577 578 579 580 581 582 583 584
<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>

585
<li><a NAME="UTT-5"></a>
586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602
    <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>

603
<li><a NAME="UTT-6"></a>
604 605 606 607 608 609 610 611 612
    <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>
    
613
<li><a NAME="UTT-7"></a>
614 615 616 617 618 619 620 621 622 623 624 625 626 627
    <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>
    
628
<li><a NAME="UTT-Swapping"></a>
629
    <h3>What is Swapping?</h3>
630
    <p>
Jay Lepreau's avatar
Jay Lepreau committed
631
    Swapping is when you (or we) temporarily swap your experiment out,
632 633 634 635 636
    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
637
    experiment, and clicking on the swapin option. 
638 639
    </p>

640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656
    <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>
    
657 658 659 660 661 662 663
    <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>
Robert Ricci's avatar
Robert Ricci committed
664

665 666 667 668 669
    <p>
    Make sure to take a look at our 
    <a href="docwrapper.php3?docname=swapping.html"> Node Usage Policies</a> 
    as well.
    </p>
Robert Ricci's avatar
Robert Ricci committed
670

671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687
<li><a NAME="UTT-Restart"></a>
    <h3>What is Experiment Restart?</h3>
    <p>
    Experiment restart (or perhaps more aptly, replay) allows you to
    rerun your experiment from scratch, but without the added expense
    of a swapin and swapout. In other words, the nodes that are
    currently allocated to your experiment are all rebooted, and the
    experiment startup state is cleared. This includes the
    <a href="#SWS-6">ready bits</a>, the boot status in the web page,
    and the <a href="#SWS-4">startup command status</a>. In addition,
    the event scheduler for the experiment is restarted, and your event
    sequence is replayed again. Note that your rpms and tarfiles are
    <b>not</b> installed again. Replay is obviously faster than
    swapout/swapin, and has the added benefit that you will not run
    the risk of not being able to swapin for lack of available nodes.
    </p>

688
<li><a NAME="UTT-8"></a>
Robert Ricci's avatar
Robert Ricci committed
689 690 691 692 693 694 695 696 697 698 699 700 701 702 703
    <h3>How can I get switch statistics (such as packet counts) for my
    experiment?</h3>
    <p>
    We have a command called <code>portstats</code> that allows you access
    to some of the port counters on our switches. To use it, you'll need
    to ssh to <b>users.emulab.net</b>. '<code>portstats &lt;pid&gt; 
    &lt;eid&gt;</code>' will get you stats for all experimental interfaces in
    your experiment. Run '<code>portstats -h</code>' to get a list of other
    options, such as different sets of stats.
    </p>

    <p>
    Note that the numbers returned by <code>portstats</code> do not get
    reset between experiments.
    </p>
704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764

<li><a NAME="UTT-Naming"></a>
    <h3>What names should I use to refer to the nodes in my
    experiment?</h3>

    <p>We set up names for your nodes in DNS, for use from outside,
    and <code>/etc/hosts</code> files for use on the nodes in the experiment.
    Since our nodes have multiple interfaces (the control network, and,
    depending on the experiment, possibly several experimental interfaces,)
    determining which name refers to which interface can be somewhat
    confusing. The rules below should help you figure this out.
    </p>

    <ul>
	<li><b>From the outside world</b> - 
	We set up names in the form
	<code><i>node</i>.<i>expt</i>.<i>proj</i>.emulab.net</code> in DNS,
	so that they visible anywhere on the Internet. This name always refers
	to the node's control network interface, which is the only one
	reachable from the outside world.
	</li>

	<li><b>On the nodes themselves</b> -
	There are three basic ways to refer to the interfaces of a node. The
	first is stored in DNS, and the second two are stored on the node in
	the <code>/etc/hosts</code> file.
	<ol>
	    <li><i>Fully-qualified hostnames</i> - These names the same ones
	    visible from the outside world, and referred to by attaching the
	    full domain name: ie.
	    <code><i>node</i>.<i>expt</i>.<i>proj</i>.emulab.net</code>. (note
	    that, since we put <code>.emulab.net</code> in nodes' domain
	    search paths, you can use
	    <code><i>node</i>.<i>expt</i>.<i>proj</i></code> as a shorthand.)
	    This name always refers to the control network
	    </li>

	    <li><i><code>node-link</code> form</i> - You can refer to an
	    individual experimental interface by suffixing it with the name of
	    the link or LAN (as defined in your NS file) that it is a member
	    of. For example, <code>nodeA-link0</code> or
	    <code>server-serverLAN</code>. This is the preferred way to refer
	    to experimental interfaces, since it uniquely and unambiguously
	    identifies an interface.
	    </li>

	    <li><i>Short form</i> - If a node is directly connected to the
	    node you're on, you can refer to that node simply with its name
	    (eg. <code>nodeA</code>.) Note that this differs from the fully-
	    qualified name in that no domain is given. If you have enabled
	    <a href="#SWS-5">routing</a>, we also create short names for 
	    any node that you have a route to. However, if two nodes are
	    connected with more than one interface, or there is more than
	    one route between them, there is no guarantee that the short name
	    has been associated with the one is on the 'best' (ie. shortest or
	    highest bandwidth) path - so, if there is ambiguity, we strongly
	    suggest that you use the <code><i>node-link</i></code> form.
	    </li>
	</li>
    </ul>

765 766 767 768 769 770 771 772 773 774 775 776 777 778 779
</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>
780 781 782
    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.
783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804
    </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>
805
    Please see the
806
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
807
    page for a summary of all Emulab NS extensions, and the
808
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
809 810
    example. 
    </p>
811 812 813 814 815 816 817 818 819 820 821 822 823

<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
824 825
    page. The command line syntax for <tt>delay_config</tt> will be
    displayed when the <tt>-h</tt> option is given.
826
    </p>
827 828 829 830 831 832 833 834 835

<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
836
    <a href='http://www.freebsd.org/cgi/man.cgi?manpath=FreeBSD+4.5-RELEASE'>
837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853
    <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>    
854

855 856 857 858 859 860 861 862 863 864
</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>
865 866 867
    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.
868 869 870 871 872 873 874 875 876 877 878 879
    </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>
880
    Please see the
881
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
882
    page for a summary of all Emulab NS extensions, and the
883
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900
    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>
901
    Please see the
902
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
903
    page for a summary of all Emulab NS extensions, and the
904
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
905 906
    example. 
    </p>    
907
    
908 909 910 911 912 913 914 915 916 917 918 919 920 921
<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>
922
    Please see the
923
    <a href="tutorial/docwrapper.php3?docname=nscommands.html">Extensions</a>
924
    page for a summary of all Emulab NS extensions, and the
925
    <a href = "tutorial/tutorial.php3">Emulab Tutorial</a> for an
926 927
    example.
    </p>    
928

929
<li><a NAME="SWS-5"></a>
930 931 932
    <h3>How can I turn on routing or set up routes automatically 
    in my nodes?</h3>
    <p>
933
    By default, we do not setup any static routes or run any routing daemon
934
    on nodes in an experiment.  However, we do provide several options for
Jay Lepreau's avatar
spello  
Jay Lepreau committed
935
    experimenters, which are described in the
936 937 938
    <a href="tutorial/tutorial.php3#Routing">"Setting up IP routing
    between nodes"</a> section of the
    <a href="tutorial/tutorial.php3">Emulab Tutorial.</a>
939 940 941
    </p>
    
<li><a NAME="SWS-6"></a>
942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957
    <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 =
958
    "tutorial/tutorial.php3">Emulab Tutorial</a> and in the <a href =
959
    "doc/docwrapper.php3?docname=tmcd.html"> Testbed Master Control
960
    Daemon</a> documentation.
961 962
    </p>
    
963
<li><a NAME="SWS-7"></a>
964 965
    <h3>Can I run my own Operating System?</h3>
    <p>
966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999
    Yes! You can run your own OS (or a customized version of an Emulab
    supported OS) on any of the PCs. You can also run <a href =
    "http://www.cs.utah.edu/flux/oskit/">OSKit</a> kernels on the
    PCs. Each of the PCs is partitioned with two DOS partitions large
    enough to hold the typical OS installation. The 1st and 2nd
    partitions are each 3GB. The 3rd partition is 500MB, and is
    labeled as Linux Swap. The 4th partition is the remainder of the
    disk, and varies in size depending on the pc type. We recommend
    that you use the 1st or 2nd partition; using the 4th partition
    will restrict the number of machines that you can run your OS on
    since it varies in size. Note that you must leave the MBR (Master
    Boot Record) in sector 0 alone, and that your custom partition
    must contain a proper DOS boot record in the first sector.
    </p>

    <p>
    Please note that while users are free to customize their disks and
    install their own operating systems, Emulab staff will not be able
    to offer more than encouragement and advice! We cannot install the
    OS for you, and we cannot load CDROMS, floppy disks, or tape drives!
    We <em>do</em> provide an easy way for you to boot FreeBSD from a
    memory based filesystem (MFS) so that you can more easily work
    with the disk (in case it is not possible to install your OS on a
    live disk). Beyond that, you are pretty much on your own!
    </p>

    <p>
    Many users had great success with customizing an Emulab supported
    OS (FreeBSD or Linux), and then creating a disk image that is
    autoloaded when the experiment is swapped in. We strongly
    encourage people to use this approach whenever possible! There is
    more information available in the <a
    href="tutorial/tutorial.php3#CustomOS">Custom OS</a> section of
    the <a href = "tutorial/tutorial.php3">Emulab Tutorial.</a>
1000
    </p>
1001

1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017
<li><a NAME="SWS-8"></a>
    <h3>What if I need more disk space on my nodes?</h3>
    <p>
    Each node has a partition at the end of the disk that you can use if
    you wish. In Linux, the partition is <code>/dev/hda4</code> ; in FreeBSD,
    it's </code>/dev/ad0s4</code> . There is no filesystem on this partition,
    so you'll need to create it yourself. For example, in Linux:
    <blockquote>
	<code>
	    mkfs /dev/hda4;<br>
	    mount /dev/hda4 /mnt;
	</code>
    </blockquote>
    This partition is only 6 Gigs, the size of the leftover space on our
    smallest drives. If you need more space than this, it would be possible
    to enlarge this partition on some machines (for example, our pc850s
Jay Lepreau's avatar
Nits.  
Jay Lepreau committed
1018
    have 40 GB disks), but that is outside the scope of this FAQ.
1019 1020
    </p>

1021 1022 1023 1024
<li><a NAME="SWS-9"></a>
    <h3>Are there testbed-specific daemons that could interfere with my
	experiment?</h3>
    <p>
Jay Lepreau's avatar
Nits.  
Jay Lepreau committed
1025
    Probably not.
1026
    By default, the testbed startup scripts currently start two daemons in 
1027 1028 1029 1030 1031 1032
    addition to the OS's standard set.  Other daemons may be started depending
    on the network services you ask for in your ns file (see below).
    </p>

    <p>
    Unconditionally started daemons:
1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047
    </p>

    <p>
    <blockquote>
    <li><code>healthd</code> - A low overhead hardware health monitor.
    </blockquote>
    </p>

    <p> 
    This deamon periodically polls the machine's health monitoring
    hardware and sends this information back to our <code>boss</code>
    node for analysis.  The hardware is polled once per second, and a
    status datagram is sent out once every five minutes.
    <code>Healthd</code>'s overhead is quite low, but it can be safely
    killed and disabled from startup if you're worried about possible
1048 1049
    side effects.  It is started by
    <code>/etc/testbed/rc.healthd</code>.
1050
    </p>
1051 1052 1053 1054 1055 1056 1057 1058 1059 1060

    <p>
    <blockquote>
    <li><code>slothd</code> - A low overhead usage analysis tool.
    </blockquote>
    </p>

    <p>
    <code>Slothd</code> is important to efficient testbed utilization
    and should run on every node whenever possible.  Its overhead is
1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076
    almost negligible (essentially less than running <code>'ls -l
    /dev'</code> once per hour), and should not interfere with your
    work.  However if your experiment is exceptionally sensitive, then
    you may arrange with us to disable <code>slothd</code>.  Please
    note that we will restart this daemon if it is not running unless
    prior arrangements have been made.
    </p>

    <p>
    Conditionally started daemons:
    </p>

    <p>
    <blockquote>
    <li><code>gated</code> - A network routing daemon.
    </blockquote>
1077 1078
    </p>

1079
    <p>
1080 1081
    If you have requested automatic routing on your nodes with  
    <code>$ns&nbsp;rtproto&nbsp;Session</code> in your NS file, this will
1082 1083
    start <code>gated</code> on all of your nodes.
    </p>
1084

1085 1086 1087 1088 1089 1090
    <p>
    We have left all daemons started by the operating systems' default
    configurations (such as <code>cron</code>) enabled, so you should also
    look at them if you are concered about running processes affecting
    your experiment.
    </p>
Mac Newbold's avatar
Mac Newbold committed
1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103

<li><a NAME="SWS-10"></a>
    <h3>Does Emulab support IP Multicast?</h3>
    <p>
      In short, yes, the local nodes in Emulab (but not all remote
      Netbed nodes) support IP Multicast on the experimental
      network. In order to use it, you must have a kernel that
      supports it, and if you want multicast routing, you'll need to
      enable <code>mrouted</code>. (You can do it manually, or
      automatically via program objects or startup commands, but the
      rtproto commands will not do it.)
    </p>

1104 1105
</ul>

1106 1107 1108 1109 1110 1111 1112 1113
<hr>

<a NAME="SEC"></a>
<h3>Security Issues</h3>
<ul>
<li><a NAME="SEC-1"></a>
    <h3>Is Emulab Firewalled?</h3>
    <p>
1114 1115
    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
1116
    (HTTP). This is for the protection of experimenters, as well as to ensure
1117 1118 1119 1120
    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.
1121 1122
    </p>
</ul>
1123 1124 1125 1126 1127 1128 1129

<hr>

<a NAME="TR"></a>
<h3>Troubleshooting</h3>
<ul>
<li><a NAME="TR-1"></a>
1130
    <h3>My experiment is set up, but I cannot
1131
	send packets between some of the nodes. Why?</h3>
1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143
    <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>
1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187

<li><a NAME="TR-2"></a>
    <h3>I asked for traffic shaping, but everything seems to be going at
    full LAN speeds.  What's wrong?</h3>
    <p>
    The most likely problem is that it is using the unshaped control
    network for the traffic you're looking at. This occurs when it
    tries to contact a node using a "pcXXX" address, like pc76 or
    pc76.emulab.net, or when it tries to ping a fully-qualified name,
    like NodeA.myexpt.myproj.emulab.net , which also resolves to a
    control network address. On one of your nodes, take a look at the
    file /etc/hosts . It shows the IP addresses and aliases that refer
    to the different experimental interfaces. These are the names/IPs
    you can use to see the delays.
    </p>

    <p>
    For instance, let's say I have an experiment that had NodeA and
    NodeB connected with a shaped link. The file /etc/hosts on NodeA
    would have a line for NodeB, with an address like 192.168.1.3, and
    on NodeB there would be an entry for NodeA with the address
    192.168.1.2. These addresses correspond to the delayed link
    between them. Any address outside the 192.168.*.* range that you
    didn't configure manually corresponds to an unshaped link.
    </p>

    <p>
    For a discussion of the way to 'name' interfaces on the control
    and experimental networks, see the the <a href="#UTT-Naming">naming
    section</a> of this document.
    </p>

<li><a NAME="TR-3"></a>
    <h3>I set a non-zero packet-loss (or delay) but 'ping'
        shows no packet-loss (or delay). Why?</h3>
    <p>
    You are probably pinging through the control net interface. See this
    Troubleshooting <a href="#TR-2">FAQ entry</a>.
    </p>
    
<li><a NAME="TR-4"></a>
    <h3>I set a non-zero packet-loss (or delay) but 'ping'
        shows a different packet-loss (or delay). Why?</h3>
    <p>
1188
    Short answer: Ping is round trip, PLR and delay are "one way".
1189
    </p>
1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212

    <p>
    Long Answer: If you're not seeing any traffic shaping at all
    (100Mbps, 0ms, 0plr), see <a href="#TR-2">this FAQ entry</a>. If
    you are seeing shaping, but something different than you
    expected, it is probably because link characteristics are one
    way, and you're measuring them over the round trip.
    </p>

    <p>
    For instance, if you asked for a link that was 100Mbps, 30ms,
    with 5% (0.05) packet loss rate (plr), you may expect ping to
    show 30ms ping times and 5% loss rate. But what you should see
    is 60ms latency for the round trip, and a loss rate of
    9.75%. Latencies can be added, therefore 30ms + 30ms gives
    60ms. However, loss rates are probabilities, and must be
    multiplied. The chance of a packet making it across a 5% lossy
    link is 95%, so with a 95% chance of arriving at the
    destination, and a 95% chance of returning if it made it there,
    and the total chance of making a round trip is .95 * .95 = .9025 or
    90.25%, or a round trip loss rate of 9.75% on a 5% lossy link.
    </p>

1213
</ul>