Remote Infrastructure Management RIM-600 User Manual

RIM-600 Manual

Alarm Logic

Network devices are monitored by the RIM-600 by pinging/connecting to programmed IP addresses

about once a minute. The unit will only attempt to ping/connect to devices which are Enabled by

the Schedule. Each time the network device responds, the RIM-600 updates the Last Response time.

A time limit for responding is assigned to each IP Alarm to determine if the device is functioning

properly. This time limit is called the ping Timeout. If a network device does not respond within

this time period, the RIM-600 will count this as a ping failure. You can program the RIM-600 to

try to ping/connect to the network device several times before tripping an alarm. The ping Retries

determines how many times the RIM-600 will try to ping/connect to the device before sending an

alarm. An alarm will only occur if the device fails to respond to consecutive ping attempts. Once

a successful response is received, the failure counter will reset. For example: If the ping Retries is

set to 3, then the RIM-600 must fail to ping/connect to the device 4 times in a row (initial attempt

+ 3 retries) to trip an alarm. If the device were to respond after the second attempt, then the failure

counter would reset, thus requiring four subsequent successive failures to trip an alarm. Once an

alarm is recognized, the Last Alarm time will be updated.

A dependency device (IP address) can be programmed for each IP Alarm. This is used to prevent

numerous alarms from occurring when common network infrastructure problems arise. If the

dependency device fails, then all IP alarms that have this dependency will be temporarily disabled

from sending alarms until the dependency device returns to normal (e.g. starts responding to ping/

connect requests). When an IP Alarm’s dependency is not responding, the status for the IP Alarm

will be shown as “IP route down.” It is recommended that the dependency device be programmed

such that it will go into alarm before any other devices. You can achieve this by setting the number

of Retries for the dependency device to a lower value than the IP Alarms which rely on this device.

In summary, for an IP Alarm to be dispatched, the following criteria must be met:

a) The IP Alarm must be enabled—as configured through the schedule.

b) It must have failed to respond to consecutive ping/connect requests and exceed the number of

retries.

c) It must be a member of a class.

d) There must be one or more user profiles which include this class.

Once the alarm is dispatched, the alarm delivery process begins. If any of the contacts are pro

grammed as Until Acknowledged, then the Last Ack time will update when the alarm has been

acknowledged. In the case where all contacts are set to Inform Only, the Last Ack time will update

immediately after the alarm occurs.

Additionally, there is an option to re-dispatch the alarm if it remains in an alarm state too long. This

programmable time period is called the Alarm Reset Time. This parameter can be set from 30 to

3600 minutes. For example: Suppose the Alarm Reset Time is set to 180 minutes. Now suppose an

IP device has stopped responding and trips an alarm which results in all programmed users receiv

ing their respective messages. If the IP device continues to remain unresponsive for 180 minutes,

then the alarm will be dispatched again and everyone will be contacted once more.

DO NOT set the Alarm Reset Time too short, otherwise you will continue to dispatch the

same alarm over and over resulting in numerous phone calls, e-mails, etc.