cancel
Showing results for 
Search instead for 
Did you mean: 

NetBackup 7.5.0.6 - Status 58 - Windows Server 2012

BenchPr3ss
Level 3

Hi all,

Just installed NetBackup v7.5.0.6 client onto Windows Server 2012.  Backups fail with Status Code 58.

Master Server to Win 2012 client - forward / reverse lookup successful

Win 2012 client to Master Server - forward / reverse lookup successful

Job details snip below, note actual servername and ip address replaced with <servername> and <IP address>:

10/22/2013 8:04:06 PM - Info bpbrm(pid=16284) connect failed STATUS (18) CONNECT_FAILED
10/22/2013 8:04:06 PM - Info bpbrm(pid=16284) status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO <servername> <IP address> bpcd VIA pbx
10/22/2013 8:04:06 PM - Info bpbrm(pid=16284) status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO <servername> <IP address> bpcd VIA vnetd
10/22/2013 8:04:06 PM - Info bpbrm(pid=16284) status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO <servername> <IP address> bpcd
10/22/2013 8:04:06 PM - Error bpbrm(pid=16284) Cannot connect to <servername>         
10/22/2013 8:04:27 PM - end writing
can't connect to client(58)

Thought maybe it's a problem with the ports being blocked as pbx, vnetd, bpcd are referenced above.

- PBX (port 1556), VNETD (port 13724), BPCD (port 13782)

But Windows Firewall on Windows Server 2012 is turned off.

Anyone know what the problem could be?

Thanks

2 ACCEPTED SOLUTIONS

Accepted Solutions

Nate_D1
Level 6

Are these seperate networks? The FROM 0.0.0.0 and <ip address> ? Is there a hardware firewall or any special routing between the NBU server and the target server?

From NBU server are you able to do a reverse lookup of the target? You can check it both ways with something like:

On NBU server:
bpclntcmd -hn <client name>
bpclntcmd -ip <client IP>

On Client:
bpclntcmd -hn <NBU servername> 
bpclntcmd -ip <NBU IP>

 

You can try running this from the NBU server too:

bptestbpcd -client <target_hostname> -debug -verbose

View solution in original post

Marianne
Level 6
Partner    VIP    Accredited Certified

Is master server also the only media server? If separate media server, have you tested connectivity and lookup from media server as well?

Have you created bpcd log folder on the client? 

We need to see if connection attempt has reached the client.

Status 58 is normally caused by one of 2 things:

reverse lookup issue on client side (bpcd will confirm)

firewall problem (no bpcd log created is a sign, telnet to port 1556 and/or 1724 will confirm)

The fact that this is a newly installed client could also mean that server host_cache id not yet updated. We normally need to refresh host cache when new client is added or updates to DNS and/or hosts files are made.

NBU automatically refreshes host_cache once every hour, so, if this was the issue, connection should work by now.
To manually refresh host_cache:
bpclntcmd clear_host_cache

View solution in original post

7 REPLIES 7

Nate_D1
Level 6

Are these seperate networks? The FROM 0.0.0.0 and <ip address> ? Is there a hardware firewall or any special routing between the NBU server and the target server?

From NBU server are you able to do a reverse lookup of the target? You can check it both ways with something like:

On NBU server:
bpclntcmd -hn <client name>
bpclntcmd -ip <client IP>

On Client:
bpclntcmd -hn <NBU servername> 
bpclntcmd -ip <NBU IP>

 

You can try running this from the NBU server too:

bptestbpcd -client <target_hostname> -debug -verbose

Marianne
Level 6
Partner    VIP    Accredited Certified

Is master server also the only media server? If separate media server, have you tested connectivity and lookup from media server as well?

Have you created bpcd log folder on the client? 

We need to see if connection attempt has reached the client.

Status 58 is normally caused by one of 2 things:

reverse lookup issue on client side (bpcd will confirm)

firewall problem (no bpcd log created is a sign, telnet to port 1556 and/or 1724 will confirm)

The fact that this is a newly installed client could also mean that server host_cache id not yet updated. We normally need to refresh host cache when new client is added or updates to DNS and/or hosts files are made.

NBU automatically refreshes host_cache once every hour, so, if this was the issue, connection should work by now.
To manually refresh host_cache:
bpclntcmd clear_host_cache

sri_vani
Level 6
Partner

The above excellent post ll help to resolve the issue.

for 58- generally I ll rely upon bpcd log

../netbackup/logs/bpcd/log.<recent -date> on the client can show the following if a hostname resolution problem exists

vnetd is used for communications through a firewall.if vnetd failed NBU failed to backup daemon port connections(i.e bpcd,bpbrm ..)

 

Marianne
Level 6
Partner    VIP    Accredited Certified

As from NBU 7.0.1, NBU will first try 1556 (pbx). If that fails, it will try vnetd (13724), then bpcd, as can be seen in the opening post. 

See http://www.symantec.com/docs/TECH136791

BenchPr3ss
Level 3
"Firewall problem (no bpcd log created is a sign, telnet to port 1556 and/or 1724 will confirm)"
- BPCD folder was created, but no log within that folder during backup test attempts. 
- Telnet to port 1556 and 13724 timed out
 
 Is there a hardware firewall or any special routing between the NBU server and the target server?
- After investigating have determined there is a firewall which does not allow traffic on the NetBackup ports (1556, 13782, 13724, 13721).
- Working on having NetBackup port exceptions added.
 
Thank you Nate D., Marianne, Sri vani for the assistance.
 
After the firewall has been sorted and tests confirm successful backups I'll update this thread.

Marianne
Level 6
Partner    VIP    Accredited Certified
Only port 1556 (pbx) needs to be opened in both directions between server (s) and client. See the TN in my previous post.

BenchPr3ss
Level 3

All - thank you for your suggestions and support.  Backups are successful after firewall changes.