26 Posts

July 5th, 2016 13:00

Hi,

This configuration is supported, and is what is called a multihomed conf, please check the rwlated part in the NetWorker administration guide.

The issue is related to the network, there is also a good part on troubleshooting network issue.

Follow those step, and give us your feedback.

Good luck

3 Posts

July 5th, 2016 21:00

Hi Largou,

Thanks for your valuable comments.

Actually, here we have only one Networker Server and one Storage Node. Multihomed configuration is for multiple networker server and storage nodes, so Multihomed configuration will not work here.

While using NSRLA command from client side it should connect to Networker IP only, but here it is checking all the IP's present in the Physical Server (Client). We don't know how to restrict it and also we tried with static routing but no change.

We tried disabling all the NIC's expect networker server NIC and Client NIC, still NSRLA command shows all IP's present in Physical Server.

Thanks,

Yuvaraj.

4 Operator

 • 

14.4K Posts

July 27th, 2016 08:00

NSRLA will always show all IPs on the system (actually all at the time when NSRLA resource has been created).  That list has nothing to do with connections.  Connections are set and ruled by your configuration and routing.

3 Posts

July 27th, 2016 23:00

Hi Hrvoje Crvelin,

Thanks for your comments.

Configuration and routing are set at Networker Server side or Windows Network Side.

Please suggest me.

Thanks.

Yuvaraj

2.4K Posts

July 28th, 2016 00:00

You should begin with the basics and run nsrlookup for both, forward and reverse directions.

Most important: Always check your hosts files just to make sure that there is no 'forgotten' entry.

4 Operator

 • 

14.4K Posts

July 28th, 2016 05:00

program not registered means communication could not be established.  Here we assume, for now, that network configuration might be blocked.  Reasons might be some blocks like firewall and of course routing. Other culprints might be client not installed.  Now, we know service is running due to nsradmin output.

Now, communication issue might in one direction too, eg. from server to client.  You need to establish that.  I do not know which interface you use, but I will use front-end so I will use those names.  If that is not the case, then replace those with desired ones.

server name is tmb-networker and client name is win-dc-dc-srvr.  Go on server and run following command:

echo p | nsradmin -p 390113 -i - -s win-dc-dc-srvr (this will test nsrexecd communication from server to client)

Next, go to client and from there run following client:

echo p | nsradmin -p 390113 -i - -s tmb-networker (this will test nsrexecd communication from client to server)


Both of these should work.  If not, something blocking the communication at basic level.


I assume you you wizard and that's where it fails.  If above tests are ok, define manually client without wizard.


In case you do not use front-end (primary) name for client, then use following rules:

- define client with name assigned to interface which can communicate with server (eg. client-vlanxxx.domain)

- in storage node field of the client, use name which client can use in communication with storage node (sn-vlanxxx.domain)

- in backup server interface of the client, use name which client can use in communication with server

No Events found!

Top