GitLab

Convert most SNMP interaction to use the snmpit*() library, so that
they get support for retrying failures, etc.

Add new library calls for wrapping bulkwalk() - so now, we will
retry those on error as well. Before, we had the bad behavior than
many functions, like listVlans() would just see empty lists instead
of errors.

When making a new Cisco object, we now test network connectivity right
away, by fetching an OID that should exist on all SNMP devices. Before,
we wouldn't find out we couldn't contact the switch until we actually
did something on it.

Also, make VLAN number choosing go a bit faster by converting it to
bulkwalk() (using the new library function) so we can grab all VLAN
numbers at once.

trunks for convenient checking against.

table.

port:card.

Call this every place (I think I got them all) a port list is used in
snmpit.

Each switch has a 'primary' stack that it belongs to if it's specified
with the '-i' parameter. Otherwise, it can be considered to be a part
of any of the stacks of which it's a member.

The main point of this is so that we can have switches that are on
both the control and experimental networks.

Note: Having a VLAN with the same name on two overlapping stacks is
like crossing the streams: that would be bad. Not "all life as you
know it stopping instantaneously" bad, but snmpit might get confused.

to assume that the leader of a stack is the switch after which it was named -
we can now name stacks things like 'Control' or 'Experiment'.

snmpitDoIt(), or zeros and/or empty strings look like failure.

* snmpit: When ElabInELabis true, use the routines in the new
  snmpit_remote.pm library for setting up and tearing down vlans for an
  experiment. At present, only these two operations are proxied out to
  the outer emulab.

* snmpit_remote.pm: A new little library that uses the XMLPRC server on
  the outer emulab to setup and destroy vlans for an inner experiment.
  This code is used from snmpit (see above).

* snmpit_lib.pm: A couple of minor changes for the server side of the
  proxy operation.

* snmpit.proxy.in: A new perl module that is invoked from the RPC
  server.  This proxy sets up and tears down vlans for an inner elab.
  The basic model is that the container experiment will have lots of
  vlans for various individual experiments running on the inner emulab.

* swapexp: A couple of minor elabinelab hacks.

* tbswap: For elabinelab experiments, reconfig/restart dhcpd when
  tearing down the experiment, and call out to new elabinelab script
  when setting up an elabinelab experiment. There is no provision for
  swapmod at this time.

* elabinelab: A new script to create the inner emulab. Does all kinds of
  gross DB stuff then more gross stuff on the inner ops and boss.

get versions of these functions.

information. Rather than pass it all in, which was getting very
cumbersome, and inconsistent between Cisco and Intel switches, the
modules query the database themselves (via a new function in
snmpit_lib.pm).

Also in this commit are two new options for switch stacks - the
ability to specify minimum and maximum VLAN number to use.

get an updated copyrights message.

default SNMP community string (from configure) for individual
switch stacks.

VLAN domain. This means that we have to create and delete VLANs on
all switches, instead of just the 'leader'. This behavior is
controlled through the new single_domain column in the
switch_stack_types table.

    Accept [switch.]<module>/<port> format for ports, so that we can
	deal with ports not in the database (mostly for my own
	debugging sanity.)
    A -n option that prevents assign from changing hardware settings
    	(though, unlike TESTMODE, does read some information from
	the switches)
    Private VLAN support, through the -x,-y, and -z switches. There
	are only 5 letters of the alphabet left, so I've given up on
	memnonic switches.
    Worked a bit on making VLAN deletion more efficient, but with
    	little sucess

Private VLANs work like so:
Make a primary private VLAN with:
snmpit -m myvlan-primary -y primary
Attach a community VLAN to it like so:
snmpit -m myvlan-community -y community -x myvlan-primary -z cisco2.1/15
Put some ports into the community VLAN:
snmpit -m myvlan-community pc1:0 pc2:0

the sleep time a bit, so that we don't end up with multiple processes
continually sending requests at the same times.

Re-worked the snmpitGet functions slightly to make them more
convenient and to work around some ickiness in the SNMP library.

The main purpose of these it to retry on failure. Most of snmpit's
direct interaction with the SNMP module will be converted to use
these new calls.

snmpitSet functions will follow shortly.

switches, in case we only have wide area nodes. Of course, snmpit
won't _do_ anything, but it shouldn't be an error to run it.

Usage: portstats <pid> <eid> [vname ...] [vname:port ...]

If only pid and eid are given, prints out information about all
ports in the experiment. Otherwise, output is limited to the
nodes and/or ports given.

As much of it as possible switch-independant, and put in snmpit_lib.
Should work for arbitrarily complicated switch toplogies, as long as
there are not multiple trunks between two switches. (Multiple ports
combined into one trunk are fine, however.)

As a result of this, VLAN creations and deletions now need to operate
on all switches, not just on the ones that have ports in the VLAN.
This is because the traffic may have to traverse switches that have no
ports in the VLAN to reach other switches that do.

Not called yet. I've done simple testing, but need to do more, as this
could get us into major trouble if it has bugs.

getTrunks: Build a structure representing all of the trunks in the switch
	topolgy
getTrunkPath: Find the shortest path between two switches, across the
	trunks found by getTrunks

Note that the getTrunkPath duplicates some work done in assign. However, we
don't currently have a good way to pass this information from assign to
snmpit, and we need to be able to figure this out anyway, in case snmpit
isn't being called as part of experiment swapin.

These functions should soon be used to pick which VLANs are allowed
across which trunks.

standardize on using /usr/bin/perl instead of /usr/local/bin/perl (most already
did.)

does not yet exist (but should soon.)

There is a new database table, switch_stack_types, that goes along with these
code changes, to indicate which module should be used for each switch stack.

speeds and duplexes from the database.

Make sure experiments actually exist, for morons like me that enter 'eid pid'
instead of 'pid eid'

When using '-t', don't try to create VLANs if they already exist, just
put ports in it (this can be used, for example, to repair damage to switch
state or fix up after manually monkeying with VLANs)

Now supports multiple switches and multiple stacks. To do this, the existing
snmpit_cisco module had to be modified to behave as a true object, and its
interface changed.

A new layer of abstraction has been added: the stack. This is to hide the
details of how things such as VLAN creation occur across multiple devices. For
example, in Cisco stacks, you always contact the stack leader (VTP server) to
create/delete VLANs. Other switches may have different semantics, such as
having to contact every switch to create the VLAN.

Now uses libdb for database access and permissions checks.

Hardware details are hidden as much as possible in the user interface. For
example, the creation and deletion commands now take VLAN identifiers, and
snmpit transparently turns these into device-specific VLAN numbers.

snmpit.in has been re-written from scratch. The new version uses three basic
steps:
1) Process command line options and determine operation to run
2) Determine which devices, ports, and VLANs will be involved and make
   the appropriate objects
3) Actually perform the operation
   when TESTMODE is set, does only steps 1 and 2

Some command-line options have changed. This is because we now use getopt,
rather than a home-grown parser, to parse the command line. As a result of the
large number of options, and an attempt to mimic old options as much as
possible, the options are no longer very mnemonic.

Uses a new table called switch_stacks to figure out which switches belong to
which stacks. A stack is defined as a set of switches that share VLANs.

All snmpit scripts and modules now run with 'use strict' to help catch certain
programming errors.

VLAN listing now prints out the pid/eid and vname for VLANs, if possible.

A few things have bitrotted due to these changes:
* snmpit_intel will need to be re-tooled to use the new interface, and to
  behave as a proper object
* vlansync, vlandiff, and resetvlans depend on the output of snmpit, and will
  need to be updated to understand its new output format