SNMP Agents are programmed to watch for certain system events and problems and to send in Traps to the SNMP Master server when they occur. An SNMP Master server sends polls to an Agent to retrieve specific information about the configuration or state of the device. All of this communication, both Traps and Polls should be configured by the SNMP administrator in such a way as to minimize SNMP's impact on network performance and maximize the effectiveness of the reporting and polling mechanisms.
Monitoring Methodologies
There are three basic SNMP methodologies used when implementing SNMP:
- Polls Only
- Traps Only
- Mixed Traps and Polls
Polling Only Method
Applications that implement an SNMP Master servers usually have options for setting up SNMP polling. SNMP Polling is the process of retreiving a specific piece of information from one or more remote devices using SNMP. SNMP is not the only way to poll a device, but for the purposes of this tutorial, we're going to stick with SNMP. There are other tutorials elsewhere on this site that talk more generally about network monitoring.
Network monitoring applications will provide some method of configuring a polling cycle. Polling cycles will include the following information:
- A list of devices to be polled
- A list of objects to be polled from each device
- A minimum time interval between polls
Once configured, the application will send out the necessary SNMP queries (polls) to each device in the list and when it completes the list, it will wait until the polling interval period has expired. When configuring polling, you should always be aware of how long it takes to actually accomplish any given poll. If it takes you fifteen minutes to poll everything in the network and you've configured the interval between polls to ten minutes, you will end up starting the second polling cycle before you finished the first one. Every cycle you will start an extra poll cycle and never finish it. Worse, this will generate more and more traffic over time, eventually swamping your network with so much monitoring traffic that the network won't transfer ordinary data.
An SNMP system that uses only polls will have all it's Agents set to be passive, if it uses Agents at all. The Agents will not send in information. The disadvantage of this method is that when a remote system is having a problem that prevents it from communicating with the master, the Master won't find out until it performs it's next poll, and only if the Master is configured to LOOK for that specific problem on that polling interval. The SNMP Master assumes a device is up until it figures out something is wrong on it's own. Since an SNMP Master can't dynamically go looking for problems and must wait for the next poll cycle, this can create serious issues on the network when a device which is not monitored goes down, is and is never noticed by the SNMP network monitoring system. The server has to do all the work, sending out a large amount of traffic to get the job done. When a polling interval arrives, the SNMP Master could swamp a medium to large size network. Worse, the returning responses are likely to swamp the SNMP Master itself. Some of those responses might time out, triggering a false alarm.
Advantages
- All configuration is centralized at the SNMP Master
- Agents are not required.
- There is no need to configure traps on the Agent or the Master.
- Since comunication is always on UDP 161, firewall rules and security policies are easier to configure.
Disadvantages
- Failures are not alerted to in real time.
- Devices that fail will not be noticed until the next polling cycle.
- Unless a poll is configured to detect a specific problem, the failure will go undetected.
Traps Only Method
A Traps-only network uses an SNMP Master configured to passively receive and not send traps. The Agent will be configured to send traps at regular intervals (whether there's a problem or not) in order to inform the Master that they are still 'alive'. The SNMP Master is placed in the position of having to assume a device is up until it fails to hear from it. This has the additional problem of having traps fail to be received as traffic from all the Agent attempts to reach the server simultaneously overwhelming the network link. Lastly, if traps are not received because the Master is too busy, the Master will think the remote Agent/device is down and trigger a false alarm that something is down when it's not. Think about what a false alarm means to an administrator who is sound asleep in his bed at 3 am...
Mixed Traps and Polls Method
Mixing Traps and Polls and combining this with additional non-SNMP polls such as ICMP pings is the best way to go in nearly all cases. By programming a device's Agent to inform you when a failure or important event occurs, you minimize the amount of traffic the Agent must send in because it only needs to send a trap when something is wrong or when you configure it to.
Because the Agent is configured to send in an alert when there is a problem, anything that fails is alerted to in real time. Furthermore, the SNMP Master can reduce it's frequency of polls by relying on these alerts. Decreasing the number of polls decreases the load placed on the network by the SNMP Master. The SNMP Master, on the other hand, can also safely assume a device is up and only needs to perform a quick poll at long intervals to make sure the device is still there.
CAVEATS
- Most often a mixed model is best but this is not always the case.
- KEEP YOUR POLLING INTERVALS AS WIDE AS CAN BE TOLERATED. If you place your polling intervals too close together you will swamp your network with SNMP poll packets and cause polls and traps to fail. This generates all kinds of false alarms and will keep you up at night.
- Always keep in mind that SNMP uses UDP. By definition, UDP does not verify that messages are received, so if there is a problem during transmission, anything could happen.
- Your monitoring is only as good as your planning and implementation. If you didn't think of it, odds are you aren't monitoring it, or at least not properly.
- Not everything can (or should) be monitored, don't try. Monitor only those items which are important. Generally, you will monitor servers and LAN equipment such as routers and switches. It is rare to need to monitor user's actual desktop computers.
- Stick to the K.I.S.S. principle (Keep It Simple Stupid). Don't overcomplicate things.
- Deploy new functionality only as needed.
- Utilize event correlation where possible. Event correlation allows you to match up reported errors in such a way as to provide confirmation of errors and to reduce the number of alarms that are generated due to congestion or processing load. your possible errors and your network's architecture, set priorities and decide which things should trigger alarms.