Understanding the SNMP Agent Process

Overview of SNMP Protocols

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:

• Respond to requests from the NMS for information and/or action. The SNMP architecture defines a limited set of management commands and responses. The NMS can issue Get, GetNext, and Set messages to retrieve single or multiple object variables or to modify the value of a single variable. The SNMP agent sends a response message to complete the Get, GetNext, or Set. This release of the LSMS does not support these functions.
• Send event notifications, called trap requests, to the NMS to identify the occurrence of conditions, such as the failure or restoration of a link interface.

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.

MIB Structure

MIB Structure

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:

1. sourceIP
2. alarmSequence

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:

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:

The LSMS SNMP Agent Implementation

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 Surveillance process, which continually monitors the LSMS hardware and software.
• The LSMS graphical user interface (GUI) process.
• One or more regional agent (npacagent) processes, each of which receives commands from Number Portability Administration Centers (NPACs) and the GUI process, interprets those commands, and initiates appropriate LSMS activities to manage regional NPAC data. The LSMS can support up to eight regions; each region corresponds to an NPAC.
• One or more eagleagent processes, each of which receives commands from the GUI process, interprets those commands, and initiates appropriate LSMS activities to send data to the network elements. The LSMS can support up to eight pairs of network elements.
• The Local Data Manager (supman) process, which manages locally provisioned data that is entered through the GUI and sent to the network elements which the LSMS supports.

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

Configuring the SNMP Agent

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.

Controlling the SNMP Agent

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.