Technical Blog Post
IBM Tivoli Monitoring - Agent Communication to and from the Tivoli Enterprise Monitoring Server
Every instance of the IBM Tivoli Monitoring product contains the ITM basic services component. One service that this component provides is the Remote Procedure Call (RPC) architecture. This allows ITM instances to register functions that can be invoked from another ITM instance using RPC.
Because of this, each ITM instance has the capability to act as a client that sends requests to other ITM instances, or as a server that accepts requests from other ITM instances.
When an agent connects to its monitoring server (TEMS), it is important to note that the TEMS must be able to send requests to the agent, just as the agent must be able to send requests to the TEMS.
The port on which the monitoring server listens is referred to as the base port, which is defined by the KDE_TRANSPORT (z/OS) or KDC_FAMILIES environment variable. Using the IP.PIPE (TCP) protocol as an example, this base port defaults to port 1918. Agents such as the Tivoli Enterprise Portal Server as well as ITM / OMEGAMON agents use the algorithm base_port + n * 4096, n > 0 such that the calculated port is less than or equal to 65535, a TCPIP architecture limitation.
This means that the agent will initiate a socket connection to the TEMS base port, and in return the TEMS will initiate a socket connection to the port upon which the agent is listening. If the socket connection in either direction cannot be made, the agent does not connect to the TEMS successfully and the agent is marked offline in the TEMS node status table.
If network routing or firewall rules prohibit this reverse socket connection, then the agent connection can be defined to be ephemeral. This means that the agent will set up the initial socket connection to the TEMS, but the TEMS will then use that agent-initiated connection to send requests to the agent rather than initiating its own reverse connection to the agent. An agent connection is defined at the agent to be ephemeral by adding the EPHEMERAL:Y value to the setting in KDE_TRANSPORT or KDC_FAMILIES for the protocol being used, such as IP.PIPE.
An agent connection that is ephemeral also causes the agent not to establish a listening port, as all inbound requests are received on the socket connection that the agent made to the TEMS at the time it initially connected. This also gets around the limitation where the calculated agent port value (base_port + n * 4096) would be greater than 65535.