Table of Contents
Advertisement
132 Chapter 8 RMON
Figure 65 How alarms fire
Rising value
Falling value
Alarm fires
No firing
It is important to note that the alarm fires during the first interval that the sample
goes out of range. No additional events are generated for that threshold until the
opposite threshold is crossed. Therefore, it is important to carefully define the
rising and falling threshold values for alarms to work as expected. Otherwise,
incorrect thresholds causes an alarm to fire at every alarm interval.
A general guideline is to define one of the threshold values to an expected,
baseline value, and then define the opposite threshold as the out-of-bounds limit.
Because of sample averaging, the value may be equal to ±1 of the baseline units.
For example, assume an alarm is defined on octets going out of a port as the
variable. The intent of the alarm is to provide notification to the system
administrator when excessive traffic occurs on that port. If spanning tree is
enabled, then 52 octets are transmitted out of the port every 2 seconds, which is
equivalent to baseline traffic of 260 octets every 10 seconds. This alarm should
provide the notification the system administrator needs if the lower limit of octets
going out is defined at 260 and the upper limit is defined at 320 (or at any value
greater than 260 + 52 = 312).
The first time outbound traffic other than spanning tree Bridge Protocol Data
Units (BPDUs) occurs, the rising alarm fires. When outbound traffic other than
spanning tree ceases, the falling alarm fires. This process provides the system
administrator with time intervals of any nonbaseline outbound traffic.
If the alarm is defined with a falling threshold less than 260 (assuming the alarm
polling interval is 10 seconds), say 250, then the rising alarm can fire only once
(Figure
alarm (the opposite threshold) must fire. Unless the port becomes inactive or
214393-A
66). The reason is that for the rising alarm to fire a second time, the falling
7821EA
Advertisement
Table of Contents
