From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Thu Dec 30 2004 - 20:01:19 GMT-3
For a value that never falls (i.e. interface counters) RMON
should use delta. If the value rises and falls (i.e. CPU or memory
utilization) RMON should use absolute.
From the Doc CD:
Delta:
Tests the change between MIB variables, which affects the
alarmSampleType in the alarmTable of the RMON MIB.
Absolute:
Tests each MIB variable directly, which affects the alarmSampleType in
the alarmTable of the RMON MIB.
Check a newer copy of the solutions guide as it will show delta
for that task.
Brian Dennis, CCIE #2210 {R&S, ISP-Dial, Security}
bdennis@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
reo@chavallos.net
Sent: Thursday, December 30, 2004 2:03 PM
To: ccielab@groupstudy.com
Subject: IEWB Lab1 Task 11.1-5
The task seems to be simple, as well as the solution.
My question is on the commons sense and real life use of it.
ifEntry.11 is type Counter32, that means that it always increases until
reaches 2**32.
---cut---
# snmpwalk -v 1 -c public rtr ifEntry.11.1
IF-MIB::ifInUcastPkts.1 = Counter32: 737076
---cut---
The task is to send trap if value increases to 15000 and falls to 5000.
It will happen only two time in Counter32 life cycle and these traps
would
not make any sense.
Basically with Counter type falling happens only once from 2**32 to 0.
The task would make better sense like this "send trap if the unicast
packets
counter changes 200 per sample interval".
Any thoughts on this?
#12944
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:32 GMT-3