On Mon, Nov 14, 2011 at 4:40 AM, Morten Brekkevold <morten.brekkevold@uninett.no> wrote:

On Tue, 04 Oct 2011 16:07:24 +0100 Seb Rupik <snr@ecs.soton.ac.uk> wrote:

> Hi all,
> I have been tasked with creating a new NAV (3.9.1) install. All appears to be
> fine until I compare it against the previous old (3.5.4) installation.
> The majoirty of our switches are Cisco 3750's nearly all stacked, but the new
> install doesn't seem to acknowledge this under 'IP Device Info' where the
> Modules' field shows '0', but the 'switch port status' table shows all
> interfaces spanning the stack.
> On the old install the 'Modules' field has the correct number and the 'Switch
> port status' shows the right number of separate modules.
>
> Looking under: 'Report-> Vendors -> Cisco' confirms that the new install is
> receiving less SNMP OIDs per switch stack; typically 75. Where as the old
> install is showing between 88-90 for the same stacks. Also in some cases the
> new install is not showing any returns under #mod, #swp, #gwp and #prefixes,
> where is does on the old install.
>

> Both installs are running libsnmp1.4-java; the old 1.4-5, and the new install
> 1.4.2-2.
> Would that account for the differences? What's the best way to test the two
> installs side by side in an output based comparison?

No. The collection system and central parts of NAV's data model changed
from version 3.5 to 3.6.

It is likely what you're seeing is an effect of NAV no longer using
Cisco-proprietary MIBs for discovering "modules", but the IETF-standard
ENTITY-MIB (RFC 4133).

I haven't much experience with stacked 3750's, but barring use of
proprietary MIBs, such a stack would present itself as a single device
SNMP-wise. I'm guessing that your 3750's will list multiple chassis in
the ENTITY-MIB::entPhysicalTable.

NAV currently has no way to model multiple stacked chassis, which could
in principle each have multiple internal modules.

There are a myriad of ways to stack and/or aggregate multiple devices,
all depending on vendor and model. Some stacking methods involve
aggregating multiple simple devices into a single superdevice, while
other methods let each stack member retain their autonomy while
channeling all management through a single IP address on a master
device.

There is very little stacking going on in UNINETT's customer base, which
means that for us there is little demand for supporting this, and
there's little equipment for us to test against.

If you have ideas on how to model the various kinds of stacking
paradigms that exist, and/or are willing/able to provide some sort of
feedback or testbed for development (or patches, for that matter), we're
all ears. I would suggest the nav-dev mailing list for technical
discussions on the matter.

--
Morten Brekkevold
UNINETT