Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Standards
Standards are specifications for implementing a particular network management function. By adhering to standards, different vendor implementations are guaranteed to interoperate. The following sections detail SNMP framework (also known as the Internet standard management framework).
Simple Network Management Protocol
The SNMP framework was developed for IP-based networks in the late 1980s (for additional details see the "Related Information" section), and is the dominant framework in the computing industry for the management of these devices. The SNMP management framework has undergone three major revisions, with the latest being SNMP V3.
The initial release of SNMP had several weaknesses:
Access control such as, Community Strings, were transmitted in clear text
Transfer of table data required multiple small operations
Limited trap types
The "Urgent trap message" was the only command the agent could initiate
These limitations were addressed in SNMP V2, which is currently the dominant protocol in the industry and the version detailed in this article.
FIGURE 3 illustrates an overview of the SNMP V2 framework. The "manager" communicates with various managed devices, which are running an SNMP agent. The SNMP framework consists of four major components:
Managed devices hosting an embedded SNMP agent.
Management server communicating with the managed devices and providing services to management applications.
Management protocol utilizing the SNMP protocol for exchanging messages between the manager and agents by encoding management information in BER.
Management Information model defining all managed resources in a pseudo object-oriented manner—a manner where all objects are stored virtually in a MIB.
)
FIGURE
3 SNMP V2 Framework
SNMP Operations
FIGURE 3 also illustrates the following SNMP V2 operations.
Get-Request (or read) obtains information from the agent about an attribute of a managed object.
GetNext does the same thing as the Get-Request operation for the next object in the tree of objects on the managed device.
Set (or write) sets the value of an attribute of a managed object.
TRAP tells the manager about some event on the managed device.
Get-Bulk-Request gets large amounts of data in one single operation, for example all the data in a large table. A new feature in SNMP V2.
Inform-Request allows a manager to communicate management information to another manager.
Response returns by the agent in response to a Get-Request, GetNextRequest, GetBulkRequest, SetRequest, or InformRequest protocol data unit (PDU).
Management Information Base
The MIB contains a description of the object hierarchy on the managed device, the name (called Object ID), syntax, and access privileges for each variable in the MIB. For example, when the MIB module is loaded in a MIB browser, the label of the variable, for example sysDescr, can be used to identify it, because the MIB browser uses MIB module to translate this label to an Object ID.
Specifying SNMP Variables in GetRequests
To specify an object to an SNMP agent, both the Object Name or ID (which defines the type of object) and the instance (the specific object of the given type) need to be provided. From the MIB, you get the Object ID, to which an instance needs to be added. For non tabular (or scalar) objects, this is simply an instance of 0 (for example, sysDescr.0). For tabular objects, the instance is defined by the MIB and is a sequence of one or more variables (for example, interfaces.ifTable.ifEntry.ifIndex.1 = 1)
In order to get and set SNMP variables, you need to specify the Object ID plus the instance. You can also use GetNext, and specify just the Object ID from the MIB (for example, sysDescr), and get the first instance of that type from the SNMP agent. This method works for all types of objects.
When using the MIB browser, select the MIB node that you need, and either select GetNext or add the instance you need at the end of the Object ID and use the Get command.
Web-based Enterprise Management/Common Information Model
The standard Web-based Enterprise Management (WBEM) was originally a consortium of several manufacturers that wanted to develop an open platform and protocol-neutral Web-based network management architecture. The original goals were to create a set of standards that allowed Web browser-based applications to share management information from any vendor. This application originally required Web-based technologies and an HTTP-based management protocol. Over the years, the consortium developed a highly successful standard information model, called the Common Information Model (CIM). The CIM allows any vendor to extend their vendor-specific resources from a common set of superclasses. The CIM is composed of the following components:
MetaSchema is the object model.
Managed Object Format (MOF) is the standard textual syntax for specifying the description of managed resources.
Extensible Markup Language (XML) is the standard language that replaced the original Hypermedia Management Protocol (HMMP), which was developed by Distributed Management Task Force (DMTF).
MetaSchema is partitioned into the following object (class) hierarchies:
Core Model—A set of classes that are common to all management systems. This includes objects such as Managed System Element, Physical Element, Logical Element, System, and Service.
Common Model—A set of classes that subclass from the core model and are related to one vertical segment, such as Physical, Systems, Devices, Applications, and Networks.
Extensions Model—A set of vendor-specific classes that extend from the common model classes.
The DMTF developed a MetaSchema mapping from the CIM MetaSchema to an XML MetaSchema, which is now used in the management protocol.
FIGURE 4 presents an overview of the WBEM/CIM architecture.
)
FIGURE
4 WBEM/CIM Architecture
The management applications access the services of the CIM object manager, which accepts requests for creating namespaces, manipulating objects, retrieving/storing management information into the CIM persistent store. If the CIM object manager is unable to service a request, that request is forwarded to the CIM object provider. The CIM object provider translates from the CIM format to a device-specific format, such as structure of management information (SMI)/SNMP, and performs that operation.
The Solaris™ WBEM services and Sun™ WBEM software development kit (SDK) provide these APIs, a query language, and other features that assist developers in creating complete WBEM solutions. Please see the "Related Information" section for additional information on WBEM.
Java Management Extensions
Java Management extensions (JMX) was created to address some of the limitations of SNMP. For instance, SNMP only permits primitive operations, so if you need an additional agent, side intelligence is required. For example, figuring out whether a spurious trap should be sent or not. The limitations of SNMPs can be overcome by using a JMX technology-based agent. The Sun Microsystems product, Java™ Dynamic Management Kit, facilitates the creation of intelligent agents using JavaBeans™ architecture. A MIB compiler included in the kit, reads in a MIB, creates the beans and stubs, and then allows you to fill in the logic.
JMX provides developers of Java technology-based applications, across all industries with the means to instrument Java platform code, create smart agents and managers in the Java programming language, implement distributed management middle-ware, and smoothly integrate these solutions into existing management systems. For additional information on JMX technology, please see the "Related Information" section. FIGURE 5 illustrates how the various components of JMX technology fit together. The JMX specification architecture is divided into three levels, or layers, which are used interchangeably.
Instrumentation layer—Provides manageability to any Java technology-based object. This level is aimed at the entire developer community utilizing Java technology. This level provides management of Java technology, which is standard across all industries.
Agent layer—Provides management agents. JMX technology agents are containers that provide core management services, that can be dynamically extended by adding JMX technology resources. This level is aimed at the management solutions development community and provides management through Java technology.
Distributed Services layer—Provides management components that can operate as a manager or agent for distribution and consolidation of management services. This level is aimed at the management solutions development community and completes the management through Java technology provided by the agent layer.
In addition, JMX technology provides a number of Java technology APIs for existing standard management protocols. These APIs are independent of the three-level model, yet they are essential because they enable JMX technology applications, in the Java programming language, to link with existing management technologies.
)
FIGURE
5 JMX Specification Architecture Components
A JMX technology agent is a management entity implemented in accordance with the JMX agent specification, and tested against the Agent Level Compatibility Test Suite. A JMX agent specification is composed of objects from the Java Dynamic Management Kit called Management Beans (MBeans). A JMX agent specification consists of an MBeans server, a set of MBeans representing managed resources, and at least one protocol adaptor or connector. A JMX agent specification can also contain management services, also represented as MBeans. The MBeans server is a registry for MBeans in the agent. The MBeans server is the component that provides the services allowing the manipulation of MBeans. All management operations performed on the MBeans are done through Java technology-based interfaces on the MBeans server.
There are two concepts used in accessing JMX technology agents: protocol adapters and connectors. Protocol adaptors give a representation of the MBeans directly in another protocol, such as hypertext markup language (HTML) or SNMP. Connectors include a remote component that provides end-to-end communications with the agent over a variety of protocols (for example HTTP, HTTP, and internet inter-orb protocol (IIOP)). Protocol adaptors and connectors let management applications access a JMX agent specification and manipulate the MBeans it contains. Because all connectors have the same Java technology-based interface, management applications use the connector most suited to their networking environment, and even change connectors transparently as needs evolve.
JMX technology and MBeans provide:
Standard manageability for any Java application, sometimes in just three to five additional lines of code.
The ability to embed all necessary management information in a standard way in the resource to be managed.
The ability to provide a wrapper for instrumented resources not based on Java technology (even proprietary or custom solutions) with Java technology-based management systems.
A JMX technology compliant agent is automatically capable of managing JMX technology resources. A non-JMX technology agent may also support JMX technology resources. Finally, the JMX technology instrumentation layer does not introduce any dependencies on external classes, a resource is entirely self contained.
The JMX specification agent and manager levels provide a flexible, distributed, and dynamic management infrastructure to be implemented in the Java programming language. By extending the Java programming language, JMX technology enhances the capabilities of existing solutions, and enables the rapid creation and deployment of new types of management solutions. These solutions can be extended dynamically to incorporate new equipment and services in a plug-and-play manner.
The JMX specification agents and managers developed using Java technology offer the following benefits:
- Platform independence
- Protocol independence
- Information model independence
- Management application independence