When not to use autodiscovery

Using autodiscovery is not advised in the following deployment configurations:

• SNMPv3 devices

• IPv6 networks.

  Autodiscovery is applicable to the discovery of SNMPv1 or v2c devices that use IPv4 addresses.

• The managed network uses many SNMP read community strings.

  By default, autodiscovery allows four read community strings; you can increase the number by reconfiguring the MaximumCommunities parameter in the discovery.conf file. In some cases, because dozens or more strings might be used, discovery filtering might become impractical.

  In addition, in a secure environment, you might not want to use community strings because a device might write a community string to a syslog file when the IP Manager polls the device with a string that does not match the device’s string.

• The managed network employs an inventory database that is being used to commission devices.

• New devices are constantly being phased-in.

  During the phase-in period, the devices are accessible on the network, but they are not fully operational and they are being tested. Though you intend to eventually add the devices to the topology, adding the devices at this point would cause spurious notifications, or would fill the IP Manager’s Pending Devices list and obscure devices that should be discovered.

• Specific devices are accessible on the network but will never be managed.

  For example, an ISP might not want to discover the client-side devices that are accessible on a physical interface of a router or switch that is managed by the ISP. If the client-side devices do not have a well-defined naming convention or can change without notice, you might have difficulty in defining discovery filters and exclude filters that ensure that the client-side devices are not discovered or are not placed on the IP Manager’s Pending Devices list.