User Guide for Cisco Unified Operations Manager 1.1
Polling?SNMP and ICMP
Downloads: This chapterpdf (PDF - 178.0KB) The complete bookPDF (PDF - 7.82MB) | Feedback

Polling—SNMP and ICMP

Table Of Contents

Polling—SNMP and ICMP

SNMP Versions that Operations Manager Supports

SNMP and ICMP Polling

ICMP Polling

SNMP Polling

How the SNMP Poller Works

Consolidating Requests to Optimize Polling

Coordinating ICMP and SNMP Polling

How Operations Manager Calculates ICMP Polling Intervals


Polling—SNMP and ICMP


The topics in this appendix describe the SNMP versions that Cisco Unified Operations Manager (Operations Manager) supports. They also describe how the ICMP and SNMP polling processes that Operations Manager uses work.

The following topics are covered:

SNMP Versions that Operations Manager Supports

SNMP and ICMP Polling

How Operations Manager Calculates ICMP Polling Intervals

SNMP Versions that Operations Manager Supports

Operations Manager supports SNMP version 1 (SNMPv1), SNMPv2, and SNMPv3 (authNoPriv only) traps for polling and receiving. Operations Manager forwards traps as SNMPv1 traps.

SNMP and ICMP Polling

Operations Manager uses both of the following polling processes:

ICMP Polling

SNMP Polling

ICMP Polling

Operations Manager uses a high-performance, asynchronous ICMP poller. The ICMP poller performs at a consistent rate that is independent of poll response times. Operations Manager achieves this using two asynchronous threads: one that sends polls and one that receives polls. Because the send and receive threads operate asynchronously, slow response times or excessive timeouts do not affect the polling rate.

Figure F-1 shows the four possible states of an element as determined by its response to an ICMP poll.

Figure F-1 Four Possible States of an Element During a Polling Cycle

The four states are Up, Notification Pending, Down, and Clearance Pending.

An element stays in the Up state until it fails to respond to an ICMP poll. When the element fails to respond, it moves to the Notification Pending state until Operations Manager can determine whether it is up or down. If the minimum stabilization period expires or the maximum failure retry count is exceeded before a successful ICMP poll occurs, the element moves to the Down state. Operations Manager does not poll the element again until the next scheduled polling cycle.

An element stays in the Down state until it responds to an ICMP poll. When the element responds, it moves to the Clearance Pending state. If the maximum success retry count is exceeded or the minimum clear pending time expires, the element returns to the Up state.

IP addresses that are unresponsive to ICMP polls are added to a "do not poll" list. The SNMP poller checks this list before sending an SNMP request. For more information, see SNMP Polling.

SNMP Polling

Operations Manager uses an SNMP poller that is synchronous and multithreaded. By default, the SNMP poller uses 10 synchronous polling threads. The SNMP poller supports the following SNMP versions:

SNMP V1

SNMP V2C

SNMP V3 (Authentication and access control, but no data encryption)

SNMP poller uses high-capacity 64-bit counters for data analysis. This capability is critical for performance analysis of high-speed data links where 32-bit counters may wrap between polls.

Operations Manager can support polling for devices with multiple IP addresses because the SNMP poller supports multiple IP addresses for each SNMP agent. The SNMP poller automatically switches to an alternate IP address during failures, ensuring the integrity of Operations Manager analysis during outages.

How the SNMP Poller Works

The SNMP poller's MIB variable poll list is driven by a just-in-time polling algorithm. As a result, only those MIB variables needed for analysis are polled. For example, if a port monitored for performance data is disabled or goes down, the Operations Manager domain manager revokes the SNMP poller's request to monitor performance data for that port, and the SNMP poller automatically removes the relevant MIB variables from the poll list. If the port is re-enabled or comes back up, the variables are automatically put back onto the MIB poll list.

Consolidating Requests to Optimize Polling

Issuing a single SNMP GET request that requests 10 variables is more efficient than issuing 10 GET requests that each request a single variable. The SNMP poller consolidates as many attributes as possible into a single SNMP GET request. Polling consolidation is not restricted to variables from the same SNMP table. It continually adapts to changes in the MIB variable poll list.

If the SNMP poller encounters recoverable errors during a GET request, it suspends polling of the affected variable and continues to poll the other variables. For example, a MIB variable might become unavailable due to a configuration change. This capability enables the SNMP poller to operate efficiently during unexpected changes to a device's configuration.

Coordinating ICMP and SNMP Polling

Synchronous polling has one drawback: attempting to poll a device that is down reduces polling throughput. This happens because the poller must wait for the initial poll and the subsequent retry polls to time out before polling the next SNMP agent. The problem is exacerbated by the large timeout and retry values that are often required to handle agents that are slow to respond.

The Operations Manager domain manager eliminates this problem by linking its SNMP and ICMP pollers. Operations Manager avoids sending SNMP requests to agent addresses that are known to be unreachable. (The ICMP poller is asynchronous and does not slow down, even in the event of a total network outage.)

IP addresses that are unresponsive to ICMP polls are added to a "do not poll" list. The SNMP poller checks this list before sending an SNMP request. If the SNMP agent address is on the "do not poll" list, the request is not sent. If the SNMP agent has multiple IP addresses, each address is checked against the list. If an alternate address does not appear on the list, the request is sent to that address. If all addresses for an agent are on the list, the agent is deemed unreachable, and all SNMP requests to that agent are temporarily suspended.

As soon as an agent's IP address becomes responsive, the address is removed from the list, and SNMP polling resumes. The net effect is that Operations Manager can support large SNMP timeout and retry values without suffering from polling slow-downs during network outages.

How Operations Manager Calculates ICMP Polling Intervals

Operations Manager calculates ICMP polling intervals for a system (for example, a switch or router) as an offset of the reachability setting's polling interval for a system. System reachability is monitored using a combination of ICMP (Ping) requests for IP status and SNMP requests for interface, port, and card status. If a device does not respond to an ICMP poll, it is placed on a "do not poll" list.

Operations Manager calculates ICMP polling intervals as an offset of the reachability setting's polling interval for a system. The following is an example of a calculation based on the default value of 240 seconds.

1. Operations Manager calculates the offset using this formula:

offset = 60; 
If (offset > pollingInterval * 0.5) { 
offset = pollingInterval * 0.5; 
}

2. Operations Manager calculates the ICIM polling interval using this formula:

icimPollingInterval = pollingInterval - offset

Thus, the default polling intervals are as follows:

ICMP polling interval is 3 minutes.

SNMP polling interval is 4 minutes.