IBM Tivoli Monitoring, Version 6.3

Implementation with ephemeral pipe

Configure your communications to use ephemeral pipe when addresses on either side of a barrier firewall are not identical or are not reachable from either side. Use of ephemeral pipe may be dictated by the per-machine agent count, as well as any form of discontiguous addressing such as a NAT firewall.

You configure an IP.PIPE or IP.SPIPE connection as an ephemeral pipe by adding the ephemeral keyword ephemeral:y the KDE_TRANSPORT environment variable immediately following the protocol keyword (IP.PIPE or IP.SPIPE) in the associated KPP ENV file for that process. You must then restart the process for the change to be effective.

Some KPP ENV files use KDC_FAMILIES instead of KDE_TRANSPORT. The process is exactly the same for the KDC_FAMILIES environment variable: adding the ephemeral keyword ephemeral:y immediately following the protocol keyword (IP.PIPE or IP.SPIPE) that is to be designated ephemeral.

For example, to configure the KNTAGENT to make an ephemeral connection to the monitoring server, change KDE_TRANSPORT (or KDC_FAMILIES) in the file KNTENV from

KDE_TRANSPORT=IP.PIPE PORT:1918 IP SNA

KDE_TRANSPORT=IP.PIPE ephemeral:y PORT:1918 IP SNA

or from

KDC_FAMILIES=IP.PIPE PORT:1918 IP SNA

KDC_FAMILIES=IP.PIPE ephemeral:y PORT:1918 IP SNA

To configure a remote monitoring server to make an ephemeral connection to the hub, change KDE_TRANSPORT (or KDC_FAMILIES) in the file KDSENV from

KDE_TRANSPORT=IP.PIPE PORT:1918 IP SNA

KDE_TRANSPORT=IP.PIPE ephemeral:y PORT:1918 IP SNA

or from

KDC_FAMILIES=IP.PIPE PORT:1918 IP SNA

KDC_FAMILIES=IP.PIPE ephemeral:y PORT:1918 IP SNA

Monitoring agents that configure their connections as ephemeral cannot warehouse data unless KPX_WAREHOUSE_LOCATION is also configured at the remote monitoring server to which the monitoring agent reports. The variable KPX_WAREHOUSE_LOCATION is an optional list of fully qualified, semicolon-delimited network names that must be added to environment file of the monitoring server to which the agents are connected. This file is located in different places, depending on the platform:

install_dir\CMS\KBBENV
install_dir/config/kbbenv.ini

The syntax is:

KPX_WAREHOUSE_LOCATION=family_protocol:#network_address[port_number];

For example:

KPX_WAREHOUSE_LOCATION=ip.pipe:#192.168.0.14[18303];ip:#192.168.0.14[34543];

The KPX_WAREHOUSE_LOCATION variable does not work if you are using EPHEMERAL ports and the Warehouse Proxy Agent is on a server other than the remote monitoring server for that agent. When this is the case, and when "EPHEMERAL:Y" is used in the KDC_FAMILIES specification of the agent, the agent will route all communications, including data exports, to its monitoring server. In the agent log, the initial lookup for the Warehouse Proxy does retrieve the correct Warehouse Proxy Agent IP and port from the monitoring server's Local Location Broker. However, the agent switches to using the monitoring server's IP address for the export instead of the Warehouse Proxy Agent IP address due to the EPHEMERAL:Y setting.

When the Warehouse Proxy Agent is collocated with the agent's monitoring server, the export works normally because the virtual port that the request gets routed to is the correct listening port for the Warehouse Proxy Agent. The IP address for the Warehouse Proxy Agent and monitoring server are also the same. However, when the Warehouse Proxy Agent is on a different machine to the agent's monitoring server, there is nothing listening on the Warehouse Proxy Agent's port on the monitoring server machine. As a result a Status = 8 error message is received when trying to route the export. There are a few possible solutions:

Enable and use the KDE Gateway component between the affected agents and their monitoring server.
Place the Warehouse Proxy Agent on the same monitoring server as the agent.
If EPHEMERAL:Y is only there as a security blanket to ensure monitoring server ↔ agent communications, remove it from the KDC_FAMILIES variables of the agents and recycle the agents.

Note: Another possible solution is to change the collection location for all attribute groups from the Tivoli® Enterprise Monitoring Agent to the Tivoli Enterprise Monitoring Server. Note that this will considerably increase the monitoring server's processing load and is not usually a preferred method for this reason. However, this method is an option if the previous solutions cannot be implemented.

Feedback