02-20-2012 01:52 AM
Solved! Go to Solution.
02-22-2012 01:15 AM
"i still don't know how to find what 3rd-party application result in this"
You need to work with your Windows Admin to find out.
All we know from NBU point of view is that SOMETHING is blocking NBU. There is no way that we can say or find out by just looking at NBU logs.
Work with your Admins, check software in Add/Remove programs, check AV settings, check for any sort of security/intrusion software.
This is proof that 'something else' is closing connecting:
we can see 13782 on client is ok, but soon the connection is closed by something on client, so i have also a doubt that something on client prevent the connection between client and server.
As a matter of interest - NBU uses vnetd (13724) as from 6.0 and PBX (1556) as from 7.0.1.
02-20-2012 02:22 AM
Create a bpcd folder under netbackup\logs\ on the client
Then try to connect again and lets see what it says in the log file
Obviously make sure no firewalls in active
02-20-2012 02:54 AM
As what Mark suggested, create the bpcd log on the client.
The check the log after running bptestbpcd -client <client_name>
Check the log file. If there is no new log data, the connection is not getting to the client at all.
02-20-2012 03:18 AM
02-20-2012 03:26 AM
02-20-2012 03:33 AM
'Something' in your client is preventing socket setup.
It could be some 3rd-party application or else problematic NBU client installation.
There have been various threads in this forum where removal and re-installation of NBU client software solved the problem.
For examples of 3rd-party software causing connect-back problems, see http://www.symantec.com/docs/TECH88628
02-20-2012 03:36 AM
On your client create a directory named bpcd under:
<installpath>\veritas\netbackup\logs\
When you then try and connect to it or run the commands from the Master Server it will create a log file
Post the contents of that on here for us to take a look
#EDIT#
Sorry - I see now that you did that - As Marianne says something is blocking the communication - check that there are no firewalls or anti virus blocking it
also check that a ping delivers the correct IP addresses in both directions (master to client to master)
02-20-2012 03:38 AM
You should see an incoming IP address from the source host to the client in the bpcd log.
Can your client resolve that IP address to a name? Is the name in the SERVER list for the client
Does your client have a network route to it?
How many network interfaces does your client have?
02-20-2012 04:16 AM
02-20-2012 04:23 AM
Apart from the NetBackup Client Service not actually running the most likely causes are:
1. A firewall
2. Anti Virus (application protection etc.) blocking its communication
3. DNS / Host name resolution
02-20-2012 06:42 AM
'any other reasons related to this problem?'
As I've said in my previous post, 2 possible reasons:
1. Faulty NBU installation - fixed by re-installation.
2. 3rd-party application preventing socket setup.
****EDIT****
One more thing:
The OS compatibility Guide says the following about XP SP2 (possibly same for SP3?):
Reference Article: TECH32041 for Windows XP SP2 firewall considerations.
02-21-2012 01:09 AM
02-21-2012 01:38 AM
Can you check a few things then please and let us know what you find:
1. What anti virus is installed on the client
2. Does the client have any form of firewall enabled
3. Is there anything in the application or system event logs of any note at around the time of the disconnect - on the client
4. Is the clients network card set to full duplex
Thanks
02-21-2012 07:14 AM
Have you had a look at TECH32041 yet? (Windows XP SP2 firewall considerations).
The assumption is that it will be applicable for SP3 as well.
Either disable firewall or add ports as per the TN. Please add ports 13724 (vnetd) and 1556 (PBX) as well.
02-21-2012 05:42 PM
02-22-2012 01:15 AM
"i still don't know how to find what 3rd-party application result in this"
You need to work with your Windows Admin to find out.
All we know from NBU point of view is that SOMETHING is blocking NBU. There is no way that we can say or find out by just looking at NBU logs.
Work with your Admins, check software in Add/Remove programs, check AV settings, check for any sort of security/intrusion software.
This is proof that 'something else' is closing connecting:
we can see 13782 on client is ok, but soon the connection is closed by something on client, so i have also a doubt that something on client prevent the connection between client and server.
As a matter of interest - NBU uses vnetd (13724) as from 6.0 and PBX (1556) as from 7.0.1.
02-22-2012 03:51 AM
Just re-read your very first post and saw this "Couldn't get peer hostname" and
C:\ >netstat -an | find /i "13782"
TCP 0.0.0.0:13782 0.0.0.0:0 LISTENING
Make sure you have full reverse lookup working and if needs be use hosts files.
It looks like host name resolution may be the issue or even that the client does not know it own name?
Show us the output, run on the client, of blclntcmd -self
Check that you can ping the Master from the client and vice versa