on 08-02-2010 08:40 AM
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 |
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 |
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 |
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 |
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 |
Source |
Destination | Service | Port |
Netware | Master | BPRD | 13720 |
Netware | Master | VNETD | 13724 |
Netware | Media | VNETD | 13724 |
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 |
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 |
Source |
Destination | Service | Port |
Java Console | Master | VNETD | 13724 |
Java Console | Master | VERITAS_PBX | 1556 |
Java Console | Java Server | VNETD | 13724 |
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
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.
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
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
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
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
Hi,
Also the following:
443 (tcp) https (to communicate with Vcenter or appliances)
53 (tcp/udp) dns (to commuinicate with DNS)
Br,
./Nathan
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.
@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
@ ./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.