A laptop at someone's home would only be able to connect to the TSM server 
using a VPN tunnel. I have a home network that uses 192.168 addresses, and 
recently had occasion to use VPN to open an administrator session to the TSM 
server. I checked the origin address the TSM server reported for this session. 
It was in one of the on-campus subnets my employer uses for network 
infrastructure.

Even if the two client systems somehow managed to connect to the TSM server in 
the past using 192.168 addresses, they have not done so in the last five days, 
and have repeatedly logged on with addresses in the right subnet. TSM should 
have replaced the 192.168 addresses in the Nodes table with the session origin 
addresses that have been used in the last few days.

Thomas Denier
Thomas Jefferson University Hospital

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Roger Deschner
Sent: Thursday, November 06, 2014 3:21 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange tcp_address value

Don't worry. 192.168.*.* addresses are typically assigned locally by something 
like DHCP. They are not exposed outside your local network. In fact they can't 
be, because each of us has our own set of 192.168 addresses. Most home routers 
use this address range. This is quite normal. Read 
http://en.wikipedia.org/wiki/Private_network

This could mean that somebody on staff took their TSM-backed-up laptop home, 
and while it was connected to their home network, the automatic scheduled 
backup happened. This may be something you want to allow.

For serious tracking of nodes and their hardware, I use GUIDs, not IP addresses.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Thu, 6 Nov 2014, Anjaneyulu Pentyala wrote:

>Please check the /etc/host entry on your tsm server. /etc/host entry
>was added with wrong entry of ip address, how ever nodes are contacting
>by using DNS. check the nodes ip address in DNS.
>
>nslookup <tcp_name>
>
>Regards
>Anjen
>
>Aanjaneyulu Penttyala
>Technical Services Team Leader
>SSO MR Storage
>Regional Delivery Center Bangalore
>Delivery Center India, GTS Service Delivery
>Phone: +91-80-40258197
>Mobile: +91- 8497812222
>e-mail: anjan.pentyala AT in.ibm DOT com
>MTP, K Block, 4F, Bangalore, India
>
>
>
>
>From:
>Saravanan <evergreen.sarav AT GMAIL DOT COM>
>To:
>ADSM-L AT VM.MARIST DOT EDU
>Date:
>11/06/2014 08:40 AM
>Subject:
>Re: [ADSM-L] Strange tcp_address value
>Sent by:
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>
>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.
>
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.