I found two ANR1639I messages within the last five days. Neither involved a
node with a 192.168 address in the Nodes table. One showed a change of GUID,
and the other showed an IP address change, with both old and new addresses in
legitimate on-campus subnets.
Thomas Denier
Thomas Jefferson University Hospital
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rhodes, Richard L.
Sent: Thursday, November 06, 2014 7:08 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange tcp_address value
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.
|
