cancel
Showing results for 
Search instead for 
Did you mean: 

Port number 1556 for netbackup client is not listening

YC
Level 4

Hi,

We have a RedHat Linux version 7.2 running Netbackup client 7.6.1. The RHEL is running as wm in vmware.

Correct me that port number 1556, 13724 and 13782 shall be listening? Please refer below, port number 1556 is not listening. How to rectify the problem?

$ netstat -a | egrep 'bpcd|vnetd'
tcp        0      0 0.0.0.0:bpcd            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:vnetd           0.0.0.0:*               LISTEN     
unix  2      [ ACC ]     STREAM     LISTENING     18061    /usr/openv/var/vnetd/terminate
_vnetd.uds
unix  2      [ ACC ]     STREAM     LISTENING     18112    /usr/openv/var/vnetd/terminate
_bpcd.uds
unix  2      [ ACC ]     STREAM     LISTENING     18121    /usr/openv/var/vnetd/bpcd.uds

$ netstat -an | grep 1556  <<< nothing in return

$ netstat -an | grep 13724
tcp        0      0 0.0.0.0:13724           0.0.0.0:*               LISTEN     

$ netstat -an | grep 13782
tcp        0      0 0.0.0.0:13782           0.0.0.0:*               LISTEN  

$ ps -ef | egrep 'vnetd|bpcd'
root      1638     1  0 Mar23 ?        00:00:00 /usr/openv/netbackup/bin/vnetd -standalone
root      1675     1  0 Mar23 ?        00:00:00 /usr/openv/netbackup/bin/bpcd -standalone

Thanks in advance

1 ACCEPTED SOLUTION

Accepted Solutions

sdo
Moderator
Moderator
Partner    VIP    Certified

This should help:

# save existing ruleset...
ls -lash /etc/sysconfig/iptables*
cp -pv   /etc/sysconfig/iptables{,.$(date "+%F_%T")}
​ls -lash /etc/sysconfig/iptables*

# add NetBackup ports...
iptables -N NBU-IN
iptables -A NBU-IN -p tcp -m multiport -s 10.0.1.0/24,192.168.1.0/24 --dports 1556,13724 -j ACCEPT
iptables -I INPUT -j NBU-IN

# save the tables...
ls -lash /etc/sysconfig/iptables*
service iptables save
ls -lash /etc/sysconfig/iptables*

.

In the example above "-m multiport" is used because we are adding a rule for two ports "--dports 1556,13724".

In the example above, two different /24 subnets are being allowed to reach the client.  You may only need one for your configuration.

.

N.B:  Some advice.  Read the man page for iptables, as there is a difference between '-A' adding an entry at the tail of iptables, and '-I' inserting an entry at the head of iptables.   i.e. inserting to the top/head means the new rules will be evaluated first, whereas adding (appending) to the the list means they will be evaluated last.   And so, if you were to 'add/append' your new rule after an existing generic drop rule, then your new rule will never be evaluated... and so we avoid this problem by 'inserting' our rule/set for NetBackup Client at the top, so that it is evaluated before any other rules.

One could argue that this is ok *IF* the volume of backup traffic outweighs any other application traffic.  A "purist" admin would check the volumes of traffic for all applications on a server, and ensure that the "order" of rules matches the mostly likely highest frame rates, i.e. the busiest and most chatty and most volumeric applications - remember MB/s is not the indicator for FW rule order, it is ethernet frames/sec over a period of "run window" or period of "application intensity" which should dictate your iptables firewall rule order.

View solution in original post

13 REPLIES 13

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Can you also check for pbx in 'ps -ef' output? Are you experiencing connectivity or backup issues?

YC
Level 4

Nothing in return for "ps -ef | grep -v grep | grep pbx"

Backup admin console is not able to connect to the client. The status of the backup shows successful but from the restoration console, the content failed to open the record. 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
What happens when you start pbx? # /opt/VRTSpbx/bin/vxpbx_exchanged start

YC
Level 4

Started pbx:

# /opt/VRTSpbx/bin/vxpbx_exchanged start
Started Symantec Private Branch Exchange
[root@hrrproxyprd2 ~]# ps -ef | grep pbx
root     18266     1  0 13:42 ?        00:00:00 /opt/VRTSpbx/bin/pbx_exchange
root     18268 18221  0 13:42 pts/0    00:00:00 grep --color=auto pbx
[root@hrrproxyprd2 ~]# ps -ef | grep -v grep | grep pbx
root     18266     1  0 13:42 ?        00:00:00 /opt/VRTSpbx/bin/pbx_exchange
[root@hrrproxyprd2 ~]# netstat -an | grep 1556
tcp        0      0 0.0.0.0:1556            0.0.0.0:*               LISTEN     
tcp6       0      0 :::1556                 :::*                    LISTEN    

 

But the backup server is not able to connect to the client. 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Check that OS firewall iptables is stopped and disabled. Create bpcd log folder on the client and try to connect again. If it still fails check bpcd log and post contents.

mph999
Level 6
Employee Accredited

You can also try and telnet to 1556

root@server1 kms $ telnet womble 1556
Trying 10.12.235.41...
Connected to womble.
Escape character is '^]'.
 

 

YC
Level 4

I stopped the firewall in the linux client and the backup server is able to connect to the client now.

Could anyone advise how to configure the firewall in linux for netbackup client?

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

I am not aware of NBU documentation specifically for Linux iptables.

You will probably need to look this up in Linux documentation.

NBU documentation for port connectivity says that port 1556 must be open in both directions.

mnolan
Level 6
Employee Accredited Certified

This is because PBX is not running because RHEL 7.2 switched to systemd and things were mucked up a bit.

Not sure why you cannot connect after manually starting PBX.

The NetBackup services do not automatically start after installing NetBackup on Linux with systemd.

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
iptables was preventing connection...

sdo
Moderator
Moderator
Partner    VIP    Certified

BTW - re those iptables instructions above, hopefully it should be clear that those commands create (-A add) a rule to a new rule set (named NBU-IN) for "incoming" traffic, and then (-I insert) this ruleset in to the top/head of the existing rulesets.  Usually this is all that is required on a Linux server.  BUT, if your server admins have previously hardened the server with additional "outgoing" filters/rules too, then you will need an additional (kind of reverse) rule/set for outgoing NetBackup Client traffic... but I'm sure you can work it out.  :)

sdo
Moderator
Moderator
Partner    VIP    Certified

This should help:

# save existing ruleset...
ls -lash /etc/sysconfig/iptables*
cp -pv   /etc/sysconfig/iptables{,.$(date "+%F_%T")}
​ls -lash /etc/sysconfig/iptables*

# add NetBackup ports...
iptables -N NBU-IN
iptables -A NBU-IN -p tcp -m multiport -s 10.0.1.0/24,192.168.1.0/24 --dports 1556,13724 -j ACCEPT
iptables -I INPUT -j NBU-IN

# save the tables...
ls -lash /etc/sysconfig/iptables*
service iptables save
ls -lash /etc/sysconfig/iptables*

.

In the example above "-m multiport" is used because we are adding a rule for two ports "--dports 1556,13724".

In the example above, two different /24 subnets are being allowed to reach the client.  You may only need one for your configuration.

.

N.B:  Some advice.  Read the man page for iptables, as there is a difference between '-A' adding an entry at the tail of iptables, and '-I' inserting an entry at the head of iptables.   i.e. inserting to the top/head means the new rules will be evaluated first, whereas adding (appending) to the the list means they will be evaluated last.   And so, if you were to 'add/append' your new rule after an existing generic drop rule, then your new rule will never be evaluated... and so we avoid this problem by 'inserting' our rule/set for NetBackup Client at the top, so that it is evaluated before any other rules.

One could argue that this is ok *IF* the volume of backup traffic outweighs any other application traffic.  A "purist" admin would check the volumes of traffic for all applications on a server, and ensure that the "order" of rules matches the mostly likely highest frame rates, i.e. the busiest and most chatty and most volumeric applications - remember MB/s is not the indicator for FW rule order, it is ethernet frames/sec over a period of "run window" or period of "application intensity" which should dictate your iptables firewall rule order.

sdo
Moderator
Moderator
Partner    VIP    Certified

@YC - I have updated the advice/tips above, you might want to re-read, as there is always an "impact" of any change, no matter innocuous they may seem.