The original design of SNMP (the Simple Network Management Protocol) was based on managers and managed devices (with agents). The manager’s responsibility was to determine what data was needed and how often it was needed. Agents provided the data only when requested by managers. Thus, the manager polled the agent and determined, based on that data, if the agent was functioning properly.
A drawback of this polling approach is the lag time between a problem or error condition occurring with an agent and the manager discovering the issue. The larger the number of managed agents, the longer the delay in discovery. Thus polling was not realistic in networks with large numbers of managed devices. By enabling the SNMP agent in a managed device to determine when an important event or error conditions has occurred within the device, the agent could then notify the management application.
The application of these notifications has changed with each version of the SNMP protocol.
With SNMPv1, an SNMP TRAP was sent by the agent. The TRAP reported the occurrence of an event to the management app. However, there was no certainty or safeguard that the management app received the TRAP.
With SNMPv2c, the agent sent an SNMP INFORM and the management app acknowledged the receipt of that INFORM. This was a big improvement as it increased confidence that the management app could at least now take action on the information contained in the SNMP INFORM. (Note that many times when significant failures occur on networks, a loss of connectivity may prevent receipt of the INFORM by the management app, and thus a failure to take any action.)
In both SNMPv1 and SNMPv2c, the TRAP or the INFORM contained an event and a list of variables and their associated values. The management application then interpreted this information and determined the next action.
As discussed in the popular paper, “Implementing Secure Network Management”: [http://iwl.com/idocs/implementing-secure-network-management]
SNMPv3 also introduced a new concept of the command generator and the command responder. These terms replace the traditional notion of a smart manager and a non-intelligent agent. SNMPv3 recognizes that many network devices and applications operate in dual or multiple modes. These devices are now “entities” and an entity can be a command generator (used to be a manager) or a command responder (used to be an agent).
To verify that notifications are properly working, an SNMP test tool, like Silver Creek [https://iwl.com/products/silvercreek], may be helpful. Silver Creek includes trap library tests that verify the following against the loaded MIBS:
• Syntax type, range and size for all included variable bindings.
• Variable bindings are ordered correctly and complete.
• Variables have valid instance identifiers. Includes support for IMPLIED indexing.