Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Tivoli predefined ports.

The object dispatcher (oserv) service listens on TCP port 94. This is a well-known port, assigned to Tivoli by the Internet Assigned Numbers Authority (IANA). All inter-ORB and inter-TMR communications with the object dispatcher use this port as the destination. When a port range is specified in the TMR, the client port that connects to 94 will be created within the port range.

Tivoli has not established any other predefined ports with IANA as registered ports (those that fall in the range 1024 to 49151). The table below is a list of the predefined ports used by the Tivoli Framework.

• 94 TCP objcall Listening port Tivoli object request broker
  (ORB) - Changeable but not supported in current release
• 94 UDP objcall Listening port Tivoli object request broker
  (ORB) - Changeable but not supported in current release
• 111 UDP portmapper RPC portmapper
• 135 DCE Usage by Tivoli Global Sign-On
• 139 NetBIOS SMB Installation of Trip from one managed node to another during Windows NT managed node install and TMA proxy install - Not changeable
• 162 UDP NetView/TEC SNMP Adapter SNMP Adapter - not changeable
• 389 Tivoli LDAP connection for Netscape Directory server
• 512 exec Installation of managed node/endpoint (rexec) - Not changeable
• 514 shell Installation of managed node/endpoint (rexec) - Not changeable
• 1500 ADSM server port Tivoli Storage Manager server port
• 1543 ADSM SSL port Tivoli Storage Manager SSL Web port
• 1580 ADSM web admin Tivoli Storage Manager Web administrative interface
• 1581 ADSM client port Tivoli Storage Manager client Web interface and scheduling daemon
• 2501 Remote Control RCL target, listening port - Changeable with policy rc_def_ports
• 2502 Remote Control file transfer RCL target - changeable with policy rc_def_ports
• 2503 Remote Control chat RCL target - Changeable with policy rc_def_ports
• 2600 ARM server and client subagents (default) Application Response Measurement
• 3000 tivaddin Tivoli Notes Module, used for notes console (client) and listening port
• 5529 TCP TEC_recv_agent TEC reception engine listening port (default on Windows NT) - Changeable
• 6000 X11 Used by desktop started with the tivoli command
• 6543 TCP UserLink UserLink listening port - Not changeable
   

Tivoli port range

Some object call requests cause the oserv to create TCP client connections (to the remote object dispatcher service) using ephemeral ports (short-lived TCP ports in the high port range, that is those above 1023). This will be true for DM monitors. The object-call induced client connections, the IOM channel server, and IOM ephemeral client connections can (optionally) locally bind to a port from a pre-selected port range.

• 8180 TCP SSL daemon Tivoli User Administration ?One Password utility
• 8890 TCP TACF Tivoli Security Management, see the seagent description in the reference manual for TACF
  - Changeable but not recommended
• 8891 TCP TACF Tivoli Security Management, used with 8890
  - Changeable but not recommended
• 9401 TCP BDT Bulk Data Transfer listening port (as of TMF 3.7.1)-Changeable
• 9494 UDP Tivoli management gateway Tivoli management gateway listening port - Changeable
• 9494 TCP Tivoli management gateway Tivoli management gateway listening port - Changeable
  9495 TCP TMA endpoint Tivoli management agent listening port - Changeable
• 31111 Maestro Tivoli workload scheduler
• 31195 Maestro Load Balancer Tivoli workload scheduler load balancer
  Any high port Inter-Object Messaging An IOM channel port is allocated by the operating system from high ports (>1023) and may or may not adhere to a TMR port range depending on the function involved
  Any high port Inter-Object Messaging Java console IOM connection
  Any high port exec The return from an rexec process could use any high destination port Port Protocol Method/Service Comment

Whenever a new socket needs to be opened, a call to a framework service is made. This service finds the next available port within the specified range and returns it to the caller. There are some differences in the port selection algorithm between Windows NT and UNIX. It is not important to understand the selection algorithm for implementing Tivoli across firewalls but we include it here as background information. The algorithm differences stem from having to get around some of the non-standard (X/OPEN non-compliance) features of the Winsock API. On UNIX, a port is considered IN USE if it is held in the TCP TIME-WAIT state and binds to these ports fail appropriately. On NT, subsequent binds to ports already in TIME-WAIT bind successfully, but fail during the connect() call.

On UNIX, when a managed node/gateway binds to a port from the range, Tivoli starts at the lowest number in the range and hunts for a port that will bind successfully. If bind() fails, the Tivoli communications moves to the next port in the port range and retries the bind. This bind attempt continues until the bind() finds an available port. It finally gives up the search when the upper bound in the range is reached.

On Windows NT, Tivoli always remembers the last port bound and connected successfully from this range. Subsequent bind attempts start from the next port. If the bind fails, the algorithm proceeds just like in the UNIX case, except that when the upper bound is reached, it wraps around and then continues until the start point is reached. This wraparound is needed because we may start at a port that is already near the upper bound, and by not wrapping, we do not give the bind a fair chance. This practice has been found to be more efficient than starting from the lower bound and heading up.

However, if the NT bind() succeeds but the connect() fails with the EADDRINUSE return code, the algorithm makes five more attempts to bind and reconnect, each time bumping the port by one. When all five attempts fail to connect, it gives up. When the BDT service is enabled the object-call induced client connections will always use BDT listening port on the server side. Note: Unfortunately, not all services and applications completely respect a configured port range. During installation for instance, several ports will be opened outside of the port range. This is partly to do with the implementation of the rexec service and partly because of some identified problems within the installation process. In later chapters, we see which components do not respect the port range.
The port range can be set using the command odadmin set_port_range on the TMR server. This command sets the port range for all managed nodes within the TMR. Every framework-based connection will start to create connections that reside in this range. Existing (sustained) connections will not be affected by this change - there is no forced reconnection to use the new range.

Usage:
odadmin set_port_range "range"

Restricts IOM channel communication ports and Tivoli communication between managed nodes to the specified port range. This option is especially helpful for firewall administrators who need to regulate the availability of ports. The oserv and gateway default ports are not affected by this option.

Examples:
odadmin set_port_range 2500-3000
odadmin set_port_range 5900-5999,6010-6040,7001
odadmin set_port_range ""

The last example resets the range to no Tivoli-defined range. To enable or disable the single port BDT service use the following command:

odadmin single_port_bdt FALSE|TRUE [od...|clients|all ]

Examples:
odadmin single_port_bdt TRUE 1
odadmin single_port_bdt TRUE clients
odadmin single_port_bdt FALSE all

To modify the port number used by the single port BDT service you can use the following command:

odadmin set_bdt_port port_number [od...|clients|all ]

Examples:
odadmin set_bdt_port 12050 all
odadmin set_bdt_port 9401 all

The settings will take effect only after the MDist 2 services are restarted. Recommended way to start and stop the services is by issuing odadmin
shutdown/start commands as opposed to odadmin reexec command. To view the current port range configuration, and single port BDT settings execute:

odadmin odinfo od

NOTE: The port range restriction will not necessarily be adhered to by every Tivoli product. The observance of port range restrictions may also vary by release level. Check product release notes for changes at each release. When setting the port range, it needs to be understood that for a Tivoli management gateway the range applies also for any downcalls to its assigned endpoints. Therefore, carefully set the range to avoid a managed node or gateway running out of available ports.The setting of the port range may involve some trial and error until ideal values can be found. If a standard Tivoli operation fails, especially with some form of communication error, such as an IOM error, then the port range should always be checked in relation to the activity that was taking place. The operating system may generate something like an "address in use" error that will usually result in a "general failure" in Tivoli.