Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Install / Switches-Db.Html


Configuring the Testbed

Initial Switch Setup

This page describes the setup of the testbed database to allow for your switches. It does not concern configuring the actual switches. These instructions are LOCAL ONLY, meaning if you are only a widearea testbed, you can skip this page.


Many tables depend on data in other tables, or depend on running programs to effect a change. Therefore, you should not edit tables other than the ones described in this chapter. You have been warned...

Step 1 - Create node types for switches

Add entries to the 'node_types' table for each type of switch you'll be using in your testbed. To do so, open the testbed database by running

mysql tbdb

You will only need to fill in the 'class' and 'type' columns. These are the switch types currently supported:

  • cisco{ 65xx,40xx,45xx,29xx,55xx}
    For example, if you had a 6509, you'd enter 'cisco6509'. If your switch runs IOS instead of CatOS, append '-ios' to the type.
  • Intel 510T
    Just put 'intel' in the type field
  • nortel1100, nortel15510
  • foundry1500, foundry9604
    Only these specific names are matched in the snmpit code. If you have a nortel 5530 (with the 10 gig ports), or 5520 (with power-over-ethernet), or a multi-pizzabox stack, just call it a nortel5510.
  • hp{5412,3500,2810}
    These are the only ones that the DETER folks have tried so far; any procurve switch obeying the same set of RFC and mibs should work, and the snmpit code matches on hp* for the node type. If the switch is a bladed switch like the 54xx or 42xx it will be necessary to add an entry to the %blade_sizes hash in see the code.

Note that the names are case sensitive. Set the "class" to 'switch'. The rest of the columns are meant for the testbed nodes and are not important. Your sql query might look something like this:

insert into node_types set
      class='switch', isswitch=1, type='cisco2950-ios';

You also need to set the forwarding protocol for your switches.

insert into node_type_attributes set

Step 2a - Create interface types for switch interconnects (if any)

If you'll be connecting two or more experimental switches together, you'll need to add interface types for the ports you'll be using to link them together. These go into the 'interface_types' table. Make up something descriptive for the 'type' column (no spaces). Make sure to set the 'max_speed' in Kbps (kilobits per second) and 'full_duplex' (1 for full duplex, 0 for half duplex) columns correctly. As an example:

insert into interface_types set

Step 2b - Create interface capabilities entries for switch interconnects (if any)

If you added any entries to 'inteface_types' in the previous step, you also need to add entries to the 'interface_capabilities' table. Using the same type name you used above, add a capkey for "protocols", usually set to "ethernet" and another capkey for "ethernet_defspeed" to the same value you used in the 'interface_types' table. Do this for each type you entered in step 2a above. For example:

insert into interface_capabilities set
insert into interface_capabilities set

Step 3 - Create switches in the nodes table

Next, add the switches to the nodes table. The only necessary fields here are 'node_id' (choose one appropriate to the switch), 'type' (use one of the ones you created earlier), and 'role'. Role, for switches, should be either 'testswitch' or 'ctrlswitch', depending on whether you're using it for the experimental or control network. If it's used for both, call it a 'testswitch'. For example:

boss> wap addspecialdevice -t cisco2950-ios cisco1

Note that 'cisco1'  (or whatever names you choose for your switches) must resolve in DNS and/or boss' /etc/hosts file - we'll use this name to contact the switch for SNMP. I.e., you must be able to ping the name you select as the switch's node_id.

Step 4 - Add state for switch interconnects

If you'll be connecting two or more experimental switches together, add interfaces to each of them. Use the interface types you created above for them, and be sure to get the correct card and port numbers. In modular switches, such as the Cisco Cat6500 series, use the switch's 'native' module and port numbers. For switches that do not have expansion modules, the card number is assumed to be 0. Make sure to get the current_speed (this time, in Mbps, and note, this is an enumerated type, not an integer, so you need to put quotes around the speed) and duplex correct. You'll also need to set 'iface' to some string representing the port, such as 'module/port' (i.e. '1/1'). Set the 'role' of the interfaces to 'other'.

      insert into interfaces set
      insert into interfaces set

Now, go into the 'wires' table and add wires connecting the switch interfaces you just created. Make sure to set the type to 'Trunk'. In this case, it doesn't matter which switch you use as node 1 (the node_id1, card1, port1 columns), and which you use as node 2. If you have a non-modular switch, all ports are considered to be on card 0.

      insert into wires set

Step 5 - Create switch stacks

A switch stack is a set of switches that share common VLANs. Usually, your experimental switches will be one stack, and the control switch(es) another. You must first create entries for each switch stack in the 'switch_stack_types' table, 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' field should be set to the node_id of the master switch in the stack. The 'stack_type' column is used by snmpit to determine which module to use to talk to the stack. Most sites should set 'stack_type' to 'generic', which handles all switch types currently supported by Emulab. Making a stack for the control network is not required, but will enable control-net firewalls. To summarize the few columns in this table that you will need to set:


Set to 'Control' or 'Experiment'


The node_id (for example, 'cisco1') of the master switch. Many sites will have just one switch, so use that.


Should be set to 'generic'


(Cisco only) This switch can make private VLANs - probably best to leave it as 0.


(Cisco only) Specifies whether all the switches in the stack use VTP to maintain a common set of VLANs. This means that we will only create VLANs on the stack leader. If set to 0, we create VLANs on each switch individually.


The SNMP community string we use for read/write access to the switch. Most switches use 'private' as a default, though you should probably have changed this (see Designing Your Network for more information).


The smallest VLAN number that the testbed will use. If left as NULL in the database, emulab software will default to 2.


Ditto, but the largest number. Defaults to 1000.

For example:

insert into switch_stack_types set
      stack_id='Experiment', leader='cisco1',
      stack_type='generic', supports_private=0, single_domain=0,
      snmp_community='yourstring', min_vlan=10, max_vlan=750;

Finally, add switches to these stacks by putting entries in the 'switch_stacks' table, listing the node_id of each switch and the stack_id of the stack it belongs to. You can leave the 'is_primary' column of these rows with its default value (1).

It is also possbile for a switch to function both as an experiment and a control switch. Make two entries, with the Experiment being primary. Note that as mentioned above, if you do not plan to create control network firewalls (private vlans), then you do not need an entry for the control network stack.

insert into switch_stacks (node_id,stack_id,is_primary)
      values ('cisco1",'Experiment',1),("cisco1",'Control',0);


After getting this set up, run 'wap snmpit -l', and make sure it doesn't give you any error messages. If it tells you that your type of device isn't supported, ask Utah - we have a list of supported devices in snmpit, but they are just the ones we've tested. Hopefully, yours will work too, and we just haven't tried it. Also, make sure that /usr/testbed/sbin and /usr/testbed/bin are in your path.

Your snmpit output should look something like this:

%wap snmpit -l
VLAN      Project/Experiment VName      Members
Control-                                myswitch:1

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's not a problem, but if you want to delete any of them, you can do so with 'wap snmpit -o <name>'.