Forum Discussion

Dockers's avatar
Dockers
Level 2
6 years ago

NBU 8.1.2 Media Server communication failure with Master Server following upgrade

we've come across a couple of challenges with our 8.1.2 upgrade.


After the master server upgrade we started on the media servers and straight away encountered issues downloading certificates required for communication between the Media and Master Server.


The media Servers are configured with a preferred network to backup our client database servers on a separate vLAN. This is where the crux of our issues currently reside:


If we disable the preferred network (rename PREFERRED_NETWORK to something else in the registry) clear to host cache communication between master/media server is established and the certificates can be uploaded. After making the certificates available for the media server we then reenable the preferred network and communication is lost again.


Running “bpclntcmd -pn” from the media server with the preferred network disabled proves connectivity however running it with the preferred network enabled doesn't provide a response.


Additionally, running “bpclntcmd -pn -verbose -debug” from the media server with preferred network enabled throws out the following errors:
13:47:37.508 [7764.9212] <2> check_vnetd_process_dup_permission: OpenProcessToken() failed: 5
13:47:37.508 [7764.9212] <2> vnet_check_windows_privileges: enabled SeDebugPrivilege privilege
13:47:37.524 [7764.9212] <8> init_local_connect_recs: [vnet_connect.c:1398] remote connections are prohibited 2 0x2
13:47:37.524 [7764.9212] <8> init_local_connect_recs: [vnet_connect.c:1398] remote connections are prohibited 1 0x1
13:47:37.524 [7764.9212] <16> connect_to_service: connect failed STATUS (18) CONNECT_FAILED
13:47:37.524 [7764.9212] <16> connect_to_service: JSON data = {"allow_large_status": [TRUNCATED] "connect failed STATUS (18) CONNECT_FAILED"}}
13:47:37.524 [7764.9212] <8> vnet_connect_to_service: [vnet_connect.c:290] connect_to_service() failed 18 0x12
13:47:37.524 [7764.9212] <2> bprd_connect: vnet_connect_to_service(MasterServer)failed: 18
13:47:37.524 [7764.9212] <16> do_request: Can't connect to host MasterServer: cannot connect on socket (25)Can't connect to host MasterServer: cannot connect on socket (25)

When running “bptestbpcd -host MediaServer -verbose -debug” from the Master Server (Preferred Network enabled) I get the following:


Host MasterServer (ip address) is not an authorized server for host MediaServer.
bptestbpcd: EXIT status = 46 server not allowed access


The preferred Network settings only contain the client names and IP Addresses of the Database clients, not the media servers or master server.


There is no preferred network configured between the master and media servers so I cannot understand why communication is lost when the preferred network settings are in place?


I suspect it’s relating to certificates but haven’t as yet found anything online similar to the issues we have.

Support have suggested speaking to our Network Team, however they do not know what the issue is. 


Does anyone have any idea’s?

  • The fact that you don't get correct answer using bpclntcmd -pn shows that you're sending reqest using incorrct interface. It's better to open bprd log on  the master and check source ip that sends the request. 

  • You may also try to run on media-server:

    # bpclntcmd -pn -verbose -debug
    

    It'll give you an idea which interface was used and what master-server  thinks about it.

    • Amol_Nair's avatar
      Amol_Nair
      Level 6
      While running the bpclntcmd -pn command from the media server you could create a folder named “bpclntcmd” under netbackup\logs. This would directly tell you the source IP used as well as the IP address of master server to which the request is sent. Then you could follow the bprd logs on the master server in order to trace back the connection on how the master responds to this request.

      Run the bpclntcmd -pn command with these 2 logs once with the preferred network entry in place and once without it and you could compare the logs to determine the difference in the connections or what may seem to cause an issue
      • Dockers's avatar
        Dockers
        Level 2

        Thanks all, 

        I'll test and respond on how it goes.