Novell is now a part of Micro Focus

How to Configure and Customize the Discovery System in ZENworks for Servers 3

Articles and Tips: article

Hemanth Yamijala
Senior Software Engineer
Novell, Inc.
YHemanth@novell.com

01 Oct 2002


This AppNote explains the basics of configuring and customizing the Discovery system of ZENworks for Servers (ZfS) 3 to tailor the discovery process to your particular needs. It also provides some troubleshooting information.


Topics

network discovery, network management, server management, ZENworks for Servers, product configuration

Products

ZENworks for Servers 3

Audience

network administrators, support technicians

Level

intermediate

Prerequisite Skills

familiarity with basic network management concepts

Operating System

NetWare, Windows NT/2000

Tools

none

Sample Code

no

Introduction

The Discovery system is a feature of the ZENworks for Servers (ZfS) 3 Management and Monitoring Services component. It is the logical starting point for managing devices and networks. Using this feature, you can automatically populate the database with the information about the discovered devices and networks.

The Discovery system runs as multiple processes on the ZfS site server. Some of these are NLMs, which constitute a system called "NetXplorer" or NXP, while others are Java-based processes referred to as "services." The data discovered by these processes is populated in the database. Additional algorithms are applied on this data to create "maps" that graphically depict the layout of the devices and networks on the ZfS console.

This AppNote introduces you to the features of the Discovery system and explains the preparatory steps that you need to perform prior to using this feature. It also describes the advanced configuration options that will help you discover the devices and networks. Where necessary, usage scenarios are described to help you decide when to use these advanced features. Common troubleshooting tips are provided at the end to help you troubleshoot errors encountered while using the Discovery system.

You can configure most of the Discovery system using the Discovery Console Utility (NXPCON) that is shipped with ZfS. Some of the configuration options require you to edit configuration files directly. We recommend that you make a backup copy of the original configuration files before modifying them. If you modify these files while the system is running, you need to restart the system for the changes to be effective.

Preparing for Discovery

This section talks about the preparatory steps that you need to do before using Discovery. You first need to configure various options for Discovery to discover the devices and networks. You may also need to configure various devices so that they can get discovered. The options that you need to configure are listed below:

  • Configuring SNMP community strings

  • Configuring router discovery

  • Configuring Discovery to use LANalyzer Agents

  • Configuring Discovery of DNS names

  • Configuring a Discovery scope

Prior to configuring the various options before you use Discovery, it is useful to understand the entities that are discovered by the different modules of the discovery system and the dependencies on external factors like routers and LANalyzer Agents.

The following table describes the entities that are discovered by the different modules of the Discovery system and the dependencies they have on external factors.


Discovery Process
Entities Discovered
Dependencies

NXPIP

Routers, networks connected to routers

SNMP community strings, access control list on routers

NXPIPX

IPX devices

SAP filtering, SNMP community strings

NXPLANZ

Following attributes of hosts: - IP/IPX address - MAC address

LANalyzer Agents installed, SNMP community strings

IPGroper

Following attributes of any IP device: - IP/MAC addresses - DNS names - Services hosted on devices,   such as ZfS Management   Agents, HP printers, and so on

SNMP community strings, DNS server configuration, router discovery or LANalyzer Agent discovery, access control list on routers

SN3 discovery

NetWare servers NDS names of servers Services hosted on devices

SNMP community strings

Bridge discovery

Which machines are connected to which ports

SNMP community strings

Note that SNMP is used extensively to discover devices. The identification of various devices and their attributes is driven almost exclusively by using SNMP information.

For IP discovery (particularly host discovery), routers and LANalyzer Agents are two important classes of devices that can help in discovering information about the network. The router's ARP tables contain information about the MAC and the IP addresses that the router knows. The LANalyzer Agent provides information about machines which generate traffic on the network. These two help in efficiently discovering several machines from a single source, instead of relying on more traffic-intensive discovery methods, such as Ping sweeps and so on.

Configuring SNMP Community Strings

SNMP uses a character string called the "community string" or "community name" as a means of authenticating machines that can get SNMP data back from a device. The default value of the community string is "public".

To discover devices using SNMP, the community names of the devices should be configured in Discovery. You can use the NXPCON utility to configure these community names.

To configure the SNMP community names using NXPCON, follow these steps:

  1. Prepare a list of all the SNMP community names of your devices.

  2. Launch NXPCON.

  3. Select Configuration Options > SNMP > Edit Community Name List. Edit the community names in this list (see Figure 1).

    Configuring SNMP community strings.

The order in which you enter the community names in NXPCON can significantly affect the speed of discovery. The rule of thumb to follow is: the greater the number of devices which are configured with a given community name, the higher up this name should appear in the community name list configured in discovery.

For example, suppose your network of 100 servers contains 20 switches or routers with the community name "acme", 10 servers with the community name "public_ acme", and the rest have the default "public" as the community name. The order you should specify these in the NXPCON utility is:

  • public

  • acme

  • public_acme

Configuring Router Discovery

Discovery communicates with the routers using SNMP. Most routers have SNMP support. In order for your routers to respond to the SNMP requests, make sure you have turned on SNMP support and configured the community strings in the NXPCON in the correct order.

In addition to community strings, some routers provide additional mechanisms to restrict access to their data through the use of an Access Control List (ACL). The list will contain the IP addresses of the devices that are allowed to receive SNMP responses from the routers. Because the ACL is more restrictive than a community string, it would not help to have the correct community string if the access control of the router restricts SNMP communication to a machine. Hence, you need to specify the IP address of the ZfS site server that runs Discovery in the access control list in order for Discovery to find the router.

You can configure two types of routers in the discovery system. A "seed router" is an IP address of a router from where Discovery will automatically start discovering other routers. An "additional router" is an IP address of a router which you want Discovery to query apart from the ones it can automatically discover.

By default, the NetWare server running Discovery is configured to work like a router even if it has only one interface. This is because NetWare servers act like routers by default. In this case, the discovery server itself acts like a seed router.

You can configure a different seed router for Discovery in the following scenarios:

  • You do not want to configure the site server as a router.

  • You would like discovery to discover routers starting from a different router elsewhere in your network.

You can configure additional IP routers for discovery in the following scenarios:

  • You do not want to configure the site server as a router.

  • You might want to discover only networks which are not where the site server is running.

  • You might have a different corporate networks connected across the public Internet, say using a VPN.

In such cases, you must specify a different seed router or add additional routers to be discovered using NXPCON. The routers you specify should be the ones that are connected to the networks you are interested in discovering.

To configure a seed router, follow these steps:

  1. Launch NXPCON.

  2. Select Configuration Options > IP Discovery > IP Router Discovery > IP Seed Router.

  3. Enter the IP address of the seed router.

To configure an additional router:

  1. Launch NXPCON.

  2. Select Configuration Options > IP Discovery > IP Router Discovery > Additional IP Router.

  3. Insert the IP addresses of the additional routers (see Figure 2).

    Configuring router discovery.

Configuring Discovery to Use LANalyzer Agents

If you are unable to grant access rights to the ZfS site server at your routers, you can use LANalyzer Agents to discover information about your network. For example, if the configuration and maintenance of the routers of your corporate network is handled by a different group of administrators who may not be willing to give SNMP access to these critical devices to the ZfS site server, you can use LANalyzer Agents to discover the information about this network.

LANalyzer Agents are a Novell implementation of the RMON (Remote Network Monitoring) MIB. In addition to the standard RMON groups, these agents implement additional SNMP groups which collect information about the hosts on a segment. Each agent can passively sniff packets flowing on the segment and learn about MAC and IP address bindings. By querying this information using SNMP, Discovery can easily retrieve information about new hosts quickly.

To configure LANalyzer Agents, follow these steps:

  1. First, identify the network segments that you want to discover and install a LANalyzer Agent on each network segment.

  2. Launch NXPCON.

  3. Select Configuration Options > NXPLANZ Discovery.

  4. Input the names and IP address of each of the agents you installed. Set the Agent Type to LANalyzer Agent (see Figure 3).

    Configuring Discovery to use LANalyzer agents.

If your network uses switches, you need not install a LANalyzer Agent on every port of the switch. You can install the agent on any one of the ports. Because of the general way in which hosts behave, the agents learn about hosts that are connected to various ports of a switch, not just the one to which the LANalyzer Agent is connected. From time to time, ARP requests are sent by hosts to discover information about other hosts. As these requests are broadcast to all the ports of the switch, the LANalyzer Agent also learns this information. Although this information will not have the accuracy of an agent in a shared media segment, it is effective in discovering hosts and therefore speeding up discovery.

Configuring Discovery of DNS Names

You need to configure DNS on the site server running Discovery for discovery of DNS names. If you have not configured DNS on your NetWare server at the time of installation, use INETCFG to configure DNS. Based on the frequency with which you change the DNS names on your network, you can adjust a configuration parameter in the Discovery system to control how often Discovery tries to refresh the information about DNS names of the machines it has discovered.

To configure discovery of DNS names, follow these steps:

  1. Edit the NXP.INI file in the install_folder\ZENWORKS\MMS\ MWSERVER\NMDISK directory.

  2. Locate the string "DNSRefreshRate" in the NXP.INI file. The value for this parameter is specified in seconds; the default is 3600.

  3. Modify this value to specify your refresh time.

Configuring a Discovery Scope

When you run Discovery, the information about all the devices on all the subnets is discovered by default. If you are interested in managing only a few subnets on your network, you can configure a discovery scope to discover only those specific subnets.

To set a discovery scope, you need to identify all the subnets you want to manage and then configure the discovery scope in NXPCON.

To configure a discovery scope, follow these steps:

  1. Launch NXPCON.

  2. Select Discovery Modules > Discovery Scope > IPX Discovery Scope or IP Discovery Scope (see Figure 4).

    Configuring a discovery scope.

The Discovery system does not work on non-contiguous scopes. If you want to discover non-local segments of the ZfS site server, you must configure the Discovery system with the additional routers and/or LANalyzer Agents present on the segment you want to manage, as described in earlier sections.

In such a case, you must set the scope to include the following entries:


IP Address / Subnet Address
IP Mask or Subnet Mask

IP address of the site server

255.255.255.255

IP address of the routers/agents you added to the list

255.255.255.255

Address of the subnet you want to manage

Subnet mask

The above configuration options enable you to run Discovery to manage the devices and networks on your management domain. However, there are additional configuration options that enable you to enhance the speed of Discovery and customize it further based on specific needs. The next section provides information on the additional configuration options.

Additional Configuration Options

To enhance the speed of Discovery and to customize it to your specific needs, the following additional configuration options are available:

  • Increasing the speed of IP host discovery

  • Discovering important devices quickly

  • Customizing which discovery modules to run

  • Customizing the stopping and starting of discovery

Increasing the Speed of IP Host Discovery

The presence of all IP devices of your network may not be apparent when you query routers or LANalyzer Agents. IP host discovery uses an ICMP ping to detect the presence of IP devices apart from the ones that are discovered using routers or LANalyzer Agents. The ICMP ping has a set timeout value to query the IP devices. By default, this value is set to 4 seconds. You can configure the default value before starting Discovery to improve the speed of the IP host discovery. In case you are on a network which does not span across WANs, or if you consider 4 seconds to be a high duration to reach any device from the ZfS site server in your network, you can reduce this timeout value.

To configure the ICMP timeout value, follow these steps:

  1. Edit the NXP.INI file in the install_folder\ZENWORKS\MMS\ MWSERVER\NMDISK directory.

  2. Locate the string "ICMPTimeout".

  3. Reduce the value of this parameter. (The minimum value you can specify is 1 second.)

Discovering Certain Important Devices Quickly

File-based discovery is a new feature in ZfS 3 which enables you to discover only specific hosts instead of all the hosts of your network. For example, you may have a very large network comprised of several workstations and non-critical servers, and you may be interested in managing only part of this large network. In this case, you would not want to wait for the Discovery process to completely discover the entire network.

You can use file-based discovery to discover all information about any SNMP-enabled device. You need to specify the IP addresses of the devices or specify the range of IP addresses that you want to discover. These addresses are specified in the DISCNODES.TXT file.

File-based discovery can also be very helpful in the following scenarios:

  • You have very few devices (like only few NetWare servers) which you are interested in managing, and you feel that running the whole discovery system is an unnecessary overhead.

  • The devices you have are not in the same segment as the ZfS site server, and you cannot give the ZfS site server access permissions to the routers connecting these segments.

  • Some of your machines are not discovered.

  • You want to start by managing some selected servers out of a very large set of devices, which by default could take a long time to discover.

To use file-based discovery, identify the devices you want to discover and then follow these steps:

  1. Create a DISCNODES.TXT file and place it in the install_folder\ZEN- WORKS\MMS\MWSERVER\NMDISK directory. This file can be created either before starting discovery or while discovery is running.

  2. Specify the list of address in the following format:

    <IP address of the device>, <subnet mask of the device>

    You can also specify wildcards in the IP address string to indicate a set of addresses.

  3. Start the Discovery process if it is not already running.

Note: The information discovered using file-based discovery is not automatically refreshed.

Customizing Which Discovery Modules to Run

The Discovery system is made of several modules that discover specific information. However, you can turn off modules that discover information you are not interested in. For example, if your network does not contain any switches or you are not interested in seeing a map that is organized according to switched topology, you can disable the switch discovery from running. By turning off unneeded modules, resources that these modules would have otherwise consumed can be reused by other modules, thereby increasing the efficiency of the system.

Configuring NLMs. To customize which NetXplorer modules to run, follow these steps:

  1. Launch NXPCON.

  2. Select Configuration Options > Discovery Modules. You could alternatively select Configuration Options > IP Discovery > IP Host Discovery. (Use this option to configure the IP Host discovery or the IP Groper.)

  3. Configure modules you do not need to run with "No" (see Figture 5).

    Configuring which discovery NLMs to run.

Configuring Java Processes. Here is the procedure to configure the Java processes related to discovery.

The SLOADER.PROPERTIES file from the install_path\ZENWORKS\MMS\ MWSERVER\PROPERTIES folder contains sections that describe the Java processes that form a part of the ZfS site server. The Java processes related to discovery are described in the sections marked by these names:

  • Topology Manager

  • Bridge Discovery

  • SN3 Discovery

The format of the Java process is as specified in this example:

[Topology Manager] Name = Topology Manager Load Option = auto <Other options>

Follow these steps to configure the Java processes:

  1. Change the value of the "Load Option" key from "Auto" to "Manual" to prevent the process from starting the next time the SLOADER command is typed on the server console.

    Note: If you modify the Properties file after the site server has already started, you must restart the ZfS site server for the changes to take effect.

  2. The "Load Sequence" and "Arguments" options in the Properties files are necessary for the site server to work correctly. Do not change these options.

Customizing the Starting and Stopping of Discovery

You can choose to stop or start the discovery NLMs or the Java discovery processes without affecting the other services of the site server like the Alarm Manager Service.

Stopping and Starting Discovery NLMs. To stop the discovery NLMs, type the following command at the server console:

UNXP

To start all the discovery NLMs, type the following command at the server console:

NETXPLOR

This cannot be done while the Java discovery services are running. In case the Java discovery services are running, first stop them, as described below, and then type the NETXPLOR command.

Stopping and Starting the Java Discovery Services. To stop the Java discovery services, type the following command at the server console:

STOPDIS

To start the Java discovery services while SLOADER is running, type the following command at the server console:

STARTDIS

You can customize the starting or stopping any of the Java discovery processes at any point in time. For example, you might have decided to not run Bridge discovery initially, but changed your mind later and decide to run it anyway. In such a scenario, you need not stop all the services and restart them. You can edit the STARTDIS.NCF file in the \ZENWORKS\MMS\MWSERVER\BIN directory, which has the following contents:

MWSETENV.NCF

java -Xbootclasspath/p:$mwxbpath -classpath $MMSCP;$CLASSPATH com.novell.utility.servicemanager.ui.Start "Topology Manager" "Bridge Discovery" "SN3 Discovery" <ip address of site server> sloader

In this file, the names like "SN3 Discovery" match the names of the sections in the sloader.properties file described above. By changing just the names in the NCF files, you can create similar NCF files to selectively stop and start the Java discovery services.

For example, in order to start just the Bridge discovery process, you can create a STARTBRI.NCF file with the following contents:

MWSETENV.NCF

java -Xbootclasspath/p:$mwxbpath -classpath $MMSCP;$CLASSPATH com.novell.utility.servicemanager.ui.Start "Bridge Discovery" <ip address of site server> sloader

Copy this NCF file into the \ZENWORKS\MMS\MWSERVER\BIN directory. You can then run the STARTBRI.NCF file to start the Java discovery bridge service that was not loaded initially.

You can follow the same procedure to stop Java discovery processes. For example, to stop the SN3 Agent process, create a STOPSN3.NCF file with the following contents:

MWSETENV.NCF

java -Xbootclasspath/p:$mwxbpath -classpath $MMSCP;$CLASSPATH com.novell.utility.servicemanager.ui.Stop "SN3 Discovery" <ip address of site server> sloader

Troubleshooting Discovery

Some of the common troubleshooting scenarios and solutions are described below. You can refer to the Management and Monitoring Services Troubleshooting Guide (http://www.novell.com/documentation) for specific information.


Problem Description
Possible Causes
Suggested Actions

Unable to discover routers

- Incorrect SNMP configuration - Unable to reach the router

- Check the SNMP configuration, as explained below. - Specify the Ip address of the router using NXPCON in the additional routers or seed routers table.

Unable to discover servers

- Incorrect SNMP configuration - Invalid scope

- Check the SNMP configuration, as explained below. - Try using file-based discovery.

Unable to discover the network segment, or the network segment is displayed in islands

- No routers or LANalyzer Agents on the segment are discovered - Segment is not in scope

- Install a LANalyzer Agent and specify the address in NXPCON . - Check your scope settings.

Unable to discover a switch, or a switch is discovered as a machine called "Switch on x.x.x.x"

- Incorrect SNMP configuration for the switch

- Check the SNMP configuration, as explained below. - Try using file-based discovery by specifying the IP address of the switch.

Over-consolidation of network segments

Some machines on the segment have one MAC address bound to different IP addresses incorrectly

Correct the configuration of these machines.

If you want to build the topology from beginning, you need to copy the empty database before restarting Discovery.

Note: Copying the empty database will result in loss of information, including alarms and other configuration information.

Checking the SNMP Configuration

This section provides you information on how to check the SNMP configuration to troubleshoot problems that you encounter during discovery.

To validate if there is any SNMP configuration issue or access control issue with a device, follow these steps:

  1. From the ZfS console, launch the MIB browser.

  2. Enter the IP address of the device.

  3. Enter the SNMP READ/GET community string.

  4. From the table below, select the node in the MIB tree according to the type of device.


    Type of Device
    Node to Query

    Router

    iso.org.dod.internet.mgmt.mib-2.system

    Switch

    iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dTp. dot1dTpFdbTable and then iso.org.dod.internet.mgmt.mib-2.dot1dBridge.dot1dstp

    Any SNMP instrumented device

    iso.org.dod.internet.mgmt.mib-2.system

    Click the Tree Walk button. If you get any results at this stage, the configuration is correct. If not, ensure that SNMP configuration on the machine is correct.

Conclusion

To conclude, let's review the key points covered in this AppNote. First, the ZfS Discovery system comes with a default configuration that works well for most simple networks. The minimum configuration required for running the discovery system in ZfS includes the following configuration options in the NXPCON:

  • Configuring community strings of the devices

  • Enabling routers for SNMP support

  • Installing LANalyzer agents on the important segments

  • Configuring the DNS on the site server

  • Setting up a scope

You can further optimize the discovery system using NXPCON or by editing certain configuration files. Some of these configuration changes include modifying timeouts of protocols, editing the refresh rate parameters, using file-based discovery, and customizing the starting and stopping of discovery services.

Using these configuration options, you can effectively use the discovery system to obtain a good map of the network that you want to manage.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates