 |
Page 1 of 1
|
| Author |
Message |
Richard Rhodes
Guest
|
 Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole new
setup FW backups would have to work - we're kicking it real hard!!!! NOPE
- it didn't help! The only thing that didn't change in this server swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
|
| Mon Feb 06, 2012 3:48 am |
|
 |
Rick Adamson
Guest
|
 Firewall problem
Richard,
Just a shot in the dark; but do by chance employ any type of intrusion
prevention? By design it will allow the connection thru the firewall to
the target IP, then assesses the traffic for suspicious behavior.
Here I had the exact situation, and seeing as the clients would connect
to the TSM Server I quickly dismissed the firewall. The clients would
start a session and within seconds disconnect. Finally, at my wits end I
contacted our network team, a rule was added to the intrusion prevention
system the issue was resolved.
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Richard Rhodes
Sent: Monday, February 06, 2012 6:47 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it
was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact
the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other
working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars.
The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole
new
setup FW backups would have to work - we're kicking it real hard!!!!
NOPE
- it didn't help! The only thing that didn't change in this server
swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing
backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
|
| Mon Feb 06, 2012 6:41 am |
|
 |
Thomas Denier
Guest
|
 Firewall problem
-----Richard Rhodes wrote: -----
Question: Is there any setting in TSM that could explain failing
backups for firewalled servers?
The 'register node' and 'update node' commands have a
'sessioninitiation' parameter. The default value, 'clientorserver',
would be needed for the backup arrangement you describe for clients
outside the firewall. The other possible value, 'serveronly', would
cause these backups to fail, possibly with the symptoms you describe.
Thomas Denier=
|
| Mon Feb 06, 2012 6:59 am |
|
 |
Huebner,Andy,FORT WORT...
Guest
|
 Firewall problem
Maybe this will help.
We have a firewall rule that allows all of the DMZ servers to contact the TSM servers and the TSM servers are allowed in on specific ports.
In the opt files we have these lines:
httpport yyyy
webports xxxx zzzz
All of our servers run the CAD.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Richard Rhodes
Sent: Monday, February 06, 2012 5:47 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole new
setup FW backups would have to work - we're kicking it real hard!!!! NOPE
- it didn't help! The only thing that didn't change in this server swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.
Thank you.
|
| Mon Feb 06, 2012 7:54 am |
|
 |
Shawn Drew
Guest
|
 Firewall problem
compare the "q opt" output from an instance that works with the instance
that doesn't. There might be a conservative timeout setting.
Other long-shot things to compare are "q node (NODENAME) f=d" for the
specific nodes that are having trouble and "q stat"
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
rrhodes < at > FIRSTENERGYCORP.COM
Sent by: ADSM-L < at > VM.MARIST.EDU
02/06/2012 06:46 AM
Please respond to
ADSM-L < at > VM.MARIST.EDU
To
ADSM-L
cc
Subject
[ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole new
setup FW backups would have to work - we're kicking it real hard!!!! NOPE
- it didn't help! The only thing that didn't change in this server swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
|
| Mon Feb 06, 2012 9:47 am |
|
 |
Schneider, Jim
Guest
|
 Firewall problem
I've had to use schedmode polling to get some firewall backups to run.
Jim Schneider
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > vm.marist.edu] On Behalf Of
Shawn Drew
Sent: Monday, February 06, 2012 11:35 AM
To: ADSM-L < at > vm.marist.edu
Subject: Re: [ADSM-L] Firewall problem
compare the "q opt" output from an instance that works with the instance
that doesn't. There might be a conservative timeout setting.
Other long-shot things to compare are "q node (NODENAME) f=d" for the
specific nodes that are having trouble and "q stat"
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
rrhodes < at > FIRSTENERGYCORP.COM
Sent by: ADSM-L < at > VM.MARIST.EDU
02/06/2012 06:46 AM
Please respond to
ADSM-L < at > VM.MARIST.EDU
To
ADSM-L
cc
Subject
[ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it
was brought up a couple years ago we have fought to get firewall backups
to work but have failed. Nodes out behind a firewall are able to
contact the TSM server, a sessions is established, then it is
immediately disconnected. This repeats over and over as the node
retries. You can sometimes see 50 or more sessions - all hung - for a
firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other
working instances. If we move the node to one of our other TSM
instances it worked just fine!! In all, we firgured this HAD to be a
firewall setup problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars.
The new servers had to have new IP addresses and run a newer AIX v6.
We've done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole
new setup FW backups would have to work - we're kicking it real hard!!!!
NOPE
- it didn't help! The only thing that didn't change in this server
swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing
backups for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in
error, please delete it and immediately notify the sender. Any use not
in accord with its purpose, any dissemination or disclosure, either
whole or partial, is prohibited except formal approval. The internet can
not guarantee the integrity of this message. BNP PARIBAS (and its
subsidiaries) shall (will) not therefore be liable for the message if
modified. Please note that certain functions and services for BNP
Paribas may be performed by BNP Paribas RCC, Inc.
|
| Mon Feb 06, 2012 10:41 am |
|
 |
Clark, Margaret
Guest
|
 Firewall problem
You doubtless checked the DNSLOOKUP option, and set it the same way on all your servers.
Is it possible that the DNS for the problem client is also the only DNS that is also behind the firewall? - Margaret
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Richard Rhodes
Sent: Monday, February 06, 2012 3:47 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although only five work. The six instances are on separate servers, so each has it's own IP address and firewall rules. The firewall rules are all identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it was brought up a couple years ago we have fought to get firewall backups to work but have failed. Nodes out behind a firewall are able to contact the TSM server, a sessions is established, then it is immediately disconnected. This repeats over and over as the node retries. You can sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW rules, talked with IBM support, run traces for them, check AIX setup, checked TSM5 setup, compared anything related to TSM5 to the other working instances. If we move the node to one of our other TSM instances it worked just fine!! In all, we firgured this HAD to be a firewall setup problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars. The new servers had to have new IP addresses and run a newer AIX v6. We've done this upgrade for the other TSM servers already. With new IP addresses we had to create new FW rules. We figured that with a whole new setup FW backups would have to work - we're kicking it real hard!!!! NOPE
- it didn't help! The only thing that didn't change in this server swing
was the actual TSM instance. It seems our FW backup problem on this one instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing backups for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
|
| Mon Feb 06, 2012 12:13 pm |
|
 |
Richard Rhodes
Guest
|
 Firewall problem
We do run some devices called "Preventia". I wonder if those are what you
describe - intrusion prevention.
Rick
From: Rick Adamson <RickAdamson < at > WINN-DIXIE.COM>
To: ADSM-L < at > VM.MARIST.EDU
Date: 02/06/2012 09:39 AM
Subject: Re: Firewall problem
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
Richard,
Just a shot in the dark; but do by chance employ any type of intrusion
prevention? By design it will allow the connection thru the firewall to
the target IP, then assesses the traffic for suspicious behavior.
Here I had the exact situation, and seeing as the clients would connect
to the TSM Server I quickly dismissed the firewall. The clients would
start a session and within seconds disconnect. Finally, at my wits end I
contacted our network team, a rule was added to the intrusion prevention
system the issue was resolved.
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Richard Rhodes
Sent: Monday, February 06, 2012 6:47 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it
was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact
the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other
working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars.
The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole
new
setup FW backups would have to work - we're kicking it real hard!!!!
NOPE
- it didn't help! The only thing that didn't change in this server
swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing
backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
|
| Tue Feb 07, 2012 5:48 am |
|
 |
Richard Rhodes
Guest
|
 Firewall problem
Thanks for all the thoughts!
The 'register node' and 'update node' commands have a
'sessioninitiation' parameter. The default value, 'clientorserver',
would be needed for the backup arrangement you describe for clients
outside the firewall. The other possible value, 'serveronly', would
cause these backups to fail, possibly with the symptoms you describe.
Will check it out.
We have a firewall rule that allows all of the DMZ servers
to contact the TSM servers and the TSM servers are
allowed in on specific ports.
In the opt files we have these lines:
httpport yyyy
webports xxxx zzzz
I'm not a firewall person - but the rules we have for the other five tsm
servers all work just fine.
It's just this one grrrrrr tsm server. THey've checked and checked.
compare the "q opt" output from an instance that works with the instance
that doesn't. There might be a conservative timeout setting.
Yes. We've done that many times. That's what makes this such
an frustrating problem. it looks the same as the other servers.
So does the AIX setup, so does the fw rules (from what the fw folks
say - except for a diff ip addr).
Other long-shot things to compare are "q node (NODENAME) f=d" for the
specific nodes that are having trouble and "q stat"
Will do.
I've had to use schedmode polling to get some firewall backups to run.
Yes, we've had to do this also for some nodes to get them to work.
Some nodes just won't work unless we change to polling. The nodes
behind firewalls just don't work with this one tsm instance, but if we
move
the node to one of the other instances - poof (technical term) - it works.
You doubtless checked the DNSLOOKUP option, and set it the
same way on all your servers.
Is it possible that the DNS for the problem client is also
the only DNS that is also behind the firewall? - Margaret
Actually, no . . .not familiar with that options. WIll have to
read up on it.
Now . . .maybe I brought up this problem too quickly. It turns out
the firewall folks missed some firewalls, so rules were not made
on some. The tsm6 instance (where fw backups work) is having failed
backups because of this. It could be that our testing last friday
evening was with a firewall'ed nodes for which there weren't
any rules!!
Nothing is simple . . . .
Thanks
Rick
-----------------------------------------
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.
|
| Tue Feb 07, 2012 6:10 am |
|
 |
Rick Adamson
Guest
|
 Firewall problem
I am not familiar with that particular product, but I would either talk
to whoever manages it or the vendor themselves. The ones I have used
have verbose logging so it's pretty easy to determine if it is the
problem.
Configuring them is very similar to a firewall. In our operation we have
it allow traffic from a particular subnet to our specific TSM servers IP
addresses on the ports used for the TSM clients (1500, 1580, 1581).
Hope that helps.....
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Richard Rhodes
Sent: Tuesday, February 07, 2012 8:40 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Firewall problem
We do run some devices called "Preventia". I wonder if those are what
you
describe - intrusion prevention.
Rick
From: Rick Adamson <RickAdamson < at > WINN-DIXIE.COM>
To: ADSM-L < at > VM.MARIST.EDU
Date: 02/06/2012 09:39 AM
Subject: Re: Firewall problem
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
Richard,
Just a shot in the dark; but do by chance employ any type of intrusion
prevention? By design it will allow the connection thru the firewall to
the target IP, then assesses the traffic for suspicious behavior.
Here I had the exact situation, and seeing as the clients would connect
to the TSM Server I quickly dismissed the firewall. The clients would
start a session and within seconds disconnect. Finally, at my wits end I
contacted our network team, a rule was added to the intrusion prevention
system the issue was resolved.
~Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Richard Rhodes
Sent: Monday, February 06, 2012 6:47 AM
To: ADSM-L < at > VM.MARIST.EDU
Subject: [ADSM-L] Firewall problem
Hi Everyone,
We have six TSM v5.5.5 instances (on AIX) named TSM1 to TSM6. All six
instances handle backups for nodes that are behind firewalls, although
only five work. The six instances are on separate servers, so each has
it's own IP address and firewall rules. The firewall rules are all
identical so we can put any node on any TSM server.
We cannot get firewall backups to work to our TSM5 instance. Since it
was
brought up a couple years ago we have fought to get firewall backups to
work but have failed. Nodes out behind a firewall are able to contact
the
TSM server, a sessions is established, then it is immediately
disconnected. This repeats over and over as the node retries. You can
sometimes see 50 or more sessions - all hung - for a firewalled node.
We've done everything we can think of: check/double/triple checked FW
rules, talked with IBM support, run traces for them, check AIX setup,
checked TSM5 setup, compared anything related to TSM5 to the other
working
instances. If we move the node to one of our other TSM instances it
worked just fine!! In all, we firgured this HAD to be a firewall setup
problem of some kind.
This past weekend we move TSM5 (and TSM6 also) to new servers/lpars.
The
new servers had to have new IP addresses and run a newer AIX v6. We've
done this upgrade for the other TSM servers already. With new IP
addresses we had to create new FW rules. We figured that with a whole
new
setup FW backups would have to work - we're kicking it real hard!!!!
NOPE
- it didn't help! The only thing that didn't change in this server
swing
was the actual TSM instance. It seems our FW backup problem on this one
instance HAS to be in TSM itself.
Question: Is there any setting in TSM that could explain failing
backups
for firewalled servers?
Thanks
Rick
-----------------------------------------
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.
|
| Tue Feb 07, 2012 6:17 am |
|
 |
Shawn Drew
Guest
|
 Firewall problem
Just remember, there are 2 ways of backing up through a firewall.
- The "insecure" way, where you open incoming ports to the TSM Servers
"TCPPORT" setting, and perform backups in "polling" mode. If the client
was compromised, it would have access to all the backups, and conceivably
the TSM server.
- The secure way where you only open outgoing ports to the TSM client, and
use the SESSIONINITIATE=serveronly; TCPCLIENTPORT options in prompted mode
Just make sure and don't get those confused.
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
rrhodes < at > FIRSTENERGYCORP.COM
Sent by: ADSM-L < at > VM.MARIST.EDU
02/07/2012 09:07 AM
Please respond to
ADSM-L < at > VM.MARIST.EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] Firewall problem
Thanks for all the thoughts!
The 'register node' and 'update node' commands have a
'sessioninitiation' parameter. The default value, 'clientorserver',
would be needed for the backup arrangement you describe for clients
outside the firewall. The other possible value, 'serveronly', would
cause these backups to fail, possibly with the symptoms you describe.
Will check it out.
We have a firewall rule that allows all of the DMZ servers
to contact the TSM servers and the TSM servers are
allowed in on specific ports.
In the opt files we have these lines:
httpport yyyy
webports xxxx zzzz
I'm not a firewall person - but the rules we have for the other five tsm
servers all work just fine.
It's just this one grrrrrr tsm server. THey've checked and checked.
compare the "q opt" output from an instance that works with the instance
that doesn't. There might be a conservative timeout setting.
Yes. We've done that many times. That's what makes this such
an frustrating problem. it looks the same as the other servers.
So does the AIX setup, so does the fw rules (from what the fw folks
say - except for a diff ip addr).
Other long-shot things to compare are "q node (NODENAME) f=d" for the
specific nodes that are having trouble and "q stat"
Will do.
I've had to use schedmode polling to get some firewall backups to run.
Yes, we've had to do this also for some nodes to get them to work.
Some nodes just won't work unless we change to polling. The nodes
behind firewalls just don't work with this one tsm instance, but if we
move
the node to one of the other instances - poof (technical term) - it works.
You doubtless checked the DNSLOOKUP option, and set it the
same way on all your servers.
Is it possible that the DNS for the problem client is also
the only DNS that is also behind the firewall? - Margaret
Actually, no . . .not familiar with that options. WIll have to
read up on it.
Now . . .maybe I brought up this problem too quickly. It turns out
the firewall folks missed some firewalls, so rules were not made
on some. The tsm6 instance (where fw backups work) is having failed
backups because of this. It could be that our testing last friday
evening was with a firewall'ed nodes for which there weren't
any rules!!
Nothing is simple . . . .
Thanks
Rick
-----------------------------------------
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.
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
|
| Tue Feb 07, 2012 8:26 am |
|
 |
|
|
The time now is Fri May 25, 2012 1:22 pm | All times are GMT - 8 Hours
|
Page 1 of 1
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|