25.1.1 Key concepts of discovery
This subsection describes briefly the major changes that were made from NNM to NNMi. For details about discovery in NNMi, see Discovering Your Network in NNMi Help.
All information is stored in a single relational database.
An easily configurable integrated discovery engine is used.
The spiral discovery process enables you to continuously update the topology information as changes occur in the network. This enables you to discover topology changes (both inventory and Layer 2) more frequently than would be possible using a set re-discovery interval.
All discovery-target nodes are counted toward the node count restriction set by the license, regardless of the management mode (MANAGED, UNMANAGED, or OUT OF SERVICE). The number of nodes that are discovered cannot exceed the license restriction.
Auto-discovery has the same meaning in both NNMi and NNM, but the configuration approach differs.
- In NNMi, you must first define an auto-discovery boundary, specify at least one IP address, and then run discovery.
- NNMi auto-discovery uses an expanding model. NNMi auto-discovery discovers and manages all routers, switches, and subnets within the specified boundary. In NNMi, you specify the additional device types to be discovered and managed.
- Note
In the default, only SNMP nodes are discovered.
Seeded discovery has the same meaning in both NNMi and NNM, but the configuration approach differs.
- In NNMi, you specify a discovery seed through the user interface.
- NNM seed files can be used in NNMi without any modifications.
- The nnmloadseeds.ovpl command in NNMi replaces the loadhosts command in NNM.
NNMi configuration polling (nnmconfigpoll.ovpl) replaces NNM demand polling (nmdemandpoll) used for determining the device configuration information.