Posted Thu, 01 Jan 2015 06:00:00 GMT by Portal Admin

Traffic Generated by InterMapper's Monitoring

InterMapper uses several techniques to determine whether a device is working properly. This technical note describes the network load that these techniques place on a network for a particular device on a map. The techniques involved are:

* Ping testing: InterMapper pings a device to elicit a ping response.
* SNMP Probes: InterMapper uses SNMP queries to retrieve one or many pieces of information from a device.
* TCP Probes: InterMapper establishes a TCP connection to the device, sends certain strings and parses the returned information.

The remainder of this note describes the number of packets/bytes of polling traffic generated by various kinds of probes. To compute the total amount of polling traffic that will be created, you must multiply the figures below by the number of each probe that's active, and also by the frequency/polling interval that you specify.

Ping Traffic

InterMapper sends 20-byte ICMP Echo requests, and expects to receive a 20-byte response. These are sent at the Poll Interval shown in the lower left corner of the map window. (You can also set an individual device's poll interval separate from the map-wide default by selecting a device and choosing Monitor > Set Poll Interval...)

InterMapper sends the ping request, then waits up to the device's Timeout (Monitor > Set Timeout...) for a response. If it doesn't hear a response, it sends a second and third ping, etc. up to the number of retries specified in the Map Settings > Device thresholds window.

InterMapper will never start a new poll (e.g., send a new ICMP Echo request) before hearing a response, or waiting the specified timeout.

SNMP Traffic - SNMP Traffic Probe

When InterMapper queries a device with the SNMP Traffic probe, several SNMP packets are exchanged with the target device to retrieve values for the desired parameters. InterMapper differentiates between two types of parameters: configuration information that changes infrequently and operational information that is updated on every poll. When InterMapper probes a device for the first time, InterMapper queries both configuration and operational parameters. On subsequent polls however, InterMapper only queries the operational parameters to minimize the network bandwidth used in polling. Periodically, every 12 hours, InterMapper re-queries the configuration information to check for changes.

InterMapper's regular polling places a minimal load on the network. This load can further be reduced by increasing the poll interval for your maps. Since InterMapper only polls data for visible interfaces, you can also reduce the polling load by hiding interfaces on devices that you do not want polled.

When polling an SNMP device, InterMapper bunches several SNMP variables (or OID's) into each SNMP request. To minimize the processing time of each target device, InterMapper maintains only one request outstanding to each device; the next request in the polling sequence is not sent until a response is received to the previous one. Upon receipt of a SNMP response, InterMapper sends the next request (unless the response is the last one in the poll.)

Code:
Number
   Visible  Bytes Per
Interfaces  Poll
         1  1232
         2  1232
         3  1848
         4  2464
         5  3080
         6  3696
         7  4312
         8  4928
         9  5544
        10  6160
      more  616 bytes/interface


Each SNMP packet (request and response) includes overhead in the form of an 8 byte UDP header and a 20 byte IPv4 header. In addition, the request has up to 260 bytes for each interface, and the response will have up to 300 bytes for each interface. Therefore, the total polling for each interface is:

(two IPv4/UDP headers at 28 bytes)
+ (one request of 260 bytes each)
+ (one responses of 300 bytes each)

Thus, worst case, the total polling traffic generated on the wire for each visible interface is approximately 616 bytes (combining the request and the response).

The number of SNMP packets generated by the SNMP Traffic probe is related to the number of visible interfaces (N) on the box. Since InterMapper combines as many queries as possible into a packet, the traffic generated is as low as possible.

Due to the vagaries of different SNMP implementations, InterMapper will never poll fewer than 2 interfaces. So N is always >= 2, even for boxes that have only one visible interface.

InterMapper will never begin a fresh poll of a device before the current poll is finished. Thus, if you set the poll interval to 5 seconds, but the SNMP poll takes 9 seconds to complete, the next poll will start in 9 seconds and effectively, the poll interval is 9 seconds for that device.

Other SNMP-Based Probes

InterMapper generates requests for MIB variables based on the OIDs specified in the probes. The same calculations hold as above, except that the average request size will be around 20-30 bytes. The size of the response data varies depending on what is requested. For example, an integer's response will be four bytes; a text string can be unlimited in length, and might easily be hundreds of bytes. The response will also have about 20-30 bytes of overhead. The same 28-byte packet header overheads apply.

TCP Probes

InterMapper's TCP-based probes establish a TCP connection to the device being tested, then exchange a certain amount of information. The probe then breaks the connection.

The amount of traffic that the probe generates is determined by the nature of the probe: InterMapper does not, in general, add any overhead to the transaction.

You must be signed in to post in this forum.