The optional Remote Monitoring feature provides the capability for the LSMS to report certain events and alarms to a remote location, using the industry-standard Simple Network Management Protocol (SNMP). The LSMS implements an SNMP agent with the SNMP agent process running on the LSMS platform.
Customers can use this feature to cause the LSMS to report events and alarms to another location, which implements an SNMP Network Management System (NMS). An NMS is typically a standalone device, such as a workstation, which serves as an interface through which a human network manager can monitor and control the network. The NMS typically has a set of management applications (for example, data analysis and fault recovery applications). The SNMP feature must be enabled while configuring the NMS.
An SNMP agent, such as that implemented by the LSMS, is responsible for SNMP managed objects; each managed object represents a data variable. A collection of managed objects is called a management information base (MIB). A copy of the MIB is maintained both at the SNMP agent and also at the NMS. The MIB can be read with a text editor.
An SNMP agent can do the following:
The SNMP protocol uses the User Datagram Protocol (UDP) transport protocol in a TCP/IP network. UDP is a connectionless protocol and does not guarantee reliable delivery of data. Therefore, SNMP does not use a preestablished connection to send data and does not guarantee reliable delivery of data.
New Object definition:
sourceIP OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Th“ source ip of the device where event was generated." ” ::= { tekelecLSMSEventObjects 44 } resyncVar OBJECT-TYPE SYNTAX INTEGER(0..1) MAX-ACCESS read-write STATUS current DESCRIPTION "Th“ object is available to be set by the NMS to indicate a request for alarm resynchronization. Object value=0 indicates a request to stop an ongoing resnchronization and Object value=1 indicates a resynchronization request." :”= { tekelecLSMSEventObjects 45 } resyncEventCnt OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only TUS current DESCRIPTION "Th“ total number of Resync alarms to be sent." ” { tekelecLSMSEventObjects 46 } alarmSequence OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Un“que sequence number identifying an SNMP Alarm Trap instance." ” ::= { tekelecLSMSEventObjects 48 } lsmsUptime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "Ti“e since LSMS is up." ::={ tekelecLSMSEventObjects 49 } specificOid OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Trap ID." ::= { tekelecLSMSEventObjects 50 } currentTimeOBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "Date and time string." ::= { tekelecLSMSEventObjects 51 } resyncErrCode OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "errorCode = 0, Resynchronization completed successfully. errorCode = 1, Resynchronization aborted by NMS. errorCode = 2, Resynchronization already in progress for the NMS. errorCode = 3, Resynchronization Aborted, Database error occurred. errorCode = 4, Resynchronization not in progress." ::= { tekelecLSMSEventsVer 218 }
New Trap Definition:
Existing traps defined for SNMP v1 are modified to include the following for the MIB for SNMP v3:
New SNMPv3 MIB Traps:
tekelecLSMSEventsV3 OBJECT IDENTIFIER ::= { tekelecLSMSEvents 3 } resyncStartTrap NOTIFICATION-TYPE OBJECTS { lsmsUptime, sourceIP } DESCRIPTION "The trap is sent by the LSMS to NMS when the LSMS is about to start resynchronization" ::= {tekelecLSMSEventsV3 212 } resyncStopTrap NOTIFICATION-TYPE OBJECTS { lsmsUptime, sourceIP, resyncEventCnt, resyncErrCode } DESCRIPTION "The trap is sent by the LSMS to NMS when resynchronization is complete" ::= {tekelecLSMSEventsV3 213 } resyncRejectTrap NOTIFICATION-TYPE OBJECTS { lsmsUptime, sourceIP, resyncErrCode } DESCRIPTION "The trap is sent by the LSMS to NMS when a resynchronization request is rejected by LSMS " ::= {tekelecLSMSEventsV3 214 } resyncRequiredTrap NOTIFICATION-TYPE OBJECTS { lsmsUptime, sourceIP } DESCRIPTION "The trap is sent by the LSMS to NMS when the LSMS is rebooted or LSMS is started" ::= {tekelecLSMSEventsV3 215 } heartBeatTrap NOTIFICATION-TYPE OBJECTS { lsmsUptime, sourceIP } DESCRIPTION "The trap is sent by the LSMS to NMS periodically to indicate that the LSMS is up" ::= {tekelecLSMSEventsV3 216 } lsmsAlarmTrapV3 NOTIFICATION-TYPE OBJECTS { currentTime,specificOid ,sourceIP, alarmSequence,specificAlarm} STATUS current DESCRIPTION "The trap will indicate that the following information is for a particular event" ::= {tekelecLSMSEventsVer 217 }
The MIB "choice fields" is added to accept a different number of arguments at runtime:
SPECIFICALARM::= CHOICE{ OBJECTID-VALUE TEKELECLSMSEVENTSVER }
Varbinds "sourceIP" and "alarmSequence" are added as a part of SNMPv3 and will be fixed varbinds to keep SNMPv1 backward compatible. SNMPv1 information will be passed as a part of "choice field."
A "currentTime" field conveys information about time when an alarm is triggered.
Current definition for SNMPv3 Trap:
LSMSALARMTRAPV3 NOTIFICATION-TYPE OBJECTS { CURRENTTIME, SPECIFICOID ,SOURCEIP, ALARMSEQUENCE,SPECIFICALARM} STATUS CURRENT DESCRIPTION "THE TRAP WILL INDICATE THAT THE FOLLOWING INFORMATION IS FOR A PARTICULAR EVENT" ::= {TEKELECLSMSEVENTSVER 217 }
Description of different varbinds of SNMPv3 Trap:
MIB OBJECTS | OID | Description |
---|---|---|
currentTime | 1.3.6.1.4.1.323.5.3.4.1.1.51.0 | Time when alarm is generated. |
specificOid | 1.3.6.1.4.1.323.5.3.4.1.1.50.0 | Oid which uniquely identifies a SNMPV3 alarm |
sourceIP | 1.3.6.1.4.1.323.5.3.4.1.1.44.0 | IP address of active alarm |
alarmSequence | 1.3.6.1.4.1.323.5.3.4.1.1.48.0 | Sequence number of triggered alarm |
specifcAlarm | List of OID for different varbinds | List of oid for different varbind and values |
Sample SNMPv3 trap for alarm 4021:
DISMAN-EVENT-MIB::SYSUPTIMEINSTANCE = TIMETICKS: (44365220) 5 DAYS, 3:14:12.20 SNMPV2-MIB::SNMPTRAPOID.0 = OID: SNMPV2-SMI::ENTERPRISES.323.5.3.4.2.0.217 SNMPV2-SMI::ENTERPRISES.323.5.3.4.1.1.51.0 = STRING: "02/01/10 20:31:31" SNMPV2-S MI::ENTERPRISES.323.5.3.4.1.1.50 .0= STRING: "1.3.6.1.4.1.323.5.3.4.2.0.40" SNMPV2-SMI::ENTERPRISES.323.5.3.4.1.1.44.0 = STRING: "192.168.59.30" SNMPV2-S MI::ENTERPRISES.323.5.3.4.1.1.48.0 = GAUGE32: 44 SNMPV2-SMI::ENTERPRISES.323.5.3. 4.1.1.1.0 = INTEGER: 4021 SNMPV2-SMI::ENTERPRISES.323.5.3.4.1.1.17.0 = STR ING: "LMGRD" MIB FOR ALARM 4021 =============== LSMSAPPSNOTRUNNING NOTIFICATION-TYPE OBJECTS { EVENTNBR, PROCESSNAME, SOURCEIP, ALARMSEQUENCE } STATUS CURRENT DESCRIPTION "THIS NOTIFICATION INDICATES THAT A SPECIFIC LSMS APPLICATION OR SYSTEM DAEMON IS NOT RUNNING." ::= {TEKELECLSMSEVENTSVER 40 }
Decoding SNMPv3 Trap for alarm 4021:
OID | MIB OBJECT | Value |
---|---|---|
1.3.6.1.4.1.323. 5.3.4.2.0.217 | lsmsAlarmTrapV3 (Indicating SNMPv3 Alarm) | NO value |
1.3.6.1.4.1.323.5.3.4.1.1.51.0 | currentTime | 02/01/10 20:31:31 |
1.3.6.1.4.1.323.5.3.4.1.1.50.0 | specificOid (unique oid of lsms alarm) | 1.3.6.1.4.1.323.5.3.4.2.0.40 |
1.3.6.1.4.1.323.5.3.4.1.1.44.0 | sourceIP | 192.168.59.30 |
1.3.6.1.4.1.323.5.3.4.1.1.48.0 | alarmSequence | 44 |
1.3.6.1.4.1.323.5.3.4.1.1.1.0, 1.3.6.1.4.1.323. 5.3.4.1.1.17.0 | eventNbr,processName(variable varbinds) | 4021,lmgrd |
The LSMS SNMP agent process supports only the SNMP version 1 trap operation. The SNMP agent receives (through UDP Linux sockets) LSMS notification events from the following processes and formats these events into trap requests:
The LSMS SNMP agent formats the information received from these processes into an SNMPv1 trap protocol data unit (PDU) and sends the trap request to one or more NMSs. Each NMS (provided by the customer) has a local copy of the LSMS MIB. When the NMS receives a trap request from the LSMS, it compares the information in the trap request to information in its own MIB to determine what event has occurred at the LSMS.
For information about the format of a trap and which events are reported in traps, see Automatic Monitoring of Events
If you install the optional Remote Monitoring feature, refer to the Configuration Guide to configure the IP addresses and community names for each of the NMSs to which you want the LSMS to send trap requests. You can also perform this procedure if you want to add or delete NMSs after you have started the LSMS. The LSMS can support up to five NMSs simultaneously.
If the optional Remote Monitoring feature is installed, it is managed by the sentry process (sentryd) and can also be controlled by the user.
After the LSMS boots up, the sentry process (sentryd) constantly monitors the LSMS SNMP agent process. If the SNMP agent process exits abnormally, the sentry process (sentryd) restarts it.
Any user who belongs to the lsmsadm permission group can use the lsmsSNMP command to start, stop, or display status of the LSMS SNMP agent.