[Nut-upsuser] Tripplite SNMPwebcard communication lost and established randomly

[Charles Lepple]

On Mar 30, 2015, at 10:41 AM, Jason Gould <jgould at cddiagnostics.com> wrote:

> Just started using NUT and having a problem. I’m not sure if it is even NUT that is causing the issue.
> I’m running the latest FreeNAS 9.3 release.
> Network UPS Tools upsmon 2.7.2.
> The UPS is a Tripplite SU6000RT4UHVPM with the SNMPwebcard installed.
> I’m trying to use the SNMPwebcard, not USB or Serial. I’ve updated the SNMPwebcard to the latest firmware version (see below).

Thanks, this is good background information.
 
> In FreeNAS I was able to create a connection to the UPS by simply adding the IP address for the Port and defining the driver as “Various ups 3 (various) SNMP - RFC 1628 (snmp-ups)”. After that querying it just worked via “upsc tripplite”. And everything looks fine. However after a few hours I started getting emails and messages in the console about communication lost (COMMBAD) and shortly after it being established. This happens over and over again. I thought perhaps I needed to change some of the settings in ups.conf. I tried adjusting the pollfreq up to 30, using an snmp_version v2c, and a few other adjustments. However the behavior persists.

There are two stages here: the snmp-ups driver polls every 'pollfreq' seconds, and upsmon sends a warning if an UPS is stale for longer than DEADTIME seconds (as set in upsmon.conf). So if you increase pollfreq, you would probably want to increase DEADTIME as well. (I'm not sure how FreeNAS exposes this setting.) The upsmon.conf documentation recommends multiplying pollfreq by three to get DEADTIME. You may want to go higher than that, depending on how long the interval is between COMMBAD and COMMOK (the messages you quoted only have one-minute resolution).

Unfortunately, it looks like snmp-ups goes into COMMBAD mode if even one of the SNMP queries fails (and it queries a lot of OIDs), so you would need to rely on DEADTIME to filter out any transient packet loss. You might also see if your firewall or switch can prioritize SNMP packets using QoS settings - I am not familiar with how many times NetSNMP retries, but SNMP is UDP-based.

You could also try running 'snmpwalk' by hand against the SNMPwebcard to see if it experiences the same packet loss. If that doesn't work, I think you have a case for Tripp Lite support.

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150330/e76c5cd6/attachment-0001.html>