C H A P T E R  3

SNMP Server Management

You can manage your server using the Simple Network Management Protocol (SNMP).

Simple Network Management Protocol

Simple Network Management Protocol (SNMP) is a network-management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security on a network.

SNMP-based management allows for third-party solutions to be used. This includes products such as HP OpenView and CA Unicenter.

The base component of an SNMP solution is the Management Information Base (MIB). The MIB is included on the Sun Fire V20z and Sun Fire V40z Servers Network Share Volume CD.

This server management configuration is beneficial when, for example, you have a cluster of machines serving web content and the platform is connected to the Internet, but the SP is protected and accessible only on an internal network.

SNMP Integration

SNMP is an open network-management technology that enables the management of networks and entities connected to the network. Within the SNMP architecture is a collection of network-management stations and managed nodes.

Network-management stations execute management applications, which monitor and control managed nodes. Managed nodes are devices such as hosts, gateways and so on, which have management agents responsible for performing the management functions requested by the management stations.

SNMP is used to communicate management information between the management stations and the agents. In other words, SNMP is the protocol by which the agent and the management station communicate.

Monitoring status through SNMP at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the management station. Managed nodes can also provide unsolicited status information to management stations in the form of traps, which are likely to guide the polling at the management station.

Communication of information between management entities in a network is accomplished through the exchange of SNMP messages, both in the form of queries (get/set) by the management station and in the form of unsolicited messages (traps) indicated by the agent.

The servers include SNMP agents that allow for out-of-band health and status monitoring. The SNMP agent runs on the SP and therefore all SNMP-based management of the server should occur through the SP.

The SNMP agent on these servers provides the following capabilities:

SNMP Management Information Base

The Management Information Base (MIB) is a text file that describes SNMP data as managed objects. These servers provide SNMP MIBs so that you can manage and monitor your server using any SNMP-capable network management system, such as HP OpenView Network Node Manager (NNM), Tivoli, CA Unicenter, IBM Director, and so on. The MIB data describes the information being managed, reflects current and recent server status, and provides server statistics.

Sun Fire V20z and Sun Fire V40z Servers MIB Tree

FIGURE 3-1 illustrates the MIB tree.


Diagram showing the SNMP Management Information Base (MIB) tree for the servers.

Integrating MIBs With Third-Party Consoles

You use the server's MIBs to integrate the management and monitoring of the server into SNMP management consoles. The MIB branch is a private enterprise MIB, located at object identifier (OID) The standard SNMP port 161 is used by the SNMP agent on the SP.

Configuring SNMP on the Servers

Note - There are several services that are supplied by the SNMP agent on the servers. Depending on your business needs and the configuration of your current office network and management environment, you might want to take advantage of these services.

There are certain prerequisites and setup requirements on both the SP and the platform in order to enable and utilize each of these services:

Customers can elect to manage a server out-of-band (OOB) through the SP. With OOB management, the SP is the target of the SNMP request. The SNMP agent on the SP is configured to provide proxy-request capability so that OID requests that are not related to the SP are forwarded, transparently, to the platform OS.

Out-of-Band Management Configuration

FIGURE 3-2 illustrates the SNMP architecture and communication paths between the SP and the platform.

FIGURE 3-2 SNMP Architecture and Communication Paths

Diagram illustrates the SNMP architecture and communication paths between the SP and the platform.

SNMP Agent on the Service Processor

The SNMP agent running on the SP facilitates the management and monitoring of the server. The SNMP agent can be used to query various types of SP information. Refer to FIGURE 3-1 for a list of the MIBs; refer to TABLE 3-3 for a detailed description of the MIBs.

There is no configuration required to use this functionality other than integrating the
server MIBs with your desired management station.

Refer to the procedure for using the SNMP agent on the SP, as explained in Integrating MIBs With Third-Party Consoles.

Note - The SNMP agent on the Sun Fire V20z and Sun Fire V40z servers supports SNMP v1 and v2c. For security reasons, there are no settable attributes in this agent.

Proxy Agent

The SP acts as an SNMP proxy-agent intermediary for the platform. Queries made from a management station to the SNMP agent on the SP are intercepted by the proxy agent on the SP and forwarded to the platform; the SP proxy agent contacts the platform to retrieve the requested information. The proxy agent then receives the data from the platform and sends the request back to the management station. The management station never knows that the request was proxied. The SP and the platform communicate over an internal private network.

To enable this facility, you must first run an SNMP agent on your platform operating system (see your OS vendor to obtain this agent). This enables platform-level management transparently through the SP. Querying MIBs other than the server MIB (for example, the Host Resource MIB) and the MIBII System MIB on the SP obtains information from the platform by proxying the request to the platform SNMP agent.

Ensure that the SP can identify the read-only and read-write community names that are configured for your platform SNMP agent. Refer to Setting the Community Name.

Setting the Community Name

The SNMP agent on the SP acts as a proxy for the SNMP agent running on the platform. (Refer to Configuring SNMP on the Servers.) To proxy properly, you must use the community string. The community string needed to do so is the value defined when you configured the platform for SNMP.

If you find that your SNMP queries are not being proxied to the platform SNMP agents, validate that the community string on the SP matches the community string on the platform. The SP proxy community string can be changed to match the platform community string using the following command:

# sp set snmp proxy community 

There are no restrictions on the length of the community strings; common names are private and public. The default name is public.

For more information, refer to SP Set SNMP Proxy Community Subcommand.

Agent X

A subagent using SNMP Agent X protocol on the platform can connect to the SNMP agent on the SP (through a special port) and forward query responses or unsolicited traps through the SP. This allows server-management traffic to be kept secure from the production network connected to the platform, if required.

To properly enable this facility, you must identify the IP address and port number pair associated with the SP (as seen from the platform). The Agent X port is fixed at 705 (TCP). However, the private-network IP address is configurable and, by default, this address is

Refer to your application documentation for instructions on configuring the subagents.

Note - You can use the subcommand sp get jnet on the SP to retrieve the JNET IP address of the SP. For more information, see SP JNET Address Subcommands.

Using a Third-Party MIB Browser

The following procedure demonstrates how to integrate the server MIBs into an SNMP node manager.

1. From the browser's Manager Preferences menu, choose Load/Unload MIBS: SNMP.

2. Locate and select the SP-MasterAgent-MIB.mib.

3. Click Load.

4. Specify the directory in which the server MIBs are placed and click Open.

5. Repeat Step 2 through Step 4 to load other MIBs.

For example, SP-SST-MIB.mib, SP-INVENTORY-MIB.mib, SP-EVENT-MIB.mib, SP-PLATFORM-MIB.mib, SP-GROUP-MIB.mib, and so on.

6. Exit the Manager Preferences menu.

7. Open an SNMP MIB browser.

The SNMP standard tree displays in the MIB Browser.

8. Locate the newisys branch located under private.enterprises.

Refer to FIGURE 3-1 for a sample view of the MIB tree.

Setting Options for Logging Events

You can also easily integrate SP-generated traps and set logging options. The following procedure demonstrates the necessary steps when using HP OpenView Network Node Manager (NNM).

1. Load the SP-EVENT-MIB.mib according to the previous procedure.

2. Choose Options>EventConfiguration

3. Select the spEvent module from the Enterprises list.

4. Double-click an event from the Events for Enterprise spEvent list.

5. Select the Event Message tab.

6. Select Log and Display in Category and choose a category from the corresponding list, or create your own event category.

7. Select the severity of the event from the Severity list.

8. Enter a message or $* to display all information in the Event Log Message field.

9. Click OK.

SNMP Traps

SNMP traps are network-management notifications of an event occurring at a managed network node. These events can identify problems in the network, machines that are up or down, and so on. The Sun Fire V20z and Sun Fire V40z servers use traps to signal conditions related to the server's health, including critical conditions related to physical components, the return to a normal state for these components, and other situations related to the state of the software running on the SP (for example, network settings are being reconfigured).

Traps are defined in the MIB files and are generated, received, and processed by an SNMP management station. SNMP trap data is uniquely identified by the MIB. Each SNMP trap contains information identifying the server's name, IP address, and other relevant data about the event.

Within the server event MIB, each trap has variables and event bindings, as described in TABLE 3-1.

TABLE 3-1 Server Event Traps




Uniquely identifies the event on the SP from where it came.


Denotes the source module that generated the event.


Denotes the component ID to which the event refers.


The event message received from its source.


The time at which this event ID was initially generated.


The most recent time at which this event ID was generated.

Configuring SNMP Trap Destinations

Although SNMP traps are generated for events that occur on the SP, you must configure where these traps are to be sent. There is no default destination for traps. You can use the server-management subcommands (see TABLE 3-2) on the SP to configure SNMP destinations.

For more information on these subcommands, refer to Appendix H.

TABLE 3-2 Subcommands for Configuring SNMP Destinations



sp get snmp-destinations

Displays all the available SNMP destination IP addresses and host names to which the SP will send traps.

sp add snmp-destination

Adds a new SNMP destination, one IP address or host name at a time.

sp delete snmp-destination

Removes an existing SNMP destination, one IP address or host name at a time.

Configuring SNMP Destinations

Admin-level and manager-level users can define SNMP destinations to which SNMP events (alerts) will be sent. All users can view the current destinations (using read-only access).

The number of destinations you can create is limited due to memory constraints.

You can configure SNMP destinations using the sp snmp subcommands. For more information about these subcommands, refer to Appendix H.

Server MIB Details

SNMP uses object identifiers (OIDs) to provide name variables by which objects are grouped together for easier reference. These servers provide agents for the MIBs shown in TABLE 3-3.







Creates the main trunk of the server MIB tree. All other MIBs of the SP branch from this tree. To be loaded first while integrating with any third-party framework.





Used for querying inventory information for all Sun Fire V20z and Sun Fire V40z servers hardware and software components.

Hardware Inventory Table-Collects all hardware component inventory.

Software Inventory Table-Collects all software component inventory.



Defines objects for the System State Table in the SP. Contains all sensor readings, including the name of the sensor, its current value, maximum allowed value, measurement type, scale, and scanning interval.



Defines objects for the platform SNMP, which includes OS state, platform state, and platform IP table.



Identifies the OIDs associated with all SNMP traps originated from the SP.



Defines objects for the SP, including host name, DNS, a reboot node, a node to hold the last port 80 postcode, a clone tree, and an IP table.

The events listed in TABLE 3-4 are sent to the SNMP destination by

TABLE 3-4 SP Events

Enterprise Trap ID
















































































SNMP Troubleshooting

You might find that SNMP queries to the service processor (SP) are timed out. If so, note that the platform OS requires both the Newisys Platform Software (NPS) driver suite RPM and an active SNMP daemon sharing the SP's community string.