ADSM-L

Re: [ADSM-L] Strange tcp_address value

2014-11-06 03:23:43
Subject: Re: [ADSM-L] Strange tcp_address value
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 6 Nov 2014 02:21:26 -0600
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.
>

<Prev in Thread] Current Thread [Next in Thread>