Chapter 3: Discovering Your Enterprise
This section contains the following topics:Discovery (see page 99)
How You Can Combine Running Classic and Continuous Discovery (see page 101)
Classic Discovery Multi-Homed Device Support (see page 102)
Discovery Classification Engine (see page 102)
Discovery Timestamp (see page 102)
How Subnet Filters Work (see page 103)
How Timeout Values Affect Discovery (see page 103)
Discovery Object Creation Rules (see page 104)
Device Not Discovered (see page 114)
Discovering Your Network Devices Continuously in Real-Time Mode (see page 115)
Discovering Your Network Devices on Demand Using Classic Discovery (see page 129)
Discovering IPv6 Network Devices using Common Discovery (see page 138)
Discovery
Discovery is the process by which devices on the network are found and classified and then placed in the MDB as managed objects. Discovery discovers and classifies devices on Internet Protocol (IP). Classic Discovery also supports two non-IP plugins that are fully integrated:
■ Storage Area Network (SAN)--SAN Discovery can be started using the command line or the SAN pages in the Discovery Classic GUI or the Unicenter MCC. It discovers devices that are on a SAN and IP-enabled, as well as access points in the SAN. It automatically creates SAN Business Process Views in the 2D Map.
■ Internetwork Packet Exchange Protocol (IPX) Discovery--IPX Discovery can be started using its own command line (ipxbe) or by using the Discovery Classic GUI. It discovers devices located on an IPX network.
Discovery also determines if a device provides Web-Based Enterprise Management (WBEM) data, and if so, creates a WBEM object in the device‘s Unispace. The Agent Technology WorldView Gateway service locates agents running on the network objects.
Note: An MDB must exist before you can run Discovery to discover your network
100 Administration Guide
Once defined, you can view, monitor, and manage these objects and their Management Information Base (MIB) through the 2D Map, ObjectView, and the Topology Browser. You can manage the entities they represent using Event Management, Agent Technology, and third-party manager applications.
When you install your product, you can decide which type of Discovery you want to use:
■ Classic Discovery is an on demand process that lets you decide which subnets you want to discover and when. You can also configure Classic Discovery to run in regular intervals, which can be used as an alternative to Continuous Discovery and ensures that your discovered environment in the MDB is always current. You can start a Classic Discovery from the Discovery Classic GUI, the Unicenter MCC, the Unicenter Browser Interface, or the command line.
■ Continuous Discovery is event-driven and ongoing. It employs a manager and agents that continuously scan your network in real-time mode for new devices or changes in IP addressing of existing IP devices. You can configure Continuous Discovery for optimal load balancing between the Discovery agents and the Discovery Manager. If you choose this method of discovery, you must install the Discovery agents and the Discovery Manager.
■ Common Discovery is a new tool used for discovery across multiple CA products. In CA NSM r11.2, you can use Common Discovery to discover devices on IPv6 networks. WorldView uses the Common Discovery Import service to poll Common Discovery and populate the MDB with IPv6 network entities. If you choose this method of discovery, you must install the WorldView Manager, MCC, and WorldView Provider. You also must install the Common Discovery component on all servers on which you want to discover IPv6 entities.
Note: We do not recommend that you run Continuous Discovery and Classic
Discovery concurrently on your network. Timing issues could result in the duplication of objects and an unnecessarily heavy load on the network and the MDB. You can however, run a combination of Classic and Continuous Discovery. For more information, see How You Can Combine Running Classic and
Chapter 3: Discovering Your Enterprise 101
How You Can Combine Running Classic and Continuous
Discovery
We recommend that you run a combination of Classic and Continuous Discovery when you want to discover subnets. However, Classic and Continuous Discovery work differently depending on what options you select for both methods. You need to be aware of these differences to avoid creating duplicate devices in the MDB.
■ Classic Discovery and Continuous Discovery name devices differently: – Classic Discovery supports naming a device using its sysname (the
MIB-II value for a device that supports SNMP), which is the default if no DNS name is available.
– Sysnames are not supported by Continuous Discovery, except for routers that do not have valid DNS names for their IP interface cards. To avoid discovering duplicate devices, in Classic Discovery, set the dscvrbe -j option to IP to use the IP address if the DNS name cannot be found. Using IP addresses to name discovered devices ensures that objects are named using the same method and that no duplicates result. Set this option only if DNS is not enabled in your environment.
Note: If you are using the Discovery Classic GUI to run Discovery, select
"Use IP address instead of Sysname."
■ When you run a full subnet discovery using Classic Discovery, stop the Continuous Discovery services.
■ Continuous Discovery discovers only subnets on which an agent is deployed. To discover non-agent subnets because you want to automatically monitor them using Continuous Discovery, you can run the Classic Discovery dscvrbe command to discover a router and all of the subnets it supports, or you can write a script using the dscvrbe -7 option to discover all of the gateways on the desired subnets.
102 Administration Guide
Classic Discovery Multi-Homed Device Support
When a device has more than one physical interface to one or more networks, it is known as a multi-homed device. You can discover and manage multi-homed devices.
When a multi-homed device is discovered, only one instance of the object is created in the MDB. However, objects that represent each of the device‘s IP addresses appear on the 2D Map and in the Topology Browser.
Note: The only multi-homed devices that Continuous Discovery supports are
routers.
Note: By default, interface objects are not created for non-router and single NIC
devices. To enable this, set the InterfaceForAllDevices registry key under HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\Discovery to true. This key is set to false by default.
Discovery Classification Engine
After Discovery discovers devices on your network, the classification engine then classifies these devices according to how you have configured the classification engine. Continuous and Classic Discovery use the same classification engine. The classification engine configuration files let you customize the discovery rules to your environment.
Classification means that a class and subclass is defined for each discovered object, it is added to the MDB, and you can manage the object using CA NSM.
Discovery Timestamp
Discovery maintains a "last seen on the network" timestamp for each device in your network.
This timestamp can help you determine if a device should not be monitored anymore and if it can be removed from the system. Using the information in this timestamp, you can define usage policies. For example, you may conclude that a device that has not been seen by the Discovery process in more than 45 days is no longer valid. This information is stored in the MDB so that you can run queries against this value for inventory reports.
The "last seen on the network" timestamp updates a property that contains the length of time that a device was not seen by the Discovery process. This time can be determined by when a device was last successfully accessed or when network traffic was last seen from the device.
Chapter 3: Discovering Your Enterprise 103
Whenever Discovery runs a ping sweep and successfully addresses an object, it saves this information. The Classic Discovery process updates the MDB
immediately, and the Continuous Discovery process holds this information in the Discovery agent caches until the Discovery Manager requests this information. You can configure the Discovery Manager to poll the agents for this information on a regular basis.
How Subnet Filters Work
Using a subnet filter on large networks with multiple large subnets is
advantageous because you can limit your search to certain subnets within the network, which can mean a shorter Discovery process.
Use a subnet filter to do the following tasks:
■ Limit the scope of Discovery by confining it to a certain range of subnets and devices. For example, if you use the subnet filter 172.24.*.*, for example, only the subnets from 172.24.1.0 to 172.224.255.0 are searched. If there is a subnet called 172.119.1.0, that subnet is not searched because it does not fall in the range specified by the subnet filter.
■ Enter a range of as many as ten filters. The filter statement uses a comma separated format of a1.b1.c1.d1,a2.b2.c2.d2,…a10.b10.c10.d10. Only those subnets passing through filter1 (a1.b1.c1.d1) or filter2 (a2.b2.c2.d2) or filtern (up to 10) will be searched and created as TNG/IP_Subnet. ■ Use the default subnet filter of *.*.*.*, which does not limit the scope of the
Discovery process. After the selected subnets are searched by Discovery, they are placed on a list in the right pane of the Discovery Subnet Management dialog.
You can also use the dscvrbe command to limit Discovery to specific subnets to discover, a range of IP addresses to discover, a range of subnets to discover, or subnets to exclude subnets from the Discovery process. You define the subnets in a text file and then specify this text file using the -8 parameter of the dscvrbe command. This functionality is available only when you use the dscvrbe
command.
How Timeout Values Affect Discovery
The values you specify for SNMP timeout and Ping timeout greatly affects how successful and how long your Discovery takes to run. If you set higher timeout values, Discovery takes longer to run, but has plenty of time to communicate with the devices and obtain the needed information. If you use lower timeout values, Discovery runs faster, but devices may not be classified correctly, or even discovered at all.
104 Administration Guide
If you are discovering routers, we recommend that you use higher SNMP timeout values. You can specify the timeout value in any of the following places, depending on how you are running Discovery:
■ Using the command line by specifying the -W parameter on the dscvrbe command
■ Using the Management Command Center Discovery or Advanced Discovery Wizard Timeouts page
■ Using the Discovery Classic GUI Timeouts box on the Discovery page of the Discovery Setup dialog
Discovery Object Creation Rules
You can define rules to help you create objects in the MDB. These rules are used by the classification engine that is used by Classic Discovery and Continuous Discovery to help you expand and customize the classification and discovery of objects.
You can write object creation rules to perform the following tasks: ■ Reclassify objects using the sysObjectID in the MIB-II.
■ Reclassify objects using additional ports, such as FTP, Telnet, SMTP, and HTTP, to gather information.
■ Reclassify objects by reading the agent MIB for a descriptor to define the class.
Types of Discovery Methods
You can write object creation rules that support the following methods of classification. You can combine these methods using logical ANDs and ORs to classify an object as exactly as possible.
You define these rules in configuration files, methods.xml and classifyrule.xml, that are used by the Discovery process to classify the object before it is added to the MDB. Classification rule files are in XML format and reside in the \Config subdirectory on the Discovery agent.
By tuning the priority and timeout properties, you can configure the system for optimal classification performance. You should give the most successful rule in your environment the highest priority. By default, the highest priority rule is Generic SNMP. However, if you have very few native SNMP installs in an environment, you should give a different rule the highest priority. For example, if you have many CA NSM agents installed, the SNMPAgentOID rule results in the best performance.
Chapter 3: Discovering Your Enterprise 105 SNMP
Uses a certain port and community string for classification. You can customize your rule files by adding a new general method to the
methods.xml file or by changing the existing SNMPGeneric string. All pattern matches for the results of SNMP queries are specified in the classifyrule.xml file. Review the classifyrule.xml file for more information about how to classify by evaluating SNMP query results.
Telnet reply pattern match
Attempts to establish a Telnet session, and returns the Telnet login screen if successful. In the classification methods, this screen can then be matched with a default pattern. The Telnet method could also be described as ―screen scraping‖ of the Telnet login screen. Default classification rules are supplied for all major operating system vendors. In many environments, these login screens are standardized. You can modify the Telnet classification rules by entering your own pattern matches if you have specialized login screens. Telnet methods specify a state computer that usually consists of establishing the connection and then waiting for the amount specified in the timeout parameter. After the timeout is reached, the connection can be closed.
UDP/TCP port scanning (socket)
Socket type methods scan ports of a computer to retrieve a port map that can be used to identify what type of device was discovered on the network. The desired port combination can be defined in the classifyrule.xml file (see this file for examples). In the port combination, you can specify whether a port should be found at all. For example, the absence of a Telnet port may signify that the device could be a Windows computer. You can now combine this rule with the NetBios port scan (SocketWindows_NetBios method) to describe the port layout of the computer so that the computer can be classified as correctly as possible. You can configure port scans for TCP/IP or UDP. You can specify pattern matches in the classification rule in the classifyrule.xml file if you know the byte pattern.
MAC address patterns
Specifies the first six bytes of a MAC address in the filter of a classification rule.
HTTP response pattern match
Queries a computer using the HTTP protocol and returns the response. The response is matched with a byte pattern in the classifyrule.xml file. Default methods are provided by Discovery.
SMTP
Attempts to establish an SMTP session with a mail server. The SMTP method is very similar to the Telnet and FTP methods. You can customize this method to fit different types of mail servers. The default method supplied by the default Discovery configuration files works for Microsoft Exchange Mail servers.
106 Administration Guide FTP
Attempts to establish an FTP session with the computer and returns the FTP login screen. The FTP method is very similar to the Telnet method.
How You Modify or Write Classification Rules
You can modify the classification rules in the classify rule.xml file provided with the CA NSM, or you can write additional Discovery classification rules to refine the classification of your network devices.
To write Discovery classification rules, follow this process:
1. Modify existing rules or add new rules to the classifyrule.xml file in the
discovery_install\config directory.
2. For Continuous Discovery, move classifyrule.xml and methods.xml to the \config folder on each Discovery agent for which the rules apply. Then restart the agent.
Note: Each Discovery agent can have a different set of rule files. You may
want to do this if you want to each agent to classify devices differently. For Classic Discovery, run ruletodbconverter.exe on the classifyrule.xml file in the discovery_install\config directory on the computer where the MDB resides. Then run Discovery.
Note: For Classic Discovery, you do not need to move the rule files from the discovery_install\config directory. Only one set of rule files is required.
How to Enable Classification of New Classes
After you write new class rules, you can enable classification of these rules using the following process:
1. Create a new class in WorldView using ClassWizard or TRIX with an associated sysObjID.
2. Open a command prompt, and navigate to DISC_INSTALL_PATH\bin. 3. Run the updateclassrules utility.
4. Run the ruletodbconverter command.
methods.xml file--Configure Classification Methods
The methods.xml file defines the methods that are used by the Discovery classification engine to classify discovered devices. The methods are based on existing protocol plugins supported by Discovery. The methods.xml file is located in the discovery_installdir\config folder, and contains the following methods:
Chapter 3: Discovering Your Enterprise 107 SNMPGeneric
Uses the common MIB-II sysobjid entries to classify a computer. SNMP must be installed on the computer that is to be discovered. Contains the following parameters:
Port
Default: 161 Community
Default: public
Timeout (in milliseconds) Default: 2000
SNMP_AgentOID
Finds Agent Technology common services (if aws_sadmin was configured to respond to SNMP requests). Contains the following parameters:
Port
Default: 6665 Community
Default: admin
Timeout (in milliseconds) Default: 4000
SNMP_SysEdgeAgentOID
Finds active CA SystemEDGE agents and evaluates their operating system information. Contains the following parameters:
Port
Default: 1691 Community
Default: public
Timeout (in milliseconds) Default: 4000
108 Administration Guide
SNMPSuspect_AP
Finds special wireless access points in an environment. If there are none, remove this method from the configuration file for better performance. All references to a removed method must be deleted from the classifyrule.xml file. Contact Technical Support for help with this type of rule modification. Contains the following parameters:
Port
Default: 161 Community
Default: public
Timeout (in milliseconds) Default: 2000
SocketWindows_DS
Scans for the Windows domain server port. Contains the following parameters:
Port
Default: 445 InitDataLength
Default: 100
Timeout (in milliseconds) Default: 2000
TCP
Default: True SocketWindows_NetBios
Scans for the Windows NetBios port. Contains the following parameters:
Port
Default: 139 InitDataLength
Default: 100
Timeout (in milliseconds) Default: 2000
TCP
Chapter 3: Discovering Your Enterprise 109 SocketUnix_RPC
Scans for the RPC port, which is a common port on Sun Solaris computers. Contains the following parameters:
Port
Default: 111 InitDataLength
Default: 100
Timeout (in milliseconds) Default: 2000
TCP
Default: True SocketSuspect_AP
Scans ports for suspect access points. Contains the following parameters:
Port
Default: 192 InitDataLength
Default: 116
Timeout (in milliseconds) Default: 2000
TCP
Default: False HTTPGeneric
Sends a generic HTTP request to a device. User ID and password are not specified. If the device has a web service that returns a login screen or an error screen, a pattern in that response can be matched with classification rules in classifyrule.xml. Contains the following parameters:
Port Default: 80 Timeout Default: 1000 UserID Default: " " Password Default: " "None
110 Administration Guide
HTTPAuthenticate
Sends an HTTP authentication request to a device. Contains the following parameters: Port Default: None Timeout Default: 1000 TelnetWithSend
Attempts to establish a Telnet connection and sends bogus data. Some specialized devices will not acknowledge Telnet commands without a subsequent send. Contains the following parameter:
Timeout
Default: 1000 TelnetGeneric
Attempts to establish a Telnet connection and returns the Telnet login screen if successful. Contains the following parameters: