[mrtg] MRTG and Sonicwall help
scot
scot at elitecode.co
Mon Aug 25 18:02:56 CEST 2014
can’t get it to work with either
Target[192.168.30.1_X1]: #X1:angrybird at 192.168.30.1:::::2
gives following errors in /var/log/mrtg.log
2014-08-25 11:25:43 -- 2014-08-25 11:25:43: WARNING: could not match&get 192.168.30.1:::::2/ifHCInOctets for Name 'X1'
2014-08-25 11:25:43 -- 2014-08-25 11:25:43: ERROR: Target[192.168.30.1_x1][_IN_] ' $target->[0]{$mode} ' did not eval into defined data
2014-08-25 11:25:43 -- 2014-08-25 11:25:43: ERROR: Target[192.168.30.1_x1][_OUT_] ' $target->[0]{$mode} ' did not eval into defined data
Target[192.168.30.1_X1]: 4:angrybird at 192.168.30.1:::::2
gives no errors in /var/log/mrtg.log
if I check the /var/www/mrtg/192.168.30.1_x1.log there are a bunch of date stamps with 4 zeros at the end
I am reunning MRTG as deamonized and a interval of 1
and still get no data.
my cfg is /etc/mrtg/mrtg.cfg
there is no mrtg.ok, I get a mrtg.pid
i tried the OID’s but get the same thing all zeros
if I change .4 to .2 interface, I get data ….
if I snmpwalk the OID’s the counters are 0 for interface 4
this is making no sense.
even using your OID’s below… still no data…
here is the SNMPWALK’s
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.2.2.1.10.4
iso.3.6.1.2.1.2.2.1.10.4 = Counter32: 0
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.2.2.1.16.4
iso.3.6.1.2.1.2.2.1.16.4 = Counter32: 0
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.31.1.1.1.6.4
iso.3.6.1.2.1.31.1.1.1.6.4 = Counter64: 0
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.31.1.1.1.10.4
iso.3.6.1.2.1.31.1.1.1.10.4 = Counter64: 0
here is the weird part change to interface 2 and DATA
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.2.2.1.10.2
iso.3.6.1.2.1.2.2.1.10.2 = Counter32: 2179258894
[root at a-mothership] mrtg > snmpwalk -v 2c -c angrybird 192.168.30.1 1.3.6.1.2.1.2.2.1.16.2
iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 629843123
I perfer to get it working my using X1 or X2, etc…. since I have 30+ sonic walls I want to add to MRTG, and trying to figure out the OID for each is going to be a pain..
I found a MIB for sonicwall I’m testing this on, but not sure if this would help.
Scot
On Aug 24, 2014, at 21:00, Steve Shipway <s.shipway at auckland.ac.nz> wrote:
> 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/c8b04e1e/attachment.html>
More information about the mrtg
mailing list