To: | "'nv-l@lists.tivoli.com'" <nv-l@lists.tivoli.com> |
---|---|
Subject: | [nv-l] Netview SNMP/Discovery Issue |
From: | "Lemire, Mark" <mlemire@jhancock.com> |
Date: | Tue, 20 May 2003 15:42:38 -0400 |
Cc: | "Kenney, Jack" <jkenney@jhancock.com>, "Hughes, Tom P." <thughes@jhancock.com> |
Delivered-to: | mailing list nv-l@lists.tivoli.com |
Delivery-date: | Tue, 20 May 2003 21:14:32 +0100 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
List-help: | <mailto:nv-l-help@lists.tivoli.com> |
List-post: | <mailto:nv-l@lists.tivoli.com> |
List-subscribe: | <mailto:nv-l-subscribe@lists.tivoli.com> |
List-unsubscribe: | <mailto:nv-l-unsubscribe@lists.tivoli.com> |
Mailing-list: | contact nv-l-help@lists.tivoli.com; run by ezmlm |
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.
(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
--------------------------------------------------------------------- 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) |
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | RE: [nv-l] Monitoring Throughput, Seminara, Sandro |
---|---|
Next by Date: | RE: [nv-l] Netview SNMP/Discovery Issue, Barr, Scott |
Previous by Thread: | [nv-l] Monitoring Throughput, Seminara, Sandro |
Next by Thread: | RE: [nv-l] Netview SNMP/Discovery Issue, Barr, Scott |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web