You are here:

ActiveXperts.com > ActiveSocket > Tools > SNMP

ActiveSocket Toolkit Add network capabilities to any Windows or .NET application

Quicklinks


ActiveXperts SNMP backgrounds (SNMP is part of the ActiveSocket Toolkit)

Introduction

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

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.

SNMP Traps

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.

Entity/Context Translation Modes

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:

  • asASN_USETRANSLATEDTRANSPORTMODE - Translate via Local Database look-up;
  • asASN_USESNMPV1TRANSPORTMODE = Literal transport address and community string;
  • asASN_USESNMPV2TRANSPORTMODE = Literal SNMPv2 party and context IDs;

asASN_USETRANSLATEDTRANSPORTMODE

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.

asASN_USESNMPV1TRANSPORTMODE

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.

asASN_USESNMPV2TRANSPORTMODE

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.

Glossary: Abbreviations, Acronyms, and Definitions

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 ControlRestriction of access to MIB objects either in scope or function or both, on the basis of party.
ACLAccess Control ListAn indication of what actions (aclPrivileges) may be performed by a given party (aclTarget) on behalf of another party (aclSubject) within a given context (aclResources).
APIApplication Programming InterfaceA defined set of procedure calls, data types, data structures, and associated semantics used to incorporate a logically external service layer into an application program.
AuthenticationVerification of message source and timeliness. Achieved in SNMPv2 normally by message component transformation via secret codes.
AuthorizationDefining 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 EntityA protocol entity that can handle both SNMPv1 and SNMPv2 operations, semantics, and communications.
CommunityAn administrative relationship between SNMPv1 entities; identified by a "community string".
CTXContextA collection of managed object resources accessible by an SNMP entity.
Dual-Role Entity
EntityProtocol EntityAn 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.
GUIGraphical User InterfaceA visually rich user interface (as contrasted with a Command Line Interface [CLI]).
Local DatabaseAn entity-specific collection of information about parties, contexts, views, and access control policies.
M2MManager-to-Manager MIBUsed to define conditions and thresholds at a manager that will trigger notifications to other managers.
MIBManagement Information BaseA virtual information store holding a collection of managed object definitions.
ViewMIB ViewA subset of the universal set of all instances of all MIB objects; defined as a collection of view subtrees.
Mid-Level ManagerA dual-role protocol entity acting primarily in a manager role except when acting in an agent role vis-à-vis other managers.
smiOIDObject IdentifierA data type denoting an authoritatively named object; a sequence of non-negative integers.
PartyA 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 MIBUsed to configure parties at protocol entities with various security characteristics, including use or non-use of authentication and/or privacy and access control constraints.
PrivacyProtection of transmitted data from eavesdropping. Achieved in SNMPv2 normally by message component encryption.
PDUProtocol Data UnitA data structure containing SNMP message components and used for communication between SNMP entities.
ProxyProxy Agent
RFCRequest for CommentsThe document series describing the Internet suite of protocols and related experiments.
SNMPSimple Network Management ProtocolThe application protocol offering network management service in the Internet suite of protocols. Abbreviation used for both SNMPv1 and SNMPv2.
variableSNMP variableAn object's identity and its instance value encoded as an smiOID.
varbindVariable-BindingA pairing of an object instance name and an associated value or pseudo-value and syntax.
varbindlistVariable-Bindings ListA grouping of one or more variable-bindings

Online ActiveSocket/PING samples

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.