Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrades.
Please accept our apologies in advance for any inconvenience this might cause.

7.0.1 Clients making calls on 1556 (PBX)

Created: 23 Aug 2010 • Updated: 01 Oct 2010 | 13 comments
This issue has been solved. See solution.

I've got a few machines, all recently upgraded to 7.0.1, that are making calls back to the Master Server on 1556, the PBX port.  The packets are being denied as my network admins have not allowed the ports, yet the bakcups are not failing.  I'm trying to understand why these machines would be making calls back on 1556 as none of them are SAN Clients or Media server, and I was under the impression that regular clients did not need to use PBX. 

The only commonality I have is that all the machines in questions were running MS SQL policies at the time the drops showed up on the router.

Thoughts?

Comments 13 CommentsJump to latest comment

Marianne's picture

I have just downloaded 7.0.1 Release Notes to see if there's something new about PBX on Clients.
All I could find was this Etrack that is fixed in 7.0.1:
Etrack Incident: 1983685
■ Contained in: NBLU_7.0.1.UNIX NBLU_7.0.1.WIN NB_JAV_7.0.1
NB_JAV_7.0.1.winnt.IA64 NB_JAV_7.0.1.winnt.x64 NB_JAV_7.0.1.winnt.x86
■ Description:
The NetBackup-Java Administration Console connects to the master or the media server. PBX makes the connection on port 1556 to vnetd instead of it being a direct connection to vnetd on port 13724.

The only conclusion (IMHO) is that this TN is still valid:
http://seer.entsupport.symantec.com/docs/306419.htm

In NetBackup 6.5, Private Branch Exchange (PBX) is included in the initial installation for all Windows clients.

PBX only needs to run if the Windows client is also a SAN client, or if the client is also a NOM server or VBR server.  Otherwise, the Service can be disabled.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

wr's picture

we have always enabled both ports (vnetd & pbx)

Will Restore -- where there is a Will there is a way

Nefarious's picture


Thanks for the info, but can you really disable the service?  At quick glance it looked like it was a dependeny of the NetBackup Client and NetBackup Legacy Network service. 

At the moment the requests are being dropped, so even if I did need it, I'd have to add allowanced into the fire wall.  Are they any risks of allowing the from all clients to the Master / Media server? 

Andy Welburn's picture

issue.

Only see NetBackup SAN Client Fibre Transport Service as a dependency of this service (but that's at 6.5.x) & not dependent upon any other.

Nefarious's picture

With 6.5.x clients or 7.x clients?  

I'm eyeballing a client running 7.0.  It actually errors out on start if PBX is not running :(

Andy Welburn's picture

If you're now seeing dependencies in your 7.x client services for pbx then maybe something's changed & isn't documented?

Nefarious's picture

Anyone have any more thoughts on this?  I guess I could open a case on this...

Andy Welburn's picture

NetBackup 7.0.1 and above attempts to use the PBX port for connections before falling back to vnetd, daemon, and legacy ports.
http://seer.entsupport.symantec.com/docs/357820.htm

Overview:

After applying the NB_7.0.1 release update, the default destination port changes for most legacy connections.  The initial attempt to connect is made to the PBX port.  If a firewall or other issue prevents the connection, it reverts to the legacy connect option selection, which makes it reverse compatible with NetBackup versions 7.0, 6.5, and 6.0.

Note: The NB_7.0.1 release update also contains a new version of PBX.

Troubleshooting:

The bptestbpcd command (servers) and bptestnetconn (servers and clients) and NetBackup debug logs show when port 1556 is used in place of 13724 or other daemon ports.  For example:

# admincmd/bptestbpcd
1 1 1
10.80.74.69:51164 -> 10.80.74.69:1556
10.80.74.69:51165 -> 10.80.74.69:1556

If a firewall does not permit connections to vnetd and daemon ports, the PBX port must be used.  You should then enable logging for PBX (product id 50936) OID 103 and NetBackup (product id 51216) OID 137.

SOLUTION
Nefarious's picture

My response from support was:

"Since your backups are running successfully, there doesn't need to be an allowance for port 1556 on the firewall for the Client to Master/Media servers.  The only exception would be if you are using SAN / Fibre Transport clients, as those would need 1556 to communicate to the Master/Media servers.  In a future NetBackup release somewhere down the road, I have heard that port 1556 will be used for communications between client and Master/Media, but currently that is not in place."

CRZ's picture

...one day PBX will be exclusive, so don't say they didn't warn you (in the most obscure manner possible)!  ;-)

wr's picture

I guess we'll stick with both ports (vnetd & pbx)
since our firewall guys are so hard to retrain cheeky

Will Restore -- where there is a Will there is a way