[mrtg] MRTG and Sonicwall help

[Steve Shipway]

Looking at your SNMP dump, it seems that the HC interface tree has a
different ifName for the ports than the normal interface tree.

 

This is a subset of the HC tree, showing ifName, ifHCInOctets, ifHighSpeed,
ifAlias:

 

iso.3.6.1.2.1.31.1.1.1.1.4 = STRING: "X1"

iso.3.6.1.2.1.31.1.1.1.6.4 = Counter64: 4189744484948

iso.3.6.1.2.1.31.1.1.1.15.4 = Gauge32: 1000

iso.3.6.1.2.1.31.1.1.1.18.4 = ""

 

and the normal tree showing ifDescr, ifSpeed and ifInOctets:

 

iso.3.6.1.2.1.2.2.1.2.4 = STRING: "X1 (WAN)"

iso.3.6.1.2.1.2.2.1.5.4 = Gauge32: 1000000000

iso.3.6.1.2.1.2.2.1.10.4 = Counter32: 2150745330

 

>From this, we see the (a) we must use SNMPv2 and the HC counters, and (b)
the HC name can be just "X1".

 

Target[192.168.30.1_X1]: #X1:angrybird at 192.168.30.1:::::2

 

So, this sets SNMPv2 (the :::::2 on the end) and (as we're using HC) should
identify the interface as X1 by ifName.  However, if that fails, then this
should always work, as it uses ifNum:

 

Target[192.168.30.1_X1]: 4:angrybird at 192.168.30.1:::::2

 

If you get an error from this, then it might be that the walking of the
interface tree is somehow failing to build up the mapping table.  If you cfg
file is called "foo.cfg" then look for a "foo.ok" in the same directory;
delete it if it exists, and make sure it (and the directory) and writeable
by the MRTG process so that it can be recreated.  Having an incorrect or
empty .ok file that is not writeable can break the name to number mapping.

 

Target[192.168.30.1_X1]:
1.3.6.1.2.1.2.2.1.10.4&1.3.6.1.2.1.2.2.1.16.4:angrybird at 192.168.30.1:::::2

 

So, this uses the explicit OIDs, but they are the normal not the HC ones.
You should instead use:

 

Target[192.168.30.1_X1]:
1.3.6.1.2.1.31.1.1.1.6.4&1.3.6.1.2.1.31.1.1.1.10.4:angrybird at 192.168.30.1:::
::2

 

Now, this uses explicit OIDs, SNMPv2, and the HC counters, so that it can
handle >100Mbps.  The first two examples above should have the same effect,
unless you have set the 'noHC[_]:yes' option (if you HAVE set this, remove
it now!)

 

So, if all you get are zeroes, then there are a couple of possibilities.
Firstly, there may be no traffic on the interface, so zero is correct.
Secondly, that you have the MaxBytes[] set too low and the calculated
traffic is being rejected as invalid.  Make sure MaxBytes[] is set to the
correct maximum octets-per-second of this interface - 128000 for a 1Mbps
link, and so on.

 

You can run MRTG interactively with the debugging enabled (
--debug=base,tarp,snpo,log,eval ) to get more details as to the data
retrieved and stored, to see what you're doing.

 

Steve

 

Steve Shipway

s.shipway at auckland.ac.nz

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.oetiker.ch/pipermail/mrtg/attachments/20140825/1493932e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5909 bytes
Desc: not available
URL: <http://lists.oetiker.ch/pipermail/mrtg/attachments/20140825/1493932e/attachment.bin>