Sorry you are absolutely correct - the -f 0 parm is mandatory if you want the
sun agents to behave.
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Foust, Kal E
Sent: Tuesday, November 11, 2003 11:56 AM
To: 'nv-l@lists.us.ibm.com'
Subject: RE: [nv-l] Sun Servers not responding.
Mike (and Scott):
We ran into some SEA problems a while back and this process seems
to work for us. By the way, I went to Sun with some string length problems
with the agent and they told me that they wouldn't be addressing that until
AFTER version 10 of Solaris! Think they blew me off? ;-)
You didn't say which version of Solaris (we're at S8), but you might
want to check your Solaris Enterprise Agent version...
# pkginfo -l SUNWmibii
on a known good system here, I'm seeing this
...
NAME: Solstice Enterprise Agents 1.0.3 SNMP daemon
CATEGORY: system
ARCH: sparc
VERSION: 11.8.0,REV=2000.01.08.18.12
...
and then perhaps your /etc/init.d/init.snmpdx file to be sure you're using
the -f 0 parameters
This flag sets the number of time-outs from operations performed by a master
on an agent to infinity. The default value of five is overridden and the
sub-agent is not deleted from the agent table if it cannot respond to an
internal snmpdx "ping" packet with the "public" community string.
The following steps will restart the snmpdx daemon with the -f 0 parameter:
1. Modify the /etc/init.d/init.snmpdx file with the following change:
...
if [ -f /etc/snmp/conf/snmpdx.rsrc -a -x /usr/lib/snmp/snmpdx ]; then
/usr/lib/snmp/snmpdx -y -f 0 -c /etc/snmp/conf
fi
...
2. Restart the snmpdx daemon
# /etc/init.d/init.snmpdx stop
# /etc/init.d/init.snmpdx start
Hope that helps.
-----Original Message-----
From: Barr, Scott [mailto:Scott_Barr@csgsystems.com]
Sent: Tuesday, November 11, 2003 12:42 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] Sun Servers not responding.
If you send the wrong community string to a sun box it will answer. I would
check your community strings in /etc/snmp/conf. My guess is you have the
wrong community string but the mib is still answering: here is an example
[ntv-denver01:root] /root#>snmpwalk -c bogusstring ntv-denver01 system no
MIB objects contained under subtree. [ntv-denver01:root] /root#>
This snmp walk is done on my netview server TO my netview server with an
obviously bogus string. The mib does NOT time out (which it should on an
invalid community string). Therefore it's a "valid" response and as such,
NetView believes it got a response. Check /var/adm/messages on those
machines for evidence.
Furthermore, all of my solaris netview servers will no longer walk the IBM
mib (the mgragentd does not register with snmpdx). I have support looking
into that part.
Recommendation: Get UCD-SNMP (or now called NET::SNMP)
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On
Behalf Of Mike Walsh
Sent: Tuesday, November 11, 2003 11:29 AM
To: nv-l@lists.us.ibm.com
Subject: [nv-l] Sun Servers not responding.
Good morning,
I have a somewhat unusal problem and am hopeing someone out there can
provide guidance.
I have a total of 6 (out of 165) sun servers which do not respond to to
Netview. I perform an snmpwalk on them the response is very slow and then
halts, finally giving me a timeout. When performing an snmpwalk with
"system" qualifier I get "no MIB objects contailed under aubtree". I am at
a loss as to what might be causeing this and how to fix it. Any suggestions
would be greatly appreciated.
Thanks,
Mike
Mike Walsh
****Please Note - New EMAIL Address mike.walsh@us.ing.com*********
612-342-3118
|