I can check on that early next week, when I have a meeting scheduled with the
system administrators
for the two systems. The Nodes table rows for the two systems have the same
value for tcp_address
but distinct values for tcp_name and guid. As far as I can see, this would
imply a separate NAT for
each of the nodes.
Thomas Denier
Thomas Jefferson University Hospital
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Stephan Rumpfhuber
Sent: Thursday, November 06, 2014 8:07 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange tcp_address value
As far as I know is the content of the address field reported by the client
node and not resolved by the tsm server.
You are sure non of your clients is behind a NAT or uses these addresses
locally ?
On 11/06/2014 01:08 PM, Rhodes, Richard L. wrote:
> Check if your actlog has any ANR1639I messages. This is thrown when the TSM
> server detects an IP address change on a node.
>
>
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Thomas Denier
> Sent: Wednesday, November 05, 2014 11:45 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: 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.
>
>
> -----------------------------------------
> The information contained in this message is intended only for the personal
> and confidential use of the recipient(s) named above. If the reader of this
> message is not the intended recipient or an agent responsible for delivering
> it to the intended recipient, you are hereby notified that you have received
> this document in error and that any review, dissemination, distribution, or
> copying of this message is strictly prohibited. If you have received this
> communication in error, please notify us immediately, and delete the original
> message.
>
|
