Hi Adrian,
There are a few different scenarios for how the collector does its discovery.
Strictly in terms of bandwidth, the collector produces very little traffic during discovery. The discovery phase only polls a few general MIBs for the purposes of categorizing the device. This device categorization determines what MIBs will be used on the device during the inventory.
Doing a discovery by a known IP address produces very little network traffic. The collector makes its request directly to the requested IP, receives it, and then doesn’t poll the device again. There is no ongoing polling required.
More specifically:
percent_usage = (elements * packet_size * 8bits_per_Byte)/(network_bandwidth*polling interval)
The discovery uses 24 elements at most. Assuming a 100 Mbps Ethernet connection:
percent_usage = (24*1500*8)/(100,000,000*1) = 0.00288
The means the discovery is using 0.00288 of the available bandwidth and only for that one instance of polling.
Doing a discovery by protocol however, is a different story. The collector makes its request for basic information from the seed IP address and then also polls a table on the device to try and learn about other devices on the network. It then reaches out to these devices and does the same, splintering out through the network according to the number of hops specified in the discovery.
The difference in bandwidth in these two scenarios is very small, but the difference in device impact (CPU usage, etc.) is huge. For example, if you do a routing table discovery on a core network device, the potentially enormous routing table could cause the CPU usage to spike, or disrupt traffic passing through the device. These kinds of discoveries should be scheduled off peak hours.
Cheers,
Lynden
