NetView v7.1.3
Solaris 2.8

Well folks, I am surprised no one else has had "the pleasure" of discovering this problem. I just got to spend about 3 days chatting with my good friends in support. Until about a half hour ago both support and I were convinced we had a major netmon bug, but au contraire, we have found a lovely little bug in the SNMP agent for Solaris.

First, you need to understand how NETMON uses the community names file during discovery. What was happening was that after discovery all of our Solaris servers (which we use $ seed file entries for) would turn red. You could ping them, but you could not demand poll them "no such name" on the system identifier. This occured on all 150+ Solaris servers I was monitoring. Netmon goes out and pings a device then issues an snmpGet for the system name. If it is successful, the device is SNMP managed and if it times out, netmon goes on to the next community name until he finds one that works.

HOWEVER (and you can try this at home if you like)

When "snmpget -c public <nodename> system.sysName.0" is issued by the netmon process, the results (which should be a time out) are:

Solaris:
# snmpget -c public wfx-vrz1 system.sysName.0                                  
snmpget: This variable does not exist: .iso.org.dod.internet.mgmt.mib-2.system..
#                                                                              
AIX (or any other system)
# snmpget -c public cxp-ds002 system.sysName.0 
snmpget: No response arrived before timeout.   

Netmon treats these responses differently. Netmon considers the first a successful SNMP query, and therefore (since it answered to public) does not add an entry into ovsnmp.conf and uses public from there on out. Next status poll - the box turns red because NETMON is busy pounding on it with public.

Solution: Since you can't put the entries into ovsnmp.conf ahead of time, you have to discover the boxes with pings, then add a static entry to the SNMP configuration table, then whack the node from discovery and rerun discovery (which will now use the correct comminity string first try since it's in the ovsnmp.conf file).

I'm not a big fan of SEA but this just put a stake in it's heart. I am telling our Unix folks to get net-snmp on all our servers as fast as they can.

May this message save you many hours of headaches......

Scott Barr

CSG Systems Inc.

Network Systems Engineer

Phone: 402-431-7939

Fax: 402-431-7413

Mail: scott_barr AT csgsystems DOT com