Finding and solving problems in your SNMP implementation can be tough.
This guide helps you identify and solve SNMP issues.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayOIDS are unique "object identifiers." They are sequences of numbers separated by decimal points (e.g., 1.3.6.1.4.1.2682.1). The MIB associates each OID with a readable label (e.g., dpsRTUAState) and various other parameters related to the object.
The MIB serves as a data dictionary or codebook that is used to assemble and interpret SNMP messages.
For example, when an SNMP manager wants to know the value of an object/characteristic, such as the state of an alarm point, the system name, or the element uptime, it will assemble a GET packet that includes the OID for each object/characteristic of interest.
The element receives the request and looks up each OID in its codebook (MIB). If the OID is found (the object is managed by the element), a response packet is assembled and sent with the current value of the object/characteristic included. If the OID is not found, a special error response is sent that identifies the unmanaged object.
SNMP typically uses five basic messages (Get, GetNext, GetResponse, Set and Trap) to communicate between manager and agents.
The Get and GetNext messages allow the manager to request information for a specific variable. The agent, upon receiving a Get or GetNext message, will issue a GetResponse message to the manager with either the information requested or an error indication as to why the request cannot be processed.
A Set message allows the manager to request a change be made to the value of a specific variable, such as in the case of an alarm remote that will operate a relay. The agent will then respond with a GetResponse message indicating the change has been made or an error indication as to why the change cannot be made.
The Trap message allows the agent to spontaneously inform the manager of an "important" event.
The Inform, sometimes supported in v2c or v3 implementations, is like a trap that also requires a confirmation response from the SNMP manager.
SNMP v2c offers a variety of improvements over v1. One significant advantage is the ability to use the new Inform notification in place of traps.
Trap notifications, supported in SNMP v1 and later, are considered non-robust because the SNMP manager doesn't send an acknowledgment in response to the Trap. The device sending the Trap sends it only once. The sending device has no confirmation that the Trap has been received, so there's no guarantee that the alarm information has been successfully sent to the SNMP manager.
Inform notifications, supported in some SNMP v2c implementations or SNMP v3, are designed for a confirmed delivery. When an SNMP manager receives an Inform, it sends a confirmation response back to the SNMP agent device. If the SNMP agent device doesn't receive a response to its Inform, it resends it until the SNMP manager sends the confirmation response or the specified number of retries is exhausted.
But Inform notifications are not the best choice for everybody; you're choosing a trade-off of reliable delivery at the cost of heavier network traffic. A Trap is only sent once, which places only a very small demand on network resources. The Inform requires a response packet to be sent (and messages may be sent several times if responses are not received), which increases reliability at the cost of increased network traffic.
Additional information about SNMP fundamentals is beyond the scope of this white paper. If you're new to SNMP and would like a more detailed introduction, please read How to Implement SNMP Monitoring in Your Network: A Practical, Step-By-Step Guide.
Every DPS Telecom white paper provides detailed guidance on a single protocol or topic.
