Understanding Network Discovery
The NetExplorerTM 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:
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.
The following illustration shows the discovery components on the server:
The NetExplorer system consists of the following interdependent components:
- Discovery
- Consolidator
- Atlas Manager
- Database Object Editor
- Management Console Software
- Additional ZfS Components
Discovery
The discovery software resides on the management server and uses the discovery NLMTM 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 IPXTM networks and sends information about systems to NetExplorer.
- NXPLANZ.NLM communicates with Traffic Analysis Agents (LANalyzer®) for NetWare and Windows* NT* to gather information about all systems communicating on the segments that are monitored, and sends this information to discovery.
The following figure 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 ConsoleOne.
Supported Protocols
ZfS software supports the Service Location Protocol (SLP) on NetWare 5.x 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 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 ZfS components use the SAP numbers listed in the following table.
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 eDirectory name of NetWare servers.The SN3 agent enhances the performance of discovery by using SLP to discover NetWare 5.x 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 ZfS database.
The following figure 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.
Command Line Options
If you want to manually operate the Consolidator, use the command line options shown in the following table.
| Option | Allows the Consolidator to |
|---|---|
-notify |
Notify the Atlas Manager that it has updated the database. |
-database data_path |
The specific location of the database file to perform operations on. |
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 ZfS 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 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.
The following figure shows the 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 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 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:
-
From ConsoleOne, select Tools > Database Object Editor > New.
-
Enter the details for the segment or the node.
-
Click OK.
To edit the information about the segment or the node:
-
From ConsoleOne, select the segment or the node you want to edit.
-
Select Tools > Database Object Editor > Edit.
Modify the required information.
-
Click OK.
To delete the segment or the node:
Management Console Software
The management console software snaps in to ConsoleOne. Management sites are created in ConsoleOne. In each site, an atlas is created that maintains the integrity of the discovery information.
Additional ZfS Components
NXPIP.NLM, NXPIPX.NLM, and NXPLANZ.NLM operate in conjunction with the following components:
- Traffic Analysis Agent for NetWare Servers
- Server Management Agent for NetWare Servers
- Bindery of NetWare Servers
Traffic Analysis Agent for NetWare Servers
The traffic analysis (LANalyzer) 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 4.x, NetWare 5.x, or NetWare 6 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 IIITM server information from the server management agent. For effective results, you should install a management agent on every NetWare 3.x, NetWare 4.x, or NetWare 5.x, or NetWare 6 server on your network.
Bindery of 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.
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 ZfS 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 install_volume\install_dir\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 (LANalyzer) Agents for NetWare and Windows NT. 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 LANalyzer agents on your network and the IP hosts on the segments monitored by these LANalyzer agents to NetExplorer. The information about the networks monitored by the LANalyzer agents and IP hosts on the monitored networks is also written to IPCACHE to enhance the effectiveness of service discovery by the IPGROPER module.
The following figure shows NXPLANZ querying Traffic Analysis Agents software on segments B and C, respectively.
To improve the effectiveness of the discovery, ensure that the LANalyzer 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 LANalyzer agents in the network.
In order to ensure that all the LANalyzer agents on your network are being queried by the NZPLANZ module, specify these LANalyzer 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 ConsoleOne through the Atlas Manager. The following figure shows the relationship of the discovery NLM processes, NetExplorer, and ConsoleOne. See Discovery Process for a description of how these pieces operate together to discover the contents and topology of a network.
The following table summarizes the default seed and 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. Once started it runs continuously. Information gathered by NetExplorer is stored in the NETXPLOR.DAT file on the management server.
In the following figure, each of the discovery processes is shown in relationship to time. Once 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 NETXPLOR.DAT file. When all three discovery processes have completed one pass, the initial discovery cycle is complete.
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 scoping information in NXPCON.
NXPIPX
NXPIPX uses a series of techniques, including SNMP, RIP, IPX, and SPXTM 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 NETXPLOR.NLM. NETXPLOR.NLM places these packets, along with a record number and a time stamp, into the NETXPLOR.DAT file, as shown in the figure below.
NOTE: Discovery re-creates the NETXPLOR.DAT file each time you load NETXPLOR.NLM. Therefore, the discovery data stored at the management server from previous runs of the NetExplorer NLM processes is not retained when you restart 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.
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
The following table shows the different types of systems discovered:
The different types of services discovered are Telnet, HTTP, DNS, SMTP, DHCP, Routers, eDirectory, SFTIII, and SNMP.
The following sections contain more information about the various systems that are discovered:
- NetWare Client Workstations
- IP Routers
- NetWare SFT III Servers
- Systems Not Equipped with the IPX Diagnostic Responder
- Routers that Use Duplicate MAC Addresses
- Third-Party Routers
- NetWare MultiProtocol Router with WAN Ports
- IPX Networks
- IP Networks
- On-Demand Links
- Third-Party Routers with WAN Ports
- NetWare Connect Servers
- Virtual Switches
NetWare Client Workstations
NXPIPX discovers all NetWare client software attached to discovered NetWare 3.x, 4.x, and 5.x 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 the following table:
When you configure the client to perform a directory login, NetExplorer discovers only those systems that are logged in to an eDirectory tree and not those that are merely attached to the 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 > IP Discovery Scope option. Also, if there are redundant IP routers, use the NXPCON IP Discovery > IP Routers option to specify the redundant IP router address; otherwise, NXPIP does not discover it. As shown in the following illustration, 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.
The following figure shows how ZfS discovers IP routers:
NetWare SFT III Servers
A NetWare SFT IIITM 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 NetWare 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.
The following figure illustrates NetWare SFT III server discovery:
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 servers
- 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.
The following diagram 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.
NetWare MultiProtocol Router with WAN Ports
NetWare MultiProtocol RouterTM (MPR) 3.0 is now bundled with NetWare 5.x.
IPX Networks
NetWare MPRTM 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 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 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 > 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.
NetWare Connect Servers
NetExplorer discovers NetWare Connect servers; however, if you have more than one 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.
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 will disappear 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 the following table:
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 the following figure, 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.
The following figure illustrates this second case.
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.
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 ZFS-INSTALL-DIR/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 " # " is treated as a comment line.
File-based discovery can be used in the following two scenarios:
- Discovering the Nodes Specified in the file
- Discovering the Nodes with Other Discovery Modules
- Discovering the Nodes with Other Discovery Modules
Discovering the Nodes Specified in the file
By default, the ZfS 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 Configuration Options > Discovery Modules.
-
Select Individual Discovery Modules > press Enter.
-
Select No to unload the modules > press Enter.
-
Press Esc to exit the Discovery Modules dialog box.
-
Click Yes to save changes.
-
Click Configuration Options > IP Discovery.
-
Select IP Host Discovery > Press Enter.
-
Select Enable IP Host Discovery > press Enter.
-
Select No to disable autodiscovery of the IP workstation.
-
Make sure that the Enable File-Based Discovery option is set to Yes.
-
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 ZfS installation will start 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 Configuration Options > Discovery Modules.
-
Select Individual Discovery Modules > press Enter.
-
Select Yes or No to load or unload each module > press Enter.
-
Press Esc to exit the Discovery Modules dialog box.
-
Click Yes to save changes.
-
Click Configuration Options > IP Discovery.
-
Select IP Host Discovery > Press Enter.
-
Select Enable IP Host Discovery > press Enter.
-
Select No to disable Auto Discovery of the IP workstation.
-
Make sure that the Enable File-Based Discovery option is set to Yes.
-
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.
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 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.
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
- eDirectory Name
- Bindery Name
- SNMP Name
- IP Address
- IPX Address
- MAC Address
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. 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.
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.