I am not sure wether this is specifically a 3750 stack problem. We have numerous of 3750 and 3750X (48PS/12-S/24-S) The only weirdities I've noticed about chassis stacked switches, is that the switchports all appear under "No module" which is merely a cosmetic problem for me. It appears to be able to poll port data from the switch just fine. I'm not sure if there is any workaround to make NAV correctly determine wether it's a single or multichassis stack (modular or stacked) and make it look pretty on the ipdeviceinfo page, but as I said - its just a cosmetical thing for me.
-Vidar
Fra: nav-users-request@uninett.no [mailto:nav-users-request@uninett.no] På vegne av Greg Cooper Sendt: 14. november 2011 18:41 Til: Morten Brekkevold Kopi: Seb Rupik; nav-users@uninett.no Emne: Re: Differences in SNMP results between versions
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.nomailto:morten.brekkevold@uninett.no> wrote: On Tue, 04 Oct 2011 16:07:24 +0100 Seb Rupik <snr@ecs.soton.ac.ukmailto: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