ADSM-L

Re: Server IP controls

2004-04-13 16:30:55
Subject: Re: Server IP controls
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 13 Apr 2004 16:31:14 -0400
Yes, it does.

As I mentioned, the DNS for the server points the the 192 address. The
session is initiated from the client to the server via this address. When
the server starts the backups, they come across the public 128.172.6.201
connection to the server, not the 192 connection. This is the problem.  I
want the TSM server to receive the backups across the 192 connection, not
the 128 connection.  Everything is established across the 192 but when the
backups flow, the go across the 128.



"Johnson, Milton" <milton.johnson AT CITIGROUP DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/13/2004 04:23 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: Server IP controls






Zoltan,

Try this, from a command line "on the client":
ping 192.168.20.44

Does the ping work? If the ping fails then you do not have a connection
to 192.168.20.44 and no amount of port opening, aliasing, etc. can get
your traffic to flow to and from 192.168.20.44.

H. Milton Johnson

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, April 13, 2004 12:01 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Server IP controls

The connection isn't the problem. The client talks to the server (and
vice-versa) just fine, if the ports are not blocked.

I want the server to use its private subnet to talk to the client, not
its public connection.  After all, this can be forced on the client via
TCPNODEADDRESS, can the server do the same.

Yes, I believe the private network is routed since lots of systems, both
physically on the same and not in the same building, connect to the TSM
server, just fine.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 04/13/2004
11:42:40 AM:

> Zoltan,
>
> According to RFC 1918, the following are private, non-routed subnets:
> 10.0.0.0 -> 10.255.255.255
> 172.16.0.0 -> 172.31.255.255
> 192.168.0.0 -> 192.168.255.255
>
> Being non-routed you cannot connect from 128.172.6.177 to
> 192.168.20.44 unless you have a connection to the same physical subnet

> as 192.168.20.44.  We use a private, non-routed subnet for our
> clients, but the clients are required a second NIC connected to the
> private, non-routed subnet.
>
> H. Milton Johnson
> Voice: (210) 677-6728
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Zoltan Forray/AC/VCU
> Sent: Tuesday, April 13, 2004 8:22 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Server IP controls
>
> Recently, we have been reconfiguring/locking down a lot of the TCPIP
> ports in use by the TSM servers and clients, attempting to
> control/route TSM traffic across a private subnet versus the more
> heavily used public network.
>
> However, we have been having some TSM scheduler communications, due to

> port blocking issues. I am trying to figure out if/how the TSM server
> can be configured to control which of its 2-IP connections it uses to
> communicate with the clients.
>
> Here is my configuration:
>
> TSM AIX 5.2.1.3 server.  2-IP connections, 128.172.6.201
> (primary/public) and 192.168.20.44 (private).
>
> The TSM client in question only has 1-IP connection, 128.172.6.177.
> The
> DSM.SYS (AIX) points to the server via DNS name that resolves to
> 192.168.20.44.
>
> My networking person says the traffic is flowing across the 6.201
> connection, not the 20.44 private connection.
>
> How, if possible, can I get the TSM server to use the private 20.44
> connection to perform the backups ?  Is there some server setting that

> can control this ?
>
> We are trying to get another connection to the client, using the
> private subnet. Unfortunately, there aren't any available ports in the

> switch, at this time. Yes, I know that when I get the other port in
> the client, I can use the TCPNODEADDRESS options to control this.

<Prev in Thread] Current Thread [Next in Thread>