Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Searchable, convenient, complete TCP/IP information.
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Network Configuration and Management Protocols (BOOTP, DHCP, SNMP and RMON)
           9  TCP/IP Network Management Framework and Protocols (SNMP and RMON)
                9  TCP/IP Simple Network Management Protocol (SNMP) Protocol
                     9  SNMP Protocol Operations

Previous Topic/Section
SNMP Protocol Object Modification Using SetRequest Messages
Previous Page
Pages in Current Topic/Section
1
2
Next Page
SNMP Protocol Security Issues and Methods
Next Topic/Section

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.

The Need for Traps in SNMP

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.

Use of SNMP Trap and Trapv2 Messages

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.


Previous Topic/Section
SNMP Protocol Object Modification Using SetRequest Messages
Previous Page
Pages in Current Topic/Section
1
2
Next Page
SNMP Protocol Security Issues and Methods
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



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.