I fight firewall issues with a couple of tests.
From the TSM server:
PING <IPofNode>
TELNET <IPofNode> <ListeningPort>
Typically, the node is listening on 1501 I believe. It should be specified in
the node dsm.opt file.
Try stopping/starting the nodes TSM Scheduler service, then try the TELNET
again.
If PING works, but the TELNET doesn't, you've likely got a firewall block.
------------------------------------------------
Harold Vandeventer
Systems Programmer
State of Kansas - Department of Administration - Office of Information
Technology Services
Harold.Vandeventer AT ks DOT gov
(785) 296-0631
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Thomas Denier
Sent: Friday, June 01, 2012 1:54 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Address in ANR0406I message
We are seeing strange behavior with one of our client systems since it was
moved behind a firewall. The client is a Windows XP system with TSM
6.2.2.0 client code. It sends backups to a TSM 6.2.2.0 server running under
zSeries Linux. Before the firewall was introduced, the client was able to run
backups with prompted mode scheduling. When the firewall was introduced, the
client was given a new IP address and the old address was transferred to the
firewall. The backups stopped running when the firewall was introduced. The
messages reporting failed attempts to contact the client system indicated that
the TSM server was trying to contact the client using the old IP address.
Backups started running again after the client system administrator added a
'tcpclientaddress' option specifying the new IP address to dsm.opt.
According to the firewall administrator, the only traffic the firewall is
currently blocking is for automatic distribution of software patches (the
system is subject to regulatory requirements for explicit control of
configuration changes).
The 'TCP/IP Address' line in the output from 'query node' with 'f=d' shows the
new address, and did so before the introduction of the 'tcpclientaddress'
option. All ANR0406I session start messages for the client show the old address
(now the firewall address), and did so before the introduction of the
'tcpclientaddress' option. According to the firewall administrator, the
firewall is not configured for NAT (Network Address Translation).
I suspect that the address in an ANR0406I message is the source address of one
of the packets involved in the TCP session initiation process, but I cannot
find any documentation that says this explicitly. Does anyone know of an
authoritative statement on this point? Does anyone have a theory that would
account for the combination of behaviors described above?
Thomas Denier
Thomas Jefferson University Hospital
[Confidentiality notice:]
***********************************************************************
This e-mail message, including attachments, if any, is intended for the
person or entity to which it is addressed and may contain confidential
or privileged information. Any unauthorized review, use, or disclosure
is prohibited. If you are not the intended recipient, please contact
the sender and destroy the original message, including all copies,
Thank you.
***********************************************************************
|