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.