Hut2co PDF

IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000
(CORBA)
Version 8.0
Reference Guide
July 6, 2012
SC23-6032-06
IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000

(CORBA)
Version 8.0
Reference Guide
July 6, 2012
SC23-6032-06
Note
Before using this information and the product it supports, read the information in Notices and Trademarks, on page 25.
Edition notice
This edition applies to version 8.0 of IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000 (CORBA)
(SC23-6032-06) and to all subsequent releases and modifications until otherwise indicated in new editions.
This edition replaces SC23-6032-05.
Copyright IBM Corporation 2006, 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 . . . . . . . vii
IBM Tivoli Netcool\OMNIbus Probe for

Huawei T2000 (CORBA) . . . . . . . . 1
Summary . . . . . . . . .
Installing probes . . . . . . .
Configuring network resource names
Firewall considerations . . . . .
Configuring firewall settings . .
SSL-based connectivity . . . . .
Data acquisition . . . . . . .
Event synchronization . . . .
Server failover . . . . . . .
Copyright IBM Corp. 2006, 2012
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
3
3
3
4
5
6
6
7
Retrieving alarms . . . . . . .
Filtering alarms . . . . . . .
Status checking . . . . . . .
Backoff strategy . . . . . . .
Command line interface . . . .
Peer-to-peer failover functionality .
Running multiple probes . . . .
Properties and command line options
Elements . . . . . . . . . .
Error messages . . . . . . . .
ProbeWatch messages . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 7
. 7
. 8
. 8
. 8
. 9
. 9
. 10
. 17
. 20
. 22
Appendix. Notices and Trademarks . . 25

Notices . . .
Trademarks .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 25
. 27
iii
iv
IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000 (CORBA): Reference Guide
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 Probe for Huawei T2000 (CORBA)
documentation is provided in softcopy format only. To obtain the most recent
version, visit the IBM Tivoli Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v8r1/index.jsp?topic=/
com.ibm.tivoli.namomnibus.doc/welcome_ptsm.htm
Table 1. Document modification history
Document
version
Publication
date
Comments
SC23-6032-01
December 20,
2006
First IBM publication.
SC23-6032-02
June 28, 2007
Summary section updated.

ORBLocalPort property description added.
SC23-6032-03
March 20,
2009
Patch number and version updated.

EventSynchronization property added.
Event synchronization section added.
ProbeWatch messages section added.
SC23-6032-04
April 30, 2009 Summary section updated.

Running multiple probes section added.
Table 1. Document modification history (continued)

Document
version
Publication
date
Comments
SC23-6032-05
October 29,
2010
Patch number and requirements updated in Summary

on page 1.
The following sections were added or substantially
updated:
v Installing probes on page 3
v Configuring network resource names on page 3
v Firewall considerations on page 3
v Configuring firewall settings on page 4
v SSL-based connectivity on page 5
v Server failover on page 7.
v Filtering alarms on page 7
v Command line interface on page 8.
v Running multiple probes on page 9
Descriptions for the following properties were added to
Properties and command line options on page 10:
v ClientCertificate
v ClientCertificatePassword
v CommandPort
v CommandPortLimit
v EnableFailover
v EnabledProtocols
v EnableSSL
v FlushBufferInterval
v SecondaryIORFile
v SecondaryNamingContextIORFile
v SecondaryORBInitialPort
v SecondaryORBInitialHost
v SecurityProtocol
v ServerSwitchingTime
v TrustStore
v TrustStorePassword
The following elements were added to Elements on
page 17:
v $protectedTP
v $ProtectionType
v $switchAwayFromTP
v $switchReason
v $switchToTP
vi
Table 1. Document modification history (continued)

Document
version
Publication
date
Comments
SC23-6032-06
July 6, 2012
Support extended to Huawei U2000 devices.

Information about operating system conventions added in
Conventions used in this guide.
Requirements updated in Summary on page 1.
The following elements were added to Elements on
page 17:
v $objectTypeQualifier
v $rcaiIndicator
v $X.733::CorrelatedNotifications
v $X.733::EventType
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.
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.
About this guide
vii
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
currently supported by Netcool/OMNIbus.
Table 2. Directory names for the arch variable
Directory name represented by arch
Operating system
AIX systems
aix5
HP-UX PA-RISC-based systems
hpux11
HP-UX Integrity-based systems
hpux11hpia
Red Hat Linux and SUSE systems
linux2x86
Linux for System z
viii
linux2s390
Solaris systems
solaris2
Windows systems
win32
IBM Tivoli Netcool\OMNIbus Probe for Huawei T2000 (CORBA)

The Huawei T2000 is a sub-network-level management system that provides
element management and network management functions for telecommunications
networks.
The Probe for Huawei T2000 (CORBA) acquires data from the Huawei T2000
element management system (EMS) using a Common Object Request Broker
Architecture (CORBA) interface. CORBA is an Object Management Group
specification that provides a standard interface definition between objects in a
distributed environment.
This guide contains the following sections:
v Summary
v Installing probes on page 3
v Configuring network resource names on page 3
v Firewall considerations on page 3
v
v
v
v
v
SSL-based connectivity on page 5

Data acquisition on page 6
Properties and command line options on page 10
Elements on page 17
Error messages on page 20
v ProbeWatch messages on page 22
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 IBM Tivoli Netcool/OMNIbus
Probe for Huawei T2000 (CORBA).
Table 3. Summary
Probe target
Huawei T2000 on iMAP V100R008 or later

Huawei iManager U2000 V100R005C00
Probe executable name
nco_p_huawei_T2000_corba
Probe installation package
omnibus-arch-probe-nco-p-huawei-T2000corba-version
Package version
8.0
Table 3. Summary (continued)

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=swg21598966
Properties file
$OMNIHOME/probes/arch/huawei_T2000_corba.props
Rules file
$OMNIHOME/probes/arch/huawei_T2000_corba.rules
Requirements
One of the following versions of IBM Tivoli

Netcool/OMNIbus:
v V7.2.0 with Interim Fix 4 (7.2.0.7-IF0004) installed
v V7.2.1 with Interim Fix 3 (7.2.1.5-IF0003) installed
v V7.3.0 (and above)
Nonnative Probe Server: probe-nonnative-base-7 (or
later)
probe-visibroker8-support
Note: The VisiBroker patch is not supplied with this
probe; you can obtain the patch from the IBM Passport
Advantage Web site:
http://www-306.ibm.com/software/howtobuy/
passportadvantage/pao_customers.htm
JDK 1.5
Connection method
CORBA
Remote connectivity
The probe can connect to a remote device using the

CORBA interface.
Licensing
Electronic licensing was deprecated with the release of

IBM Tivoli Netcool V7.2.0. All IBM Tivoli Netcool V7.2.0
(and later) products use the IBM software licensing
process.
Multicultural support
Available
For information about configuring multicultural
support, including language options, see the IBM Tivoli
Netcool/OMNIbus Installation and Deployment Guide.
Peer-to-peer failover functionality Available

IP environment
IPv4 and IPv6

Note: The probe is supported on IPv6 when running on
IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1 and 7.4.0 on
all UNIX and Linux operating systems.
Federal Information Processing

Standards (FIPS)
IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1 and 7.4.0 use

the FIPS 140-2 approved 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 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
Information Center:
com.ibm.netcool_OMNIbus.doc/probes/install/wip/out-html/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 Information Center:
com.ibm.netcool_OMNIbus.doc/probes/install/wip/out-html/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.
Configuring network resource names

After installing the probe, you might need to change the names of any network
resources that report alarms.
The probe breaks event data down into tokens and parses them into elements. The
elements are then used to assign values to ObjectServer fields.
The element $nativeEMSName contains the name of the network resource reporting
an alarm, as displayed in the EMS user interface. If brackets are passed to the
$nativeEMSName element as part of a resource name, the node field in the event list
will not be filled. Therefore, any network resource that reports alarms must be
configured so that its name does not contain brackets.
Firewall considerations
When using CORBA probes in conjunction with a firewall, the firewall must be
configured so that the probe can connect to the target system.
Most CORBA probes can act as both a server (listening for connections from the
target system) and a client (connecting to the port on the target system to which
the system writes events). If you are using the probe in conjunction with a firewall,
you must add the appropriate firewall rules to enable this dual behavior.
There are three possible firewall protection scenarios, for which you must
determine port numbers before adding firewall rules:
1. If the host on which the probe is running is behind a firewall, you must
determine what remote host and port number the probe will connect to.
2. If the host on which the target system is running is behind a firewall, you must
determine the incoming port on which the probe will listen and to which the
target system will connect.
3. If each host is secured with its own firewall, you must determine the following
four ports:
a. The outgoing port (or port range) for the probe.
b. The hostname and port of the target system.
c. The outgoing port on which the target system sends events if the probe is
running as a client.
d. The incoming port on which the probe listens for incoming events.
Note: Most, but not all, CORBA probes listen on the port specified by the
ORBLocalPort property. The default value for this property is 0, which means that
an available port is selected at random. If the probe is behind a firewall, the value
of the ORBLocalPort property must be specified as a fixed port number.
CORBA probes that use EventManager or NotificationManager objects may use
different hosts and ports from those that use NamingService and EntryPoint
objects. If the probe is configured to get object references from a NamingService or
EntryPoint object, you must obtain the host and port information from the system
administrator of the target system. When you have this information, you can add
the appropriate firewall rules.
Configuring firewall settings

The Probe for Huawei T2000 (CORBA) can be used in conjunction with a firewall.
If a firewall exists between the probe and the target system, you must configure
the following firewall ports to enable data flow:
v The Naming Service port number.
The port for this service is on the target system. You must also specify this port
on the probe side of the firewall, using the ORBInitialPort property. The default
value of the ORBInitialPort property is 1570.
v The notification service port number.
The port for this service is on the target system. This port number is usually
random but can be set to a fixed value by the administrator of the target system.
No firewall configuration is required on the probe side.
v The CORBA Agent (ORB at target system or inter-ORB bridge) port number.
The port number is specified both on the target system and on the probe side of
the firewall. On the probe side, use the OrbLocaLPort property to specify this
value, which must be greater than 0. The port number on the target system can
be obtained from either the Naming Service or the Interoperable Object
Reference file (specified by the IORFile property).
When using the probe over Secure Sockets Layer (SSL) connections, you must
configure the same ports listed above.
SSL-based connectivity
The Probe for Huawei T2000 (CORBA) supports Secure Sockets Layer (SSL)
connections between the probe and the EMS server. SSL connections provide
additional security when the probe retrieves alarms from the EMS.
To enable SSL connections, you must obtain the required SSL certificates and the
Trusted Authority certificate from the EMS vendor, Huawei Technologies. The
certificates must be added to a local Java keystore so that they can be referenced
by the ClientCertificate and TrustStore properties.
Prerequisites
To create the keystore, you must have the following software installed:
v The OpenSSL toolkit.
This is available from http://www.openssl.org/.
v The IBM KeyMan utility.
This is available from http://www.alphaworks.ibm.com/tech/keyman/
download.
You must also obtain the client and server certificates, client_ca.cer and
server_ca.cer, and the server key pair, server_key.pem, from Huawei
Technologies.
Note: The certificate and key pair files used here are the default files used by the
Huawei T2000 EMS. If you replace these files, you must create a keystore
containing the new files.
Creating the SSL keystore

To create a Java keystore, follow these steps:
1. Convert the server certificate to PKCS12 format using the following OpenSSL
toolkit command:
openssl pkcs12 -export -inkey server_key.pem -in server_ca.cer -out
server_ca.pkcs12
2. Create the keystore using the KeyMan utility:
a. Start the KeyMan utility.
b. Click Create New and select the Keystore token option.
c. Click File > Import and choose the server_ca.pkcs12 file that you created
in step 1.
This imports the keyEntry into the keystore.
d. Click File > Import and choose the server_ca.cer certificate.
This imports the server certificate into the keystore.
e. Click File > Import and choose the client_ca.cer certificate.
This imports the client certificate into the keystore.
f. Click File > Save and enter a password and name for the keystore, for
example trusted_keystore.jks.
Enabling SSL connections

To enable SSL-based connections between the probe and the EMS server, follow
these steps:
1. Set the EnableSSL property to true.

When the EnableSSL property is set to true, the following properties are
enabled:
v ClientCertificate
v ClientCertificatePassword
v TrustStore
v TrustStorePassword
v EnabledProtocols
v SecurityProtocol
2. Use both the ClientCertificate property and the TrustStore property to
specify the location of the keystore file trusted_keystore.jks.
3. Use both the ClientCertificatePassword property and the TrustStorePassword
property to specify a password for the keystore.
4. Encrypt the keystore file password using the nco_g_crypt utility.
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 IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000 (CORBA) gathers
events from the EMS using a CORBA interface.
This section contains the following topics:
v
v
v
v
v
Event synchronization
Server failover on page 7
Retrieving alarms on page 7
Filtering alarms on page 7
Status checking on page 8
v Backoff strategy on page 8

v Command line interface on page 8
v Peer-to-peer failover functionality on page 9
v Running multiple probes on page 9
Event synchronization
The probe supports event synchronization between the EMS server and the
ObjectServer.
When the probe reconnects and requests a full resynchronization, the EMS does
not send any cleared alarms. The ObjectServer will still show those alarms in its
event list.
To synchronize the ObjectServer with the EMS so that the ObjectServer shows only
uncleared events, set the Resynch and EventSynchronization properties to true.
After the resynchronization is complete, the events that did not come from the
EMS through resynchronization (those that have been cleared) will be removed
from the ObjectServer.
Note: Event synchronization only works for resynchronization events. It does not
affect any new notification alarms. The ObjectServer will continue to receive all
notifications sent by the EMS, without regard to the state of the alarms.
Before running the probe for event synchronization, change the following
properties in the EventSynch_T2000.sh file, located in the $OMNIHOME/probes/
directory:
Server="NCOMS" (Object Server Name)
User="root"
(User name of Object Server)
Password=""
(Password)
Server failover
If events are not received within a specified time period, the probe can switch
between the CORBA Naming Services of a primary EMS server and a secondary
EMS server.
The ServerSwitchingTime property specifies the amount of time the probe waits to
receive events before disconnecting from the primary EMS server and switching to
the secondary EMS server. The probe will continue to switch between the primary
and secondary server until a connection is made to one of them.
Note: To enable the server failover function, the following conditions must be met:
1. The EnableFailover property must be set to true to enable the values specified
in the following properties:
v ServerSwitchingTime
v SecondaryIORFile
v SecondaryNamingContextIORFile
v SecondaryORBInitialHost
v SecondaryORBInitialPort
2. The Retry property must be set to true.
If the Retry property is set to false, the probe will not be in continuous
reconnect mode and will not failover to the secondary EMS server.
3. The value of the ServerSwitchingTime property must not exceed 4096 seconds.
This is the default value of the backoff strategy time that, if exceeded, will
cause the probe to disconnect from the CORBA interface.
Retrieving alarms
The probe initially receives a list of all active alarms from the AlarmIRP server. The
probe then connects to the NotificationIRP server and uses the CORBA notification
push model to receive new alarms from the server as they are generated.
Filtering alarms
You can limit the types of alarms the probe retrieves using the filtering properties.
The filtering properties allow you to exclude resynchronization alarms according to
their severity. They cannot be used to filter new notification alarms.
For example, to exclude alarms of severity Indeterminate, set the
ExcludeSeverityIndeterminate property to true.
Note: By default, the probe retrieves resynchronization alarms of all severities.
The Filtering properties table shows the filtering properties that are available.
Table 4. Filtering properties

Property
Alarm Severity
ExcludeSeverityCleared
Cleared
ExcludeSeverityCritical
Critical
ExcludeSeverityIndeterminate
Indeterminate
ExcludeSeverityMajor
Major
ExcludeSeverityMinor
Minor
ExcludeSeverityWarning
Warning
Status checking
The probe checks that the EMS server is running by sending a ping command
every 60 seconds. You can change this frequency using the AgentHeartbeat
property.
Backoff strategy
If the Retry property is set to true, and the probe fails to establish a connection or
loses an existing connection to the device, it reverts to a backoff strategy. The probe
tries to reestablish a connection after one second, two seconds, then four seconds,
and so on, up to a maximum of 4096 seconds. Once the connection is made to the
CORBA interface, the probe tries to log in to the device. If the probe fails to log in,
it shuts down and tries to connect again. The backoff strategy remains in place
until a successful login occurs.
Command line interface

The Probe for Huawei T2000 (CORBA) is supplied with a Command Line Interface
(CLI) that allows you to execute commands using the probe.
To use the CLI, you must use the CommandPort property in the properties file to
specify a port through which commands will be sent. The default port is 6970.
When you want to run commands, use Telnet to connect through this port.
The following table describes the commands that you can use with the CLI.
Table 5. CLI commands
Command
Description
exit/quit
Use this command to close the connection.
help
Use this command to display online help about

the CLI.
resynch_alarm
Use this command to perform a full or partial

resynchronization of the alarms. A full or partial
resynchronization will depend on the value of the
ExcludeSeverity properties (Cleared, Critical,
Indeterminate, Major, Minor, Warning) specified in
the properties file.
version
Use this command to display the version of the

probe and the CLI.
Note: As the CLI is based on Telnet connections, you can connect to the probe
from anywhere by creating a desktop tool to open a Telnet connection, send a
command, and then close the connection. This means that simple scripts can be set
up to allow users to acknowledge selected events from the IBM Tivoli
Netcool/OMNIbus event list.
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 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 is
running again, the slave continues to receive events, but no longer sends them to
the ObjectServer.
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.
The following example shows the peer-to-peer settings from the properties file of a
master probe:
Server
RulesFile
MessageLog
PeerHost
PeerPort
Mode
:
:
:
:
:
:
"NCOMS"
"master_rules_file"
"master_log_file"
"slave_hostname"
5555 # [communication port between master and slave probe]
"master"
The following example shows the peer-to-peer settings from the properties file of
the corresponding slave probe:
Server
RulesFile
MessageLog
PeerHost
PeerPort
Mode
:
:
:
:
:
:
"NCOMS"
"slave_rules_file"
"slave_log_file"
"master_hostname"
5555 # [communication port between master and slave probe]
"slave"
Running multiple probes

You can run multiple instances of the probe.
For each running instance, specify a different port to which the server listens using
the ORBLocalPort property.
Running multiple probes in a failover configuration

If you have implemented a peer-to-peer failover configuration, both the master
probe and the slave probe have their own Object Request Broker (ORB) local port.
Where you are running this configuration in conjunction with a firewall, add the
receiving port of each probe to the firewall rules. The direction of the connection is
from the target system to the master or slave probe.
You set the peer-to-peer failover mode in the properties files of the master and
slave probes.
Include the following peer-to-peer settings in the master's probe properties file:
PeerHost
PeerPort
: "slave_hostname"
: 5555 # [communication port between master and slave probes]
Include the following peer-to-peer settings in the slave's probe properties file:
PeerHost
PeerPort
: "master_hostname"
: 5555 # [communication port between master and slave probes]
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 6. Properties and command line options
Property name
Command line option
Description
AgentHeartbeat integer
-agentheartbeat integer
Use this property to specify the

frequency (in seconds) at which
the probe sends a ping command
to check whether the EMS server
is still running.
The default is 60.
ClientCertificate string
-clientcertificate string

location of the keystore file that
contains the client certificate for
SSL.
The default is "".
ClientCertificatePassword -clientcertificatepasswordUse this property to specify the

string
string
password required to access the
certificate specified by the
ClientCertificate property.
The default is "".
Note: You must encrypt this
password using the nco_g_crypt
utility with Netcool/OMNIbus.
CommandPort integer
-commandport integer

port to which users can connect
using Telnet and run commands.
The default is 6970.
CommandPortLimit integer
-commandportlimit integer

maximum number of command
port sessions.
The default is 10.
10
Table 6. Properties and command line options (continued)

Property name
Command line option
Description
EnableFailover string
-noenablefailover (This
is equivalent to
EnableFailover with a
value of false.)
Use this property to specify

whether the server failover
function between the probe and
the primary and secondary EMS
servers is enabled or disabled.
This property takes the following
values:
-enablefailover (This is
equivalent to
EnableFailover with a
value of true.)
false: The server failover function

between the probe and the EMS
servers is disabled.
true: The server failover function
between the probe and the EMS
servers is enabled.
The default is false.
EnabledProtocols string
-enabledprotocols string

list of comma-separated values
that indicate the enabled
protocols, for example SSLv2,
SSLv3, and so on.
The default is SSLv2.
EnableSSL string
-noenablessl (This is
equivalent to EnableSSL
with a value of false.)
-enablessl (This is
equivalent to EnableSSL
with a value of true.)

whether SSL connectivity between
the probe and the EMS server is
enabled or disabled. This property
takes the following values:
false: SSL connectivity between
the probe and the EMS server is
disabled.
true: SSL connectivity between the
probe and the EMS server is
enabled.
EncodingStandard string
-encodingstandard string

standard used to encode and
decode multi-byte characters.
The default is ISO-8859-1.
11

Property name
Command line option
Description
EventSynchronization
string
-noeventsynch (This is
equivalent to
Use this property to synchronize

the ObjectServer with the EMS.
This removes the alarms from the
ObjectServer that were cleared in
the EMS while the probe was not
running. This property takes the
following values:
-eventsynch (This is
equivalent to
false: The probe does not

synchronize with the EMS on
startup.
true: The probe synchronizes with
the EMS on startup.
Note: If you set this property to
true, you must also set the
Resynch property to true.
string
-excludecleared (This is
equivalent to

whether the probe excludes alarms
of severity Cleared from those that
it retrieves. This property takes
the following values:
-noexcludecleared (This is
false: The probe does not exclude
equivalent to
alarms of severity Cleared.
true: The probe excludes alarms
of severity Cleared.
ExcludeSeverityCritical
string
-excludecritical (This is
equivalent to
ExcludeCritical with a
value of true.)
-noexcludecritical (This
is equivalent to
ExcludeCritical with a
value of false.)

of severity Critical from those
that it retrieves. This property
alarms of severity Critical.
of severity Critical.
12

Property name
Command line option
Description
ExcludeSeverity
Indeterminate string
-excludeindeterm (This is
equivalent to
ExcludeSeverity
Indeterminate with a
value of true.)

of severity Indeterminate from
those that it retrieves. This
property takes the following
values:
-noexcludeindeterm (This
is equivalent to
ExcludeSeverity
Indeterminate with a
value of false.)

alarms of severity Indeterminate.
of severity Indeterminate.
string
-excludemajor (This is
equivalent to
-noexcludemajor (This is
equivalent to

of severity Major from those that it
retrieves. This property takes the
following values:
alarms of severity Major.
of severity Major.
string
-excludeminor (This is
equivalent to
-noexcludeminor (This is
equivalent to

of severity Minor from those that it
retrieves. This property takes the
following values:
alarms of severity Minor.
of severity Minor.
string
-excludewarning (This is
equivalent to

of severity Warning from those that
it retrieves. This property takes
-noexcludewarning (This is
equivalent to
alarms of severity Warning.
of severity Warning.
13

Property name
Command line option
Description
FlushBufferInterval
integer
-flushbufferinterval
string
Use this property to specify how

often (in seconds) that the probe
flushes all alerts in the buffer to
the ObjectServer.
The default is 0 (which instructs
the probe to never flush alerts to
the ObjectServer).
IORFile string
-iorfile string

location of the Inter-operable
Object Reference (IOR) file for the
interface object
EmsSessionFactory_I on the EMS.
The default is "".
NamingContextIORFile
string
-nsior string
If the values of either the

ORBInitialHost or the
ORBInitialPort properties are not
specified, use this property to
specify the location of the IOR file
that contains the root context of
the Naming Service.
The default is "".
NamingContextPath string
-nspath string

location of the interface object
within the Naming Service.
The default is
TMF_MTNM.Class/HUAWEI.Vendor/
Hua wei\\/T2000.EmsInstance/2\\
.0.Ve rsion/Huawei\\/
T2000.EmsSession Factory_I.
ORBInitialHost string
-orbinitialhost string

name of the Naming Service host.
The default is "".
ORBInitialPort integer
-orbinitialport integer

port number of the Naming
Service
ORBLocalPort integer
-orbinitialport integer

local port on which the Object
Request Broker (ORB) listens for
events.
The default is 0 (the ORB selects
an available port at random).
Password string
-password string

password required with the
Username property to log in to the
system.
The default is "".
14

Property name
Command line option
Description
PersistenceFile string
-persistencefile string

location of the IOR file for the
notification service.
The default is "".
PersistentNotification
string
-nopersist (This is
equivalent to
-persist (This is
equivalent to

whether the probe reuses the same
IOR for the notification service on
reconnection. This property takes
false: The probe does not use the
same IOR for reconnection.
true: The probe uses the same
IOR for reconnection.
Resynch string
-noresynch (This is
equivalent to Resynch with whether the probe requests all
a value of false.)
active alarms from the server
before acquiring new alarms. This
-resynch (This is
property takes the following
equivalent to Resynch with values:
a value of true.)
false: The probe does not perform
resynchronization.
true: The probe perform
resynchronization.
ResynchBatchSize integer
-resynchbatchsize integer

maximum number of alarms that
the probe retrieves in each batch
of resynchronization alarms.
The default is 100.
Retry string
-noretry (This is
equivalent to Retry with a whether the probe attempts to
reconnect to the system using a
value of false.)
backoff strategy following a
-retry (This is equivalent reported error. This property takes
to Retry with a value of
true.)
false: The probe shuts down and
does not attempt to reconnect.
true: The probe attempts to
reconnect to the system using the
backoff strategy.
Note: For details about the
backoff strategy, see Backoff
strategy on page 8.
15

Property name
Command line option
Description
SecondaryIORFile string
-seciorfile string

location of the IOR file of the
secondary EMS server.
The default is "".
SecondaryNamingContext
IORFile string
-secnsior string

location of the IOR file for the root
context of the Naming Service of
the secondary EMS server.
The default is "".
SecondaryORBInitialHost
string
-secorbinitialhost string

Naming Service host name of the
The default is "".
SecondaryORBInitialPort
string
-secorbinitialport string

Naming Service port number of
the secondary EMS server.
The default is 1570 .
SecurityProtocol string
-securityprotocol string

security protocol. This property
SSL
SSLv2
SSLv3
TLS
TLSv1
The default is TLSv1.
ServerSwitchingTime
integer
-serverswtime integer

time (in seconds) that the probe
waits to receive events before
disconnecting from the CORBA
Naming Service of the primary
EMS server and switching to the
CORBA Naming Service of the
Note: The probe will continue to
switch between the primary and
secondary server, in the specified
time, until a connection is made to
either server.
16

Property name
Command line option
Description
Timeout integer
-timeout integer .

time (in seconds) that the probe
waits to receive events before
disconnecting from the CORBA
Naming Service and shutting
down.
The default is 0 (the probe never
times out).
TrustStore string
-truststore string

path to the keystore file containing
the trusted authority certificate.
The default is "".
TrustStorePassword string
-truststorepassword
string

password required to access the
keystore file containing the trusted
authority certificate.
The default is "".
Note: You must encrypt this
password using the nco_g_crypt
utility within Netcool/OMNIbus.
Username string
-username string

user name of the account with
which the probe logs in to the
EMS interface.
The default is "".
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 tables describe the elements that the Probe for Huawei T2000
(CORBA) generates. Not all the elements described are generated for each event.
The elements that the probe generates depend upon the event type.
Table 7. Elements
Element name
Element description
$additionalInfo
This element contains additional information

about the alarm.
$additionalText
This element contains a brief description of the

problem being reported by the alarm.
$affectedTPList
This element displays the list of termination

points affected by the problem being reported.
$emsTime
This element indicates the time at which the

alarm was reported by the EMS.
$event_type
This element indicates the type of the alarm.
17
Table 7. Elements (continued)

Element name
Element description
$isClearable
This element indicates whether the alarm can be

cleared. The possible values are:
false
true
$layerRate
This element indicates the layer to which the

alarm applies.
$nativeEMSName
This element contains the name of the object

reporting the alarm, as displayed in the EMS user
interface.
Note: Object names must not contain brackets. If
brackets are passed to the $nativeEMSName
element as part of an object name, the node field
in the event list will not be filled.
$nativeProbableCause
This element indicates the probable cause as

given in the EMS user interface.
$neTime
This elements indicates the time at which the

error occurred in the network element.
$notificationId
This element contains the unique identifier of the

alarm. This is derived from the serial number of
the alarm as used by the EMS.
$objectName
This element contains the name of the object

reporting the alarm.
$objectType
This element indicates the type of object

$objectTypeQualifier
This element indicates the type of object

Note: This element is only applicable to objects
added in TMF 3.0.
$perceivedSeverity
This element indicates the perceived severity of

the alarm.
$probableCause
This element contains the probable cause of the

alarm.
$probableCauseQualifier
This element contains the qualifier used to

classify the alarm type.
$rcaiIndicator
This element indicates whether an alarm is a root

alarm. This alarm has the following possible
values:
v True (The alarm is a root alarm)
v False (The alarm is a common alarm)
$serviceAffecting
18
This element indicates whether the alarm has

affected the service.
Table 7. Elements (continued)

Element name
Element description
$X.733::CorrelatedNotifications
This element contains a list of root alarms that

cause correlative alarms. This alarm has the
following possible values:
v soSource (This field is always empty)
v notifIDs (For correlative alarms this field
displays the serial number of the root alarm.
For example, if alarm A causes alarm B, and
alarm B causes alarm C this field will display
alarm C along with the serial numbers of
alarm A and alarm B.)
$X.733::EventType
This element contains the alarms classified into

the following six basic types according to the
ITU-T X.733:
v communicationsAlarm
v qualityofServiceAlarm
v equipmentAlarm
v processingErrorAlarm
v securityAlarm
v environmentalAlarm
Table 8. Elements specific to NT_PROTECTION_SWITCH alarms

Element name
Element description
$protectedTP
This element identifies the protected termination

point when the switch occurs.
$ProtectionType
This element indicates the type of protection.
$switchAwayFromTP
This element identifies the source termination

point from where the switch is being made.
$switchReason
This element indicates the reason why the switch

has been made.
$switchToTP
This element identifies the destination

termination point where the switch is being
made.
Table 9. Elements specific to NT_TCA alarms

Element name
Element description
$granularity
This element contains the details of the threshold

that has been crossed.
$pmParameterName
This element contains the pmParameter that has

crossed the threshold.
$pmLocation
This element indicates the pmLocation where the

threshold has been crossed.
$thresholdType
This element indicates whether a threshold was

set for the log report.
$unit
This element contains the faulty program unit.
$value
This element contains the threshold value.
19
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 10. Error messages
Error
Description
Action
Failed to connect to
Naming Service
The probe failed to connect to

the Naming Service. Either
the Naming Service was not
running on the specified host
and port, or the IOR specified
for the Naming Service was
not correct.
Check that the Naming

Service is running on the
specified host and port, and
that the Naming Service IOR
is correct.
The probe failed to connect to

the Notification Service.
Either the Notification Service
was not running on the
specified host and port, or the
IOR specified for the
Notification Service was not
correct.
Check that the Notification

Service is running on the
specified host and port and
that the Notification Service
IOR is correct.
The CORBA service is not

running on the expected
Host/Port/IOR
Failed to connect to
Notification Service
Check that the Huawei server

CLI requested resynch but The probe failed to call a
method on the Huawei server. is running correctly and that
can't as probe not
the IOR files are up to date.
connected!Failed to get
interface version
information
Failed to ping Huawei
server
Failed to load consumer
administration interface
Failed to load supplier
proxy
20
Failed generate and

process Probewatch event
for the event loss
occurring.
The ProbeWatchManager
failed to create a ProbeWatch
message.
Check the ObjectServer is

running.
Failed to retrieve next

batch of resync alarms :
The probe failed to retrieve

the next batch of alarms.
Check that the Huawei server

is running correctly.
Table 10. Error messages (continued)

Error
Description
Action
The probe failed to get the

Check that the IOR file exists
object reference from the IOR and that it is a valid IOR file.
file. Either the IOR file
Failed to get object from requested was not found or it
IOR file
did not contain a valid IOR
file.
Failed to find file,
please check file exists!
Failed to get object
reference from IOR file
Failed to convert IOR to

object
Please check that the
interface is running and
the probe is using up to
date IOR files
The probe failed to narrow
the object reference to the
interface object.
This is a CORBA related error

and is probably related to the
CORBA installation.
Failed to create
CorbaUtil object :
The probe could not create

the internal object.
Ensure that the $CLASSPATH

environment variable contains
the path to the IBM ORB
.jar files.
Failed to resolve Naming

Context
Check the NamingContextPath

property.
Exception raised when

locating server
The probe failed to resolve

the naming context path to
find the server object. Either
the naming context path was
invalid or did not exist.
Name is null, cannot

create element
The probe failed to parse the

alarm.
Check that the alarm

conforms to the
StructuredEvent format.
Persistence has not been

enabled for this Object
Request Broker (ORB), or it is
not available for this
implementation of the ORB.
Check that the Persistent

Event feature has been
initiated on the ORB.
Failed to narrow object

reference
Failed to narrow manager
reference
Cannot parse type

value_type : name
Failed to parse alarm
Failed to parse element
elementname because
description
Failed to extract values
from the
remainder_of_body
There is a possibility
that the Persistent Event
feature has not been
initiated on the ORB, or
is not available on this
ORB implementation.
Please check with your
ORB provider on how to do
this
21
Table 10. Error messages (continued)

Error
Description
Action
Failed to run event

synchronization
The EventSynch_T2000.sh
script did not run properly.
Verify that the

EventSynch_T2000.sh file
exists in the $OMNIHOME/probes
directory and that the
permissions have been set
correctly.
Failed to perform resynch
Check the value of the server,

user, and password fields in
the EventSynch_T2000.sh file.
Failed to get EMS session Either the ORBLocalPort
property has been set but the
object :
port is occupied by another
org.omg.CORBA.OBJ_
process, or the ORBLocalPort
ADAPTER:
and Retry properties have
been set but the probe's
java.net.BindException:
listening port has not been
Address already in use
properly released before the
probe attempts to reconnect to
Failed to get EMS Manager
the EMS server.
reference
Check that the ORBLocalPort

is set to a port that is not
occupied by other processes,
or disable the Retry property
and then set up the process
control to restart the probe.
Unable to get EMS session
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 11. ProbeWatch messages
22
ProbeWatch message
Description
Triggers/causes
ClientSession event loss

occurred.
Events were lost between the

EMS and the ObjectServer.
Check the connection between

the EMS and the ObjectServer.
ClientSession event loss

cleared.
Loss of events between the

EMS and ObjectServer is
cleared
Events are no longer being

lost and the EMS is now
capable of providing relevant
notifications.
Failed to generate and

process Probewatch event
for the event loss being
cleared.
The specified notification IRP

file does not exist.
The IRP manager is not set up

correctly.
Performing Resynch....
The probe is performing

resynchronization.
The probe has started

resynchronization.
Will listen for commands

on port number 6970.
The probe will listen for

commands on the specified
port number.
The probe has successfully

created the specified
command port in the
properties file.
Table 11. ProbeWatch messages (continued)

ProbeWatch message
Description
Triggers/causes
Failed to listen for

commands on port number
6970.
A problem occurred while

There was a problem
trying to listen for commands initializing the connection
on the specified port number. because of insufficient
memory or, if this message
was sent after some events
were parsed, there was a
license failure, a connection
failure, or the port is already
in use.
23
24
Appendix. Notices and Trademarks

This appendix contains the following sections:
v Notices
v 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.
25
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
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.
26
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.
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.
Appendix. Notices and Trademarks
27
28

Printed in USA
SC23-6032-06

Hut2co PDF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hut2co PDF

Uploaded by

Copyright:

Available Formats

IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000

IBM Tivoli Netcool/OMNIbus Probe for Huawei T2000

IBM Tivoli Netcool\OMNIbus Probe for

Copyright IBM Corp. 2006, 2012

Appendix. Notices and Trademarks . . 25

About this guide

Document control page

First IBM publication.

June 28, 2007

Summary section updated.

Patch number and version updated.

April 30, 2009 Summary section updated.

Copyright IBM Corp. 2006, 2012

Table 1. Document modification history (continued)

Patch number and requirements updated in Summary

Table 1. Document modification history (continued)

Support extended to Huawei U2000 devices.

Conventions used in this guide

Operating system-dependent variables and paths

About this guide

Operating system-specific directory names

HP-UX PA-RISC-based systems

HP-UX Integrity-based systems

Red Hat Linux and SUSE systems

Linux for System z

IBM Tivoli Netcool\OMNIbus Probe for Huawei T2000 (CORBA)

SSL-based connectivity on page 5

v ProbeWatch messages on page 22

Huawei T2000 on iMAP V100R008 or later

Probe executable name

Probe installation package

Copyright IBM Corp. 2006, 2012

Table 3. Summary (continued)

For details of supported operating systems, see the

One of the following versions of IBM Tivoli

The probe can connect to a remote device using the

Electronic licensing was deprecated with the release of

Peer-to-peer failover functionality Available

IPv4 and IPv6

Federal Information Processing

IBM Tivoli Netcool/OMNIbus V7.3.0, 7.3.1 and 7.4.0 use

Configuring network resource names

Configuring firewall settings

Creating the SSL keystore

Enabling SSL connections

1. Set the EnableSSL property to true.

v Backoff strategy on page 8

IBM Tivoli Netcool\OMNIbus Probe for Huawei T2000 (CORBA)

Table 4. Filtering properties

Command line interface

Use this command to close the connection.

Use this command to display online help about

Use this command to perform a full or partial

Use this command to display the version of the

Peer-to-peer failover functionality

Example property file settings for peer-to-peer failover

Running multiple probes

Running multiple probes in a failover configuration

Properties and command line options

Command line option

Use this property to specify the

Use this property to specify the

ClientCertificatePassword -clientcertificatepasswordUse this property to specify the

Use this property to specify the