How to use and troubleshoot bpclntcmd command

Article: 100017942
Last Published: 2013-10-08
Ratings: 7 0
Product(s): NetBackup & Alta Data Protection

Description

The bpclntcmd command performs name resolution using the same operating system APIs as the NetBackup software.  The -pn , -self , -hn , and -ip options are useful in troubleshooting network connectivity issues associated with name resolution.  
 
In Netbackup, the OS gethostbyname and gethostbyaddr API calls are no longer used for forward and reverse resolution, respectively.  Instead getaddrinfo is used because it is IPv4 and IPv6 compliant.  Also note that, in NetBackup, a host cache is used which will retain the getaddrinfo return information for up to an hour.  If making changes to DNS or other name resolution services, be sure the clear the host cache to discard the stale information.  Persistent NetBackup processes will detect the host cache reset and pickup the changes within 10 seconds.
 
These are some recommended troubleshooting steps when errors are returned by the command.  
 
UNIX/Linux:  /usr/openv/netbackup/bin/bpclntcmd
Windows:    <install>\Veritas\NetBackup\bin\bpclntcmd
 
bpclntcmd -pn
When the -pn option is run on a NetBackup host, it initiates an inquiry to the NetBackup master server, and the master server returns information about the requesting client to the requesting host.  The information returned is, in effect, how the master server "identifies" the requesting host.  The client contacts the first server listed in its servers list, found in the bp.conf file on UNIX/Linux clients (the SERVER= lines) and in the Backup, Archive, and Restore GUI, under File - Specify NetBackup Machines and Policy Type on a Windows client.  

Bpclntcmd identifies the server replying to the request (the "expecting response from" line), and then it displays the information returned from that server.  The following is an example of the output of the bpclntcmd -pn command:

> bpclntcmd -pn
expecting response from server master_server_01
client_01.domain.com client_01 192.168.0.30 3815


In the above example:
  • The master server is "master_server_01"
  • The connection name (peername) is "client_01.domain.com"
  • The configured client name is "client_01"
  • The source IP from which the connection originated is 192.168.0.30
  • The source port used to connect is 3815.   
The master server resolved 192.168.0.30 to "client_01.domain.com".  The FQDN was not configured as a client in any policy, but the shortname "client_01" was present. 
 
If the output showed *NULL* for the configured client name (as shown below), the client is not configured in a policy and does not show up in the image database.

> bpclntcmd -pn
expecting response from server master_server_01
client_01.domain.com *NULL* 192.168.0.30 3815

 
Review the policy configuration on the master server, and see if the peername is listed correctly in a policy.  

Because the  -pn option causes a connection to the master server, that connection is logged in the bprd debug log on the master.  The log entries will show how bprd tries to resolve the source IP to a hostname (peername).  This command can be very useful to troubleshoot a client host that has multiple network interfaces. 
If this command is failing, check the bprd log on the master to see what IP address is being resolved.  Additionally, check the following:
  • Check the permission on the services file (found in C:\WINDOWS\system32\drivers\etc on a Windows machine, and the /etc directory on a UNIX/Linux machine). If the bpclntcmd command is being run by a non-root/administrative user, ensure they have permission to read the services file.
  • Ensure the entry in the services file for the bprd service is correct - if this is missing/commented out or the port number is incorrect, then this problem can occur.   (i.e:  bprd   13720/tcp    bprd) 

Note: In Netbackup, services file entries are no longer required as Veritas has registered them with IANA.  However, an errant entry can cause an unexpected port to be used.     

  • For a UNIX/Linux machine, check the /etc/nsswitch.conf, /etc/resolv.conf, and/or nscd configuration files.  These files are used to determine how names and services are resolved. Ensure the permissions here are correct as well.
  • If NIS is being used, the services file on the NIS Master should be checked and pushed out to the NIS clients.
  • Check the SERVER entries for discrepancies in the bp.conf file or in the servers list (on a Windows client).  For example, the first server entry is misspelled, incomplete, or has two dots: master..domain.com.  
  • If the source IP address is not correct.  Check the client host configuration.  Is the first server entry for the correct network interface on the master server, or are there configuration settings that may cause source IP address spoofing, i.e. 

   REQUIRED_INTERFACE <local_interface>
   PREFERRED_NETWORK <local_interface> PROHIBITED
   PREFERRED_NETWORK <master_subnet> MATCH <local_interface>
 
Alternatively, the network routing table on the client host may not be correct; check with netstat -n -r.

Here is a sample bprd debug log.  Notice the initial peername identification is via hostname resolution.  Then the requesting host is compared to the servers list, and finally bpdbm is contacted to get the configured client name for the peername.

08:33:17.290 [1843254] <2> logconnections: BPRD ACCEPT FROM 192.168.0.30 3815 TO 192.168.0.1.13720
08:33:17.292 [1843254] <2> connected_peer: Connection from host client_01.domain.com, 192.168.0.30, on non-reserved port 3815
08:33:17.297 [1843254] <2> process_request: no authentication required
08:33:17.297 [1843254] <2> nb_is_valid_master_server: checking if client_01.domain.com is a valid server
08:33:17.298 [1843254] <2> nb_is_valid_master_server: *** host client_01.domain.com is NOT a valid server
08:33:17.298 [1843254] <2> nb_is_valid_master_server:     h_name is client_01.domain.com
08:33:17.298 [1843254] <2> nb_is_valid_master_server:     ip address is 192.168.0.30 (0x276e520a)
08:33:17.298 [1843254] <2> db_valid_master_server: client_01.domain.com is not a valid server
08:33:17.438 [1843254] <2> process_request: command C_CLIENT_ID (45) received
08:33:17.438 [1843254] <2> process_request: client_01.domain.com is 6.0MP_4
08:33:17.438 [1843254] <2> get_ccname: determine configured name for client_01.domain.com
08:33:17.441 [1843254] <2> getsockconnected: host=master_server_01.com service=bpdbm address=192.168.0.1 protocol=tcp non-reserved port=13721
08:33:17.442 [1843254] <2> bind_on_port_addr: bound to port 40151
08:33:17.442 [1843254] <2> logconnections: BPDBM CONNECT FROM 192.168.0.1.40151 TO 192.168.0.1.13721
08:33:17.444 [1843254] <2> check_authentication: no authentication required
08:33:19.042 [1843254] <2> get_ccname: configured name is: client_01


 
bpclntcmd -self
The -self option reports information about the client without making any connection to the master server.  This is, in effect, how the client "identifies" itself.  

Sample output:
C:\Program Files\VERITAS\NetBackup\bin>bpclntcmd -self
gethostname() returned: client_01
host client_01: client_01.domain.com at 192.168.0.30 (0x276e520a)
checkhname: aliases:

 
In the above example, the NetBackup client name is client_01, the fully qualified domain name is client_01.domain.com, and client_01 resolves to IP address 192.168.0.30.  This information can be helpful when used in conjunction with the -pn output.  For example, if the -pn output indicated the NetBackup client name was client_01 with an IP address of 192.168.0.30 and the -self option returned client_01 with an IP address of 192.168.0.31.  This may indicate incorrect information within the name resolution configuration, if the client host is not multi-homed, and the client and master server hosts are resolving the client's name to two different IP addresses.  
 
 
bpclntcmd -ip <ip_address>
The -ip option requests  bpclntcmd to resolve the specified IP address to a hostname.  It attempts to obtain the host name associated with the IP address as defined in the host's Domain Name Service (DNS), local hosts file, or Windows Internet Naming Service (WINS) entries.  Like the -self option, no connection is made to the master server.  
 
Sample output:
C:\Program Files\VERITAS\NetBackup\bin>bpclntcmd -ip 192.168.0.30
checkhaddr: host   : client_01: client_01.domain.com at 192.168.0.30
(0x276e520a)
checkhaddr: aliases:

 
 
bpclntcmd -hn <host_name>
The -hn option requests  bpclntcmd to resolve the specified host name to an IP address.  It attempts to obtain the IP address associated with the host name as defined in the host's Domain Name Service (DNS), local hosts file, or Windows Internet Naming Service (WINS) entries.  Like the -self option, no connection is made to the master server.  
 
Sample output:
C:\Program Files\VERITAS\NetBackup\bin>bpclntcmd -hn client_01
host client_01: client_01.domain.com at 192.168.0.30 (0x276e520a)
checkhname: aliases:


On the NetBackup master server, use bpclntcmd -hn to confirm the operating system can resolve the host name of the NetBackup client (as configured in the client list for the policy) to an IP address. The IP address is then used to search the local network routing tables make connections outbound from the NetBackup server.

Was this content helpful?