Quicklinks
The ActiveSocket SNMP COM/OLE object defines a programming interface for network management applications running under the Microsoft Windows family of GUI/operating system products, enabling those applications to make use of a logically external SNMP engine or service layer.
For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The new framework that is currently a proposed Internet standard, as described in RFCs 1441, 1442, 1443, 1444, 1445, 1446, 1447, 1448, 1449, 1450, 1451, and 1452, is termed the SNMP version 2 framework (SNMPv2). In addition, there are three proposed Internet standards, as described in RFCs 1418, 1419, and 1420, that address the use of transports other than UDP over IP for SNMPv1. These RFCs describe SNMPv1 over OSI, AppleTalk, and IPX. Note that these transports are directly addressed in SNMPv2 by RFC 1449.
The purpose of ActiveSocket SNMP is to promote the development of SNMP-based network management applications running under the Microsoft Windows family of GUI/operating system products. ActiveSocket provides a single interface to which application developers can program and multiple SNMP software vendors can conform. This specification thus defines the procedure calls, data types, data structures, and associated semantics to which an application developer can program and which an SNMP software vendor can implement.
SNMP is a request-response protocol used to transfer management information between entities acting in a manager role and entities acting in an agent role. Managers are often configured as management stations and agents are often configured as managed nodes. A manager can also act as an agent to another manager in both vertical (hierarchical) and horizontal (distributed) relationships. Likewise, a physical node might be managed by multiple agents, and an agent might manage multiple physical nodes. When hereinafter we use the prototypical management station/managed node perspective for the sake of simplicity and clarity of presentation, that practice is not meant to preclude other forms of SNMP interactions.
Each managed device or application contains monitoring and (possibly) control instrumentation. This instrumentation is accessed by the agent. The agent represents its access to this instrumentation to the manager via a MIB, filtered by the SNMP security mechanisms. Management applications communicate with agents via SNMP to monitor and (possibly) control managed devices or applications.
A management application may issue several requests to an agent, before waiting for a response. Alternately, it may issue a request and wait for a response, operating in a lock-step fashion with the agent. Furthermore, SNMP may be implemented on a wide range of transport protocols, each with varying delivery mechanisms and reliability characteristics. The normal transmission mechanism (UDP) is through non-guaranteed messages which may be dropped, duplicated, or re-ordered. Thus, with SNMP, it is the responsibility of each management application to determine and implement the desired level of reliability for its communications. This means that the management application decides on its own re-transmission and timeout strategy.
Each device on the network has its own Management Information Base (MIB), which contains details of device-specific functionality. The MIB resides in the firmware of the device but must also be mirrored in the host management system, by importing a corresponding database file into the overall network management database. For instance, the printer MIB was developed by printer manufacturers working together. Any printer with the printer MIB resident in its firmware can therefore managed by any network management software which employs SNMP. SNMP is the command set that makes communication with the MIB possible. SNMP itself is transported across the network in traditional packets using standard network protocols.
Many organisations are now moving towards an "open systems" environment. SNMP is independent of operating system or hardware type and effectively bridges the gaps between them, to provide enhanced compatibility.
An SNMP trap is simply a notification message that is transmitted by an SNMP-managed device whenever it has something of interest to report. Traps can be thought of as event messages, similar to the events in the Windows event logs. Traps, like regular SNMP variables, are defined in MIB (Management Information Base) files. They are defined as a set of SNMP variables contained in (or referenced by) an OID (Object Identifier). If you look at the system directory on any Windows machine that has SNMP installed, you will find several MIB files. (They have the extension ".mib".) If you look through them you will see the variables that are supported on that machine.
SNMP traps are the primary means of receiving notification of abnormal (or normal) events from SNMP-enabled devices. This makes receiving and interpreting the traps trap monitoring essential to the proper management of a network. Usually, traps are sent to a management system running software capable of receiving the traps, interpreting them, and displaying notification messages in a graphical display. The people at the management center viewing the display are then alerted to the problem. Most management software also has the capability to send alerts to e-mail accounts or pagers.
ActiveSocket applications have the capability of instructing the implementation to interpret entity and context arguments as either literal SNMPv1 agent address and community string, respectively, or as literal SNMPv2 party and context IDs, respectively. The preferred alternative to either of these modes is that in which these arguments are interpreted as user-friendly names for entities and managed object collections to be dereferenced ("translated") into their respective SNMPv1 or SNMPv2 components via the implementation's local database.
The three entity/context translation modes are:
When the translation mode is set to asASN_USETRANSLATEDTRANSPORTMODE, an application will make calls similar to the following:
snmpObj.Open "Accounting_Hub", "Traffic_Stats"
The implementation will use its selected access method to look-up "Accounting_Hub" and "Traffic_Stats" in its local database and, if successful, will assemble the appropriate internal data structures to open a sesson to the (remote) device.
When the translation mode is set to asASN_USESNMP1TRANSPORTMODE, an application will make calls similar to the following:
snmpObj.Open "192.168.0.200", "public"
The implementation will assume - based on the asASN_USESNMPV1TRANSPORTMODE setting - that "192.151.207.34" equates to an IP address to be reached via UDP port 161.
When the translation mode is set to SNMPAPI_UNTRANSLATED_V2, an application will make calls similar to the following:
snmpObj.Open "192.168.0.200", "public"
The first string is an initialPartyID with an agent from 134.141.40.162; the second string is an intialContextID with the same agent.
The implementation will assume--based on the SNMPAPI_UNTRANSLATED_V2 setting for hSomeSession - that
"1.3.6.1.6.3.3.1.3.134.141.40.162.1" equates to an a PartyID instance at IP address 134.141.40.162 to be reached via UDP port 161.
The following table of abbreviations and definitions presents terms frequently used in the SNMP RFCs and related literature along with the official, customary, or consensual meaning(s). An editing objective of this specification is to use none of these terms in any sense other than that shown in the corresponding definition, nor to invent or employ new terms with meanings functionally equivalent to those of these established terms.
| Short | Term | Definition |
|---|---|---|
| Access Control | Restriction of access to MIB objects either in scope or function or both, on the basis of party. | |
| ACL | Access Control List | An indication of what actions (aclPrivileges) may be performed by a given party (aclTarget) on behalf of another party (aclSubject) within a given context (aclResources). |
| API | Application Programming Interface | A defined set of procedure calls, data types, data structures, and associated semantics used to incorporate a logically external service layer into an application program. |
| Authentication | Verification of message source and timeliness. Achieved in SNMPv2 normally by message component transformation via secret codes. | |
| Authorization | Defining and controlling the levels of legitimate access to data and/or resources. Achieved in SNMPv2 with the use of ACLs, and in SNMPv1 with the use of Community strings. | |
| Bilingual Entity | A protocol entity that can handle both SNMPv1 and SNMPv2 operations, semantics, and communications. | |
| Community | An administrative relationship between SNMPv1 entities; identified by a "community string". | |
| CTX | Context | A collection of managed object resources accessible by an SNMP entity. |
| Dual-Role Entity | ||
| Entity | Protocol Entity | An SNMP-conversant process, operating in either and agent role or in a manager role, or both, which performs network management operations by generating and/or responding to SNMP protocol messages. |
| GUI | Graphical User Interface | A visually rich user interface (as contrasted with a Command Line Interface [CLI]). |
| Local Database | An entity-specific collection of information about parties, contexts, views, and access control policies. | |
| M2M | Manager-to-Manager MIB | Used to define conditions and thresholds at a manager that will trigger notifications to other managers. |
| MIB | Management Information Base | A virtual information store holding a collection of managed object definitions. |
| View | MIB View | A subset of the universal set of all instances of all MIB objects; defined as a collection of view subtrees. |
| Mid-Level Manager | A dual-role protocol entity acting primarily in a manager role except when acting in an agent role vis-à-vis other managers. | |
| smiOID | Object Identifier | A data type denoting an authoritatively named object; a sequence of non-negative integers. |
| Party | A conceptual, virtual execution environment who operation is restricted to an administratively defined subset of all possible operations of a particular entity. A set of specific security characteristics. | |
| Party MIB | Used to configure parties at protocol entities with various security characteristics, including use or non-use of authentication and/or privacy and access control constraints. | |
| Privacy | Protection of transmitted data from eavesdropping. Achieved in SNMPv2 normally by message component encryption. | |
| PDU | Protocol Data Unit | A data structure containing SNMP message components and used for communication between SNMP entities. |
| Proxy | Proxy Agent | |
| RFC | Request for Comments | The document series describing the Internet suite of protocols and related experiments. |
| SNMP | Simple Network Management Protocol | The application protocol offering network management service in the Internet suite of protocols. Abbreviation used for both SNMPv1 and SNMPv2. |
| variable | SNMP variable | An object's identity and its instance value encoded as an smiOID. |
| varbind | Variable-Binding | A pairing of an object instance name and an associated value or pseudo-value and syntax. |
| varbindlist | Variable-Bindings List | A grouping of one or more variable-bindings |
Click here for online SNMP samples for various development and scripting platforms, including VBScript, Visual Basic, Visual C++, ASP, ASP .NET, Visual Basic .NET and Visual C# .NET.