Home > Blogs > VMware vCenter Orchestrator Blog


SNMP plug-in for vCenter Orchestrator

The SNMP plug-in allows vCenter Orchestrator to connect and receive information from SNMP enabled systems and devices.

These devices could include communication equipment (routers, switches, etc.), network printers, UPS devices and many others. Events from vCenter can also be received over the SNMP protocol.

The SNMP plug-in provides two different manners of communication with the SNMP devices – queries for the values of specific SNMP variables and listening for events (SNMP traps) that are generated from the devices and pushed to the registered SNMP managers.

Inventory

The SNMP plug-in adds inventory objects to vCO, that consist of a trap host and a set of SNMP devices.

Snmp.01.Inventory

The trap host node represents vCO listening for SNMP traps. It holds the basic configuration of vCO, acting as SNMP manager. It can be either online or offline, which is configurable with workflows.

The list of devices that follow the trap host holds configuration information that is needed for the access to these devices.

Each device can have a set of specific queries, which can be started, in order to obtain data from the device.

Device management

The list of SNMP devices is managed by the workflows in the Device Management section of the vCO workflow library.

Snmp.02.DeviceManagement

They reflect the whole lifecycle of an SNMP device:

1. Register an SNMP device

Snmp.03.RegisterDevice

With this workflow SNMP devices can be added to the vCO inventory. Device address is the most important parameter of the workflow. All the others are optional or have default values. It can be either IP address or DNS name, although using IP address is recommended, because SNMP is often used as diagnostic and problem-alerting protocol, and the dependency on DNS decreases it’s level of reliablity.

The name parameter is used to define user-friendly name. If skipped, the device address is used to generate a name autmatically.

By default, devices are registered for SNMP v2c version, on port 161, with community name “public”. In advanced mode these settings can be changed.

Supported versions are v1, v2c and v3. The support for v3 is limited to AuthPriv security level, with MD5 authentication and privacy with DES pass-phrase same as the MD5 password.

2. Edit an SNMP device

Snmp.04.EditDevice

The “Edit an SNMP device” workflow allows to change the properties of an already registered SNMP device. It has the same fields as the “Register an SNMP device” workflow, with the exclusion of the advanced mode radio button.

3. Unregister an SNMP device

Snmp.05.UnregisterDevice

This is a very simple workflow with only one field – a chooser of the device to unregister. When a device is unregistered, all the queries attached to it are lost.

Query management

Each device can have a list of queries attached to it.

Snmp.06.QueryManagement

They hold settings of object identifiers, query types, etc. They can be used as building blocks in more complex workflows.

1. Add a query to an SNMP device

Snmp.07.AddQuery

This workflow creates an SNMP query and attaches it to an SNMP device in the vCO inventory.

The allowed types are GET, GETNEXT and GETBULK. OID is the object identifier of the variable that we want to query. Only numeric OIDs are supported, with the single exception of OIDs that start with “iso”.

Examples of supported types of OIDs are: “1.3.6.1.2.1.1.5.0”, “.1.3.6.1.2.1.1.5.0”, “iso.3.6.1.2.1.1.5.0”.

If the name parameter is skipped, a name is automatically generated, using the type and the OID, like “GET 1.3.6.1.2.1.1.5.0”.

2. Copy an SNMP query

Snmp.08.CopyQuery

This is a convenient workflow, that allows to copy existing queries between registered devices.

3. Edit an SNMP query

Snmp.09.EditQuery

This workflow allows to modify existing SNMP queries. It has the same parameters as the “Add a query to an SNMP device” workflow.

4. Remove a query from an SNMP device

Snmp.10.RemoveQuery

This is a single parameter workflow, that allows to delete queries that are no longer necessary.

5. Run an SNMP query

Snmp.11.RunQuery

With this workflow, an SNMP query can be run. The result is retrieved as an array of properties in the following format (which is also logged to the vCO system log):
Element 1:

=============

oid: 1.3.6.1.2.1.1.5.0

type: String

snmp type: Octet String

value: myhostname

The type of the result is a high-grain selection between String, Number and Array. More specific type can be retrieved from the snmpType property, where the original type of the result is stored.
If more detailed result information is needed, any custom workflow may run queries in the same manner as “Run an SNMP query” and work directly with the returned SnmpResult object, which has the following structure:

Snmp.12.SnmpResult

Trap host management

These workflows handle how vCO is listening for SNMP Traps.

Snmp.13.TrapHostMgmt

1. Set the SNMP trap port

Snmp.14.SetPort

This workflow stops the trap host, sets the new port and then starts the trap host. It is important to note that the default port for SNMP traps is 162, but in Linux systems, it is not possible to open ports bellow 1024, without super user permissions. That’s why the default port for listening to SNMP traps in the SNMP plug-in is 4000. It can be changed to other one with this workflow, if 4000 is unavailable, or 162 is accessible.

2. Start the trap host

Parameterless workflow, that starts the trap host.
3. Stop the trap host

Parameterless workflow that stops the trap host.

Generic SNMP request workflows

They perform the basic SNMP requests, without the need to create a specific query.

1. Get SNMP value

Snmp.15.SnmpGet

Performs basic SNMP GET request, with the provided object identifier.

2. Get next SNMP value

Very common to the “Get SNMP value”, this workflows performs SNMP GETNEXT request.

3. Get bulk SNMP values

Snmp.16.GetBulk

Performs SNMP GETBULK query. Specific for this workflow is the “Number of results” field, which specifies how many result elements will be retrieved in one GETBULK request. The default is 10.

SNMP traps

There are two ways to receive SNMP traps in the SNMP plug-in. With workflow, which is waiting for a single trap message, or with policy, which can handle traps continuously.

1. Wait for a trap on an SNMP device

Snmp.17.WaitForTrap

This workflow features a trigger, which stops the execution of the workflow and waits for an SNMP trap to continue. When such a trap is received, the workflow is resumed. It can be used as part of more complex workflows, or as a sample that can be customized or extended for a specific need. The OID field identifies either the Enterprise OID of the trap, or any variable OID. If no OID is provided, the workflow resumes after receiving any trap from the specified SNMP device. Otherwise, it is waiting for a trap with the provided OID.

2. SNMP trap policy

Snmp.18.TrapPolicy

A policy can be used if it is necessary to continuously listen for traps from an SNMP device. For that purpose, the “SNMP Trap” policy template must be applied. After this, a policy with the specified name appears in the Policies group. To start listening for traps, this policy must also be started. If necessary, it’s “Startup” option may be edited, to allow starting the policy on server startup.

Snmp.19.Policy

Then a specific workflow or scripting code may be associated with this policy for integration in a more complex scenario.

SNMP traps can be sent to other systems with the “Send an SNMP trap” workflow.

Snmp.20.SendTrap

The manager address and port fields point to the receiving system. If the port field is left empty, it will be substituted to 162.

The enterprise OID is not mandatory. It identifies the type of the device that is sending the trap.

Type can be String, Number or Array. String values are sent as SNMP Octet String. Number values are sent as Gauge32. And the Array values are sent as multiple variable binding traps of Octet String SNMP type. Array values are represented as comma-separated list of oid:value pairs in the Value field of the workflow.