can’t get it to work with either
Target[192.168.30.1_X1]: #X1:[email protected]:::::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:[email protected]:::::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@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@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@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@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@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@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 <[email protected]> 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:[email protected]:::::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:[email protected]:::::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:[email protected]:::::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:[email protected]:::::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
> [email protected]
_______________________________________________
mrtg mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
