cancel
Showing results for 
Search instead for 
Did you mean: 
AAlmroth
Level 6
Partner Accredited
Have you ever been frustrated over network communication issues when deploying NetBackup in heavily segmented or protected network environments? If you say yes, then please read on, perhaps there is some information below that could make your life easier. And, if you say no; wow, lucky bastard! :)

NetBackup depends on the network in order to be able to send control traffic as well as the backup/restore traffic over the LAN/SAN. In secured environments it is generally very complicated and time-consuming to find where the problem lies. Many companies use firewalls or access-lists in the routers/switches to control from, to, and how, and if the ports required for NetBackup are blocked, then you will have a problem.
Symantec has released a document on ports used, but reading it is somewhat difficult, so I thought I should put it all in table form, and in a format that could be used to send to the security administrator or used in the change request system.

Primarily, all communication use TCP at protocol, the exception being Granular Restore Technology (GRT) restores, where the UDP protocol is used for the NFS traffic. This is not covered in this article.
So we will start with the default ports as most environments do not change the ports, then followed by each tier.

Default ports

Service
Port Description
VNETD 13724  NetBackup Network daemon.
VERITAS_PBX 1556  VxPBX Symantec Private Branch Exchange Service
VRTS-AT-PORT 2821 VxAT Symantec authentication service
VRTS-AUTH-PORT 4032 VxAZ Symantec Authorization Service
BPCD 13782 NetBackup Connection Daemon
PDDE_CTRL 10102 PureDisk Controller
PDDE_CR 10082 PureDisk Content Router
BPRD 13720 NetBackup Request Daemon
 
These eight ports are the primary ports used in almost all NetBackup environments using at least version 6.0. Support for 5.x clients and servers is very limited in NetBackup 7, as the main application communication protocols has changed as of version 6.0.

Master server

The master server needs to be able to communicate will all tiers, such as the media servers, EMM server, VxSS server, clients, as well as servers where the Java or Administration console is running. Following minimum ports are required;

Source
Destination Service Port
Master Media VNETD 13724
Master Media VERITAS_PBX 1556
Master EMM VERITAS_PBX 1556
Master Client VNETD 13724
Master Admin Console VERITAS_PBX 1556
Master Java Server VERITAS_PBX 1556
Master Netware VNETD 13724
Master Netware BPCD 13782
Master VxSS server VRTS-AT-PORT 2821
Master VxSS server VRTS-AUTH-PORT 4032

 
Media server

The media servers must be able to communicate with the master server and EMM server and obviously the clients. In secure environments the VxSS server is also required. In backup and restore operations it is primarily the media server that communicates with the clients.

Source
Destination Service Port
Media Master VNETD 13724
Media Media VNETD 13724
Media Master VERITAS_PBX 1556
Media EMM VERITAS_PBX 1556
Media Client VNETD 13724
Media Netware VNETD 13724
Media Netware BPCD 13782
Media VxSS server VRTS-AT-PORT 2821
Media VxSS server VRTS-AUTH-PORT 4032
Media Media PDDE_CTRL 10102
Media Media PDDE_CR 10082
Media Client PDDE_CTRL 10102
Media Client PDDE_CR 10082

 
EMM server

The Enterprise Media Manager server (EMM) is the central database for media information as well as many new features in 6.x and 7.0. The EMM server is in almost all cases installed on the master server, but for huge environments or in shared media environments, the EMM server may be a separate server.

Source
Destination Service Port
EMM Master VERITAS_PBX 1556
EMM Media VERITAS_PBX 1556
EMM Admin Console VERITAS_PBX 1556
EMM Java Server VERITAS_PBX 1556

 
Client

The client requires access to the master server for scanning of backups as well as initiating user or archive operations. The client must also be able to connect to the media servers when connect-back backup types such as Oracle and SQL backup is used. When using client side de-duplication, the client must also be able to communicate with the PDDE media servers or all servers in a PureDisk Storage Pool, including the Storage Pool Authority (SPA), and Content Routers (CR). In secure enviroments, the clients must also be able to authenticate against the VxSS server.

Source
Destination Service Port
Client Master VNETD 13724
Client Media VNETD 13724
Client Media PDDE_CTRL 10102
Client Media PDDE_CR 10082
Client VxSS server VRTS-AT-PORT 2821

 
Novell NetWare

If there are any NetWare servers being backed up, following ports must be open;

Source
Destination Service Port
Netware Master BPRD 13720
Netware Master VNETD 13724
Netware Media VNETD 13724

 
Administration Console

If you are using the Windows Administration console which is native Windows application, you first have to add the DNS name of the workstation or server to the list of "trusted" servers in the master server. After that, following ports must be open;                

Source
Destination Service Port
Admin Console Master VNETD 13724
Admin Console Master VERITAS_PBX 1556
Admin Console Media VNETD 13724
Admin Console EMM VERITAS_PBX 1556
Admin Console VxSS server VRTS-AT-PORT 2821

 
Java Server

The Java server is the process running on the master server when you connect using the Java Administration Console. It needs to be able to communicate with all the core components.

Source
Destination Service Port
Java Server Master VNETD 13724
Java Server Master VERITAS_PBX 1556
Java Server Media VNETD 13724
Java Server EMM VERITAS_PBX 1556
Java Server VxSS server VRTS-AT-PORT 2821

 
Java Console                               

Many use the Java Console instead of the Windows native Administration Console, and as it uses the Java Server for further communication, it only requires below ports;

Source
Destination Service Port
Java Console Master VNETD 13724
Java Console Master VERITAS_PBX 1556
Java Console Java Server VNETD 13724

 
Summary

It is my belief that having the core ports used by NetBackup in tabular form does make it easier to communicate the requirements to the network team, so they can carry out the necessary changes to the network.
Comments
AAlmroth
Level 6
Partner Accredited
I noticed I forgot to list port 1556 for client to media server communication when using client-side de-duplication. This port is required for this feature.
As always, I recommended opening the port both ways...

/A

westy42
Not applicable
Partner
AAlmroth's picture
AAlmroth
Level 6
Partner Accredited

Good point! But are these the only ports actually required? I mean in old days NFS was pretty heavy on random ports for RPC traffic. Or does the NBU GRT only use these ports and no real RPC custom traffic?

 

/A

TomerG
Level 6
Partner Employee Accredited Certified

From what I've seen of NBU 7.0.1 and later, clients are starting to use (or attempt to use) the PBX port (1556), and specifically in the case of client-side deduplication, it may be required. I can't verify this through testing, so anyone feel free to confirm or chime in as necessary.

AAlmroth
Level 6
Partner Accredited

Hi Tomer,

 

I noticed this as well, and it is in the log for updating the article. For client-side de-dup I have noticed following ports needs to be open to the media/master servers;

1556/TCP

10082/TCP

10102/TCP

13724/TCP

 

 

/A

3viertelheinz
Level 2

First thx for that list. Great. One question: When do i need that media server to media server comunication? From dmz we don't want to open the fire wall to other media server.

 

Heinz

AAlmroth
Level 6
Partner Accredited

Hi,

 

Yes, it seems that SYMC changed the default behaviour lately. So, the process try to communicate using PBX, and failing that it reverts to VNETD or BPCD.

This technote explains; http://www.symantec.com/business/support/index?page=content&id=TECH136791

 

/A

AAlmroth
Level 6
Partner Accredited

Hi,

 

Media server to media server is required when duplicating a backup image from one server to another.

In 7.x, media server communication is also required when using a load-balancing server for a PureDisk disk pool.

So, in theory, if you won't be doing any of the above, you don't need to open the firewall between the two media servers, but communication between the master and the DMZ media server is still required both ways.

 

/A

mikent
Level 3

Hi,

Also the following:

443 (tcp) https (to communicate with Vcenter or appliances)

53 (tcp/udp) dns (to commuinicate with DNS)

 

Br,

 

./Nathan

HoldTheLine
Level 4

Has anyone ever seen an environment where the Master is not allowed to communicate with the clients because of network seperation/firewalls, but the media servers can communicate with the clients?  I am not convinced that would even work since first line of troubleshooting is always "Can the master communicate with the client"

 

We are looking at sort of a strange DR situation and network folk are convinced this will work but those of us working with NBU day to day....not so much.

nathanmike
Level 4
Partner

@HoldTheLine,

I will try to understand your netbackup infrastructure and issue you are facing:

1. You master server is on a different segment than your media server (eg. 192.168.2.0/24)

2. your media server is on a different segment than youe master server (eg. 192.168.1.0/24)

3. You need to make sure that lookup/reverse ip is working correctly depending if you relay on host file or DNS server

4. You need to make sure that tcp port 1556 is open in your firewall in bi-directional. If not, it will never work.

5. You need to make sure that your Switch/Router device(s) is(are) configured correctly, especially if you are using VLANID

6. Make sure your routing table on master or media server is configured correctly

Once you can confirm all of this, you can perform the following test on master/media server:

bpclntcmd -self

bpclntcmd -hn <target_fqns> (eg. bpclntcmd -hn master.example.com)

bpclntcmd -ip <target_ip) (eg. bpclntcmd -ip 192.168.2.22)

bptestbpcd -client <client_name> -verbose -debug (eg. bptestbpcd -client master.example.com -verbose -debug)

telnet <target_fqns> <port> (eg. telnet master.example.com 1556)

traceroute <target_fqns> (eg. traceroute master.example.com )

netstat -rn

for windows:

tracert <target_fqns> (eg. tracert master.example.com )

route print

./nathan

HoldTheLine
Level 4

@ ./nathan -

 

Sort of - the Master and Media servers will all be able to communicate with each other.  But the clients may or may not be visible to the master - this is still unknown to me.  Apparently years ago Symantec told them that as long as the media servers can communicate with the clients then the Master does not need to - having never seen a network so locked down I have no idea if this is true or not.  Looking at the flow chart here:

https://www-secure.symantec.com/connect/downloads/netbackup-7x-process-flow

I *think* this will work, because I don't see any part of that flow that requires a client to communicate directly with the master ...obviously it's not ideal because I will have to remember all the time that a 58 or 25 from the master to the client may not always mean the client is down or services have stopped - it may just mean that they have blocked access to it and I will have to check from a media server instead.  Ack.

Version history
Last update:
‎08-02-2010 08:40 AM
Updated by: