| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
SNMP Protocol Information Notification Using Trap(v2) and InformRequest Messages (Page 1 of 2) The first topic in this section introduced the two basic methods of communicating information between SNMP devices: using polls or interrupts. All of the message types and exchanges we have examined thus far in this section have been poll-driven: they consist of an SNMP manager making a specific request that results in action being taken, and a response being generated by an SNMP agent. Polling is ideal for the exchange of routine information that needs to be gathered on a regular basis. For example, the regular Get requests could be used to verify the settings on a device, examine error counts over a period of time, or check its up-time or use statistics. And obviously, polling is the only real method for performing a Set operation, where data is changed. But polling is not well-suited for important information that needs to be communicated quickly. The reason is that poll-driven communication is always initiated by the recipient of the information: the SNMP manager. If something significant occurs on a managed device that the manager wasn't expecting, the manager won't find out about it unless it specifically asks to see the variable that has changed. This means that important variables would need to be checked all the time by the SNMP manager, which is highly efficient. In the real world, using polling to implement situations where critical information needs to be sent would be like having the emergency response service in your town call everyone every hour to find out if they needed an ambulance or fire truck. Similarly, in SNMP, a mechanism was needed to let an SNMP agent initiate the communication of information. This capability was originally made part of the SNMPv1 protocol through the inclusion of the Trap-PDU message type. In computer science, a trap is simply a set of conditions that a device monitors continuously. If the appropriate conditions occur, the trap is triggered and causes some sort of action to occur. In SNMP, traps are programmed into SNMP agents, and when they are triggered, an SNMP Trap-PDU message is sent to an SNMP Manager to inform it of the occurrence. Examples of traps in the SNMPv1 specification include ones that trigger in the event of a communication link failure, restart of the device, or an authentication problem. The communication in the case of a trap is trivial; the SNMP Agent sends the trap and the SNMP Manager is thereby considered informed of what happened. That's pretty much it. These are Unconfirmed messages and no reply is made back to the SNMP Agent. The triggering of the trap may lead the network administrator to take follow-up action at the device that sent the trap. The designer of a particular management information base must determine what traps to create for a particular group of objects. The implementation must specify the conditions under which the traps will trigger, and also the destination to which the Trap-PDU message will be sent when this occurs. In SNMPv2, the original trap notification message was retained in the form of the Trapv2-PDU message.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |