Resolving network communication problems with UNIX clients
The following procedure is for resolving NetBackup communications problems, such as those associated with NetBackup status codes 25, 54, 57, and 58. This procedure consists of two variations: one for UNIX clients and another for Windows clients.
Note:
In all cases, ensure that your network configuration works correctly outside of NetBackup before trying to resolve NetBackup problems.
For UNIX clients, perform the following steps. Before you start this procedure, add the VERBOSE=5 option to the /usr/openv/netbackup/bp.conf file.
Table: Steps for resolving network communication problems with UNIX clients
Step | Action | Description |
|---|---|---|
Step 1 | Create debug log directories. | During communication retries, the debug logs provide detailed debug information, which can help you analyze the problem. Create the following directories:
Use the bprd log directory to debug client to master server communication, not client to media server communication problems. |
Step 2 | Test a new configuration or modified configuration. | If this configuration is a new or a modified configuration, do the following:
|
Step 3 | Verify name resolution. | To verify name resolution, run the following command on the master server and the media servers: # bpclntcmd -hn client name If the results are unexpected, review the configuration of these name resolution services: Also run the following on the client to check forward and reverse name lookup of the master server and media server that perform the backup: # bpclntcmd -hn server name # bpclntcmd -ip IP address of server |
Step 4 | Verify network connectivity. | Verify network connectivity between client and server by pinging the client from the server. # ping clientname Where clientname is the name of the client as configured in the NetBackup policy configuration. For example, to ping the policy client that is named # ping ant
ant.nul.nul.com: 64 byte packets
64 bytes from 199.199.199.24: icmp_seq=0. time=1. ms
----ant.nul.nul.com PING Statistics----
2 packets transmitted, 2 packets received, 0% packet
loss round-trip (ms) min/avg/max = 1/1/1
A successful ping verifies connectivity between the server and client. If the ping fails and ICMP is not blocked between the hosts, resolve the network problem outside of NetBackup before you proceed. Some forms of the ping command let you ping the bpcd port on the client as in the following command: # ping ant 1556
Ping 1556 ( |
Step 5 | Ensure that the client listens on the correct port for the bpcd connections. | On the client, run one of the following commands (depending on platform and operating system): netstat -a | grep bpcd netstat -a | grep 13782 rpcinfo -p | grep 13782 Repeat for 1556 ( # netstat -a | egrep '1556|PBX|13724|vnetd|13782|bpcd' | grep LISTEN *.1556 *.* 0 0 49152 0 LISTEN *.13724 *.* 0 0 49152 0 LISTEN *.13782 *.* 0 0 49152 0 LISTEN LISTEN indicates that the client listens for connections on the port. If the NetBackup processes are running correctly, the expected output is as follows: # ps -ef | egrep 'pbx_exchange|vnetd|bpcd' | grep -v grep root 306 1 0 Jul 18 ? 13:52 /opt/VRTSpbx/bin/pbx_exchange root 10274 1 0 Sep 13 ? 0:11 /usr/openv/netbackup/bin/vnetd -standalone root 10277 1 0 Sep 13 ? 0:45 /usr/openv/netbackup/bin/bpcd -standalone Repeat the procedure on the master server(s) and media server(s), to test communication to the client. |
Step 6 | Connect to the client through telnet. | On the client, telnet to 1556 ( telnet clientname 1556 telnet clientname 13724 Where clientname is the name of the client as configured in the NetBackup policy configuration. For example, # telnet ant vnetd Trying 199.999.999.24 ... Connected to ant.nul.nul.com. Escape character is '^]'. In this example, telnet can establish a connection to the client Repeat the procedure on the master server(s) and media server(s), to test communication to the client. |
Step 7 | Identify the outbound socket on the server host. | On the master server(s) and media server(s): Use the following command to identify the outbound socket that is used for the telnet command from step 6. Specify the appropriate IP address to which the server resolves the policy client. Note the source IP (10.82.105.11), the source port (45856) and the destination port (1556). # netstat -na | grep '<client_IP_address>' | egrep '1556|13724' 10.82.105.11.45856 10.82.104.99.1556 49152 0 49152 0 ESTABLISHED If telnet is still connected and a socket is not displayed: Remove the port number filtering and observe the port number to which the site has mapped the service name. Check that process listens on the port number in step 5. $ netstat -na | grep '<client_IP_address>' 10.82.105.11.45856 10.82.104.99.1234 49152 0 49152 0 ESTABLISHED If the socket is in a SYN_SENT state instead of an ESTABLISHED state, the server host is trying to make the connection. However, a firewall blocks the outbound TCP SYN from reaching the client host or blocks the return bound TCP SYN+ACK from reaching the server host. |
Step 8 | Confirm that the telnet connection reaches this client host. | On the master server(s) and media server(s), to confirm that the telnet connection reaches this client host, run the following command: $ netstat -na | grep '<source_port>' 10.82.104.99.1556 10.82.105.11.45856 49152 0 49152 0 ESTABLISHED One of the following conditions occurs:
|
Step 9 | Verify communication between the client and the master server. | To verify client to master server communications, use the bpclntcmd utility. When -pn and -sv run on a NetBackup client, they initiate inquiries to the NetBackup master server (as configured in the client bp.conf file). The master server then returns information to the requesting client. More information is available about bpclntcmd. See About the bpclntcmd utility. The PBX, vnetd, and bprd debug logs should provide details on the nature of any remaining failure. |