Forum Discussion

BenchPr3ss's avatar
BenchPr3ss
Level 3
11 years ago

NetBackup 7.5.0.6 - Status 58 - Windows Server 2012

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

  • 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

  • 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

7 Replies

  • 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

  • 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

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

     

  • "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.
  • Only port 1556 (pbx) needs to be opened in both directions between server (s) and client. See the TN in my previous post.
  • All - thank you for your suggestions and support.  Backups are successful after firewall changes.