The two clients are connecting to the TSM server regularly with distinct 
addresses in the appropriate subnet. Even if misconfiguration of the IP stacks 
on the clients produced 192.168 addresses sometime in the past, TSM should have 
replaced the 192.168 addresses in the Nodes table with the session origin 
addresses the nodes are currently using.

Thomas Denier
Thomas Jefferson University Hospital

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Grigori Solonovitch
Sent: Wednesday, November 05, 2014 11:48 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange tcp_address value

Most possible you have IP duplication clients. Windows is selecting some 
strange addresses in this case. Please check client configuration (preffered) 
by "ipconfig /all" and try to restart TSM services on clients.

Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, 
www.ahliunited.com.kw


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Thomas Denier
Sent: 05 11 2014 7:45 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Strange tcp_address value

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.


Please consider the environment before printing this Email.

________________________________

CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.