ADSM-L

Re: dual-homed clients

2003-02-28 03:08:48
Subject: Re: dual-homed clients
From: "Marcel J.E. Mol" <marcel AT MESA DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 28 Feb 2003 09:07:34 +0100
On Thu, Feb 27, 2003 at 05:03:21PM +0100, Lambelet,Rene,VEVEY,GL-CSC wrote:
> 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

it does report so.

>   and
>   # host tsm1
>   -> answer must be 172.20.1.10

and this too.

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

Host command is not available on this machine (remember this is
a windows 200 machine). However using
    > ping nms5
    it reports the 10.x address.

Using the nslookup command and asking about nms5 it reports
the correct 172 address and also for tsm1 the correct address is found.

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


I finally tried to hardcode the ip-address in the tcpclientaddress parameter
in dsm.opt and restarted the scheduler. To my supprise still the 10.x address
is listed in the 'q node nms5'.

Apperantly the tsm client code just ignores the tcpclientaddress parameter and
tries to arrange everything around the 'Nodename' paramater.
I checked some other hosts and all seem the give the same problem.
On an AIX client box for example I explicetly set the tcpclientaddress to
the dns entry (e.g. nms1_eth) that points to the 172.20.x.x address (e.g the
network segment the tsm server is in) but a 'q node' for these machine still
lists the 'main' hostname and ip-address (e.g. nms1 with 17.21.x.x).

Guess it is time to file a bug report to IBM

-Marcel

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

-- 
     ======--------         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

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