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.
***********************************************************************