07-03-2014 09:48 PM
I have netbackup master server and client both running on solaris 10.
I am using the same master server as media server. I don't have media server seperately
my master and client are in two different VLANs. However, they are reachle using ping, telnet, ssh etc..
But, bptestcd and policy creation is failing
Is it not possible to create policy for client that is in different VLAN ??
Solved! Go to Solution.
07-03-2014 10:10 PM
When using ping, telnet, etc., are you using hostname or IP address?
Have you added /etc/hosts entries to master and client, followed by refreshing of host_cache?
bpclntcmd -clear_host_cache
See: When and how to clear the NetBackup host cache
http://www.symantec.com/docs/TECH136792
Have you added master server hostname as SERVER entry in client's bp.conf?
Different vlans is not a problem.
The only NBU requirements are forward and reverse name lookup in both directions and port connectivity.
NBU 7.5 will use PBX (port 1556) in both directions.
Please create bpcd log folder on the client under /usr/openv/netbackup/logs
Run bptestbpcd again:
bptestbpcd -client <client-name> -debug -verbose
Please post output of command as well client's bpcd log.
Copy the log to bpcd.txt and upload as File attachment.
PS:
You said policy creation is failing?
How exactly is policy creation failing?
What is the error message?
NBU does not check connectivity when policy is created. Unless this is snapshot policy.
07-04-2014 05:55 AM
Use the NBU ports when testing telnet:
1556 (PBX)
13724 (vnetd)
13782 (bpcd)
Using 'default' telnet port does not help.
NBU can only connect on these ports.
If you cannot telnet from master to any of these ports on the client, there is probably a firewall in the way.
Get network and OS teams to check routing tables - 7-8 hops seems excessive.
07-05-2014 02:24 AM
@somesh_p, Marianne has lead you a right dirction to troubleshoot this issue. I just supplement additional couple of points for your reference.
1. It's recommended to use hostname in NetBackup environment instead of IP address as NBU server/client name. From your post, it seems that you like to use IP address. is that right?
2. Use bpclntcmd with the following parameter to see the result of name resolution.
a) execute commands against nbu server and client, respectively.
bpclntcmd -ip <ip_address>
bpclntcmd -hn <host_name>
b)execute command against nbu master, you have done with this.
usr/openv/netbackup/bin# ./bpclntcmd -pn
expecting response from server nb_server
172.26.146.30 *NULL* 172.26.146.30 27539
*NULL*, indicates that you don't configure this client in any nbu polies.
The first column "172.26.146.30" in second line indicates that you don't have hostname associated with the IP address, do you? As it should print hostname associated with the IP.
More info regarding bpclntcmd, please refer to the following link:
http://www.symantec.com/docs/TECH50198
3. As Marianne said, make sure that the three ports are open.
thanks
07-03-2014 10:10 PM
When using ping, telnet, etc., are you using hostname or IP address?
Have you added /etc/hosts entries to master and client, followed by refreshing of host_cache?
bpclntcmd -clear_host_cache
See: When and how to clear the NetBackup host cache
http://www.symantec.com/docs/TECH136792
Have you added master server hostname as SERVER entry in client's bp.conf?
Different vlans is not a problem.
The only NBU requirements are forward and reverse name lookup in both directions and port connectivity.
NBU 7.5 will use PBX (port 1556) in both directions.
Please create bpcd log folder on the client under /usr/openv/netbackup/logs
Run bptestbpcd again:
bptestbpcd -client <client-name> -debug -verbose
Please post output of command as well client's bpcd log.
Copy the log to bpcd.txt and upload as File attachment.
PS:
You said policy creation is failing?
How exactly is policy creation failing?
What is the error message?
NBU does not check connectivity when policy is created. Unless this is snapshot policy.
07-04-2014 02:51 AM
Agree with Marianne, NBU only need Forward and reverse lookup to work properly.
try command bpclntcmd with various switches to test them or nslookup
This should solve your bptestbpcd issue.
and for policy creation NBU does not check connectivity with the client. please post the exactl error message
07-04-2014 04:45 AM
here is output of bptestbpcd. I did clear host cache. but, still facing the issue
07-04-2014 04:56 AM
Please use hostnames. Not IP addresses.
If the server and client are not on DNS, add entries to /etc/hosts.
You say that telnet is working. Which port did you try?
bptestbpcd output shows that connection attempts are failing to all of these ports:
PBX (1556)
vnetd (13724)
bpcd (13782)
11:29:57.454 [19174] <16> connect_to_service: connect failed STATUS (18) CONNECT_FAILED status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO 172.21.6.194 172.21.6.194 bpcd VIA pbx status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO 172.21.6.194 172.21.6.194 bpcd VIA vnetd status: FAILED, (44) CONNECT_TIMEOUT; system: (150) Operation now in progress; FROM 0.0.0.0 TO 172.21.6.194 172.21.6.194 bpcd
Please verify that pbx, bpcd and vnetd are running on the client with this command:
/usr/openv/netbackup/bin/bpps -x
Next, verify that port 1556 is open in both directions between server and client.
07-04-2014 05:22 AM
i tried with hostname instead of Ip. bptestbpcd is giving the same result
i used bpps -x on client, all three mentioned services are running on client
One thing, i noticed is that i did traceroute from server to client and client to server
from server to client, it is taking backup interface route and from client to server, it is using public interface route. Is that the problem ??
07-04-2014 05:28 AM
traceroute will follow the network path associated with hostnames and OS routing tables.
NBU will follow the same route.
You have not replied to port connectivity in my previous post:
You say that telnet is working. Which port did you try?
.... verify that port 1556 is open in both directions between server and client.
Have you checked that yet?
Is there a firewall between server and client?
07-04-2014 05:46 AM
Not sure if there is a firewall or not in between, I'll ask network admin
but, traceroute is taking multiple hots nearly 7-8
telnet/ssh is using their default ports. I didn't mention any specific ports while connecting
i checked 1556 on both client and server using netstat. it is being listened upon
bpclntcmd from netbackup client is giving below output
usr/openv/netbackup/bin# ./bpclntcmd -pn
expecting response from server nb_server
172.26.146.30 *NULL* 172.26.146.30 27539
There is no *NULL* in other working client in a different setup
07-04-2014 05:55 AM
Use the NBU ports when testing telnet:
1556 (PBX)
13724 (vnetd)
13782 (bpcd)
Using 'default' telnet port does not help.
NBU can only connect on these ports.
If you cannot telnet from master to any of these ports on the client, there is probably a firewall in the way.
Get network and OS teams to check routing tables - 7-8 hops seems excessive.
07-05-2014 02:24 AM
@somesh_p, Marianne has lead you a right dirction to troubleshoot this issue. I just supplement additional couple of points for your reference.
1. It's recommended to use hostname in NetBackup environment instead of IP address as NBU server/client name. From your post, it seems that you like to use IP address. is that right?
2. Use bpclntcmd with the following parameter to see the result of name resolution.
a) execute commands against nbu server and client, respectively.
bpclntcmd -ip <ip_address>
bpclntcmd -hn <host_name>
b)execute command against nbu master, you have done with this.
usr/openv/netbackup/bin# ./bpclntcmd -pn
expecting response from server nb_server
172.26.146.30 *NULL* 172.26.146.30 27539
*NULL*, indicates that you don't configure this client in any nbu polies.
The first column "172.26.146.30" in second line indicates that you don't have hostname associated with the IP address, do you? As it should print hostname associated with the IP.
More info regarding bpclntcmd, please refer to the following link:
http://www.symantec.com/docs/TECH50198
3. As Marianne said, make sure that the three ports are open.
thanks
07-25-2019 11:01 AM