nv-l
[Top] [All Lists]

RE: Using public as community name in spite of...

To: nv-l@lists.tivoli.com
Subject: RE: Using public as community name in spite of...
From: "Smith, Kristi" <kristi_smith@mentorg.com>
Date: Tue, 6 Feb 2001 08:21:15 -0800
I have seen this as well on Solaris.  My experience was with a specific
device - some SNMP queries would use the "public" community string and other
queries would use the customized community string I had configured in
ovsnmp.conf.  I haven't had time to follow up on this particular problem
yet.

I also had to remove the communityNames.conf file as it would automatically
add entries to the ovsnmp.conf files. The new entries would have the
discovery polling defaults of 15 minutes and trying to pull up to 800 routes
off the device and that causes alot of problems in my network.  Anyone know
how to make the real discovery polling default to be other than 15
minutes/800 routes?  I have configured the Global Default in ovsnmp.conf to
be what I want it to be but that doesn't seem to affect anything.

Regards,
Kristi Smith
Mentor Graphics Corporation
(503) 685-1971
kristi_smith@mentor.com 

-----Original Message-----
From: Jane Curry [mailto:jane.curry@skills-1st.co.uk]
Sent: Monday, February 05, 2001 1:40 PM
To: NetView mailing list
Subject: [NV-L] Using public as community name in spite of...


We are struggling with NetView 6.0.1 on NT to prevent it using public as
a community name.  ovsnmp.conf has a few specific node/community names
(none using public) and a default that is NOT public.  We have entirely
removed communityNames.conf.   In spite of this, we find nodes being
sent SNMP packets with public - and when the SNMP GET is successful, the
node is automatically added to ovsnmp.conf with public.

WE DON'T HAVE CONTROL OVER THESE DEVICES SO SUGGESTING CHANGING THE
AGENT CUSTOMISATION IS NOT VALID, but we really, really, don't want to
get SNMP answers out of them.

An earlier append suggested that following this process, including the
complete removal of communityNames.conf, solved the problem - but
perhaps that scenario was Unix rather than NT??

2 questions:
1) Does anyone else see this problem and have a solution?  We are
working on using the "I" flag in oid_to_type - not sure yet whether it
is going to suffice
2) Does anyone know if this is fixed in 6.0.2 which James said had gone
to manufacturing last week  (Hint - James - if you have time, I'd love a
list of bug fixes in 6.0.2.....)

Thanks for any input,
Jane
--
Tivoli Certified Enterprise Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2001 Jane Curry <jane.curry@skills-1st.co.uk>.  All rights
reserved.


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web