I've been using "SNMP Browser" to browse relevant parameters, and
then its "monitor" feature to initiate stripcharts of the parameter
of interest.
This works fine for things like unicast traffic (ifInOctets and such).
The browser displays a list of numbers for the interfaces, these
numbers change with time; the "monitor" produces a set of graphs, with
appropriate plots. All works fine. These parameters are in a path
that starts internet.mgmt.mib-2.interfaces.ifTable.ifEntry ... and are
of type Counter32.
However, when I try to do the corresponding thing with the DVMRP MIB,
for example the virtual interface octets like dvmrpVInterfaceInOctets,
here's what happens. The browser shows a plausible list of values,
and shows them of being type Counter32 as before. The "monitor"
function sets up what looks like a plausible monitoring job and draws
their graphs, but the numbers that are plotted are always exactly
zero (displayed in the caption as well as plotted, or should I say
"not" plotted).
I have tried this with a range of counter parameters in the "normal"
MIB and they all work fine. I have tried with a range of counter
parameters in the DVMRP MIB, the path to which starts
internet.experimental.dvmrpMIB.dvmrpMIBObjects.dvmrp.dvmrpVInterfaceTable
, and always get the same result: the _browsed_ values look plausible,
and they increase with time, but the _plotted_ (monitored) values are
always exactly zero.
I have inspected the respective monitoring jobs' parameters and
cannot see any obvious difference between them that would explain
why one is getting good data while the other is claiming to get zero
(from parameters, I re-iterate, that when browsed are definitely
not zero and are definitely changing).
Does this represent a problem that anyone recognises, please?
I have little expertise in debugging this kind of application
but I would be happy to carry out any tests that people thought
relevant. Due to firewalling I am sorry but I cannot point you
to an actual router (mrouted) of mine that you can try this out for
yourself against, but I've tried it against other people's
SNMP-capable mrouteds that I was able to reach, and have observed the
exact same symptoms, so I know that it isn't specific to the one
mrouted that I am trying to monitor.
thanks.
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.