SNMP Research International, Inc.

Secure Your Network

EMANATE® Product Details

Additional Information

EMANATE® FAQ

This page contains the answers to the frequently asked questions about EMANATE®. The information provided in this document is intended for both engineers and managers. If anything is unclear, or if additional questions arise, SNMP Research invites the reader to 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), and the tables associated with SNMPv2c 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?
Of course, EMANATE imposes a small overhead for the Master Agent/Subagent communication. The performance is not affected dramatically. The round-trip time for sending an SNMP request between two workstations on SNMP Research's network is between 6 and 12 ms. As disk access time is typically in this range as well, this is not considered problematic.
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. If you have none of the above, you will need to obtain the source code to EMANATE® and do one of the following:
  1. Recreate the functionality present in AgentSocketRead() and AgentSocketWrite(), and make the file descriptors returned by these functions work correctly with the select() system call.
  2. Recreate the functionality present in AgentSocketRead() and AgentSocketWrite(), and rewrite the SendSubagentEvent() and GetSubagentEvent() functions (part of the core event management code in the master agent and in the subagent libraries) without using select().
  3. Arrange for a direct function call in shared address space.
How do traps work?
The subagent sends a trap event to the EMANATE® Master Agent, which generates the SNMP Trap.
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.
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.