Marcel, here the answer from one of my AIX colleague:

There are different ways to make this work, one is:

Through correct name resolution:

- Check name resolution on tsm1 using command
  # host nms5
  -> answer must be 172.20.1.15
  and
  # host tsm1
  -> answer must be 172.20.1.10

- Check name resolution on nms5 using command
  # host nms5
  -> answer must be 172.20.1.15
  and
  # host tsm1
  -> answer must be 172.20.1.10

This way you don't have to use any routes.
Name resolution is the most common error in this cases.


Cheers,
Jesús MUIÑO CONDE
Supplier for GLOBE
Central Support Center
Unix Level 2
c/o Nestec SA
Av. Nestlé 55  CH-1800 Vevey (Switzerland) 
tél +41 (0)21 924 79 23   fax +41 (0)21 703 30 17      local Bussigny
mailto:jesus.muinoconde AT nestle DOT com

-----Original Message-----
From: Paul van Dongen [mailto:paul AT VANGUARD-IT.COM DOT BR]
Sent: Thursday,27. February 2003 15:18
To: ADSM-L AT VM.MARIST DOT EDU
Subject: RES: dual-homed clients


Hi Marcel, 

   Do you have a TCPCLIENTADDRESS line in your DSM.OPT? It tells the
server which address to contact in prompted scheduling mode.


-- 
Paul Gondim van Dongen
Engenheiro de Sistemas
MCSE
Tivoli Certified Consultant - Storage Manager
VANguard - Value Added Network guardians http://www.vanguard-it.com.br
Fone: 55 81 3225-0353
 

-----Mensagem original-----
De: Marcel J.E. Mol [mailto:marcel AT MESA DOT NL] 
Enviada em: Thursday, February 27, 2003 10:31
Para: ADSM-L AT VM.MARIST DOT EDU
Assunto: dual-homed clients


Hi list,

We have a problem concerning dual-homed clients in our TSM environment:

  SERVER                                     CLIENT
 +--------------------+                     +--------------------+
 | AIX 5.1            |172.20.1.10          | Win 2000           |
10.128.3.15
 | TSM server 5.1.5.4 |---------------------| TSM client 5.1.5.9
|------------
 | Host: tsm1         |         172.20.1.15 | Host: nms5         |
 +--------------------+                     +--------------------+


When the scheduler service on nms5 is started it correctly connects to
the tsm1 server and gets schedule info. This traffic must go via the
172.20 network as the 10.x net is not connected to the 172.20 net.
However, listing the node info on the server it shows the 10.x address
as client address:

tsm: TSM1>q node nms5 f=d

                     Node Name: NMS5
                      Platform: WinNT
               Client OS Level: 5.00
                Client Version: Version 5, Release 1, Level 5.9
            Policy Domain Name: FSNT
         Last Access Date/Time: 02/27/03   13:24:00
        Days Since Last Access: <1
        Password Set Date/Time: 02/26/03   14:13:41
       Days Since Password Set: 1
         Invalid Sign-on Count: 0
                       Locked?: No
                       Contact:
                   Compression: Client
       Archive Delete Allowed?: Yes
        Backup Delete Allowed?: No
        Registration Date/Time: 02/26/03   14:13:41
     Registering Administrator:
Last Communication Method Used:
   Bytes Received Last Session: 0
       Bytes Sent Last Session: 0
      Duration of Last Session: 0.00
   Pct. Idle Wait Last Session: 0.00
  Pct. Comm. Wait Last Session: 0.00
  Pct. Media Wait Last Session: 0.00
                     Optionset: WIN_SERVER
                           URL: http://nms5:1581
                     Node Type: Client
    Password Expiration Period:
             Keep Mount Point?: No
  Maximum Mount Points Allowed: 2
        Auto Filespace Rename : No
             Validate Protocol: No
                   TCP/IP Name: NMS5
                TCP/IP Address: 10.128.3.15
            Globally Unique ID:
1d.69.3d.a1.2c.6e.11.d7.8e.d1.00.02.55.67.75.b4


Now when the tsm1 server wants to contact the nms5 client to start the
backup it cannot reach it:

02/26/03   19:02:19      ANR8213W Session open with 10.128.3.15 timed
out.
02/26/03   19:02:19      ANR2716E Schedule prompter was not able to
contact
                         client NMS5 using type 1 (10.128.3.15 1501).

When we disable the clients network interface on the 10.x network
everything works fine.

Also when directly initiating a backup from the client itself works
fine.

The dns entry for the NMS5 machine only reports the 172.20.1.15 address.

So what goes wrong here? The client initially connects to the server
using its 172.x interface and address but the server registers it with
the 10.x address. Why does tsm starts with a clients IP-address anyways,
while it knows the clients TCPNAME and hence should use that as a base
connection location?

Anybody else seen this behaviour and/or knows how to resolve this?

I have seen this behaviour on more dual-homed machines (AIX, Netware and
Windows) but in most cases the 'other' network is reachable via some
router so tsm can connect to those clients. Fortunately the real backup
data still goes via the 172.20 network (which is a 100Mb net as opposed
to a 16 Mb token ring for the other networks).

Any hints/tips?

-Marcel
--
     ======--------         Marcel J.E. Mol                MESA
Consulting B.V.
    =======---------        ph. +31-(0)6-54724868          P.O. Box 112
    =======---------        marcel AT mesa DOT nl                 2630 AC
Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The
Netherlands ____
 They couldn't think of a number,           Linux user 1148  --
counter.li.org
    so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com