A traceroute from the TSM server shows a typical route to one of my employer's 
core routers. There is no output after that. In particular, there are not lines 
with asterisks indicating timeouts.

I don't have logon access to the two clients, and I don't see how running 
tracerte commands on the clients would help. The two client systems are 
connecting regularly with addresses in the appropriate subnet. There is no 
evidence of any current source of 192.168 client addresses.

Thomas Denier
Thomas Jefferson University Hospital

-----Original Message-----

TCP address is mostly choosen by network and you can try tracerte from both 
ends to identify the issue 

By Sarav
+65-82284384


> On 6 Nov 2014, at 12:45 am, Thomas Denier <Thomas.Denier AT JEFFERSON DOT 
> EDU> wrote:
> 
> If I execute the command:
> 
> select node_name,tcp_address from nodes
> 
> on one of our TSM servers, two nodes have the same, very strange, 
> value for the
> address: 192.168.30.4. The same address appears in the corresponding 
> output fields from 'query node' with 'format=detailed'.
> 
> This address does not belong to my employer. All of the network 
> interfaces on the TSM server have addresses in one the officially 
> defined private address ranges. This has been the case since the TSM server 
> code was first installed.
> Given that, I don't see how a system with the address 192.168.30.4 
> could ever have connected to the TSM server.
> 
> I see session start messages for both nodes on a daily basis. There 
> are no error messages for these sessions except for an occasional 
> expired password message. Even when that happens, subsequent sessions 
> run without errors, indicating that a new password was negotiated 
> successfully. The origin addresses for the sessions look perfectly 
> reasonable. They are in the same private address range as the TSM 
> server addresses, and in the right subnet for the building the client 
> systems are in. Every relevant statement I have found in the TSM 
> documentation indicates that the tcp_address field should be updated to match 
> the session origin address.
> 
> When the TSM central scheduler attempts to request a backup of one of 
> the nodes it attempts to contact an address in the same subnet as the 
> session origin addresses.
> 
> The TSM server is running TSM 6.2.5.0 server code under zSeries Linux. 
> The two clients are running Windows XP and using TSM 6.2.2.0 client 
> code. The two clients are administered by the same group of people.
> 
> Does anyone know where the strange address could have come from, or 
> how to get the TSM to track the node addresses correctly in the future?
> 
> Thomas Denier
> Thomas Jefferson University Hospital
> The information contained in this transmission contains privileged and 
> confidential information. It is intended only for the use of the person named 
> above. If you are not the intended recipient, you are hereby notified that 
> any review, dissemination, distribution or duplication of this communication 
> is strictly prohibited. If you are not the intended recipient, please contact 
> the sender by reply email and destroy all copies of the original message.
> 
> CAUTION: Intended recipients should NOT use email communication for emergent 
> or urgent health care matters.