If multiple Tivoli® Monitoring
agents are installed on the same system, they cannot share the same
port number for IP.PIPE or IP.SPIPE communications. An automatic mechanism
has been developed to allocate additional ports for communications
to the monitoring server. IBM® Tivoli Monitoring uses the following
algorithm to allocate port numbers for monitoring agents
to reach the monitoring server: reserved
port = well-known port + (N*4096)
where:
- well-known port is the port number assigned to the monitoring server,
for example, 1918.
- N indicates the position of the monitoring agent in
the startup sequence for agents.
For example, if there are two monitoring agents
on a system, and the monitoring server uses
port 1918, the first monitoring agent in
the startup sequence is assigned port 6014 (1918 + 1*4096) and the
second agent to start is assigned port 10110 (1918 + 2*4096). These
port assignments occur automatically to avoid conflicts between multiple
monitoring agents.
For
"piped" protocols such as IP.PIPE and IP.SPIPE (but not
IP or SNA), you also have the ability to control how port numbers
are assigned to a monitoring agent by using the SKIP and COUNT parameters
on the KDE_TRANSPORT environment variable. These two parameters are
described in more detail below, but here is an example of how you
might use them when configuring a monitoring agent:
KDE_TRANSPORT=IP.PIPE PORT:1918 COUNT:1 SKIP:2 IP use:n SNA use:n IP.SPIPE use:n
See
also the following information about using the IP.PIPE and IP.SPIPE
protocols and parameters:
- The PORT parameter specifies the well-known port for the monitoring server.
- The piped protocols allocate one, and only one, physical port
per process.
- There can be at most 16 IP.PIPE/IP.SPIPE processes per host.
- If you need to run more than 16 processes on a host, you can choose
one of the following options:
- Use IP.UDP (User Datagram Protocol) for connections except to
and from the Tivoli Enterprise
Portal Server. The use of UDP is not recommended for the portal server.
- Add EPHEMERAL:Y as an optional KDE_TRANSPORT setting, for example:
KDE_TRANSPORT=IP.PIPE PORT:1918 EPHEMERAL:Y IP use:n SNA use:n
Marking an agent as ephemeral means that it will not try to open
its own listening port. Instead, it will only initiate one-way, outbound
communication to the monitoring server.
- The COUNT:N parameter is the mechanism for reserving IP.PIPE
ports for components that connect to the monitoring server. N is
the number of IP.PIPE ports to reserve on a host in addition to the
well-known port for the monitoring server.
Use the COUNT parameter to reserve ports for components that must
be accessible from outside a firewall. Accessibility from outside
the firewall requires IP.PIPE ports and because these ports must be
permitted at the firewall, the ports must be predictable.
For example,
if the well-known port is 1918, COUNT:3 starts the search at port
6014 (1918 + 1*4096). If the agent process cannot bind to port 6014,
the algorithm tries port 10110 (1918 + 2*4096). If port 10110 is
not available, the search goes to port 14206 (1918 + 3*4096).
The
agent is assigned to the first available port encountered in the search.
The process fails to start if the search reaches the highest port
without a successful binding (port 14206 in this example).
- The SKIP:N parameter specifies the number of ports to skip
when starting the search for an available port using the port assignment
algorithm. Use the SKIP parameter for components that do not need
access across a firewall.
For example, if the well-known port is
1918, SKIP:2 specifies to start the search at port 10110 (1918 + 2*4096),
skipping ports 1918 and 6014 (1918 + 1*4096). The algorithm continues
searching until it finds an available port.
- The USE parameter enables or disables a protocol. To disable a
protocol, specify use:n. To enable a protocol, specify use:y.
This parameter has no default.
Note: Tivoli Monitoring agents
allocate ports 1920 and 3661 as HTTP and HTTPS listener ports.
In environments behind firewalls it is critical that the Warehouse
Proxy Agent listens on the same port each time it is started. To ensure
a consistent IP.PIPE listening port, regardless of the sequence in
which other monitoring agents on the system are started, the Warehouse
Proxy Agent by default uses the high-numbered port 63358. This is
accomplished by leveraging the COUNT and SKIP parameters. The Warehouse
Proxy Agent internally sets COUNT:1 and SKIP:15 in order to obtain
63358 as its listening port (63358 = 1918 + (15 * 4096)). You do not
need to add these parameters when configuring the Warehouse Proxy
Agent. All other monitoring agents that archive their historical data
should then configure 63358 as the well-known listening port of the
Warehouse Proxy Agent.
Note: You are not required to use port 63358
for the Warehouse Proxy Agent, but this is the most commonly used
port. If you decide to use a different listening port, then you will
need to add your own custom COUNT and SKIP values when configuring
the agent.
Example
The example in Table 1 shows the coding
to use on a system that contains the components shown:
Table 1. Using COUNT and SKIP variables to assign
port numbersComponent |
Coding |
Tivoli Enterprise Monitoring Server |
The monitoring server uses
port 1918. |
Warehouse Proxy Agent
|
KDE_TRANSPORT=IP.PIPE COUNT:1 SKIP:15
This
coding reserves port 63358 (1918 + 15*4096) for the Warehouse Proxy Agent.
|
Windows OS
agent - Does not require firewall access
|
KDE_TRANSPORT=IP.PIPE SKIP:2
This
coding reserves port 10110 (1918 + 2*4096) for the Windows OS agent. If the agent fails to open
port 10110, it tries port 14206 and so on, until it finds an available
port or exhausts all possibilities.
|