How RMON alarms work
The alarm variable is polled and the result is compared against upper and lower limit values
you select after you create the alarm. If either limit is reached or crossed during the polling
period then the alarm triggers and generates an event that you can view in the event log or
the trap log.
The upper limit of the alarm is called the rising value, and its lower limit is called the falling
value. RMON periodically samples the data based upon the alarm interval. During the first
interval in which the data passes above the rising value, the alarm triggers as a rising event.
During the first interval in which the data drops below the falling value, the alarm triggers as a
falling event.
The following figure describes how alarms are triggered.
Figure 1: RMON alarm triggers
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 cause 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 you after excessive traffic occurs on that port. If spanning tree is enabled, 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 provides notification to you if the lower limit of octets going out
is defined at 260 and the upper limit is defined at 320 (or at a value greater than 260 + 52 =
312).
The first time outbound traffic other than spanning tree Bridge Protocol Data Units (BPDU)
occurs, the rising alarm fires. After outbound traffic other than spanning tree ceases, the falling
alarm fires. This process provides you with time intervals of a non-baseline outbound traffic.
If the alarm is defined with a falling threshold less than 260 (assuming the alarm polling interval
is 10 seconds) the rising alarm can fire only once. For the rising alarm to fire a second time,
the falling alarm (the opposite threshold) must fire. Unless the port becomes inactive or
spanning tree is disabled (which causes the value for outbound octets to drop to zero), the
Remote Monitoring
Configuration — System Monitoring March 2013 23
To Next Page
Loading...
