SNMP

Please be advised that the online documentation for LabTech 2013 and later resides at http://docs.labtechsoftware.com/documentation/. The documentation below is only applicable to LabTech 2012 and will not be maintained moving forward.

SNMP

Was this information helpful?
(3 votes)
  1. Overview
    1. SNMP Versions
  2. Understanding MIBs
    1. MIB Object Definitions
  3. SNMP Walking
  4. SNMP Traps
    1. Adding Trap Filters
    2. Sample Trap Creation
  5. SNMP Traps Received
    1. Removing a Trap Entry
  6. Document Revision History

Overview

SNMP stands for Simple Network Management Protocol. The SNMP standard allows for retrieval of information (referred to as a Get) from a device, as well as altering accessible parameters within the device (referred to as a Set). LabTech mainly focuses on using SNMP to Get information, particularly information pertaining to device status (e.g. enabled/disabled) and usage (e.g. how many pages has a printer printed?) through network monitors.

LabTech accesses SNMP data for a device, one piece at a time. Each piece of data is accessed by its Object Identifier (OID). Object Identifiers work in a similar manner to an IP address, in that they use a dotted notion to indicate a destination (e.g. 1.3.6.1.2.1.1.3.0 accesses the time (in hundredths of a second) since the network management portion of the system was last re-initialized). How OID's are formulated is discussed in further detail below.

For typical users of LabTech, no knowledge of how SNMP works is required (other than the ability to enable SNMP and set appropriate passwords for devices on their network). The LabTech Control Center provides easy access to most commonly used OID's.

For advanced users, the probe configuration section provides a mechanism to access specific information for devices via SNMP, which requires some level of SNMP understanding. This section provides an introduction access data via SNMP. It is recommended that any users interesting in using the advanced features familiarize themselves with SNMP with additional research.


Note NOTE: Community strings, Trap Port and SNMP Timeout settings are configured on the Network Probe > General tab.  To disable SNMP trap listening, set the Trap Port to 0.

SNMP Versions

There are three versions of SNMP:

  • Version 1 was the first version of SNMP. This is the most commonly used version. The major drawbacks with version 1 are no support for 64-bit numbers and poor security.
  • Version 2 initially provided support for 64-bit numbers, as well as an enhanced security model. However, the version 2 security model is not widely accepted. Because of this, there are multiple standards of Version 2, the most commonly used being Version 2vc. This is the version supported by LabTech. Version 2 is used mostly by high speed routers and switches to count incoming/outgoing bytes.
  • Version 3 provides encryption (scrambling of the message so it is not viewable across the network) and authentication (verification that the snmp message actually came from the device in question, and was not tampered with)

Versions 1 and 2 use an access keyword, referred to as the Community Name (or Community String), as a simple form of security. However, this method is not secure due to the fact the community name is simply placed in the header of the message, and thus visible to anyone monitoring the network. Most modern devices have two community names, one that provides read-only access to the device (the 'public' community name), and a private one that allows writing to certain objects.

Understanding MIBs

SNMP is a standard protocol that devices support to Get and Set information. The actual information each device contains is referred to as the device's MIB, which stands for Management Information Base. This information is almost always described in one or more MIB-modules. Each object in an MIB is required to be defined by a single ASCII string, and is typically the concatenation of multiple words and abbreviations describing the element (e.g. ifOutBroadcastPkts, hrPrinterDetectedErrorState).

MIB information exists in a tree-like structure. The benefit of using a tree-like structure is that it allows for the addition of new data items without disrupting prior configurations. To demonstrate the tree structure, an MIB representing a human being might be organized as follows:

  • humanBeing (1)
    • PhysicalFeatures (4)
      • Face (7)
        • Forehead (2)
          • ConcentrationLines(1)
          • ForeheadHeight(2)

Notice the numbers next to each object name. Each object in a MIB has a corresponding code number. Objects are accessed in a MIB by using the correct OID (Object Identifier), which is a concatenation of all code numbers in the tree structure. For example, the correct OID to get the number of concentration lines on a person's forehead would be "1.4.7.2.1.0". Notice how the OID ends with the number 0. Data objects that only exist once, such as a person's height, weight, or birthday, are always accessed with a "0" indicating a single value.

Objects that may exist more than once (typically referred to as table data) are accessed with an index, where the meaning and range of the indexes is defined in the MIB. To demonstrate this, let's add eyes to the Face. So our MIB now looks like this:

  • humanBeing (1)
    • PhysicalFeatures (4)
      • Face (7)
        • Forehead (2)
          • ConcentrationLines(1)
          • ForeheadHeight(2)
          • Eyes(3)
          • EyeIndex(1)
          • EyeColor(2)
          • PupilRadius(3)

For the purposes of this discussion, let's assume that an index of 1 refers to the left eye, while an index of 2 refers to the right eye. So, to access the left eye color, the correct OID is 1.4.7.3.2.1, while for the right eye's pupil radius, the correct OID is 1.4.7.3.3.2.

MIB Object Definitions

MIB modules are text files that contain all of the information necessary to access a device. It is not necessary that users are capable of parsing MIB – modules, since the LabTech Control Center handles MIB parsing. However, a basic understanding of how actual objects are defined may be helpful. To do this, let's review an object definition. The following is the definition for the sysDescr object, which is mandatory for every SNMP device.

   sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A textual description of the entity. This value
should include the full name and version
identification of the system's hardware type,
software operating-system, and networking
software. It is mandatory that this only contain
printable ASCII characters."
::= { system 1 }

Each MIB Object typically has the following information:

  • SYNTAX: How the data is formatted. This can vary from text (OCTECT STRING) to numbers (INTEGER) to a custom format, such as 3 bytes that contain hour, minute, and second. In the example above, the DisplayString is a convention (found elsewhere in the MIB-module) that indicates the field is text.
  • ACCESS: Determines whether the device can be read and/or written to.
  • STATUS: Whether the object must be supported by any device that claims to support the MIB module.
  • DESCRIPTION: Description of the information contained in the field. This description is the most important piece of information for LabTech users.

SNMP Walking

In addition to Get and Set, SNMP supports the GetNext command. This command gets the OID after the OID specified. Using the GetNext command, it is possible to iterate through all the objects in an MIB. This iteration is referred to as Walking.

SNMP Traps

The purpose of the SNMP Trap tab is to allow you to set filters to define which traps should be accepted and which are thrown out.  A trap has to pass a filter in order for it to be sent to the server.  

Devices must be configured to send SNMP traps to the probe-enabled computer. To enable and configure traps, review the specific device's documentation. Exclusive use of traps is not recommended for the following reasons:

  • Traps only report some of the issues that indicate there is a problem with the device. For example, a device that has no power obviously cannot send a trap indicating power loss, but a constant network monitor will detect this issue.
  • SNMP traps use the UDP protocol, which is not guaranteed to be received by the SNMP trap listener. SNMP traps are typically not rebroadcast.

Figure 1: Sample SNMP Traps
Fig01_SampleSNMPTRAPS_10A.41.150

The SNMP Traps tab will show all trap filters that have been created along with the parameters that define what traps are passed through to LabTech.

Adding Trap Filters

The purpose behind creating traps is to have devices notify the probe of abnormal conditions. A Trap operation is different than the Get, GetNext and Set operations because it is initiated from a managed device. A trap message is used to alert to the fact that a specific threshold has been reached, or that an error/event of some type has occurred.

To add SNMP traps, follow the steps listed below:

  1. Double-click on the probe-enabled computer from the navigation tree in the Control Center.
  2. Select the Network Probe tab > SNMP Traps tab.  This will display all SNMP traps that have been created.
    Figure 2: SNMP Traps
    Fig02_SNMPTraps_10A.41.150
  3. Right-click in the white space and select Add Trap from the menu that displays.
    Figure 3: Sample SNMP Trap
    Fig03_SampleTrap_10A.41.150
  4. Enter the desired Name for the trap you want to create.
    The IP Address Filter, OID Value Filter, Generic Type Filter and Specific Code Filter can all be used in conjunction with each other or individually.
  5. If applicable, select the IP Address Filter field and enter the IP Address of the printer or router generating the trap in the IP Address field. If this field is not checked, it will ignore the IP address.
  6. If applicable, select the OID Value Filter and enter the OIDvalue or click on the ellipsis button to select from the OID selector.  For this example, we entered an OID for upsAlarmonBattery. The upsAlarmBattery will return two possible results (1=is not drawing power from the batteries or 2= is drawing power from the batteries).
    1. Select the Check Condition from the drop-down menu.
    2. Enter the Result that you want the trap to report on.  Using the above example, we want a trap for any UPSs drawing power from the batteries.
  7. For an alert to be generated when a trap is received, select the desired alert template from the Alert Template drop-down.  If there is not an appropriate template available, you can choose to create a new template.  For additional information on how to create a new template or edit the alerts on an existing template, please refer to the Alert Templates documentation.
  8. If applicable, select the Generic Type Filter.  Refer to the following table for standard generic traps. For example, if we select 'Equals' and '4' in the Result field, a trap will be created for authentication failures.  
    1. Select the Check Condition from the drop-down menu.
    2. Enter the Result that you want the trap to report on. 
  9. If applicable, select the Specific Code Filter.  Typically, specific codes are manufacturer specific.
    1. Select the Check Condition from the drop-down menu.
    2. Enter the Result that you want the trap to report on.

Table 1: Generic Trap Descriptions

Trap Name/Number Description
coldStart (0) Indicates that the device has rebooted. All management variables will be reset; specifically, Counters and Gauges will be reset to zero (0).
warmStart(1) Indicates that the agent has reinitialized itself.  None of the management variables will be reset.
linkDown(2) Sent when an interface on a device goes down.  The first variable binding identifies which interface went down.
linkUp(3) Sent when an interface on a device comes back up.  The first variable binding identifies which interface came back up.
authenticationFailure(4) Indicates that someone has tried to query your agent with an incorrect community string; useful in determining if someone is trying to gain unauthorized access to one of your devices.
egpNeighborLoss(5) Indicates that an Exterior Gateway Protocol (EGP) neighbor has gone down.
enterpriseSpecific(6) Indicates that the trap is enterprise-specific. SNMP vendors and users define their own traps under the private-enterprise branch of the SMI object tree.
  1. Once you have entered the appropriate information, click Save.
  2. Select Begin > Commands > Probe > Refresh Configuration to update the configuration.  It can take up to 10 minutes for the probe to update its configuration based on its activity. You can check the progress by looking at the Network Probe > Probe Commands tab. Any time changes are made you will need to update the configuration.

Note NOTE: To edit a trap, right-click on the trap and select Edit Trap from the menu or simply double-click.  Make the appropriate changes and click Save. To delete a trap, right-click on the trap and select Delete Trap.  You will be prompted to confirm.  Click Yes to delete.

Sample Trap Creation

The Vertical Wave IP system sends traps in response to events taking place.  For these traps, the value sent in the trap is the number of the trunk affected.  The specific code sent in the header of the trap actually indicates what event has taken place.  A subset of the traps, taken from Eventlog.mib, is shown below:

Figure 4: Sample Eventlog.mib - Subset of Traps
Fig04_SampleEventLog_10A.41.150

For this example, we want to capture when the voice mail disk is full (e.g., eventLog-VoiceMailDiskIsFull).  According to the above example log, '57' is sent when the voice mail capacity has been reached.

  1. From the SNMP Traps tab, right-click in the white space
    Figure 5:  Sample SMTP Trap - Specific Code
    Fig05_SpecificCode_10A.41.150
  2. Enter the name.  For our example, we will enter 'Wave Device Voice Mail Full'.
  3. Select the Specific Code Filter checkbox to enable the Check Condition and Result fields.
  4. Select 'Equals' from the Check Condition drop-down.
  5. Enter '57' in the Result field.
  6. Typically, when a specific code is sent with the trap, the generic code is required to be 6, so adding a check for code 6 is a viable option.
    Figure 6: Sample SMTP Trap - Generic and Specific Code
    Fig06_Generic_and_Specific_Code_10A.41.150

    Note NOTE: Given that other devices may use code 57, some additional filtering is probably a good idea.  You could filter on IP address or if you know the trap OID, you can use this.  For the current example, the Wave device OID is constant for all traps sent so that can be used.

    Figure 7: Sample SNMP Trap - OID Filter, Generic & Specific Code Filters
    Fig07_OID_Filter_10A.41.150
  7. Click Save.  This will create a trap to receive messages when the voice mail is full based on the information provided in the Eventlog.mib. 

SNMP Traps Received

The SNMP Traps Received will show you all the SNMP traps that have been received based on the trap filters you have created on the SNMP Traps tab. 

Figure 8: SNMP Traps Received
Fig08_Traps_Received_10A.41.150

Table 2: SNMP Traps Received

Column Description
IP Address Displays the IP address of the device. 
OID Displays the OID of the received trap. 
Trap OID Displays the OID that came over in the trap. The last two numbers of the trap value indicate the generic and specific codes.  For example, for the OID 1.3.6.1.4.1.9.6.1; 6 is the generic code and 1 is the specific code. 
Trap Value Displays the trap value.
Record Time Displays the date and time that the trap was received.
SNMP Version Indicates the SNMP version. V3 may process traps differently from versions 1 and 2.

From this screen, there are additional options.  You can refresh the list, copy the text, search the list, print the list or export the list to Excel.  Each of these options can be accessed by right-clicking in the white space of the window. 

Removing a Trap Entry

If you want to remove a trap entry from the SNMP Traps Received listing, be aware that you will not be prompted to confirm the removal. 

  1. To remove a trap entry, right-click on the trap and select Remove Trap Entry from the menu that displays. 

Document Revision History

Date Notes
04/11/2011 Updated for 2011 release
09/01/2011 Added Update Configuration to list of steps after creating traps.

Bonnie Whitmire Approved

Last modified on Friday, 07 October 2011 13:56
More in this category: « Syslog Probe Schema »
There are currently no Video for this item
There are currently no Blueprint for this item
There are currently no Related Materials for this item
Comments (0)Add Comment

Write comment

busy