Secure Your Network
A clear market requirement for all telecom and datacom networking equipment today is support for remote manageability. This is normally provided by an SNMP agent, although other access mechanisms (e.g. command line, web browser) may also need to be supported. In addition to the industry standard management objects defined by MIB-II and other IETF standards (e.g. bridge MIB, RMON MIB), the SNMP agents typically need to support their company's private or ``enterprise'' MIB objects.
This pervasive requirement for an SNMP agent extends beyond the traditional embedded communications equipment to include the new generation of Internet ``appliances,'' which are frequently based on Linux, Solaris, or other popular operating environments. Companies who deploy these appliances want to use their standards-based network management applications to monitor and manage the processes and applications running on these systems. The agent developer needs to produce an SNMP agent that is reliable, conformant with the standards documents, and ideally field-proven to interoperate with SNMP-based management systems. They need to complete the development within a defined budget and schedule, and with minimal risk. Frequently, the agent developer is familiar with the system being designed, but is not an SNMP ``guru.''
Today, powerful tools exist to aid the agent developer. SNMP Research offers agent development toolkits which automate much of the development process. This allows the developer to focus on what they know best, which is the architecture and internals of the device being managed, and not worry too much about the intricacies of SNMP. In addition to speeding up the development and testing process, this method assures field-proven standards compliance and interoperability, and provides a source for patches and upgrades to evolve with changes to the standards documents.
The basic steps to develop an agent are:
The toolkit products come with extensive documentation and example code, and SNMP Research's exceptional support team provides assistance and consulting every step of the way. The agent developer's confidence level of completing an interoperable agent on schedule and under budget is very high.
SNMP Research's EMANATE agent development tools are designed to take the guesswork out of adding management object support to the agent. Unlike many other SDKs, EMANATE's agent development tools assume you have limited SNMP expertise, and output nearly all the source code needed for a complete extension. All that is needed is a MIB document and limited C coding to fill in the stub routines. The development process is well defined and documented, and provides the developer with step-by-step source code examples designed to address both simple and more advanced concepts.
Here is what one developer said about our development tools...
Kudos are due your developers at SNMP Research! I've used other SNMP SDKs, and read documentation for still others. They were all quite unpleasant, to be frank. I always felt that I should just have to compile the MIB, provide the MIB data (``instrumentation''), and provide some smarts for advancing table indices. But, the other packages always required me to do that and much more. Not so with Emanate: there's no rough edges, all the corners have been rounded off. It was so pleasant, that not only was I able to focus on my instrumentation, but I also felt encouraged to flesh out the MIBs (RFC 2248 and 2249), providing instrumentation for some of the more esoteric variables which I otherwise would not have done (and did not do in the past when using other SDKs).
Thanks! - Dan Newman, Senior Software Engineer, Sun Microsystems, Inc.
Because the EMANATE APIs are isolated from the system dependent layer of the agent code, a developer can reuse the same code to implement agents on multiple operating systems or new underlying chipsets. This means that agent code may be reused for future versions of the managed device. For example, a storage appliance based on Solaris may be re-implemented on the Linux/Intel architecture. The agent code simply needs to be recompiled for the new target system.
EMANATE tools maximize the developer's productivity and reduce the total development investment in the agent project. Agent SDKs which appear to be "free" at first glance begin to cost expensive engineering time and money when developers have to turn the code into something useful with limited documentation and support. Sorting through multiple public domain tools, downloads, and ``not quite ready'' sample code can be a confusing mess, and the agent developer does not have a clear and well-defined process for going from MIB document to tested agent. EMANATE and the SNMP Research support team provide the complete package and guidance for every step of the process.
EMANATE has the power to support a hot-swappable chassis in which application cards are optional and may be plugged into the system in various combinations. Some application cards may not be fabricated or even designed before the `motherboard' unit is shipped to customers. The agent is run-time extensible. EMANATE/Lite is very compact and ideal for a single-board computer with a small memory budget. All application-level information must be known when the unit is produced. The agent is compile-time extensible.
The EMANATE (Enhanced MANagement Agent Through Extensions) run-time extensible agent system was developed by SNMP Research under the direction of Dr. Jeffrey D. Case. Dr. Case is the co-author of the SNMPv1, SNMPv2c, and SNMPv3 standards documents and has been an influential pioneer in standards-based management since the late 1980s.
EMANATE agents are constructed in a modular, hierarchical manner and consist of a Master Agent and zero-to-many subagents which support various MIB objects. The subagents are permitted to connect and disconnect to the Master Agent at will, at which time their MIB objects are added and removed dynamically from the Master Agent. Examples of EMANATE subagents might be the MIB-II Subagent, the RMON Subagent, the Host MIB Subagent, and the FDDI Subagent.
The Master Agent and subagents communicate over an asynchronous message passing interface which is optimized for a particular architecture. Furthermore, EMANATE places no restrictions on the order in which the Master Agent and subagents may be started. EMANATE provides an easy-to-use system independent API which developers can use for implementing support for their MIB objects in an EMANATE subagent. This system independent API hides the details of the particular system on which the subagent is being developed and permits much subagent code reuse across different architectures. Furthermore, the API provides a well-defined interface to the system dependent portion of the subagent code. EMANATE was designed to address the problem of multiple SNMP agents on a single platform via a modularly constructed extensible agent. In particular, this architecture is designed to meet the needs of:
EMANATE was designed to allow multiple subagents to support the same MIB objects. That is, two subagents can support different rows of a table (e.g. the interfaces table). This is helpful for modular systems where subagents are associated with specific plug-in devices.
The EMANATE Master Agent, which is SNMP protocol dependent but MIB independent, functions as the core of the SNMP agent. MIB independence means that the Master Agent does not need to contain MIB-specific knowledge of the objects that the agent supports. The Master Agent contains the agent protocol engine for SNMPv1, SNMPv2c, and SNMPv3, and is in charge of the authentication, authorization, access control, and privacy mechanisms. It is multithreaded in that each SNMP request is handled by a different thread. This means that agent operation is asynchronous. The Master Agent receives the request, initiates the thread which will have control of that request, and can then process further requests. In summary, the Master Agent does the ``difficult'' work specific to SNMP encoding, decoding, and packet processing.
The Master Agent architecture includes both system dependent and system independent portions. The system dependent portion includes network packet initialization and routines for sending and receiving SNMP requests. Furthermore, the Master Agent end of the asynchronous message passing interface is system dependent, as are the multi-threading support and non-volatile storage access routines.
Processing of get-next and get-bulk requests, multi-phase set processing, registration, deregistration and lookup of subagents, and subagent management are entirely system independent, as is most of the trap handling. In most cases of subagent development, the subagent developer need not work with the Master
Agent but rather will concentrate entirely upon development of the subagent. This means, for example, that application management developers need know very little about SNMP specifics but can instead concentrate on that which they know best-their system or application and how it should be managed.
EMANATE subagents, in contrast to the Master Agent, are protocol independent (they make no assumptions about whether SNMPv1, SNMPv2c, or SNMPv3 is used) and MIB dependent. Because the Master Agent is responsible for the ``difficult'' tasks means that subagents are relatively simple and easy to implement and test. Subagents, which are built with the Subagent Development Kit (SADK), are modular and are again divided into system dependent and system independent portions. The subagents consist primarily of method routines conforming to the system independent API. Subagents are essentially small programs which provide access to method routines. The typical subagent simply runs in a loop, and awaits requests from the Master Agent whereupon it gathers the information requested and returns the response. This is an oversimplification; the subagent may do more than simply respond to messages, such as sending traps.
Method routines are the functions which actually collect the information specified in the MIB document. That is, the counters, gauges, etc. that are specified in the MIB document must be instrumented within the system or application. This instrumentation must in turn be accessed, and this occurs in the method routines.
The method routines are divided into a system independent part and a system dependent part. Most, and usually all, of the system independent method routines are generated automatically by the EMANATE MIB tools, and stubs are generated for the system dependent method routines (examples are given below). All of the C data structures and function prototypes necessary for the subagent are also generated by these same tools. Of course, code specific to the system or application being managed is not generated.
Much of the subagent code can be reused in multiple EMANATE environments. That is, if you have developed a subagent for one architecture, then you will be able to reuse all of the system independent code on a different architecture since the API is exactly the same. System dependent code and dependencies which the developer introduces into the subagent will have to be ported. Additionally, since the APIs and development methodology are the same as that used in other EMANATE family products, the code developed for subagents can easily be integrated into a monolithic SNMP agent (and vice versa). Subagent development using the Subagent Development Kit is a five step process, which is explained in detail below.
EMANATE/Lite is used to develop a monolithic SNMP agent for an embedded system. The agent is extended at compile-time, which means that in order to add new MIB variables to the agent, it is necessary to have access to the source code and to compile and link in the new extensions to the MIB already supported by the agent.
EMANATE/Lite provides the core SNMP protocol engine that should be installed within each SNMP managed element or device. It receives and responds to SNMP queries and commands issued from SNMP management stations. It provides access to management information for each of the managed protocol layers within the network element.
EMANATE/Lite can be compiled to support SNMPv1, SNMPv2c, and/or SNMPv3. This trilingual option preserves the investment in current management technology while providing a smooth transition to secure SNMPv3-based management.
EMANATE/Lite features include:
It is likely that those who purchase an SNMP agent intend to add support for their own MIB objects to the agent. This section outlines the procedure to add additional MIB objects using the EMANATE tools.
SNMP Research recommends that developers use standard MIB documents whenever possible. This will save a great deal of time. Otherwise, write the MIB document in SMIv2 format (RFC2578, RFC2579, RFC2580). The SMIv2 MIB document can be converted with a program called mosy into the SMIv1 Concise MIB format (RFC1212) if necessary (using the -1 argument).
Before proceeding to the next step, verify that the MIB document is syntactically and semantically correct. The mosy program will be helpful during the debugging phase.
The specific instructions for Step 2 vary slightly between the EMANATE and EMANATE/Lite products, but the general procedure is as follows:
MIB objects can only report information which has been gathered by an application, and the agent extension must have access to the information which has been gathered. For example, it is impossible for an agent to support the TCP family of objects if the operating system kernel does not collect the appropriate TCP statistics. If the kernel gathers the necessary information, it must also be available to the agent's MIB structures.
It is possible that the developer might need to add instrumentation to support the new MIB objects. In the case of the TCP group, one might have to add counters or gauges to the kernel. This instrumentation will then be accessed by the agent's method routines.
If the application already collects the information modeled in the MIB document, or if the developer is replacing or augmenting a proprietary protocol with SNMP, then this step is greatly simplified and may even be bypassed entirely.
The EMANATE code generation tool called postmosy automatically generates a set of method routine stubs from the MIB document. The method routines are those functions which access the instrumentation.
There are two parts to a method routine: the system independent function and the system
dependent function. In most cases, the system independent method routines do not have to be
modified by the agent developer. They provide a uniform interface to the system dependent
functions, which they call. The system dependent method routines, found in a file called
k_<base>.stb, localize that part of the code which can vary from architecture to
architecture. It is the system dependent method routines which must be altered.
As an example, consider the following stub routine:
thermometer_t *
k_thermometer_get(serialNum, contextInfo, nominator)
int serialNum;
ContextInfo *contextInfo;
int nominator;
{
#ifdef NOT_YET
static thermometer_t thermometerData;
/*
* put your code to retrieve the information here
*/
thermometerData.thrmTemperature = ;
thermometerData.thrmUnits = ;
SET_ALL_VALID(thermometerData.valid);
return(&thermometerData);
#else /* NOT_YET */
return(NULL);
#endif /* NOT_YET */
}
This stub was generated from an example MIB document with a family of scalar objects called thrmTemperature and thrmUnits. The lines
thermometerData.thrmTemperature = ; thermometerData.thrmUnits = ;
are of course not compilable, but they make it very clear what needs to be done. The developer must know:
The system dependent method routine is where this information must be filled in. The completed function might look like this:
thermometer_t *
k_thermometer_get(serialNum, contextInfo, nominator)
int serialNum;
ContextInfo *contextInfo;
int nominator;
{
static thermometer_t thermometerData;
thermometerData.thrmTemperature = check_thermometer();
thermometerData.thrmUnits = get_thermometer_units();
SET_ALL_VALID(thermometerData.valid);
return(&thermometerData);
}
After creating the instrumentation, completing the method routines, and building the subagent(s), the developer will need to test the completed agent subsystem. Note that the hardest part of this step may be ensuring that the instrumentation is collecting and furnishing the correct data.
SNMP Research's Web Site:
SNMP Research Incorporated
3001 Kimberlin Heights Rd.
Knoxville, TN 37920
U.S.A.
Tel: +1 865 573 1434
Fax: +1 865 579 6565
E-mail: info@snmp.com
www.snmp.com