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@VM.MARIST.EDU] On Behalf Of Stephan Rumpfhuber Sent: Thursday, November 06, 2014 8:07 AM To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf > Of Thomas Denier > Sent: Wednesday, November 05, 2014 11:45 AM > To: ADSM-L@VM.MARIST.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. >
