SNMP Research International, Inc.

Secure Your Network

For More Information

EMANATE® Product Details

EMANATE® FAQ

This page contains the answers to the frequently asked questions about SNMP Research's SNMP Agent software, named EMANATE®. If you have questions about this FAQ, please send comments or questions to info@snmp.com.

Open All Close All
What does EMANATE stand for?
EMANATE stands for "Enhanced MANagement Agent Through Extensions".
What is the EMANATE Master Agent/Subagent architecture?
The EMANATE Master Agent provides the core agent services including the agent protocol engine, authentication, authorization, privacy, and access control, plus support for some MIB objects, including the system and SNMP groups of MIB-II (RFC 1213, RFC 2863, RFC 3418, RFC 4001, RFC 4022, RFC 4113, RFC 4292, RFC 4293, and RFC 4898), and the tables associated with SNMPv3 (RFC 3410-3418, RFC 3584) security. Other MIB-II groups are supported by a subagent devoted to that purpose. Similarly, other subagents can be used to instrument other systems and subsystems on the host platform, such as RMON (RFC 1757), Host Resources (RFC 1514 and RFC 2790), client-server applications, and other hardware and software components.
What is meant by "asynchronous" in the context of EMANATE?
In the monolithic agent environment, each incoming SNMP request must be processed to completion prior to accepting a new request.
EMANATE deals with this differently. Each new request starts a new "thread" or "task". This "thread" then processes the request, allowing the agent to accept further requests.
Note that EMANATE is asynchronous on a per-message basis and not on a per-VarBind basis. That is, all the VarBinds in a message will be handled by the same "thread".
What do you mean by "run-time extensible"?
In a monolithic agent environment, adding new MIB objects into the agent requires that the agent be linked with new object files which implement the new MIB objects.
EMANATE uses a different architecture entirely. Rather than a single agent, EMANATE uses the Master Agent/Subagent paradigm. That is, there is a single master agent and (potentially) many subagents, each of which is responsible for some part of the agent's MIB. These subagents can connect and disconnect from the master agent at will, at which time their portion of the MIB is added or deleted from the master agent's "MIB tree". Thus, portions of the MIB tree are added and deleted while the master agent is running.
If EMANATE is made up of a master agent and (potentially) many subagents, does that mean that the manager station needs to know about all of them?
No. To the manager of the EMANATE system, it simply appears to be a single agent. Of course, the manager must be in tune with the sorts of MIB objects with which it is dealing and must accept their dynamic nature.
Does a subagent register instances of objects?
Yes. Subagents can register instances of objects in addition to registering entire classes of objects. The subagent can assign a priority to its version of an object class or object instance as opposed to the versions owned by other subagents.
Can a subagent register MIB subtrees?
Yes. Subagents can register subtrees of objects in addition to registering individual objects. The master agent correctly handles situations where object database entries for multiple subtrees and/or individually registered objects overlap one another.
Can different rows of a table be in different subagents?
Absolutely. In fact, this was one of the primary design goals of the EMANATE system.
When a subagent connects to the EMANATE Master Agent, it sends its portion of the MIB tree to the master agent. If the master agent encounters duplicate object database entries, it maintains a priority-ordered list of the subagents which support that object. This allows multiple subagents to support the same objects and hence different rows of the same table.
How does the mechanism for assigning a priority to a subagent's copy of an object database entry?
In the ObjectInfo structure for that object, which is passed to the master agent when the subagent connects, there is a priority field. If two subagents have the same MIB database entry with the same priority, then later registrations "hide" previous registrations.
How does EMANATE deal with Gets, GetNexts, and Sets when different rows of a table are in different subagents?
This depends very much on what sort of message it is:
  • Keep in mind that for each MIB object for which there are multiple subagents, the master agent has a priority-sorted list of subagents which have that object.
  • When a Get request arrives at the master agent, each subagent which has a matching object database entry is asked (in order of priority), "Do you have this instance?" The value returned by the first subagent that responds affirmatively is returned in the response.
  • When a GetNext request arrives at the master agent, all subagents which have that object are asked, "What is the next instance you have after this OID?" When all responses from subagents have arrived, the lexicographically smallest object is returned.
  • If a Set request arrives at the master agent, it calls the test methods for each subagent which has that object, and the first subagent that returns a non-fatal error status "wins". Again, they are checked in priority order.
What is the arbitration mechanism for finding out what index a subagent should use for a row in one of its tables?
In some circumstances, it may make sense for an application-specific mechanism to be used for determining the instance.
When the instance of a MIB object must be unique but is arbitrary, or for other circumstances when an application-specific mechanism is not used, EMANATE provides an "instance reservation" mechanism. The instance reservation mechanism is described by a MIB, and the MIB is implemented in a subagent. Subagents cooperate by consulting the Instance Reservation Subagent before registering to support instances.
Is there a way to tell if the master agent/subagent is alive?
Yes. If the master agent or a subagent dies, an appropriate event will be generated to let the other party know of this.
Can a subagent request information from a different subagent?
Yes, by going through the master agent. It works in a way very similar to a Get request.
Is there a performance hit from using EMANATE as opposed to a monolithic agent?
EMANATE improves performance, especially on systems with multiple core processors. The Master Agent/Subagent communication may impose a small overhead on single-processor systems but performance is not affected dramatically. Other factors also affect performance, such as disk access time and whether or not SSL is used. Using SSL between the Master Agent and Subagents requires additional resources. Use SSL only when necessary.
What sorts of IPC mechanisms are currently implemented and how do we customize it for our environment?
The most commonly used IPC mechanisms are UNIX Domain Sockets, TCP, and Shared Libraries. SSL is also supported.
How do traps work?
The subagent sends a notification event to the EMANATE® Master Agent, which generates zero, one, or many SNMP Trap messages plus zero, one, or many SNMP Inform messages, depending on the configuration of the Master Agent.
What are the steps in creating a subagent?
The five steps are:
  1. Define the MIB.
  2. Compile the MIB with the SNMP Research, Inc. MIB tools and create the runnable subagent, all by typing 'make'.
  3. Create the instrumentation (create the counters, collect the information as defined in the MIB, etc.)
  4. Complete the method routines. Skeletons are created by the MIB Tools, but you must write the code which reads the counters, accesses the information in the kernel, etc.
  5. Test.
SNMP Research's MIBGuide™ MIBGuide/Lite: a more intuitive, GUI-based MIB tool set for developers which provides the 5-step method in the form of a computer program.
Do you have to have threads to run EMANATE®?
Yes. However, SNMP Research does provide threads packages for some platforms which could be ported to other platforms if required. Native threads packages included with operating systems are preferred.
What is the 'System Dependent API' and of what does it consist?
The system dependent part of the API is just that--the part of the code which performs the IPC in a system-dependent way. The subagent developer should not have to worry about this.
What is the "System Independent API" and of what does it consist?
This is the part of the API that the subagent developer will use. It is an interface to the system dependent API. The API is the same no matter what (internal) mechanism is being used to communicate with the master agent. Much of this code is generated by the SNMP Research MIB Tools.
Can I move extensions from the SNMP Research monolithic agent to an EMANATE Subagent?
Yes. The API that is used by EMANATE is a superset of the API that is used in the monolithic (compile-time extensible) agent.
Can I move method routines from an EMANATE Subagent to the SNMP Research monolithic agent?
Yes. As noted above, the API that is used by EMANATE is the same. Of course, if EMANATE-specific routines are used by the method routines, these will have to be eliminated to integrate the method routines into the monolithic agent.
How do Sets (write operations) work?
There are five passes involved when processing a Set request:
  1. Each variable in the variable binding list of the received PDU is checked to guarantee that each object is accessible and/or creatable, and writable. The test method for each object is called to verify the object's instance, size/range, and value. If an object is supported in more than one subagent, the master agent calls the Test method routine in each subagent in priority order, and the first to return a successful status will receive the Set method call in Pass 3 or 4. The variable binding list is parsed to construct a list of simultaneous Set operations for groups of objects.
  2. This pass verifies that all required objects within a group have specified or default values. It also insures that all required values meet the relational constraints specified in the MIB.
  3. Sets are performed on all of the individual objects that can be reversed in case something goes wrong.
  4. Sets are performed on all the remaining individual objects.
  5. The resources used to accomplish steps 1-4 are freed.
Can I access MIB instrumentation from a Web browser?
Yes. An optional feature called DR-Web™ allows the EMANATE Master Agent to receive HTTP requests from Web browsers. Special URLs tell the master agent which MIB values to retrieve, and the master agent obtains these values in the "usual" way. An HTML page to display in the Web browser is generated "on the fly" as MIB values are supplied by the subagents.
The DR-Web enhancements to EMANATE include a subagent which serves a database for custom Web pages. Custom pages may contain graphics, figures, hyperlinks, java scripts, and any other valid HTML text. Special tags allow custom pages to supply the current values of MIB objects.
Can I access MIB instrumentation from a CLI?
Yes. An optional feature called EPIC™ CLI allows the EMANATE Master Agent to receive SNMP requests from Web browsers. Special URLs tell the master agent which MIB values to retrieve, and the master agent obtains these values in the "usual" way. An HTML page to display in the Web browser is generated "on the fly" as MIB values are supplied by the subagents.
The DR-Web enhancements to EMANATE include a subagent which serves a database for custom Web pages. Custom pages may contain graphics, figures, hyperlinks, java scripts, and any other valid HTML text. Special tags allow custom pages to supply the current values of MIB objects.