23.1 Understanding Network Discovery
The NetExplorer™ software drives the discovery process on the management server. The discovered information is populated in the Topology database. The Atlas Manager creates a related atlas database which encapsulates the topology information and adds information related to how the user views the maps.
The following sections will help you understand the network discovery process:
23.1.1 Discovery Components
The NetExplorer and Consolidator software that runs on the management server aids in discovering your network and updating the database.
Your network is automatically discovered by NetExplorer when you start it for the first time.
Figure 23-2 shows the discovery components on the server:
Figure 23-2 Discovery components on the Server
The NetExplorer system consists of the following interdependent components:
Discovery
The discovery software resides on the management server and uses the discovery NLM™ software to discover the various network devices.
-
Nxpip.nlm discovers IP routers on IP networks and sends IP router information to discovery. It communicates with the IPCACHE module to share this information with IPGROPER.
-
IPGROPER detects IP host addresses and the following services: Domain Name System (DNS) names, Dynamic Host Configuration Protocol (DHCP) services, Telnet, Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP).
-
Nxpipx.nlm discovers various NetWare® systems on IPX™ networks and sends information about systems to NetExplorer.
-
Nxplanz.nlm communicates with Traffic Analysis Agents for NetWare and Windows* to gather information about all systems communicating on the segments that are monitored, and sends this information to discovery.
Figure 23-3 illustrates the architecture of the discovery system and shows the roles of the various components, network systems, and agent software.
IMPORTANT:Discovery uses the server and traffic management agents to obtain certain discovery information. Though not required, using these agents across your network enhances the accuracy and detail of logical maps displayed by Novell ConsoleOne.
Figure 23-3 Purser of the Discovery system
Supported Protocols
Novell ZENworks Server Management software supports the Service Location Protocol (SLP) on NetWare networks to enhance the discovery speed.
The server management and Traffic Analysis Agents for NetWare use the Service Advertising Protocol (SAP) to identify themselves to other components. SAP filtering prevents routers from passing SAP packets. To enable the management server and Novell ConsoleOne to receive the SAP packets that identify manageable servers, Hub Management Interface (HMI) hubs, and other servers, configure the router that is filtering SAP packets to list the specific SAP numbers that it should pass. NetWare systems and ZENworks Server Management components use the SAP numbers listed in Table 23-1.
Table 23-1 SAP Numbers used by the NetWare systems and ZENworks Server Management
Consolidator
The Consolidator software resides on the management server and performs the following tasks:
-
Reads the NetExplorer data files, which contains all the discovered information.
-
Interprets the records in the netxplor.dat file.
-
Checks whether the system has already been created in the Topology database. If the system does not exist in the Topology database, the Consolidator creates the system.
-
Uses the Bridge agent to query the Bridge Management Information Base on IP networks and discovers which systems are connected to a port of a bridge.
-
Uses the SN3 agent to get the Novell eDirectory name of NetWare servers. The SN3 agent enhances the performance of discovery by using SLP to discover NetWare servers.
-
Runs the mibcompiler.rule file on all the discovered devices and verifies for the MIBs mentioned in the rule file on these devices and updates the database. You can also add or delete the MIBs in the mibcompiler.rule.
-
Writes discovery information to the Novell ZENworks Server Management database.
Figure 23-4 shows the tasks of the Consolidator. Netxplor.nlm creates the netxplor.dat file and the Consolidator starts reading the records from the file. If NetExplorer processes are restarted, the netxplor.dat file is re-created and the Consolidator requests the first record in the new file.
When the Consolidator retrieves a record from the netexplor.dat file, it searches for the record in the database. If the system is not in the database, the Consolidator inserts it and notifies the Atlas Manager of the update.
Figure 23-4 Consolidator Tasks
Command Line Options
If you want to manually operate the Consolidator, use the command line options shown in Table 23-2.
Atlas Manager
The Atlas Manager software consists of a server and a client component. The server component resides on the management server along with the Novell ZENworks Server Management topology database. The Atlas Manager server component retrieves discovery data from the topology database and creates its own atlas database.
The client component of the Atlas Manager resides on Novell ConsoleOne. The server component can communicate with several console components at any given time. Any changes made to the maps on the console (for example, rename, import, and layout) are communicated to the Atlas Manager server component, to update the atlas database.
Figure 23-5 shows the Atlas Manager server and client software:
Figure 23-5 Atlas Manager server and client software
The Atlas Manager looks for a rule in its rules table to help classify the system. The rules help the Atlas Manager make decisions, such as which icon should be used to display the system on the maps. If the system in the record matches one of the rules, the Atlas Manager updates the database according to the rule.
Database Object Editor
The Database Object Editor supplements the discovery system. Sometimes auto discovery might not discover devices on your network, or might display incorrect information of the devices on your network. You can use Database Object Editor to add the missing entities into the database or to edit incorrect information of the entities.
The Database Object Editor client uses ConsoleOne snap-in to display the user interface. Using the Database Object Editor, you can perform operations on a segment or a node.
The Database Object Editor Server interacts with the Consolidator to process information related to the node and segment object and populates the topology database with this information.
You can use the Database Object Editor to add or delete a segment or a node and modify the segment or the node information.
To add a segment or a node:
-
In ConsoleOne, select , then click > > .
-
Enter the details for the segment or the node.
-
Click .
To edit the information about the segment or the node:
-
In ConsoleOne, select the segment or the node you want to edit.
-
Click > > .
Modify the required information.
-
Click .
To delete the segment or the node:
-
In ConsoleOne, select the segment or the node you want to delete.
-
Click > > .
To add or delete list of MIBs to a node:
-
In ConsoleOne, select the node where you want to add/delete the MIBs.
-
Click > > .
-
Select Implemented MIBs on the left pane to add or delete MIBs.
To add or delete list of services to a node:
-
In ConsoleOne, select the node where you want to add/delete services.
-
Click > > .
-
Select on the left pane to add or delete services.
NOTE:If you install the LANalyzer service on a node, the RMON service is also automatically installed because the LANalyzer service cannot function without the RMON service. The Service pane of the Database Object Editor displays LANalyzer service only.
To add, delete, or modify the interfaces of a node:
-
In ConsoleOne, select the node whose interfaces you want to add/delete/modify.
-
Click > > .
-
Select on the left pane to add/delete/modify interfaces.
To modify operating system of a node:
-
In ConsoleOne, select the node whose operating system you want to modify.
-
Click > > .
-
Change the type of Operating System in the field.
To add, delete, or modify the switch port to the end node connectivity:
-
In ConsoleOne, select the switch whose connectivity needs to be added/deleted/modified.
-
Click > > .
-
Select on the left pane to add/delete/modify switch port to node connectivity.
Working with Unnumbered Links
Unnumbered links are point to point links between routers with no IP address bound to interfaces on the two ends of the WAN link.
The Router Discovery Module (NXPIP) discovers unnumbered WAN links between routers using the following methods:
-
Auto Discovery of Unnumbered Links: In this method, the router tables for each router is obtained. The unnumbered links between two routers are identified by correlating the routers that point to each other.
-
Manual Configuration of Unnumbered Links: You can use this method of discovery in scenarios where auto discovery fails to discover a link or incorrectly discovers a link. Using the nxpip.ini file you can specify a link between two routers having unnumbered interfaces or prevent auto discovery from creating a link. Refer to the nxp.ini file in the installation_directory\novell zenworks\mms\mwserver\nmdisk directory for configuration details.
If the interface type of the unnumbered link that is discovered is not a PPP, ATM, FrameRelay, or X 25, the unnumbered link will be created with the interface type as unknown.
To enable the unnumbered link discovery, make the following changes in the netxplor.ncf file:
-
Open the netexplor.ncf file in the installation_directory\novell zenworks\mms\mwserver\nmdisk directory.
-
Locate the line Load NXPIP. If you are unable to find this line, use NXPCON to enable the NXPIP module. This line will now be added to the netexplor.ncf file.
-
Add the following options: /autould/iniuld. The line should now read as follows: Load NXPIP /autould/iniuld.
NOTE:Add any one of the numbered IP address of the routers to the additional routers list. For more information on how to add the additional routers, see Specifying a Seed Router and Additional IP Routers.
When you restart NetExplorer, the unnumbered links will be discovered and displayed in the atlas namespace.
Viewing the Unnumbered links in the Atlas Namespace
To view the unnumbered links on a router:
-
Go to the properties page of a router.
-
Select the tab.
-
Thefield displays the string Unnumbered IP Address (n), where n is the number of unnumbered interfaces of the router.
To view the unnumbered links on a segment:
-
Go to the properties page of a segment.
-
Select the tab.
The Unnumbered Network string is used in the field to display the network number of the unnumbered link.
Using the tab in the Database Object Editor you can add, modify, or delete the unnumbered links for the router. The unnumbered links includes the interface type and the connected router. All the unnumbered links you created and configured will be displayed in the list.
Figure 23-6 Unnumbered Links
Adding an Unnumbered Link
-
In the tab, click.
-
In the drop-down list, select the interface type of the router.
-
Click to select the router that you want to connect.
-
Click .
Editing an Unnumbered Link
-
In the tab, select the unnumbered link you want to edit from the list, then click .
-
In the drop-down list, modify the interface type of the router.
-
Click to select the router that you want to connect.
-
Click .
Deleting an Unnumbered Link
-
In the tab, select the unnumbered link you want to delete from the list.
-
Click .
If you delete any of the connected node, the corresponding unnumbered link will be deleted. All the information pertaining to the unnumbered link will be updated in the database.
Management Console Software
The management console software snaps in to Novell ConsoleOne. Management sites are created in Novell ConsoleOne. In each site, an atlas is created that maintains the integrity of the discovery information.
Additional Novell ZENworks Server Management Components
The nxpip.nlm, nxpipx.nlm, and nxplanz.nlm software operate in conjunction with the following components:
Traffic Analysis Agent for NetWare Servers
The Traffic Analysis Agent for NetWare is a set of NLM files that provides traffic analysis of Ethernet, Fiber Distributed Data Interface (FDDI), or token ring segments. The Traffic Analysis Agent discovers all systems on the segments it monitors, regardless of the protocols the systems use. You can monitor multiple segments by placing agents on each segment.
The nxplanz.nlm software on the management server uses SNMP to query servers running the Traffic Analysis Agent for information about each system that resides on their segments.
IMPORTANT:For an effective discovery process, you should have the Traffic Analysis Agent monitoring each source-routed token ring segment.
Server Management Agent for NetWare Servers
To discover IPX servers and workstations, managed servers are any NetWare servers with the server management agent installed. Server management agents respond to SNMP queries from nxpipx.nlm with the username and address of those workstations that are logged in to the server. Nxpipx.nlm obtains SFT III™ server information from the server management agent. For effective results, you should install a management agent on every NetWare server on your network.
Bindery of Novell NetWare Servers
Nxpipx.nlm queries all NetWare servers for information in their binderies. All NetWare servers allow their binderies to be examined by the discovery process when their security settings are set to the default values.
For the NetExplorer NLM software to discover the login names of workstations attached to a NetWare server, a server management agent must be installed on the server.
23.1.2 Discovery Process
NetExplorer discovers your network continually. The following sections discuss the discovery processes:
Discovery Cycles
When you first start discovery, you should let it run as long as necessary to build the baseline data. Very small networks might take one or two hours, while very large networks (several thousand nodes) might require a day or two to be discovered.
The discovery process occurs in cycles. A cycle is the process by which a discovery module identifies every node it can at a time. You can configure discovery on the server to discover only certain addresses, thus reducing the duration of a cycle. For more information, see Changing the Discovery Scope.
The initial cycle continues until no additional devices are discovered. This initial cycle gathers information that might be insufficient to classify certain devices or to identify the correct segment for each device. Further discovery cycles provide additional, new, and changed information. As discovery cycles proceed, the information becomes more accurate.
Each discovery process queries the network using different methods to discover systems. Four independent discovery modules run in the order mentioned below during each discovery cycle:
-
IP router discovery on IP networks only.
This process, run by the NXPIP module, starts from the local router. Using the local router's routing table information, NXPIP discovers other routers on the network. It then uses the routing table information to further discover the network. This process is repeated for each router discovered.
The NXPIP module stores the router address information and information about any IP-bound network device in the IPCACHE module.
Nxpip.nlm is installed on the management server. It uses SNMP to discover IP routers. To use this NLM, your management server must also be running TCP/IP bound to at least one of your network's interface boards. Nxpip.nlm uses MIB-II information, such as the system table, routing table, interface table, interface data-link type and frame type, and segment data-link type. Note that because there are different versions of MIB-II implementations for different vendors, the information you receive might differ.
IMPORTANT:If you have specified an additional level of control by allowing certain IP addresses to perform SNMP queries to the routers, ensure that the IP address given to the Novell ZENworks Server Management server is privileged to query all the routers in the network. Otherwise, discovery will not be complete, and incomplete network information will appear in the Islands page of the atlas.
-
IP discovery of workstations and servers.
This process, run by the IPGROPER module, receives the router and network information written into the IPCACHE by the NXPIP module as the input. RMON, based discovery run by the NXPLANZ module also writes the information about the networks and IP hosts that it discovers into IPCACHE. This also acts as an input to the IPGROPER module.
It queries each router that has been discovered by NXPIP for its ARP tables, identifying each active IP host on the network. For IP addresses that are not found in the ARP table of any of the routers, IPGROPER tries to ping and identify whether a host by that IP address is alive.
IPGROPER queries each IP host that is identified to be alive for information about the following hosted services: HTTP, DHCP, Telnet, SMTP, and DNS. It also verifies whether the server management software and the Traffic Analysis Agents are installed and running on this host.
Simultaneously, the IPGroper module queries the DNS server specified in the sys:\ect\resolv.cfg file on the management server for the DNS names of all these IP hosts.
IMPORTANT:For a server or a segment to be manageable, it is important to discover the server management agent and the Traffic Analysis Agent running on an IP host on that server or the segment.
-
IPX discovery on all networks, including NetWare/IP networks:
This process, run by the NXPIPX module, starts at the management server itself to discover its IPX address, the LAN type of each adapter, and SAP information about other known devices and their services. After gathering this information, NXPIPX requests the same types of information from each device listed in the bindery. This process is repeated each time NXPIPX discovers a new device.
Nxpipx.nlm uses a variety of NetWare, SNMP, and IPX protocols, such as IPX diagnostics, to discover NetWare servers, IPX routers, and IPX workstations.
IMPORTANT:When nxpipx.nlm is loaded, a working directory named NXPWORK is created by default under the installation_volume\install_dir\Novell ZENworks\mms\mwserver\nmdisk subdirectory. During installation, you can specify a different path to create the NXPWORK subdirectory. NXPIPX puts all of its temporary files in this directory. Do not read, modify, or delete any file in this directory because this might cause some discovery process to not function.
-
RMON based discovery of IP Hosts.
This process, run by the NXPLANZ module, starts by identifying all the remote agents, which includes the Traffic Analysis Agents for NetWare and Windows. The Traffic Analysis Agents on a segment discover devices based on the IP address to MAC address binding data contained in packets that are transmitted on the segment. The NXPLANZ module on the management server retrieves the data by using SNMP to communicate with the Traffic Analysis Agents.
The NXPLANZ module reports information about the Traffic Analysis Agents on your network and the IP hosts on the segments monitored by these Traffic Analysis agents to NetExplorer. The information about the networks monitored by the Traffic Analysis Agents and IP hosts on the monitored networks is also written to IPCACHE to enhance the effectiveness of service discovery by the IPGROPER module.
Figure 23-7 shows NXPLANZ querying Traffic Analysis Agents software on segments B and C, respectively.
Figure 23-7 NXPLANZ Querying Traffic Analysis Agent Software
To improve the effectiveness of the discovery, ensure that the Traffic Analysis Agent is installed and running on each network segment that you want to discover. If SLP is disabled on your network or if SAP packets are filtered by the routers in your network, NXPLANZ may not be able discover all the Traffic Analysis agents in the network.
In order to ensure that all the Traffic Analysis agents on your network are being queried by the NZPLANZ or NXPLANZ module, specify these Traffic Analysis agents explicitly using NXPCON.
During the initial discovery cycle, these modules run sequentially. As a result, information about the Traffic Analysis Agent software is discovered late.
In later discovery cycles, the four modules run concurrently. They continue their discovery processes, but send only new or changed data to netxplor.nlm. As additional data arrives, segments can be consolidated, devices can be placed on the appropriate segments, and new devices can be discovered.
Each succeeding cycle of different discovery NLM files has the potential to provide key information that finally identifies a device and provides sufficient data for NetExplorer to consolidate the data.
The data discovered by the NLM processes is communicated to Novell ConsoleOne through the Atlas Manager. Figure 23-8 shows the relationship of the discovery NLM processes, NetExplorer, and Novell ConsoleOne. See Discovery Process for a description of how these pieces operate together to discover the contents and topology of a network.
Figure 23-8 The relationship of the discovery NLM processes, NetExplorer, and the management console
Table 23-3 summarizes the default seed and scope and user-definable changes for each discovery module:
Table 23-3 Summary of the default seed, scope and user-definable changes for each discovery module
Continuous Discovery
NetExplorer discovers the internetwork on which it resides, through a process initiated and controlled by netxplor.nlm. Initially, each discovery NLM identifies itself to netxplor.nlm, which then begins the initial discovery cycle. The cycle starts with NXPIP discovery, followed by NXPIPX discovery, and finally NXPLANZ discovery. The discovery cycles of IPGROPER are not controlled by netxplor.nlm. After starting, it runs continuously. Information gathered by NetExplorer is stored in the netexplor.dat file on the management server.
In Figure 23-9, each of the discovery processes is shown in relationship to time. After NXPIP finishes its first pass, NXPIPX begins and NXPIP starts over. After NXPIPX finishes its first pass, NXPLANZ begins and NXPIPX starts its second pass.
Unless otherwise directed, all three of the discovery processes run continually to detect changes to the network. Any changes to the network are saved as records in the netexplor.dat file. When all three discovery processes have completed one pass, the initial discovery cycle is complete.
Figure 23-9 The discovery processes in relationship to time
The following sections describe each sequence in greater detail:
NXPIP
The first sequence in the NetExplorer discovery cycle involves the discovery of IP routers. NXPIP locates its local router using TCP/IP configuration information. NXPIP then queries the router for the identity of other routers on the network. NXPIP queries the MIBs on the routers using SNMP to collect the IP addresses, interface types, and MAC addresses.
By default, NXPIP attempts to discover your entire IP network. You can restrict the scope of the IP discovery by specifying the scope information in NXPCON.
NXPIPX
NXPIPX uses a series of techniques, including SNMP, RIP, IPX, and SPX™ diagnostics to discover the attached IPX or NetWare/IP internetwork. After NXPIP completes its first pass, NXPIPX begins discovery at the management server. NXPIPX examines its own server and discovers the names of other servers. It then queries each of these servers to discover more servers and repeats this process until no more servers are found.
In addition, NXPIPX reads the connection table of each NetWare server to determine which NetWare clients are logged in to the server. NXPIPX sends IPX diagnostic packets to each client to collect additional information. NXPIPX will not discover clients that do not appear in the connection table because they have not been logged in recently and clients whose diagnostics are turned off. It is therefore important to leave IPX diagnostics enabled on NetWare clients.
NXPIPX also discovers IPX routers in your network. Third-party IPX routers are discovered only if there is a NetWare server on the routed segment. NXPIPX does not discover interface information when routed segments do not have NetWare servers.
By default, NXPIPX attempts to discover your entire IPX internetwork. You can restrict the scope of discovery by specifying a list of IPX network numbers using NXPCON. For NXPIPX to discover other IPX nodes ensure that one of the IPX numbers is bound to the management server.
NXPLANZ
The Traffic Analysis Agent for NetWare monitors every packet on the network segment it is installed on. It creates a list of physical (MAC) addresses and IP addresses of all the systems communicating on the segment on the local memory. After NXPIPX completes its first pass, NXPLANZ uses SNMP to query all servers with Traffic Analysis Agents installed to read the list of workstations communicating on the network. NXPLANZ also obtains a list of the agents running on the servers from NXPIPX.
IPGROPER
The information about the routers and network segments written into IPCACHE by NXPIP, and the information about network segments, and hosts written to IPCACHE by NZPLANZ forms the input to the IPGROPER module. For each network segment, IPGROPER tries to discover all the hosts on that network, the DNS names of the hosts, the services hosted on them, server management agents, and Traffic Analysis Agents.
NETXPLOR
As the discovery processes gather information about systems on the network, they forward packets of related data to netexplor.nlm. Netexplor.nlm places these packets, along with a record number and a time stamp, into the netexplor.dat file, as shown in Figure 23-10.
NOTE:Discovery re-creates the netexplor.dat file each time you load netexplor.nlm. Therefore, the discovery data stored at the management server from previous runs of the NetExplorer NLM processes is not retained when you restart netexplor.nlm.
Figure 23-10 Discovery process of NETXPLOR.NLM
SNMP Community String Discovery
Each time NetExplorer tries to access a system through SNMP, it uses the community strings that have been configured using the NXPCON utility on the management server. When it encounters a new system, it tries each of the configured community strings. After it has found a community string for a particular IP or IPX address, it records this name in a file so that in subsequent cycles it does not need to retry with the other configured names.
You can view these community strings using NXPCON. The community strings are used in the order specified. Therefore, the most-used community string should be configured first in the list.
IMPORTANT:An SNMP query with an invalid SNMP community string results in no response from the target system and the request times out.
23.1.3 What Is Discovered
NXPIP, NXPIPX, and NXPLANZ use a variety of techniques to discover the following categories of network objects and present them in the atlas:
Generally, information gathered by NXPIP and NXPIPX is sufficient to place systems on the network maps correctly. When NXPIP and NXPIPX have not discovered systems, NXPLANZ retrieves MAC addresses collected by the Traffic Analysis Agent software and the new systems are added to the database. Consequently, all systems are discovered on segments monitored by the Traffic Analysis Agents.
Systems
Table 23-4 shows the different types of systems discovered:
Table 23-4 Types of systems discovered
The different types of services discovered are Telnet, HTTP, DNS, SMTP, DHCP, Routers, Novell eDirectory, SFTIII, and SNMP.
The following sections contain more information about the various systems that are discovered:
Novell NetWare Client Workstations
NXPIPX discovers all Novell NetWare client software attached to discovered NetWare servers. Clients that are turned off or are not attached to a server are not discovered. For this reason, a NetExplorer process that is run at night or on a weekend might not yield a complete map. Note that NetWare clients must have IPX diagnostics enabled.
When you configure a NetWare client to perform a bindery login, consider the scenarios in Table 23-5:
Table 23-5 Bindery Login Scenarios
When you configure the client to perform a directory login, NetExplorer discovers only those systems that are logged in to an Novell eDirectory tree and not those that are merely attached to the Novell eDirectory tree. NXPIPX uses SNMP community string to communicate with the management agent and query on all NetWare servers for the username.
After NetExplorer discovers a NetWare client, NXPIPX queries the client using the IPX diagnostic protocol to confirm the discovery and gather more information about it. If IPX diagnostics are turned off, NXPIPX does not report the system. This applies to printers as well.
IP Routers
NXPIP uses SNMP to query all IP routers on the network by using the SNMP community string used by the routers. You must enter the list of community strings used by your routers using NXPCON.
You can configure this information into the router's MIB by using any SNMP configuration tool, including the SNMP MIB browser. If you configure router information such as the system name in the routers SNMP MIB, the discovery process records it in the database, allowing IP routers to be displayed with meaningful names.
By default, IP discovery discovers the entire network. The exploration can be restricted by specifying network numbers using the NXPCON Discovery Scope, and then IP Discovery Scope option. Also, if there are redundant IP routers, use the NXPCON IP Discovery, an then the IP Routers option to specify the redundant IP router address; otherwise, NXPIP does not discover it. As shown in Figure 23-11, if the management server IP address is 130.57.12.0, the IP discovery NLM discovers the entire 10.57.85.0 network and its subnets.
Figure 23-11 shows how Novell ZENworks for discovers IP routers:
Figure 23-11 Novell ZENworks for discovery of IP routers
Novell NetWare SFT III
A NetWare SFT III™ server usually consists of two computer systems, each containing an input/output engine (IO engine) and a mirrored server engine (MS engine). Therefore, physically there are two IO engines and two MS engines; logically there are two IO engines and one MS engine.
If Novell Server Management Agent is loaded on an SFT III server, the MS engine and both IO engines are discovered correctly with their names and placed in the correct segment in the atlas. However, the MS engine is placed in the Islands page. This happens because the two MS engines are associated with only one logical server on the network, and the location of the MS engine might change depending on which copy of the MS engine is the primary at any given time.
Figure 23-12 illustrates NetWare SFT III server discovery:
Figure 23-12 Server discovery for NetWare SFT III
If the server management agent is not loaded on the MS engine, Discovery discovers only the MS engine and the IO engine that are primary at the time of discovery. The primary IO engine is labeled Noname in the area page. To change the name of an IO engine on a segment map, right-click the icon and click Rename.
Systems Not Equipped with the IPX Diagnostic Responder
NXPIPX discovers the following systems, but does not necessarily place them correctly in the atlas:
-
NetWare for UNIX* servers
-
Portable NetWare
-
Access servers
-
Modem servers
-
Print servers
Because these systems do not respond to IPX diagnostics, they cannot answer queries from NXPIPX. Consequently, the LAN information required to place them on the maps might not be available. In this situation, NetExplorer places these systems in the Islands page of the atlas. In most cases, the presence of a Traffic Analysis Agent on each segment on which these systems appear, enables NetExplorer to obtain the missing information and correctly locate the systems in the maps.
If these systems are running IP, they will be discovered and placed correctly in the maps.
Routers that Use Duplicate MAC Addresses
NetExplorer can experience difficulties in discovering some routers because of the method routers use to identify their adapters. In some cases, the same MAC address is used on several network interfaces of a router. In these cases, it appears to NetExplorer that one adapter is connected to multiple segments. Unless otherwise specified, NetExplorer interprets multiple adapters as one adapter.
The multiple segments connected to the adapters are seen as one segment and NetExplorer consolidates the multiple segments.
Third-Party Routers
NXPIP discovers IP-bound interfaces only. When IP is not running on a router, NetExplorer discovers the IPX-bound interfaces, which results in:
-
A separate router icon is shown for each interface in the router.
-
Discovered interfaces are not placed in the same router in the atlas. Therefore interconnections are incorrect on the internetwork map and the router appears as separate, multiple routers, each containing one network interface from the real router.
Figure 23-13 illustrates a router with IPX running on Network Interfaces 2 and 3 but not on Network Interface 1. NetExplorer places this router on the internetwork map as two separate systems. As shown, the connection to Segment 1 is not displayed, and the connections to Segments 2 and 3 are shown attached to two separate systems.
Figure 23-13 Internetwork map connections for an IPX router
Novell NetWare MultiProtocol Router with WAN Ports
Novell NetWare MultiProtocol Router™ (MPR) 3.0 is now bundled with Novell NetWare 5.x.
IPX Networks
Novell NetWare MPR 3.0 reports the correct segment type of the WAN links. NetExplorer detects these correctly and displays them with the appropriate icon.
IPXWAN links between Novell NetWare MPR 3.0 systems do not have an IPX network associated with them. When NetExplorer discovers such a link, it creates a name for the WAN segment of the form #UNNUM -n, where n is an integer assigned to make the segment name unique. On multi-access networks, such as frame relay and X.25, each connection in the network adds another #UNNUM -n to the segment name.
IP Networks
With Novell NetWare MPR 3.0, you can configure both numbered and unnumbered IP links. NetExplorer discovers numbered links correctly. NetExplorer does not discover unnumbered IP links, resulting in the Islands page.
If IP is running on a third-party router and NXPIP is running on the management server, NetExplorer discovers only the IP-bound interfaces. The router is shown correctly in the atlas. If IP is not running on a third-party router but NXPIPX is running on the management server, NetExplorer discovers the IPX-bound interfaces. However, these IPX-bound interfaces are not placed in the same router icon in the atlas.
On-Demand Links
An on-demand link is a WAN connection between two routers in which only user data (no routing traffic) is exchanged across the link. The link is brought up only when there is data to send.
NetExplorer discovers on-demand IP and IPX links correctly, if sufficient static routing information has been configured to allow the management server to reach the other side of the on-demand link.
However, if a link is an on-demand and unnumbered IP link, the entire topology on the remote end of the link is not discovered. Click IP Discovery, and then the Additional IP Routers in the NXPCON utility to configure an additional IP router address for the missing router.
Third-Party Routers with WAN Ports
NetExplorer discovers third-party routers correctly if they support MIB-II SNMP. Certain third-party routers can have a WAN link with no IP or IPX network number on the link In this case, the WAN link is not discovered.
Novell NetWare Connect Servers
NetExplorer discovers Novell NetWare Connect servers; however, if you have more than one Novell NetWare Connect® server on the network, NetExplorer consolidates them and they appear as one server.
Virtual Switches
A virtual switch is represented by the same icon used for a switch or bridge in the atlas maps. The display name of a virtual switch is always shown as the “switch on IP address of network.” It is primarily used in atlas maps to display a meaningful network topology when discovery information is incomplete. Since the addresses are not known, the MAC address of the virtual switch is specified as an Ethernet Port or Token Ring Port or FDDI Port based on the connectivity type.
A virtual switch is shown in atlas maps under the following conditions:
-
When two or more different physical media are connected by a switch, but the switch is not yet discovered. The virtual switch disappears as soon as the real switch is discovered.
-
When two or more different physical media are connected by a switch, the switch is configured with SNMP community strings other than public, and the SNMP community strings of the switch were not provided through NXPCON before starting discovery.
-
When two or more different physical media are connected by a non-manageable switch or a hub.
Network Segments
NetExplorer discovers the following network segments:
NetExplorer cannot fully discover the following:
LAN and WAN Segment Types
NetExplorer discovers the LAN and WAN segment types shown in Table 23-6:
Table 23-6 List of Known and Unknown segments in CIM database
These values are discovered correctly if a system connected to the segment responds with an interface type from MIB-II RFC 1573.
Source-Route Bridged Token Rings
Atlas Manager displays source-route bridged token rings depending on whether the Traffic Analysis Agent for NetWare is installed on each ring.
-
If you do not have the Traffic Analysis Agent for NetWare installed on each source-route bridged token ring in your network, NetExplorer discovers the network but consolidates all source-route bridged token rings that share the same IPX network number or IP subnet into a single segment. For example, in Figure 23-14, rings R1, R2, and R3 are displayed as one segment, and rings R4 and R5 are displayed as another segment on the internetwork map.
-
If you have the Traffic Analysis Agent for NetWare installed on each source-route bridged token ring, each Traffic Analysis Agent for NetWare discovers its own ring (segment) and every system on it. Atlas Manager displays the ring as a disconnected segment on the internetwork map.
-
If you have the Traffic Analysis Agent for NetWare installed on a source-route bridged token ring connected to a router, the WAN page in the atlas shows the correct connections. However, if two networks each have several rings and only one ring in each network is connected to a router, the WAN page shows the correct connections of only the rings that are directly connected to the router. The other source-route bridged token rings in each network are displayed as disconnected segments on the WAN page.
Figure 23-14 illustrates this second case:
Figure 23-14 Internetwork Map Connections for Source Route Bridge Rings
In all cases, bridge information is not discovered. As a result, discovery treats each interface of a source-route bridge as a separate system on the network. One icon appears in the atlas for each interface of the source-route bridge.
When you have the Traffic Analysis Agent for NetWare installed on one server on each ring of an IPX source-route bridged network, the segment names displayed on the WAN page consist of the IPX network number followed by the MAC address of that server's interface to the ring. If the Traffic Analysis Agent for NetWare is monitoring more than one interface, the address shown for a ring is the MAC address of the interface monitoring that ring.
Transparent Bridges
Discovery cannot completely discover transparent bridges. It consolidates groups of transparently bridged segments running the same network number into a single segment on the maps.
Configuration Changes
Discovery detects most changes in the network topology, such as the addition, reconfiguration, or deletion of interfaces, resulting in changes being made to the atlas. However, if you remove the system from the network, it is not detected unless you move it to another location in the network.
23.1.4 File-Based Discovery
The enhancement to the ipgroper.nlm allows the you to use the discnodes.txt file to specify the IP Address and mask of a set of nodes to be discovered. The information about the nodes is obtained through SNMP.
The IPGroper NLM must be loaded with specific options that enable it to receive inputs from the discnodes.txt file. If these options are not provided, the NLM will discover without taking input from the file. Prior to starting the discovery, the discnodes.txt file must be placed in the ZENworks _installation_directory/mwserver/nmdisk directory. After the initial discovery, if you want more nodes to be discovered, you must create a new discnodes.txt file with the new node entries and place it in the same directory. These nodes will be queried in the next discovery cycle.
The discnodes.txt input file has the following format for individual IP addresses:
-
Individual IP Address specification format:
IPAddress <, SubnetMask>
-
Specifying addresses using regular expressions
IPAddress <, SubnetMask>
IPAddress -> AddressPattern
Characters allowed in AddressPattern include the numerals 0-9; the period (.); the question mark (?), which represents one character; and the asterix (*), which represents more than one character, up to a maximum of three.
-
Wildcard characters are not allowed in the subnet mask.
NOTE:164.99.149.0 does not come into the range. ? does not stand for 0 if it is the only letter in the octet.
164.99.149.1?0 - all addresses in the range from 164.99.149.100 to 164.99.149.190. Here ? stands from 0
-
In the text file, any line that begins with a pound sign (#) is treated as a comment line.
File-based discovery can be used in the following two scenarios:
Discovering the Nodes Specified in the file
By default, the Novell ZENworks Server Management installation loads the NXPCON utility with all the discovery modules running and with file-based discovery enabled.
To discover only the nodes specified in the input file:
-
In NXPCON, click > .
-
Select , then press Enter.
-
Select to unload the modules, then press Enter.
-
Press Esc to exit the Discovery Modules dialog box.
-
Click to save changes.
-
Click > .
-
Select , then press Enter.
-
Select , then press Enter.
-
Select to disable autodiscovery of the IP workstation.
-
Make sure that the Enable File-Based Discovery option is set to .
-
Press Esc to exit the IP Host Discovery dialog box.
-
At the Management server prompt, unload NetExplorer by entering unxp.
-
Reload the NetExplorer modules by entering netxplor.
Discovering the Nodes with Other Discovery Modules
By default, the Novell ZENworks Server Management installation starts all the discovery modules along with the file-based discovery. Use the following procedure to individually select the modules that need to be started or to change the configuration.
To discover only the nodes specified in the input file:
-
In NXPCON, click > .
-
Select , then press Enter.
-
Select or to load or unload each module, then press Enter.
-
Press Esc to exit the Discovery Modules dialog box.
-
Click to save changes.
-
Click > .
-
Select , then press Enter.
-
Select , then press Enter.
-
Select to disable Auto Discovery of the IP workstation.
-
Make sure that the option is set to .
-
Press Esc to exit the IP Host Discovery dialog box.
-
At the Management server prompt, unload NetExplorer by entering unxp.
-
Re-load the NetExplorer modules by entering netxplor.
Using Command Line Options for IPGROPER
The ipgroper.nlm has three command line options to discover nodes specified in the discnodes.txt file.
Table 23-7 Command Line Options for IPGROPER
23.1.5 Discovery Console
The Discovery Console enables you to send a request to discover a set of IP addresses using Novell ConsoleOne. You can discover a list of host addresses, all the hosts on a subnet, range of addresses, or addresses in the form of a regular expression. The Discovery Console also enables you to view the status of the requests that you have submitted, or to delete a request.
IMPORTANT:To use the Discovery Console, ensure that IPGROPER is running.
Figure 23-15 Discovery Console
To create and submit a request for discovery:
-
From Novell ConsoleOne, click > .
The Discovery Console dialog box is displayed with a default Request Name.
-
Enter a different request name if you want to change the default request name.
You can perform the following operations:
Add IP Addresses
-
In the Discovery Console dialog box, click
.
-
Provide the following information:
-
IP Address: The host address or a subnet address. You can include wildcard characters while specifying the IP address. Specify the correct subnet mask for a subnet address.
-
IP Address Range: The range of IP addresses to query. For example, 160.100.144.1 - 160.100.144.254.
-
Subnet Mask: The correct subnet mask for a specified address.
-
-
Click .
-
In the Discovery Console dialog box, click .
Edit IP Addresses
-
In the Discovery Console dialog box, select the IP addresses you want to edit, then click
.
-
Modify the required information.
-
Click .
-
In the Discovery Console dialog box, click to submit the request.
Remove IP Addresses
You can remove IP addresses if you have not added the request.
-
In the Discovery Console dialog box, select the IP addresses you want to remove, then click
.
View Status of a Request
This option displays the status details of the request that you have submitted. A request can have one of the following status levels:
-
Pending: The request is yet to be submitted to IPGROPER.
-
Submitted: The request is submitted to IPGROPER.
-
In Progress: The request is being processed by IPGROPER.
-
Completed: The request is processed by IPGROPER.
To view the status of the request:
-
In the Discovery Console, select the request, then click .
You can perform the following operations:
-
Details: Displays the details for the selected request in the table.
-
Delete: Deletes a request you selected. You can delete a request if the status is pending.
-
Refresh: Displays the current status of the requests.
-
23.1.6 Effects of Discovery on Maps
The Atlas Manager on the management server creates an atlas database as the topology database is populated and the information is displayed as maps on Novell ConsoleOne. The WAN page displays all the Area pages and the connecting ro8uters between them. The Area pages display the segments and the connecting routers.
The discovered systems are placed on the Area pages of the atlas based on the connecting routers or bridges. The Islands page contains segments for which routers have not yet been discovered. The Atlas Manager relocates the segments to the correct pages when connecting routers are discovered.
Review the following sections for more information on the effects of discovery on maps:
Name Source Priority
As discovery cycles proceed and more information is discovered, the names displayed in the maps can change. Different priorities are given to names, depending on the source of the name information. If none of the names are discovered, the IP/IPX address of the node is displayed as the node name.
To determine how to display the name of the discovered object, the Atlas Manager uses the following list in the order shown:
-
User Defined Name
-
DNS Name
-
Novell eDirectory Name
-
Bindery Name
-
SNMP Name
Representation of Systems in the Atlas
When representing a system in a map, the Atlas Manager refers to the following list of services in the order shown in Table 23-8. As soon as it associates the first service with the node, it displays it without looking for further matches. The icon may change if a service with a higher priority is detected later during discovery.
Table 23-8 Atlas Manager Services
If a system has either an IPX or IP router service, the Atlas Manager considers it a router and displays it on the appropriate pages and segments.