Hi Morten, I'm still very much in the learning phase of SNMP so I couldn't really make any suggestions on any models. I do however have four 3750G-48TS switches which I'd happily wire together for the purpose of testing any relevant patches.
cheers, Seb.
On 14/11/11 10:40, Morten Brekkevold wrote:
On Tue, 04 Oct 2011 16:07:24 +0100 Seb Rupiksnr@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.