|
|
This page describes the setup of the testbed database to allow for your switches. It does not concern configuring the actual switches.
|
|
|
|
|
|
### Step 1 - Create the Switch Stacks
|
|
|
|
|
|
A switch *stack* is a set of switches that share common VLANs. Usually,
|
|
|
your experimental switch(es) will be one stack, and the control switch(es)
|
|
|
another. You must create both stacks, even if there is only one switch in a
|
|
|
stack. The control stack should be named 'Control', and the experimental
|
|
|
stack 'Experiment' (make sure to get the capitalization right). The
|
|
|
*leader* should be set to the node_id of the master switch in the
|
|
|
stack.
|
|
|
|
|
|
For this step you will want to know the unqualified names of the *leader*
|
|
|
switches for your Control and Experimental networks. If you are using a
|
|
|
single switch for both, then you will use the same switch name. Be sure
|
|
|
that you can `ping` the switch names from boss.
|
|
|
|
|
|
```
|
|
|
boss> wap addstack -p PASSWORD Experiment EXP_SWITCH_NAME
|
|
|
boss> wap addstack -p PASSWORD Control CTRL_SWITCH_NAME
|
|
|
```
|
|
|
|
|
|
where PASSWORD is the *snmp community string* that you will configure your
|
|
|
switches with. EXP_SWITCH_NAME is the name of your experiment network
|
|
|
leader switch, and CTRL_SWITCH_NAME is the name of your control network
|
|
|
leader switch (or the same as EXP_SWITCH_NAME if you are using the same
|
|
|
switch to control both the Experiment and Control networks.
|
|
|
|
|
|
### Step 2 - Add the Switches
|
|
|
|
|
|
Now we add the switches to the database. For each switch, make sure your
|
|
|
can `ping` the unqualified name from boss, and then:
|
|
|
|
|
|
```
|
|
|
boss> wap add switch -t SWITCH_TYPE -S STACK_ID SWITCH_NAME
|
|
|
```
|
|
|
|
|
|
where SWITCH_NAME is the unqualified name of each switch, STACK_ID is one
|
|
|
of `Experiment` or `Control`, and SWITCH_TYPE is the *type* of the switch.
|
|
|
|
|
|
**NOTE:** When choosing a type name for your switch, it is a very good idea
|
|
|
to follow this convention: `manufacturer`-`model`. For example, a Force10
|
|
|
s3048 should have the type name `force10-s3048`. If you have older cisco
|
|
|
switches, please contact testbed-ops@flux.Utah.edu for guidance on how to
|
|
|
name your cisco switches. A list of supported and type names we recommend
|
|
|
follows:
|
|
|
|
|
|
* Need to generate this table, and suitable switch types
|
|
|
* Need to generate this table, and suitable switch types
|
|
|
* Need to generate this table, and suitable switch types
|
|
|
|
|
|
### Step 3 - Add Switch Interconnects
|
|
|
|
|
|
If you'll be connecting two or more experimental switches together (control
|
|
|
switches), you will need to add the interconnect info to the database.
|
|
|
There are two types of info; interfaces and wires (that connect the
|
|
|
interfaces). As example, lets say you have two experimental switches
|
|
|
(`switch1` and `switch2`), and that they are connected by two 10G links.
|
|
|
|
|
|
First we add the interfaces. For each link between the switches:
|
|
|
```
|
|
|
boss> wap addinterface -b SPEED myswitch1 "module1/port1"
|
|
|
boss> wap addinterface -b SPEED myswitch2 "module2/port2"
|
|
|
```
|
|
|
|
|
|
A word about `module/port` ... many switches address ports by a simple
|
|
|
module and port numbering scheme. For example, "1/2" is port 2 on module
|
|
|
1. If your switches are like that, that makes things simple! Just use the
|
|
|
"module/port" string for each of the interfaces you need to add. If you
|
|
|
have switches require more complicated port naming, please post a message
|
|
|
on emulab-admins so we can help you out.
|
|
|
|
|
|
For SPEED, choose one of 100Mb, 1Gb, 10Gb, 40Gb, or 100Gb. If you have
|
|
|
interfaces with a different speed, please let Utah (via the emulab-admins
|
|
|
google group) know so we can add it for you.
|
|
|
|
|
|
Now add the *wires* that connect your switch interfaces: For each wire
|
|
|
between two interfaces that you added above:
|
|
|
|
|
|
```
|
|
|
boss> wap addwire -t Trunk myswitch1:module1/port1 module1,port1 myswitch2:module2/port2 module2,port2
|
|
|
```
|
|
|
|
|
|
### Step 4 - Testing `snmpit`
|
|
|
|
|
|
`snmpit` is the Emulab tool that talks to the switch fabric, creating and
|
|
|
deleting vlans as experiments come and go. It also handles adding vlans to
|
|
|
the trunk links between the switches, enabling and disabling ports, etc.
|
|
|
|
|
|
If all has gone well and your switch(es) are supported, you should be able
|
|
|
to run `snmpit` likes this, and receive no errors:
|
|
|
|
|
|
```
|
|
|
boss> wap snmpit -l -l
|
|
|
```
|
|
|
|
|
|
If there are no errors, you should see something like:
|
|
|
|
|
|
```
|
|
|
VLAN Project/Experiment VName Members
|
|
|
----------------------------------------------------------------------------
|
|
|
Control- myswitch:1</pre>
|
|
|
```
|
|
|
|
|
|
Note that 'Control-' is a truncated version of the name 'Control-hardware',
|
|
|
which would have only been created if you decided to partition your control
|
|
|
network. If you see any other VLANs on this list, that is not a problem,
|
|
|
but if you want to delete any of them, you can do so with:
|
|
|
|
|
|
```
|
|
|
boss> wap snmpit -o <name>
|
|
|
```
|
|
|
|
|
|
* [Prev](install/Creating the First Project)
|
|
|
* [Next](install/Memory Filesystems)
|
|
|
* [Home](install/Installing Emulab) |