Commit 5a73a070 authored by Chad Barb's avatar Chad Barb
Browse files

modified considerably; fixed stuff, went over it with Rob, also added stylesheet

parent 774632cf
<html>
<head>
<title>Utah Network Testbed - Tutorial</title>
<link rel='stylesheet' href='../tbstyle2.css' type='text/css'>
</head>
<body>
<h1>Utah Network Testbed - Tutorial</h1>
<h3>First of all</h3>
<h3>Logging Into the System</h3>
<p>
First of all,
to make sure you have
a working account
on
the Utah Network Testbed, log in
via the
First of all, make sure you have
an account on the Utah Network Testbed. Log in via the
<a href="https://www.emulab.net/tbdb.html">Testbed Web Interface.</a>
If you do not have
an account, don't worry--
the login page
contains
detailed information about obtaining
and
verifying
an account.
If you don't yet have an account, don't worry--
the login page contains detailed information about obtaining and
verifying an account.
</p>
<h3>Designing a Network Topology</h3>
<p>
......@@ -31,12 +23,14 @@
<p>
The Utah Network Testbed uses the "NS" ("Network Simulator")
format to describe network topologies.
This is substantially the same format used by
<a href="http://www.isi.edu/nsnam/ns/">ns-2</a>.
Since the Utah Network Testbed interface doesn't interpret these
files directly with
<a href="http://www.scriptics.com/software/tcltk/">Tcl</a>,
some functionality may work differently than you expect, or not at all.
This is substantially the same
<a href="http://www.scriptics.com/software/tcltk/">Tcl</a>-based
format used by <a href="http://www.isi.edu/nsnam/ns/">ns-2</a>.
Since the Utah Network Testbed offers emulation,
rather than simulation, these files are interpreted in a somewhat
different manner than ns-2.
Therefore, some ns-2 functionality may work
differently than you expect, or may not be implemented.
If you feel there is useful functionality missing, please let us know.
Also, some
<a href="tbcommands.html">testbed-specific commands</a>
......@@ -61,34 +55,29 @@
# This is a simple ns script. Comments start with #.
set ns [new Simulator]
# First, define some nodes.
set A [$ns node]
set B [$ns node]
set C [$ns node]
set D [$ns node]
# Second, make some links between them, specifying
# bandwidth, latency, and queue type
$ns duplex-link $A $B 100Mb 10ms DropTail
$ns duplex-link $B $C 100Mb 10Ms DropTail
$ns duplex-link $B $D 100Mb 10Ms DropTail
# If you are running FreeBSD or Linux on any nodes
# you can set the IP addresses like this:
# #TB set-ip-interface
# For instance, the next line sets the IP address of B on the port going to C:
#TB set-ip-interface B C 192.168.42.42
# Note: The initial '#' is required to insure that 'ns'
# will ignore these testbed-only commands.
# The Testbed software will choose IP addresses for you, but you can choose
# them if you prefer. It is generally a good idea to have every link from
# any given node be on a different subnet, and to have both ends of a link
# on the same subnet.
</pre><p class="comment">First, define some nodes:</p><pre>
set NodeA [$ns node]
set NodeB [$ns node]
set NodeC [$ns node]
set NodeD [$ns node]
</pre><p class="comment">Second, make some links between them,
specifying bandwidth, latency, and queue type:</p><pre>
$ns duplex-link $NodeA $NodeB 100Mb 60ms DropTail
$ns duplex-link $NodeB $NodeC 100Mb 30ms DropTail
$ns duplex-link $NodeB $NodeD 100Mb 40ms DropTail
</pre><p class="comment">If you are running FreeBSD or Linux on any nodes
you can set the IP addresses like this:
</p><pre>
#TB set-ip-interface
</pre><p class="comment"> For instance, the next line sets the IP address
of node B on the port going to node C:</p><pre>
#TB set-ip-interface NodeB NodeC 192.168.42.42
</pre><p class="comment"><i>Note: The initial '#' is required to insure that 'ns'
will ignore these testbed-only commands.</i></p>
<p class="comment"> The Testbed software will choose IP addresses for you, but you can choose
them if you prefer. It is generally a good idea to have every link from
any given node be on a different subnet, and to have both ends of a link
on the same subnet.</p><pre>
$ns run
# end example.ns
......@@ -136,67 +125,75 @@ C eth0 B 192.168.42.2
D eth0 B 192.168.3.2
B eth1 D 192.168.3.3
</pre>
<p>
<p class="comment">
Notice that three "delay nodes" have been allocated to accomodate the
10ms delay time, as specified in the .NS file.
60ms/30ms/40ms delay times, as specified in the .NS file.
</p>
<h3>So now you have your nodes...</h3>
<h4>Logging in</h4>
<p>
Once nodes have been allocated for an experiment, they are rebooted,
For each node allocated for an experiment,
a clean operating system is installed, the node is rebooted,
and all members of your Project are given login accounts.
Your username and password for testbed machines
will be the same as the one you use on the web interface.
Use ssh to log into "ops.emulab.net". If your machine, as configured, supports
ssh, you can "ssh <i>machinename</i>" into one of your machines
("tbpc15" is one such machine in the above example.)
will be the same as the one you use on the web interface.
You may also use this username and password to log on to
<code>ops.emulab.net</code> through ssh.
Nodes are configured by default to run <code>sshd</code>;
From <code>ops.emulab.net</code>, you can then log in using <code>ssh <i>machinename</i></code>.
(<code>tbpc15</code> is one machinename in the above example.)
If you are concerned about ssh traffic interfering with an experiment,
or if you have configured a machine to run an operating system which does not
support incoming ssh connections, an alternative is
"tip <i>machinename</i>", which communicates directly with a machine's
support incoming ssh connections, log in to <code>ops</code> and run
<code>tip <i>machinename</i></code>, which communicates directly with a machine's
serial port. The standard FreeBSD and Linux installations listen for logins
on this port.
</p>
<p>
Once you are logged in, use "sudo" to run commands as root.
Once you are logged in, use <code>/usr/local/bin/sudo</code> to run commands as root (if your account was given permission to do so by your project leader.)
</p>
<h4>Powercycling Nodes</h4>
<p>
Nodes may be rebooted or powered off using local commands on the
machine, if available. In addition, machines are connected to a power controller,
accessable through "ops.emulab.net".
While logged into ops,
use the commands "power on <i>machinename</i>", "power off <i>machinename</i>", and
"power cycle <i>machinename</i>" to control power to your nodes.
accessable through <code>ops.emulab.net</code>.
While logged into <code>ops.emulab.net</code>,
use the commands
<code>power on <i>machinename</i></code>,
<code>power off <i>machinename</i></code>, and
<code>power cycle <i>machinename</i></code> to control power to your nodes.
</p>
<h4>Reconfiguring Node Operating Systems</h4>
<p>
Each PC on the testbed has three hard disk partitions.
One partition contains Redhat Linux 6.2, another FreeBSD 4.0, and the last
can be loaded with any suitable operating system.
can be loaded with an operating system of your choice.
Unless specified otherwise in the .NS file, normal nodes will default to Linux, while
delay nodes will default to FreeBSD. If a delay node's operating system is changed to
to something other than FreeBSD, it will not function as a delay node.
delay nodes must run FreeBSD.
</p>
<p>
Node operating systems can be initially configured using the following command
in a .NS file:
</p>
"#TB <a href="nscommands.html#set-node-os">set-node-os</a> <i>nodename</i> <i>imagename</i>"
<br>
<i>nodename</i> is the machine name you're using in your NS file.
<br>
<i>imagename</i> is "RHL62-STD", "FBSD40-STD", or an image of your own devising.
<pre>
#TB <a href="nscommands.html#set-node-os">set-node-os</a> <i>nodename</i> <i>imagename</i>
</pre>
<p class="comment">
(<i>nodename</i> is the machine name you're using in your NS file.
</p>
<p class="comment">
<i>imagename</i> is <code>RHL62-STD</code>, <code>FBSD40-STD</code>, or an image of your own devising.)
</p>
<p>
Node operating systems can also be changed while an experiment is underway,
via the www.emulab.net web interface. Go to the
via the web interface. Go to the
"Experiment Information" page, select your experiment, then select the
name of a machine from the list of those allocated for that experiment.
This will bring up the Node Control Center.
In the box labeled "Def boot image" choose "RHL62-STD" or "FBSD40-STD",
In the box labeled "Def boot image" choose <code>RHL62-STD</code> or <code>FBSD40-STD</code>,
or an image of your own devising (this is documented elsewhere.)
Submit the change, and if all goes well, the node will be reconfigured.
The changes will take effect next time the machine is rebooted.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment