GitLab

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.

not the creation suceeded, which caused snmpit to erroneously think that it had
failed.

First, the stack-level createVlan() function no longer takes as an
argument a list of devices the VLAN exists on, since it looks like
this will never be needed.

In it's place, createVlan() now takes a list of ports, so that it can
(if so desired) put the ports in the VLAN without a seperate lock and
unlock.

The snmpit_intel module now uses its 'nested locking' feature to avoid
additional locking in these cases. Note though, that the way that this
is done is not safe for multiple switches in a stack. If we ever have
to support multiple Intels (looks doubtful), this will have to be
removed, or locking will need to be moved a level up to
snmpit_intel_stack . Yuck.

For Intels, the removeVlan() function calls removePortsFromVlan()
itself, again to save locking overhead. The Cisco behavior, however,
is unchanged, as locking is not expensive, and this would be too
messy.

account for the time it may take for changes made at the master to
propagate to the slaves. Added a paramter to override this, as sometimes,
we know that we're talking to the master so the delay does not come into
play.

This should improve the running time of snmpit by about 10 seconds per VLAN
created, since we can tell right away if the VLAN already exists or not.

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

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)

was preventing VLANs from being cleared out before they were delted.

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