[mrtg] Re: vpdn oids changing from time to time
Rich Adamson
radamson at routers.com
Fri Mar 1 12:12:14 MET 2002
> is anyone there experienced a using variable oids? i thought i'm very lucky
> because at last i've found oids for our vpdn tunnel w/ cisco. the oid of
> every tunnel is changing from time to time so how we could use that w/ MRTG?
> any ideas regarding this would highly be appreciated.
I've not worked with the vpn stuff, but would imagine it can't be done
realistically with a stock mrtg.
SNMP oid's can be very dynamic (as you are seeing), with a specific oid
instance only being active and available at the time a specific session
(vpn tunnel) is in progress. In many cases, an snmp index is available
elsewhere within the mib variables that indicates what specific instances
are active at a specific time. In order to find that index, one would
have to understand Cisco's mib variable logic comparing the documented
mib to what is seen from a repetitive GetNext mib walk. (Most companies
do not document the inter-relationships of their mib tree elements
other than the comments included in each mib variable definition.)
Needless to say, mrtg does not have logic built into it to automatically
find Cisco's logic and present you with a "static" oid needed for mrtg
polling.
Two approaches that might partially work include:
1. write your own perl (or whatever) script to do a GetNext mib walk of
each oid occurance matching all but the last index number within the
oid. Use the results from the script to poll the variables wanted.
2. Find and understand the relationships/logic that Cisco used to design
the mib tree, and use that logic to find/poll the variables wanted.
In either case you probably won't like the results. The issue with
dynamic oid's is that a single oid can come and go in the middle of your
mrtg five-minute (or whatever) polling cycle and you won't know it.
Second, an oid instance many exist in one polling cycle and disappear
before the next polling cycle; what kind of logic would you implement
to address those cases? Even if you shorten the polling cycle to
something less than a minute, you would still need to address those
two issues within your script. Probably not realistic.
--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive http://www.ee.ethz.ch/~slist/mrtg
FAQ http://faq.mrtg.org Homepage http://www.mrtg.org
WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
More information about the mrtg
mailing list