I'm having the same issue. I'm a consultant, and I have several customers who want a great network management/monitoring tool. I recommend NAV to them, since I've used it for a long time.
However, they almost all have 3750 stacks. At this one particular customer, I'm not getting really any inventory info from ipdevpoll when it talks to a 3750 stack. I see:
2011-11-14 18:31:10,711 [ERROR jobs.jobhandler] [inventory sw01-3750] Job 'inventory' for evv-sw01-3750.brake.local aborted: User timeout caused connection failure.
I've been searching for a way to fix this... Does anyone have any advice to help me? I'm at the latest available version of NAV (from the debian sources)
Thanks!
Greg
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