• Home
  • Get The Most Out Of The T:LAN/RIO Alarm Reporting Capabilities (Part 1)

Get The Most Out Of The T:LAN/RIO Alarm Reporting Capabilities (Part 1)

This is Part 1 of a series which attempts to provide a more comprehensive look at the SNMP alarm reporting capabilities of the Optima T:LAN and RIO products. Here is some background information before we get into the details.

Protocols & Data Exchanges

When talking about alarm events, it is important to distinguish between T:LAN’s use of SNMPv1 traps and RIO’s use of SNMPv2 InformRequests.

Both are typically referred to as traps, yet they cover completely different event types. They also act differently in terms of the underlying SNMP protocol, packet exchanges, expected replies (or lack thereof), repeat counts and repeat rates at which they are sent.

SNMPv1

The following is an excerpt from the T:LAN User Guide, Chapter 4: Theory Of Operation – SNMP Traps. It covers the use of the SNMPv1 traps. These are used exclusively to communicate events recorded on the T:LAN.

Refer to the T:LAN User Guide, Chapter 5: Configuration – SNMP Menu for details on how to mask each of the available trap categories for any of the four possible NMS destinations. This allows precise steering and control over the types of SNMP traps being generated by each T:LAN unit and sent to each NMS destination.

SNMPv2

The RIO alarms use SNMPv2 InformRequest PDUs to relay alarm information.

This is superior to SNMPv1 fire-and-forget traps. SNMPv1 did not resolve the uncertainty whether or not the recipient actually received the intended communication.

Therefore, with SNMPv2, the InformRequest sent by the alarm sender (T:LAN+RIO) will be ‘ACK‘ed by the recipient (NMS). This is done by sending back a copy of the processed SNMPv2 InformRequest. This assures the alarm originator that the recipient has indeed received and processed the event being reported.

Even though this is only a small change in the operation of SNMP ‘traps’, it eliminates the need to repeat the same event notification just to ensure proper reception.

It also saves valuable bandwidth, lowers the required processing overhead, and significantly reduces the possibility of causing ‘event storms’ when many events need to be reported at once.

How Many Event Entries Does The T:LAN Keep In Its Event Log?

Up to 640 events are kept in the T:LAN Event Log.

How Many SNMPv1 Traps (Also Called Generic Traps) Can The T:LAN Handle Concurrently?

The T:LAN can handle up to 16 concurrent SNMPv1 (generic) traps.

How Many Times Will Each Generic Trap Be Repeated?

Each generic trap will be repeated 3 times.

What Is The Repeat Interval Between Generic Traps?

The interval is 5 seconds.

Are These Values User Configurable?

No. Contrary to the operation of the SNMPv2 InformRequests, the parameters of the rarely used generic traps are not user configurable.

How Else Can A User Control The Generation Of SNMPv1 Traps In The T:LAN?

See the T:LAN User Guide, Chapter 5: Configuration – SNMP Menu. Each trap category can be masked individually for each NMS destination to stop unnecessary/nuisance traps:

What Is AAS (Adaptive Alarm Suppression)?

Here is how the RIO User Guide explains Adaptive Alarm Suppression:

Can Contact Bounce Be Reduced?

Of course. You can find all the details in the RIO User Guide, Chapter 1: Improved Resiliency of Contact Inputs.

What Can Be Done To Slow The Rate At Which Events Are Generated?

Here are several tips (which you can all combine) to reduce the number of alarm events being generated. As you are applying these measures right at the source (where it makes the most sense) you will really see the impact this will have on your overall network traffic!

ADD A QUALIFICATION TIMER.

Probably the most effective and important step! Do this for each offending discrete contact input. Only if the input stays in alarm for longer than the qualification period will the T:LAN+RIO issue an alarm.

Correspondingly a clear will only be issued once the input has gone back to the rest state for longer than the qualification period. This eliminates the ‘chatter’ usually seen from noisy alarm inputs.

ADD AAS (Adaptive Alarm Suppression).

Enabling the AAS feature on an alarm input will cause future alarms to be automatically squelched (for a defined period of time), should the input transition more than the allowed number of times within in a set time window.

This is a great way of reigning in misbehaving (or chatty) inputs. And it does NOT require manual intervention. The AAS algorithm automatically takes a suppressed input out of AAS again after a set period of time.

If the input still chatters away at that time, then it will once again be put under AAS control.

Should you observe this kind of pattern (several periods of AAS control following each other), then you have a clear indication that this input really needs some TLC or scheduled maintenance to bring it back in line.

MAKE SURE THE NMS RESPONDS PROPERLY.

Ensuring that the NMS answers each SNMPv2 INFORM REQUEST tells the T:LAN+RIO that it no longer needs to repeat an alarm notification and that the NMS acknowledges receipt. If that mechanism is not in place, the T:LAN+RIO will attempt to re-transmit the same SNMP notification based on the user selected interval period and repeat count.

CHANGE THE TRAP FORWARDING MODE.

The T:LAN+RIO support two distinct RIO Trap Forwarding Modes:

A) CONCURRENT EVENT REPORTING

Once an event is recorded, the trap forwarder begins reporting the state transition. If a new event for the same IO is recorded before the trap forwarder has finished reporting the previous event, then two or more concurrent trap notifications for the same IO will be sent out. Choose this mode if preserving the event sequence is of priority. This is the default setting!

B) ONLY MOST RECENT EVENT REPORTING

Newly recorded events abort any prior event reporting for the same IO still in progress. The trap forwarder immediately begins reporting the most recent event for the corresponding IO. Choose this mode if the most up to date state reporting is of priority.

CHANGE THE REPEAT COUNT AND REPEAT INTERVAL.

By default, the following settings are active in a T:LAN+RIO:


MINOR Alarms (Any Level 1-9):

Repeat MINOR ALARM RAISED NOTIFICATIONS for a maximum of 5 times, every 30s unless ACKed sooner by NMS destination.
Repeat MINOR ALARM CLEARED NOTIFICATIONS for a maximum of 5 times, every 30s unless ACKed sooner by NMS destination.

Result: T:LAN+RIO will only attempt to deliver MINOR events for a max period of 5 x 30s = 150s = 2 minutes and 30 seconds.


MAJOR Alarms (Any Level 1-9):

Repeat MAJOR ALARM RAISED NOTIFICATIONS for a maximum of 10 times, every 20s unless ACKed sooner by NMS destination.
Repeat MAJOR ALARM CLEARED NOTIFICATIONS for a maximum of 10 times, every 20s unless ACKed sooner by NMS destination.

Result: T:LAN+RIO will only attempt to deliver MAJOR events for a max period of 10 x 20s = 200s = 3 minutes and 20 seconds.


CRITICAL Alarms (Any Level 1-9):

Repeat CRITICAL ALARM RAISED NOTIFICATIONS for a maximum of 25 times, every 10s unless ACKed sooner by NMS destination.
Repeat CRITICAL ALARM CLEARED NOTIFICATIONS for a maximum of 25 times, every 10s unless ACKed sooner by NMS destination.

Result: T:LAN+RIO will only attempt to deliver CRITICAL events for a max period of 25 x 10s = 250s = 4 minutes and 10 seconds.


OTHER Alarms (Covers INFO/WARNING/FAIL Events):

Repeat INFO NOTIFICATIONS for a maximum of 2 times, every 50s unless ACKed sooner by NMS destination.

Result: T:LAN+RIO will only attempt to deliver INFO events for a max period of 2 x 50s = 100s = 1 minute and 40 seconds.


Repeat WARNING NOTIFICATIONS for a maximum of 3 times, every 40s unless ACKed sooner by NMS destination.

Result: T:LAN+RIO will only attempt to deliver WARNING events for a max period of 3 x 40s = 120s = 2 minutes.


Repeat FAIL NOTIFICATIONS for a maximum of 25 times, every 10s unless ACKed sooner by NMS destination. These are the highest level notifications, usually reserved for hardware fail events.

Result: T:LAN+RIO will only attempt to deliver FAIL events for a max period of 25 x 10s = 250s = 4 minutes and 10 seconds.


The RIO however supports a much wider range of repeat intervals: these can be specified as follows:

  • 1 to 60 seconds
  • 1 to 60 minutes
  • 1 to 24 hours
  • 1 to 60 days
Stretch out the time between repeated attempts to transmit the same event. This will help reduce network congestion and increase the chances of getting an alarm event notification through even though the network might be busy or a network link might be temporarily down.
Example: Typical link downtime: 3h = 180 minutes. Programming a an event severity to repeat 40 times every 5 minutes = 200 minutes.
 
Remember, there are a total of 30 for RAISED + 30 for CLEARED = 60 repeat count and 30 interval period settings that can be adjusted. This provides really fine granularity. Enough to program each severity level individually.
 
If this sounds too daunting, keep in mind the default settings  listed above. You only need to modify those that you actually use or find important enough to adapt to your own requirements.
Ralf Doewich

Optima Tele.com, Inc.

Configuration, Software, Tech Tips

Leave a Reply

Your email address will not be published. Required fields are marked *

Newsletter

Get The Latest From Optima

Be In The Know

Subscribe To Optima E-mail Updates

Keep up to date with all the latest Optima developments. Subscribe to our e-mail newsletter and be the first to know when we post new articles or update our blog.

Sign up is easy. Just enter your details below and we will send you a quick confirmation. All you have to do is to confirm the receipt of the verification e-mail and you are all set!

Please note: Your e-mail address will solely be used to inform you of Optima updates. It will not be sold or shared.
We will send out a verification e-mail message to the account you provide. Make sure to follow the instructions given to complete the sign-up process.
 
 

Get In Touch

How To Contact Optima

Optima BLOG

Insight, Advice, Tips & More

Recent Posts

Optima News