RE: [nv-l] Netview SNMP/Discovery Issue

["Lemire, Mark" <mlemire@jhancock.com>]

Hi Scott -- I think you nailed the issue with that one.

 

Further experimenting here shows that -- at least with Solairs -- Netview will only keep an object on the map if two conditions are met at discovery: (1) the object responds to an snmpget with valid mib-2 data, or (2) the snmp query times out.  Otherwise Netview will either not add the object to the map (not sure if it creates a database stub or not), or -- if the object is manually added to the map -- Netview will simply delete it at the next polling cycle.

 

The solaris servers which are problematic have a third condition: the snmp query does *not* time out, but neither is any mib-2 data returned -- rather only a small amount of proprietary mib data.  This seems to be a clear violation of snmp standards and we consider it to be a separate problem.

 

The only way around it we have found is to add an entry to the Netview SNMP configuration table for the object, enabling the "use proxy" checkbox, and specifying any device which will generate an SNMP timeout.  Netview then seems to add the object process ICMP polling against it properly.

 

We are in the process of adding scripts which will manage the SNMP configuration table for problematic devices, but are concerned that if a large number are set up to continuously receive SNMP timeouts, if this will have a significant performance impact or not.  In the meantime -- we are doing what we can to migrate to a supported release.  Anyone know if v7.1.3 behaves in a similar way?

 

Thanks!

 

Mark

-----Original Message-----
From: Barr, Scott [mailto:Scott_Barr@csgsystems.com]
Sent: Wednesday, May 21, 2003 2:59 PM
To: Gareth Holl; Lemire, Mark
Cc: nv-l@lists.tivoli.com
Subject: RE: [nv-l] Netview SNMP/Discovery Issue

One more thing about solaris

 

when you snmpwalk system.sysName.0 with the wrong community name you will get a "valid" response from the agent. Discovery proceeds but the box is not properly discovered.

 

More solaris fun

-----Original Message-----
From: Gareth Holl [mailto:gholl@us.ibm.com]
Sent: Wednesday, May 21, 2003 1:24 PM
To: Lemire, Mark
Cc: nv-l@lists.tivoli.com
Subject: Re: [nv-l] Netview SNMP/Discovery Issue

You may want to look at migrating to version 7.1.3 soon as version 6.x is no longer a supported release.

Gareth Holl
Staff Software Engineer
gholl@us.ibm.com

IBM Software Group - Tivoli Brand
Research Triangle Park,  North Carolina.

"Lemire, Mark" <mlemire@jhancock.com> 05/20/2003 03:42 PM

To:        "'nv-l@lists.tivoli.com'" <nv-l@lists.tivoli.com>         cc:        "Kenney, Jack" <jkenney@jhancock.com>, "Hughes, Tom P." <thughes@jhancock.com>         Subject:        [nv-l] Netview SNMP/Discovery Issue

We have encountered a situation where Netview is auto-deleting objects from its database almost immediately after discovering them.

This only appears to happen with Unix servers running Solaris 2.8; it's not a problem with our NT servers or with older versions of Solaris.

Here's our configuration:

(1) We're running Netview v6.0 on Solaris 2.6.
(2) Netmon is configured to use a seedfile that contains a statement: !@oid 0 to block auto-discovery of devices that are not running SNMP -- mainly workstations.

(3) Netview SNMP configuration does not have any specific or wildcard overrides in terms of this issue.  It uses a default community string that is configured on all routers and switches, which *do* get autodiscovered as expected.

(4) NT servers run an SNMP service but do not use the default community string.  These devices are not auto-discovered.  To manage these devices, we add their IP address to the seedfile once they are active on the network.  This works OK - once discovered, they stay managed.

(5)Unix servers running older versions of Solaris (i.e. 2.6) work the same way as NT; these servers do not run an SNMP daemon normally.

The problem is with Unix Servers running 2.8.  These do not use the default community string defined to Netview.  When we add the IP address to the seedfile, they do not get discovered.  When we explicitly add them in the read/write map, they initially get discovered but get auto-deleted 5 minutes later, apparently as part of the next polling cycle.  The only way to successfully get Netview to manage these servers (using the non-default community string), is to add a specific override in the Netview SNMP configuration.  We could also get around the problem by configuring netmon with the "-h" alternate community string option, but have rejected this solution since it would need to be left in place most of the time and adds to Netview's overhead.

We would expect this "auto-delete feature" of Netview to at least act in a consistent manner, affecting both NT and Unix servers alike.

Before opening a problem with support, we first just wanted to see if anyone out there has seen this or can offer an explanation.

Thanks!!

Mark Lemire
Sr. Consultant
John Hancock Financial Services ---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)

---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)