|
|
During the network discovery process, device discovery is started for the IPs that are to be discovered. The following are steps involved in the device discovery process.
UserDiscovery is invoked for the IP, if the UserDiscovery is configured in userdiscovery.conf. Please refer "User Defined Discovery" for more information.
If SNMP discovery is enabled, SNMP Discovery is performed for this IP. If SNMP discovery succeeds, function in step 5 is performed.
If ICMP discovery is enabled, ICMP discovery is performed for this IP. If ICMP discovery succeeds, function in step 5 is performed.
When both SNMP and ICMP discovery fails, function in step 6 is performed.
Appropriate Objects are constructed and passed through discovery filters. Then the objects are added into the database. If the object is already added, the Properties of the object is updated with the Properties that are currently discovered for this device.
This process now returns to the Network discovery process.
During the discovery process, NMS will send SNMP queries to the Agent (OIDs of system table). If the Agent responds to the SNMP queries, Web NMS will identify that the Agent is SNMP enabled and will add the device as SNMP enabled.
For determining if the Node is a Router or not, additional SNMP queries will be sent to the ipAddrEntry Table of the Agent. If the device does not respond to the additional SNMP queries, Web NMS will not discover the device as a router, but will discover it as an SNMP device.
The criteria on which NMS will discover objects as a router are,
1. Object must have two or more interfaces.
2. "ipForwarding" of the device must be set to 1.
When a router is discovered by NMS, the discovery engine will identify the list of interfaces in the router and the networks to which these interfaces belong to. Based on the value of MANAGE_OTHER_NETWORKS value, the discovery of the networks discovered during router discovery will be started.
Switch discovery is part of the default NMS discovery engine. Switch Discovery is performed by SwitchDiscoveryFilter. You can view the source of this in <Web NMS Home>/default_impl/applications/SwitchMap directory.
The following are the criteria that a device should satisfy to be classified as a switch:
The device should be SNMP enabled.
The device should implement BRIDGE-MIB and should respond to queries for
a) .1.3.6.1.2.1.17.1.2.0 (to get the number of ports),
b) .1.3.6.1.2.1.17.2.6.0 (to get the cost of the path to the root as seen from this bridge) and
c) .1.3.6.1.2.1.17.2.7.0 (to get the port number of the port which offers the lowest cost path from this bridge to the root bridge) OIDs.
If the above criteria are satisfied, then a Switch Object will be added into the database.
To get the list of ports and their properties in the switch you can perform the following queries.
1.3.6.1.2.1.17.1.4.1.2. + (appropriate port value), to get the ifIndex value, defined in MIB-II, for the interface corresponding to this port.
.1.3.6.1.2.1.17.2.15.1.3. + (appropriate port index), to get the port's current state as defined by application of the Spanning Tree Protocol.
3. Queries to get the IfSpeed and IfIndex are sent to the agent with appropriate portindex values appended at the last of the oids .1.3.6.1.2.1.2.2.1.5. and .1.3.6.1.2.1.2.2.1.2.
The port objects are added into the database with the properties collected using the above mentioned queries.
|
|
Note: The Switch discovery performed here is a general implementation. This can be improved based on the type of the Switch you are trying to discover/manage. |
The source code of SwitchDiscoveryFilter.java is available in <Web NMS Home>/default_impl/applications/SwitchMap directory. This default implementation illustrates how switches and switch ports are filtered from the managed objects and added into the database. Refer the README.html to learn how to use the default implementation.
Printer Discovery is performed by PrinterDiscoveryFilter. You can view the source of this in <Web NMS Home>/default_impl/applications/PrinterMap directory.
The following are the criteria that a device should satisfy to be classified as a printer.
The device should be SNMP enabled.
The device should implement Printer-MIB and should respond to query for .1.3.6.1.2.1.43.5.1.1.1.1 (to get the number of ports).
If the above criteria are satisfied, then a Printer Object will be added into the database.
The properties of the Printer object is filled using the following queries to the device.
.1.3.6.1.2.1.25.3.2.1.5.1, to get the current operational state of the device described by this row of the table.
.1.3.6.1.2.1.25.3.5.1.1.1, to get the current status of this printer device.
.1.3.6.1.2.1.25.3.5.1.2.1, to get any error conditions detected by the printer.
.1.3.6.1.2.1.43.16.5.1.2.1.1 to get the content of a line in the logical display buffer of the operator's console of the printer.
.1.3.6.1.2.1.43.17.6.1.5 to get the printer Console Description.
.1.3.6.1.2.1.43.17.6.1.4 to get the printer Console Color.
The above mentioned queries are sent to the device to get more information of the printer object. These properties are stored in the database as Properties of Printer object.
|
|
Note: The Printer discovery performed here can be improved based on the type of the Printer you are trying to discover and manage. |
The source code of PrinterDiscoveryFilter.java is available in <Web NMS Home>/default_impl/applications/PrinterMap directory. This default implementation illustrates how you can add, delete and modify the properties of a specific Managed Object (i.e.printers) using discovery filters. Refer the README.html to learn how to use this default implementation.
|
|
