A tcpclientaddress option with a 192.168 address would cause the TSM central scheduler to attempt to open a connection to that 192.168 address when the time came to run a scheduled backup. When the central scheduler tries to request a backup of either of the clients involved in the problem TSM reports failure to connect to an address in the correct subnet.
Thomas Denier Thomas Jefferson University Hospital -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Kirubhakaran, Wellington Sent: Thursday, November 06, 2014 12:15 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Strange tcp_address value Kindly check dsm.sys whether tcpclientaddress option is specified. Regards, Wellington +965 50369767 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Anjaneyulu Pentyala Sent: Thursday, November 06, 2014 7:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Strange tcp_address value 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.penty...@in.ibm.com MTP, K Block, 4F, Bangalore, India From: Saravanan <evergreen.sa...@gmail.com> To: ADSM-L@VM.MARIST.EDU Date: 11/06/2014 08:40 AM Subject: Re: [ADSM-L] Strange tcp_address value Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.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.den...@jefferson.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. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ 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.
