Get The Most Out Of The T:LAN/RIO Alarm Reporting Capabilities (Part 3)
This is the 3rd and final part 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. Part 1 (which you can find here) introduced some background information and measures to counter alarm floods. Part 2 (which you can find here) continued to discuss additional measures to prevent these notorious notification storms. Part 3 concludes the discussion:
What happens if the SNMP transmission path gets interrupted?
Our customers have occasionally set their repeat rates and interval times to cover the rare event of a network connection outage lasting several hours.
Good event reception at the NMS can still be achieved by stretching the window during which the T:LAN/RIO will attempt to report the alarm event beyond the average outage period. Again, no fixed recommendation can be made as such periods are unique to each customer and highly dependant on the network environment in which each T:LAN/RIO must function.
What happens if power is lost or the T:LAN re-boots?
As with any other RAM based log, all current log entries and any active retry counters/interval timers will be lost.
Only alarm conditions that persist and are still present when the T:LAN finishes re-booting (or powering up) will generate a new entry in the RIO Event Log. These re-generated entries then behave in the same manner as those present before the re-boot/power up event.
What are QuickAlerts?
The QuickAlerts feature presents a fast and easy-to-use means for relaying specific alarm information from a T:LAN/RIO to the Remote Commander Client user. This feature eliminates the need to either log into remotely deployed units or into a central network monitoring system (NMS) in order to consult multiple event logs.
Each T:LAN/RIO supports up to 10 category alarms (QuickAlerts). Higher order alarms can be configured by combining lower level (constituent) alarms into a combinatorial event notification. An 11th QuickAlert provides the user with an instant status read-out of the ecoLOGIC app deployed on that particular T:LAN/RIO:
For more details, refer to the Remote Commander Client User Guide Chapter 5, QuickAlerts and the RIO User Guide Chapter 3, RIO QuickAlerts Menu:
Are QuickAlerts reported via SNMP?
No. QuickAlerts are only reported to the Optima Remote Commander Client (RCC) for display in the QuickAlerts column. However, the individual alarms that constitute any combinatorial QuickAlert are still reported via SNMP (if so enabled).
What is the quickest way to completely turn off the SNMP trap generation?
- Log into the T:LAN.
- Go to the [P]rotocols & IP Filtering Menu.
- Select the [S]NMP Menu.
- Set [T]rap Generation to 0 = disabled.
Is the SNMP Proxy Trap Mode fully implemented yet?
Although selectable through the user interface, the SNMP Proxy Trap mode is not fully implemented at the time of writing (August 2018).
However, to aid the identification of the original alarm source in routed environments, the T:LAN/RIO SNMPv2 InformRequest PDUs embed an extra OID binding identifying the origin (MAC address) of the event notification. This feature has been added beginning with BN7378.
Can the T:LAN/RIO SNMP port be redefined?
Yes. Check the [S]NMP Menu, sub-option SNMP Port of the [S]NMP Handling command.
Can the T:LAN/RIO send SNMPv1/v2 traps to non-standard ports?
Yes. Users can re-define the SNMP port to be used when sending all traps/notifications to each of the four NMS destinations.
This also aids in running multiple NMS instances at the same destination IP address.
How about simulating SNMP alarms in order to check the proper reception at the NMS end?
Easy! Just go to the RIO EDIT MENU of the corresponding alarm to be tested. Then use the [T]est command to either raise or clear a test alarm.
Is there a way to distinguish test alarms from real world alarm events?
Yes. Each event is tagged with a sequential identifier. Observe the values in the ID column of the RIO Event Log. All manually generated test events will have an ID starting with ‘AAAAAA‘.
How does the alarm ID tag work?
Each new alarm event will be tagged with the next alarm ID in sequence. This aids in sorting and identifying alarm notifications.
Repeat transmissions always use the SAME ID. Only new events will have a different ID.
What is the most current MIB for the T:LAN/RIO?
The most current at the time of writing (August 2018) is V1-9-0.
Is there a separate MIB available for the RIO?
No. All the RIO specifics are governed by the T:LAN MIB.
Is there separate documentation available that details the operation of SNMP GET/RESPONSEs?
Yes. Please refer to document #: 4000-A400115D
What if none of the RIO Node 0 events are being reported?
Although this is less of an SNMP issue, it obviously hampers the reporting via SNMP. The root cause may be a rather rare hardware fault.
Symptoms: If your alarm tests come through normal and you only see a change in the alarm I/Os when you do a SYNC (followed by a ‘+’ to refresh the screen), then there might be something wrong with the internal alarm request line (hardware issue).
Detection: To diagnose this fault, use the MAIN MENU [N]PA command. Type in the following code:
$ADBCEC24 ENTER
Procedure: Check the level being reported for the Q0 Signal. Under regular operation, the Q0-Level should show ‘H‘ (for HIGH).
Here are the steps to try to determine the cause in case the Q0-Level reports ‘L‘ (constantly LOW):
Remove ALARM 2 cable from back of T:LAN.
Run the [N]PA command $ADBCEC24 again. Check for Q0-Level: ‘H‘. If it now shows ‘H‘, check for an ALARM2 wiring issue!
If it still reports ‘L‘, remove ALARM 1 cable from back of T:LAN.
Remove the alarm cable(s) at the T:LAN end(!), not the BIX end!
Run the [N]PA command $ADBCEC24 again. Check for Q0-Level: ‘H‘. If it now shows ‘H‘, check for an ALARM1 wiring issue!
If it still reports ‘L‘, then power down (not just re-boot) the T:LAN.
After powering back up, run the [N]PA command $ADBCEC24 again. Check for Q0-Level: ‘H‘. If it now shows ‘H‘, check all T:LAN hook-ups, especially the power and GROUND connections. Re-load the latest OS, default ALL RIO Node0 settings, create new RIO Node 0 I/O mappings. This ensures you are starting with a fresh configuration.
If it still reports ‘L‘, please RMA the unit. Most likely the unit sustained lightning damage to the RIO Node 0 inside the T:LAN unit.
Ralf Doewich
Optima Tele.com, Inc.