The Management Station and Collection Station Relationship

You begin your understanding of distributed network management with a clear definition of the two NNM systems in the hierarchy. Let’s emphasize that there are exactly two levels in this hierarchy and that any trickery to attempt to generalize this won’t work, at least as of NNM 6.1 or previous versions. The higher level NNM system in the hierarchy is the management station and the lower level NMM system is the collection station. See Figure 6-1.

The collection station performs autodiscovery, status polling, configuration checking, SNMP data collection, receives SNMP traps, and generates events. It maintains a live database and is authoritative for all this information since it directly manages devices within its management domain. Users log onto the collection station and run ovw sessions as usual. Large corporate networks may have dozens of collection stations, each representing a patch of the quilt that covers the enterprise.

A collection station does not need to run the ovrepld daemon, but it is enabled by default. A filter definition in the filters file defines which objects the collection station will pass on requests to a management station via SNMP. This filter is defined using the command line option -f filter in the ovtopmd.lrf file. This is because ovrepld on the management station uses snmpget and snmpset to communicate with ovtopmd on the collection station. Do not confuse this filter with the discovery filter, which is a different filter definition in the filters file. Recall that the discovery filter is defined in the $OV_CONF/polling file and set in the polling configuration GUI.

Collection stations send status information reliably to management stations via TCP between their pmd daemons. This is in contrast to topology information which is sent to the management station using SNMP.

The collection station volunteers no information except when it is explicitly requested to do so by a management station. The collection station becomes one when the management station initiates the relationship. A collection station may be related to more than one management station. A collection station may be a Windows NT, HP-UX, or Solaris™ system.

A management station initiates the relationship with its collection stations and uploads the various topology patches into a single end-to-end view of the corporate network. If the collection station management domains are defined correctly, each patch fits together into the quilt with no missing sections. Note that the patches may overlap because the management domains do so.

The management station polls each collection station at five-minute intervals by default. This involves SNMP sets and gets. This may appear to be unusual since NNM normally does very little snmpset operations. Network security probes located on the NNM systems and on the network may detect this activity and generate a security alert. Be prepared to work with the security staff to educate them on this subject early in the NNM deployment project.

As the management station uploads objects from the collection station they are placed into the usual NNM databases. The resulting map will contain just these imported devices. The Internet submap will contain hundreds of devices and by default it will resemble wagon wheels within wagon wheels. A map builder will need to customize this map and apply the same care and attention as collection station maps.

A management station need only collect information from collection stations. However, if it is appropriate or necessary, it can also discover and poll some small local management domain. This is fully supported. But given the performance and configuration implications of this approach, the author recommends that autodiscovery be disabled at the management station.