Nagios Support Forum

We are seeing two different graphs for the same interface, an edge router for example.

I hope I can explain this properly, my co-worker has a better handle on the issue. Essentially, we are seeing two very different performance graphs for the same network interfaces. One performance graph is produced by Nagios XI, and we also utilize Cacti for performance graphing. They do not even appear to be close. My colleague thought it might have something to do with "Nagios XI needing to poll at 64 bit counters".

I guess at this point, we are unsure what the real issue is. I attempted to upload two attachments, a Cacti graph, and a Nagios XI graph of the same network interface.

Can you provide us with any feedback/explanation/etc???

Thank you,

Mark Frew
Atlantic Broadband

There can be a lot of reasons for this, although I do admit that I haven't used Cacti much. Here are some pointers that might help you troubleshoot the difference.

The NagiosXI graphs are drawn from a few default templates, depending on the type of service it's monitoring. Cacti specializes in creating custom templates, I'm noticing everything, including the unit of measurement is different in the Cacti graph. If the template from Cacti is different you will get a very different graph than the one generated by XI.

Start time, stop time, and also the span of time will also affect how the data is displayed. The rrdtool will return performance data at a different resolution (time intervals) depending on the start and stop times you define. The data from rrdtool can be at 1,5, 15, or 60 minute intervals, depending on the time specifications.

In XI, you can often click on a service graph, and it will display several graphs for a single service if there are multiple sets of performance data returned by a check plugin.

It appears this is related to SNMP versions/64 bit counters and the default polling in cfgmaker. I modified the switch.inc.php script to include --snmp-options=:::::2

from this line
$cmd.=" --noreversedns ".$snmpcommunity."@".$address;

to this line:
$cmd.=" --noreversedns --snmp-options=:::::2 ".$snmpcommunity."@".$address;

and now the counters are appearing to poll correctly. I think by default cfgmaker was grabing the SNMPv1.

I readded the device in question as the IP address instead of the FQDN so I can have a side by side comparison of this interface. The previous value is showing:

OK - Current BW in: .04Gbps Out: .04Gbps

and the new version is showing

OK - Current BW in: .26Gbps Out: 1.12Gbps

Looking at MRTG's site that should be the corrective action.

(From this site http://www.percom.org/2005/mrtg/cfgmaker.html)


community@router

Community is the community name of the device you want to create a configuration for. The default community name is 'public'; you might want to try this first if you do not know the community name of a device. If you are using the wrong comunity name you will get no response from the device.
Router is the DNS name or the IP number of an SNMP-managable device. Following the name you can specify 6 further options separated by colons. The full syntax looks like this:


B<router>[:[B<port>][:[B<timeout>][:[B<retries>][:[B<backoff>][:B<version>]]]]]


Of special interest may be the last parameter, version. If you set this to '2' then your device will be queried with SNMP version 2 requests. This allows to poll the 64 bit traffic counters in the device and will thus work much better with fast interfaces (no more counter overrun).

Would it be possible to add the version to the Switch Config Wizard so that we can specify per device what should be the snmp version to use?

Thanks

Kevin Michaels
Atlantic Broadband

I'm not an SNMP guy at all, but I do development and I've done some modifying on the switch wizard. Is the change below the only thing that needs to be modifed to work for the 64bit version?

from this line
$cmd.=" --noreversedns ".$snmpcommunity."@".$address;

to this line:
$cmd.=" --noreversedns --snmp-options=:::::2 ".$snmpcommunity."@".$address;

That is what seemed to have worked for me.

I think the --snmp-options argument can be three things depending on the SNMP version on the targeted device; based on this structure:

--snmp-options :[port][:[timeout][:[retries][:[backoff][:version]]]]

It can be

--snmp-options=:::::1
--snmp-options=:::::2
--snmp-options=:::::3

When 3 is used you will aslo need to use the

--username
and possibly
--authpassword

options as specified here:


The User-based Security Model (USM) used by SNMPv3 requires that a securityName be specified using the --username argument. The creation of a Net::SNMP object with the version set to SNMPv3 will fail if the --username argument is not present. The --username argument expects a string 1 to 32 octets in length.

Different levels of security are allowed by the User-based Security Model which address authentication and privacy concerns. A SNMPv3 target will derive the security level (securityLevel) based on which of the following arguments are specified.

By default a securityLevel of 'noAuthNoPriv' is assumed. If the --authkey or --authpassword arguments are specified, the securityLevel becomes 'authNoPriv'. The --authpassword argument expects a string which is at least 1 octet in length. Optionally, the --authkey argument can be used so that a plain text password does not have to be specified in a script. The --authkey argument expects a hexadecimal string produced by localizing the password with the authoritativeEngineID for the specific destination device. The snmpkey utility included with the Net::SNMP distribution can be used to create the hexadecimal string (see snmpkey).

It also might not hurt to use the [port] part of this to so users can query non standard ports.

Thanks

Kevin Michaels
Atlantic Broadband

Ok, I'll put this on the TODO list for the switch wizard. It may be a bit before I can make the changes, since I've got a few other projects I need to finish first. However, once I start working on this would you be willing to do some testing for us, as our hardware testing with SNMP is somewhat limited.

Ok, sounds good. This isn't a high priorty for us now that we identified the issue and put in a work around. Let me know when you are ready and I will load it up and see how it works

Thanks

Kevin

I am marking this to "re-visit" as well.