IBM Tivoli Netcool/Omnibus Ping Probe: Reference Guide Chapter 1

IBM® Tivoli® Netcool/OMNIbus Ping Probe 7.0

Reference Guide March 2, 2012

IBM

SC23-6009-07

Note Before using this information and the product it supports, read the information in Appendix A, “Notices and Trademarks,” on page 13.

Edition notice This edition (SC23-6009-07) applies to version 7.0 of IBM Tivoli Netcool/OMNIbus Ping Probe and to all subsequent releases and modifications until otherwise indicated in new editions. This edition replaces SC23-6009-06. © Copyright International Business Machines Corporation 2007, 2012. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents

About this guide...... v Document control page...... v Conventions used in this guide...... v

Chapter 1. Ping Probe...... 1 Summary...... 1 Installing probes...... 2 Data acquisition...... 2 Ping file...... 3 Host status...... 4 Name resolution...... 4 Peer-to-peer failover functionality...... 4 Properties and command line options...... 5 Elements...... 9 Error messages...... 9 ProbeWatch messages...... 10 Running the probe...... 11 Limitation...... 12

Appendix A. Notices and Trademarks...... 13 Notices...... 13 Trademarks...... 14

iii iv About this guide

The following sections contain important information about using this guide. Document control page Use this information to track changes between versions of this guide. The IBM Tivoli Netcool/OMNIbus Ping Probe documentation is provided in softcopy format only. To obtain the most recent version, visit the IBM Tivoli Netcool Information Center: https://www.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/common/Probes.html

Table 1. Document modification history

Document Publication date Comments version

SC23-6009-01 September 25, First IBM publication. 2007

SC23-6009-02 August 22, 2008 Support for Linux® for zSeries added.

SC23-6009-03 December 31, Summary table updated. 2008 IPv6 support information added. FIPS information added. Installation section added.

SC23-6009-04 February 19, 2010 “Summary” on page 1 updated.

SC23-6009-05 March 31, 2011 Installation section replaced by “Installing probes” on page 2.

SC23-6009-06 July 29, 2011 Information about operating system conventions added in “Conventions used in this guide” on page v. IP environment information updated in “Summary” on page 1. Information about running the probe updated in “Running the probe” on page 11.

SC23-6009-07 March 2, 2012 Summary table updated. IPv6 support added for all UNIX and Linux operating systems.

Conventions used in this guide All probe guides use standard conventions for operating system-dependent environment variables and directory paths.

Operating system-dependent variables and paths All probe guides use standard conventions for specifying environment variables and describing directory paths, depending on what operating systems the probe is supported on.

© Copyright IBM Corp. 2007, 2012 v For probes supported on UNIX and Linux operating systems, probe guides use the standard UNIX conventions such as $variable for environment variables and forward slashes (/) in directory paths. For example: $OMNIHOME/probes For probes supported only on Windows operating systems, probe guides use the standard Windows conventions such as %variable% for environment variables and backward slashes (\) in directory paths. For example: %OMNIHOME%\probes For probes supported on UNIX, Linux, and Windows operating systems, probe guides use the standard UNIX conventions for specifying environment variables and describing directory paths. When using the Windows command line with these probes, replace the UNIX conventions used in the guide with Windows conventions. If you are using the bash shell on a Windows system, you can use the UNIX conventions. Note : The names of environment variables are not always the same in Windows and UNIX environments. For example, %TEMP% in Windows environments is equivalent to $TMPDIR in UNIX and Linux environments. Where such variables are described in the guide, both the UNIX and Windows conventions will be used.

Operating system-specific directory names Where Tivoli Netcool/OMNIbus files are identified as located within an arch directory under NCHOME or OMNIHOME, arch is a variable that represents your operating system directory. For example: $OMNIHOME/probes/arch The following table lists the directory names used for each operating system. Note : This probe may not support all of the operating systems specified in the table.

Table 2. Directory names for the arch variable Operating system Directory name represented by arch

AIX® systems aix5

Red Hat Linux and SUSE systems linux2x86

Linux for System z linux2s390

Solaris systems solaris2

Windows systems win32

OMNIHOME location Probes and older versions of Tivoli Netcool/OMNIbus use the OMNIHOME environment variable in many configuration files. Set the value of OMNIHOME as follows: • On UNIX and Linux, set $OMNIHOME to $NCHOME/omnibus. • On Windows, set %OMNIHOME% to %NCHOME%\omnibus.

vi IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Chapter 1. Ping Probe

The Ping Probe is used for general purpose applications on UNIX platforms and does not require any special hardware. It can be used to monitor devices, such as switches, routers, and UNIX- or Windows- based hosts, that support the Internet Control Message Protocol (ICMP).

The following topics describe the probe and its features: • “Summary” on page 1 • “Installing probes” on page 2 • “Data acquisition” on page 2 • “Properties and command line options” on page 5 • “Elements” on page 9 • “Error messages” on page 9 • “ProbeWatch messages” on page 10 • “Running the probe” on page 11 Summary Each probe works in a different way to acquire event data from its source, and therefore has specific features, default values, and changeable properties. Use this summary information to learn about this probe. The following table provides a summary of the Ping Probe.

Table 3. Summary

Probe target Any device that supports the Internet Control Message Protocol (ICMP).

Probe executable file name nco_p_ping

Package version 7.0

Probe supported on For details of supported operating systems, see the following Release Notice on the IBM Software Support website: https://www-304.ibm.com/support/docview.wss? uid=swg21580416

Properties file $OMNIHOME/probes/arch/ping.props

Rules file $OMNIHOME/probes/arch/ping.rules

Requirements A currently supported version of IBM Tivoli Netcool/OMNIbus.

Connection method ICMP

Remote connectivity Not available

Multicultural support Available

Peer-to-peer failover functionality Available for UNIX and Linux operating systems. Not available for Windows operating systems.

IP environment IPv4 and IPv6 Note : IPv6 is not available on Windows operating systems.

Federal Information Processing IBM Tivoli Netcool/OMNIbus uses the FIPS 140-2 approved Standards (FIPS) cryptographic provider: IBM Crypto for C (ICC) certificate 384 for cryptography. This certificate is listed on the NIST website at http://csrc.nist.gov/groups/STM/cmvp/documents/ 140-1/1401val2004.htm. For details about configuring Netcool/ OMNIbus for FIPS 140-2 mode, see the IBM Tivoli Netcool/ OMNIbus Installation and Deployment Guide.

Installing probes All probes are installed in a similar way. The process involves downloading the appropriate installation package for your operating system, installing the appropriate files for the version of Netcool/OMNIbus that you are running, and configuring the probe to suit your environment. The installation process consists of the following steps: 1. Downloading the installation package for the probe from the Passport Advantage Online website. Each probe has a single installation package for each operating system supported. For details about how to locate and download the installation package for your operating system, visit the following page on the IBM Tivoli Knowledge Center: http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/ reference/install_download_intro.html 2. Installing the probe using the installation package. The installation package contains the appropriate files for all supported versions of Netcool/OMNIbus. For details about how to install the probe to run with your version of Netcool/OMNIbus, visit the following page on the IBM Tivoli Knowledge Center: http://www-01.ibm.com/support/knowledgecenter/SSSHTQ/omnibus/probes/all_probes/wip/ reference/install_install_intro.html 3. Configuring the probe. This guide contains details of the essential configuration required to run this probe. It combines topics that are common to all probes and topics that are peculiar to this probe. For details about additional configuration that is common to all probes, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide. Data acquisition Each probe uses a different method to acquire data. Which method the probe uses depends on the target system from which it receives data. The probe regularly polls a list of hosts using ICMP packets in a similar way to the UNIX ping utility. It sends an ICMP packet to each host and then waits for a reply. The probe generates events in the following conditions: • A host cannot be located by name or by IP address (this may represent a DNS problem) • A host fails to respond to the ICMP packets (for example, host down)

2 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide • A host begins to respond after previously failing to respond (for example, host back up) • A new host is added to the list of hosts to be pinged • A host is removed from the list of hosts to be pinged • A host responds too slowly The following topics describe how the probe acquires data: • “Ping file” on page 3 • “Host status” on page 4 • “Name resolution” on page 4 • “Peer-to-peer failover functionality” on page 4

Ping file The probe acquires the list of hosts to be polled from a ping file specified by the PingFile property. Each line in the ping file contains the name of a host, how often the probe should ping it, and the length of time in which a response is expected. Each host listed in the ping file has a poll time. After this poll time has elapsed, the probe pings the host. If the host responds within the timeout time, the poll timer for the host is reset so that it is not pinged again until the poll time has elapsed again. To set the timeout period, you use the TimeOut property in the properties file. This value can be overridden for an individual host by using the time out parameter in the ping file. The length of the poll time is specified for all hosts by the Poll property in the properties file. However, you can override this time for an individual host by using the poll rate parameter in the ping file. Similarly, the trip time can be set by the Trip property in the properties file or can be overridden for an individual host by using the trip time parameter in the ping file. If the host does not respond, the poll timer is not reset because this instructs the probe to ping the host again after it has gone through all the other hosts in the ping file. The probe attempts to ping the host on each pass of the ping file until either the host responds or the maximum number of retries has been reached, in which case the probe deems the host to be unreachable and sends an alarm indicating this to the ObjectServer. It then resets the poll timer and does not attempt to ping the host again until the poll time has elapsed.

Example ping file The following example shows a ping file:

# # Example ping file # # Format: One host per line # # To add a trip time, a poll rate must also be entered, but a trip time # is not necessary for adding a poll rate only. # # Each line takes one of the following formats: # host [ poll rate ] # host [ poll rate ] [trip time ] [timeout] # host [ - ] [ trip time ] # host_01 30 1600 host_02 25 host_03 - 1600

Chapter 1. Ping Probe 3 Ping cycle The probe pings the hosts specified in the ping file in cycles. The minimum length of each cycle is specified by the Interval property. During each ping cycle, the probe pings the number of hosts specified by the MaxPingBurst property. In each cycle, the probe: 1. Finds the next host that has not been deemed unreachable or responsive during the current poll time. 2. Pings that host. 3. Checks whether it has pinged the number of hosts specified by the MaxPingBurst property during the current cycle. If not, it goes back to step 1. Once the probe has pinged the number of hosts specified by the MaxPingBurst property, it does the following: 4. Processes all the responses received so far. 5. Processes any timeouts that have occurred. 6. Reloads the ping file if the time specified by the PingFileCheck property has elapsed. 7. Sleeps for any remaining time specified by the Interval property.

Host status The probe uses the response time of the host following a ping to determine the status of the host. The probe determines the host status in the following ways: • If the host responds before the trip time, the probe sets the $status element to alive. • If the host takes longer to respond than the trip time, but less than the time specified in the TimeOut property, the probes sets the $status element to slow. • If the host takes longer than the TimeOut period to respond, the probe sets the $status element to unreachable. The probe provides valid responses even if the IP address is not the same as the IP address for which the probe was configured. This deals with situations where IP address aliases are used. Note : If the hosts to be pinged are on the other side of a firewall, the firewall must be configured to allow ICMP packets through.

Name resolution If you are using a naming service, such as Domain Name System (DNS) or Network Information Service (NIS), the IP address of each host can be written in either dotted quad format (for example, 193.131.98.3) or can be assigned a human-readable host name. By default, the probe resolves all dotted quad IP addresses before sending events to the ObjectServer. If you set the NoNameResolution property to 1, you can instruct the probe to send events to the ObjectServer without resolving the host name first. This option can improve the performance of the probe.

Peer-to-peer failover functionality The probe supports failover configurations where two probes run simultaneously. One probe acts as the master probe, sending events to the ObjectServer; the other acts as the slave probe on standby. If the master probe fails, the slave probe activates. While the slave probe receives heartbeats from the master probe, it does not forward events to the ObjectServer. If the master probe shuts down, the slave probe stops receiving heartbeats from the master and any events it receives thereafter are forwarded to the ObjectServer on behalf of the master probe. When the master probe is running again, the slave probe continues to receive events, but no longer sends them to the ObjectServer.

4 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Example property file settings for peer-to-peer failover

You set the peer-to-peer failover mode in the properties files of the master and slave probes. The settings differ for a master probe and slave probe. Note : In the examples, make sure to use the full path for the property value. In other words replace $OMNIHOME with the full path. For example: /opt/IBM/tivoli/netcool. The following example shows the peer-to-peer settings from the properties file of a master probe:

Server : "NCOMS" RulesFile : "master_rules_file" MessageLog : "master_log_file" PeerHost : "slave_hostname" PeerPort : 6789 # [communication port between master and slave probe] Mode : "master" PidFile : "master_pid_file"

The following example shows the peer-to-peer settings from the properties file of the corresponding slave probe:

Server : "NCOMS" RulesFile : "slave_rules_file" MessageLog : "slave_log_file" PeerHost : "master_hostname" PeerPort : 6789 # [communication port between master and slave probe] Mode : "slave" PidFile : "slave_pid_file"

Properties and command line options You use properties to specify how the probe interacts with the device. You can override the default values by using the properties file or the command line options. The following table describes the properties and command line options specific to this probe. For information about default properties and command line options, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide (SC14-7608).

Table 4. Properties and command line options

Property name Command line option Description

AsyncEventProcessing -synceventprocessing Use this property to specify whether the integer (equivalent to probe processes alerts synchronously or AsyncEventProcessing asynchronously: with a value of 0) 0: The probe forces the probe to process - alerts synchronously; this means a common asynceventprocessing timing is established between the sender and (equivalent to the receiver during which the events are sent. AsyncEventProcessing 1: The probe forces the probe to process with a value of 1) alerts asynchronously; this means that no common timing is established between the sender and the receiver. The default is 0.

Chapter 1. Ping Probe 5 Table 4. Properties and command line options (continued)

Property name Command line option Description

BindAddress string -ipaddress string Use this property to specify the IP address to which the probe binds. The default is " ". Note : If the value is blank the probe binds to all the IP addresses on the machine.

Force integer -force (equivalent to Use this property to specify whether the Force with a value of 1) probe forces the use of risky property combinations (such as when Interval is -noforce (equivalent to less than 10, Retry is greater than 20, or Force with a value of 0) Timeout is less than 250): 0: The probe prevents the use of risky property combinations. 1: The probe forces the use of risky property combinations. The default is 0.

Interval integer -interval integer Use this property to specify the minimum length of time (in milliseconds) that a probe sets aside for pinging and processing the responses of the number of hosts specified by the MaxPingBurst property. If the probe pings and processes the responses in a time shorter than this, it sleeps for the remainder of the Interval period before starting the next ping cycle. Note : You can increase the ping rate by decreasing the value specified by the Interval property.

LookupOnFailure integer -lookuponfailure Use this property to force the probe to look (equivalent to up the IP address of a host if it fails to LookupOnFailure with a respond to a ping: value of 1) 1: The probe looks up the IP address of the -nolookuponfailure host that did not respond to a ping. (equivalent to 0: The probe does not look up the IP address LookupOnFailure with a of the host that did not respond to a ping. value of 0) The default is 0.

6 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Table 4. Properties and command line options (continued)

Property name Command line option Description

MaxPingBurst integer -maxpingburst integer Use this property to specify the maximum number of hosts that the probe pings during a single ping cycle. The default is 1. MaxPingBurst affects the time it takes the probe to go through the ping file and the load this has on your network. Increasing the value of the MaxPingBurst property reduces the time it takes the probe to go through the whole ping file, but it also increases the burst load on the network.

MultipleUnreachable -singleunreachable Use this property to specify whether the integer (equivalent to probe sends multiple alerts while the host is MultipleUnreachable unreachable: with a value of 0) 0: The probe sends a single alert while the -multipleunreachable host is unreachable. (equivalent to 1: The probe sends an unreachable alert for MultipleUnreachable every ping to which the host fails to respond. with a value of 1) The default is 1.

NoNameResolution -nameresolution Use this property to specify whether the integer (equivalent to probe performs name resolution on IP NoNameResolution with addresses: a value of 0) 0: The probe performs name resolution. -nonameresolution 1: The probe does not perform name (equivalent to resolution, and sends the event to the NoNameResolution with ObjectServer with the host name given as an a value of 1) IP address in dotted quad format. The default is 0.

PacketSize integer -packetsize integer Use this property to specify the ping packet size. The default is 64.

PingFile string -pingfile string Use this property to specify the path of the file that specifies the hosts, which the probe pings. The default is $OMNIHOME/probes/arch/ ping.file. Note : On Windows operating systems, use forward slashes (/) in the path instead of back slashes (\).

Chapter 1. Ping Probe 7 Table 4. Properties and command line options (continued)

Property name Command line option Description

PingFileCheck integer -pingfilecheck integer Use this property to specify the frequency (in seconds) with which the probe checks for any changes in the ping file. Changes can be addition or removal of hosts, and changes in the Poll, Trip, or TimeOut properties for each hosts. According to these changes the probe pings the hosts. The default is 60.

Poll integer -poll integer Use this property to specify the frequency (in seconds) with which the probe pings each host specified in the ping file. Once this poll time has elapsed, the probe pings the host. If it responds, the poll timer for the host is reset. If it does not respond, the probe pings the host again once it has gone through all the other hosts in the ping file. The default is 600. Note : You can override the Poll property for an individual host by specifying a poll rate for that host in the ping file.

Retry integer -retry integer Use this property to specify the maximum number of times that the probe retries pinging a host without response before it assumes that the host is not reachable. If this number is reached, the probe sends an unreachable event to the ObjectServer. The default is 3.

TimeOut integer -timeout integer Use this property to specify the time (in milliseconds) within which the probe expects the host to respond before assuming that it will not respond to that ping attempt. The default is 2500. Note : You can override the TimeOut property for an individual host by specifying a time out period for that host in the ping file.

Trip integer -trip integer Use this property to specify the time (in milliseconds) within which the probe expects the host to respond to a ping before deeming the host to be slow. The default is 2500. Note : You can override the Trip property for an individual host by specifying a trip time for that host in the ping file.

8 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Elements The probe breaks event data down into tokens and parses them into elements. Elements are used to assign values to ObjectServer fields; the field values contain the event details in a form that the ObjectServer understands. The following table describes the elements that the Ping Probe generates. Not all the elements described are generated for each event; the elements that the probe generates depends upon the event type.

Table 5. Elements

Element name Element description

$alias This element identifies the alias of the host.

$host This element shows the name of the host.

$icmp_stats This element contains the standard ICMP statistics of the host.

$ip_address This element shows the IP address of the host machine.

$status This element indicates the status of the host. Possible values are: • unreachable: the host has failed to respond • responded: the host has responded • alive: the host has responded after previously failing to respond • slow: the host has taken longer than trip time but less than poll-rate to respond • noaddress: the probe cannot find the IP address of the host • removed: the host is removed from the ping file • newhost: the host is added to the ping file

Error messages Error messages provide information about problems that occur while running the probe. You can use the information that they contain to resolve such problems. The following table describes the error messages specific to this probe. For information about generic error messages, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide (SC14-7608).

Table 6. Error messages

Error Description Action

Error: Socket Failed: The current username does not Log on as root or setuid root Permission denied have sufficient permission to run and rerun the probe. the probe. Error: This program can only be run by root

Chapter 1. Ping Probe 9 Table 6. Error messages (continued)

Error Description Action

NMQueue The ping probe failed to receive a Check that the host is running. If it failed:nrc=portnumber ping from the specified host. This is, make more memory available could be due to the host being and rerun the probe. down or to a memory allocation error.

Packet not for our PID: The probe received a packet in an Check that the device is running Discarding unexpected format. correctly. Packet not ICMP_ECHORPLY: Discarding Packet too short: Discarding

Parse failure in The probe could not parse the Correct the invalid property value ping.props, line elements. at the line identified by the error linenumber near F message. Failed to process arguments: Opl library error (see previous messages)

PacketSize too large: The value set for the PacketSize Set the PacketSize property to a max -290 in Windows property is greater than the value less than or equal to 290. maximum allowable for the Windows platform.

PacketSize too large: The value set for the PacketSize Set the PacketSize property to a max -4096 property is greater than the value less than or equal to 4096. maximum allowable for the UNIX platform.

ProbeWatch messages During normal operations, the probe generates ProbeWatch messages and sends them to the ObjectServer. These messages tell the ObjectServer how the probe is running. The following table describes the raw ProbeWatch error messages that the probe generates. For information about generic ProbeWatch messages, see the IBM Tivoli Netcool/OMNIbus Probe and Gateway Guide (SC14-7608).

Table 7. ProbeWatch messages

ProbeWatch message Description Triggers or causes

Going Down The probe is shutting down. The probe is shutting down after performing the shutdown routine.

10 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Table 7. ProbeWatch messages (continued)

ProbeWatch message Description Triggers or causes

Heartbeat Message This is the heartbeat message The probe has not received any that the probe sends to the events for the time specified by ObjectServer. the Heartbeat property. This may be useful for debugging purposes.

Running The probe is running normally. The probe has just started up.

Running the probe How you run the probe depends on the operating system you are using.

Starting the probe To start the probe on UNIX and Linux operating systems, use the following command: $OMNIHOME/probes/nco_p_ping Note : On UNIX and Linux operating systems, you must run the probe as the root or suid root user. To start the probe from the Windows command prompt, use the following command: %OMNIHOME%\probes\win32\nco_p_ping.bat To run the probe as a Windows service, use the following steps: 1. To run the probe on the same host as the ObjectServer, use the following command to register it as a service: %OMNIHOME%\probes\win32\nco_p_ping.bat -install -depend NCOObjectServer 2. To run the probe on a different host to the ObjectServer, use the following command to register it as a service: %OMNIHOME%\probes\win32\nco_p_ping.bat -install 3. Start the probe service using the Microsoft Services Management Console. Note : Before running the probe on Windows operating systems, you must edit the default value of the PingFile property to use forward slashes (\) in the file path instead of back slashes (/).

Running the probe as suid root The probe can be run as suid root without compromising system security. In this mode, the probe retains root privileges for the entire time that it is running. To run the probe as suid root, use the following steps: 1. Log in as root. 2. In the $OMNIHOME/probes/arch directory, run the following command to change the owner of the probe binary: chown root nco_p_ping 3. Run the following command to enable the probe binary to run as suid root: chmod +s nco_p_ping 4. Run the following command to register the Netcool/OMNIbus library directory as a trusted directory: crle -s /usr/lib/secure:/opt/netcool/omnibus/platform/arch/lib

Chapter 1. Ping Probe 11 5. If the crle command is not available on your system, use the following steps to register the Netcool/ OMNIbus library directory as a trusted directory: a. Locate /etc/ld.so.conf and open the file for editing. b. Add your LD_LIBRARY_PATH environment value to the file. c. Run /sbin/ldconfig. The probe can now be run as suid root from the $OMNIHOME/probes directory.

Running the probe on AIX Problems with library paths and events not being read properly by the probe have been reported by some users of the AIX operating system. If you experience these issues, one possible workaround is to run the probe from the $OMNIHOME/ platform/arch/lib directory. To do this, use the following steps: 1. Change to the following directory: /usr/Omnibus/platform/aix4/lib 2. Run the following command: $OMNIHOME/probes/nco_p_ping options If running the probe from this directory does not work, contact IBM® Software Support. Limitation

There is a limitation with the Ping Probe whereby the running of multiple instances of the probe on the same server is not supported. If you try to do so, you may see the following types of messages written to the Ping Probe log file:

Debug: D-P_P-002-032: Packet not for our PID. Discarding.

The reason for this is that running multiple instances of the Ping Probe creates more than one instance sending Ping echos and expecting to receive Ping replies. (The multiple instances can be identified using the process ID or PID in the Ping packet.) As there is only a single channel to listen for incoming ICMP packets, this creates a race scenario between the two PIDs to process Ping replies. This may also make a particular probe instance unable to get actual remote machine status and may generate a false report (namely, reporting a host is down) when the other instance continues to discard Ping packets not for its PID.

Workaround Alternatively as a workaround, you can install more than one network interface card (NIC) and bind each instance to a different IP address of the additional NIC using the Ping Probe's BindAddress property. Note : For this workaround, the following conditions must be met, and the NIC in this context refers to either a physical NIC or a virtual NIC created by hypervisor: 1. Each Ping Probe needs to bind to an IP Address of a different NIC. Binding to secondary IP addresses created on one NIC using a technique such as virtual IP or alias IP from O/S level is not supported. 2. No other process or other instance of the Ping Probe are sending Ping packets using the same NIC binded by the running Ping Probe. There should be at least one extra NIC than the total number of Ping Probe instances to run, and this extra NIC should be configured as the default NIC for the other processes to perform Ping. For example, if you wish to start two instances of the Ping Probe, then three NICs are needed.

12 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Appendix A. Notices and Trademarks

This appendix contains the following sections: • Notices • Trademarks Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106-0032, Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation Software Interoperability Coordinator, Department 49XA

© Copyright IBM Corp. 2007, 2012 13 3605 Highway 52 N Rochester, MN 55901 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without notice. Dealer prices may vary. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: © (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. © Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information softcopy, the photographs and color illustrations may not appear. Trademarks IBM, the IBM logo, ibm.com®, AIX, Tivoli®, zSeries, and Netcool® are trademarks of International Business Machines Corporation in the United States, other countries, or both. Adobe, Acrobat, Portable Document Format (PDF), PostScript, and all Adobe-based trademarks are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, other countries, or both.

14 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java™ and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others.

Appendix A. Notices and Trademarks 15 16 IBM Tivoli Netcool/OMNIbus Ping Probe: Reference Guide

IBM®

SC23-6009-07