Most network communication is initiated by the Gateway Server console to the remote agent. The Gateway Server console initiates a request to port 10128 (the Service Daemon port) on the remote node to start data collection, query the remote agent, and transfer the data back to the Perform console.

Some network communication is initiated by the remote agent to the Perform console. The remote node must be able to initiate a connection to the Perform console on port 6768 for Investigate alert assertions to update the Investigate GUI and for some UDR Collection Manager (UCM) Status Reporting functionality to work.

In the default configuration Investigate charts and drill downs require the remote node to initiate a connection to the Perform console on a dynamically allocated port in the 30000 or lower or 40000 or lower range. There is more detail on Investigate port usage below.
 

PORT 10128

The console needs to be able to initiate a connection to agent port 10128 for collection start, query and pull request.

In legacy versions and even the newest versions, during normal nightly automation through Manager the console initiates all communication to port 10128 on the remote node. The remote agent does not need to initiate a connection to the console on port 10128. This is because Manager exclusively uses the PULL type data transfer request where the console initiates the network connection to the remote agent and the data is then streamed back to the console using that established network connection.

The only time the remote agent attempts to initiate to the console on port 10128 is during a PUSH type transfer. In Perform version 7.2.00 or later this type of transfer is only done when one-off data collection requests are issued via the Collect GUI on Unix, via a one-off collection and transfer request using the Collect Data Wizard on Windows console.
 

PORT 10129

The General Manager features uses the GeneralManagerServer process on the Gateway Server Unix console or the General Manager Server service on the Gateway Server Windows console to access information related to the active Manager runs on that console. This port allows the communication between the TSCO Web console and the Gateway Server console and it is bidirectional. This also applies for ETL Servers where the VIS Parser ETL is scheduled at.

 

PORT 6768

The 'Manager Daemon' (b1mgrdmon process on Unix, part of the bgs_sdservice.exe process on Windows) listens on port 6768 for status and alert messages sent from remote agents.

The agent needs to be able to initiate a connection to console port 6768 for collection status messages.

Port 6768 is also required for the new component UDR Collection Manager (UCM) introduced in Perform 7.2.00.
 

PORT 6767

The Perform Agent listens on port 6767 on the remote node. The Perform console initiates connections to the remote agent on port 6767 to check if the Perform Agent is running, activate alerts, and initiate a request for graph or drill down data.
 

PORT 30000

Port 30000 (*) is used for Investigate graphs. This port is dynamically allocated on the managing node. The managing node determines a free port and passes this information along to the remote node. This port is necessary for graphs. On Windows Port 30000- is used for both chart and drill down requests.

On Windows, one port is allocated in this range for each remote node. On Unix, one port is allocated in this range for each console instance.
 

PORT 40000

Port 40000 (*) is used on the Unix console for Investigate drill downs. This port is dynamically allocated on the managing node. The managing node determines a free port and passes this information along to the remote node. This port is necessary for drill downs.
 

• If port numbers 40000 or 30000 are not available, then the next lower port is checked for its availability. This process continues until an unused port is found. These ports are dynamically allocated as needed.

On Unix platforms, if multiple drill downs or graphs are created, the product still only uses one port. Multiple ports will not be opened.

Optionally, you can change the some of the default ports described in this section if you prefer to use ports other than those listed previously.

1. The Investigate port range (30000- and 40000-) cannot be changed within the product.

2. The Service Daemon port can be changed on Unix via the /etc/services file on Unix (if the Service Daemon is being run through inetd or in standalone mode) or through other files depending on the Service Daemon execution method being used (such as xinted on Linux or the SMF facility on Solaris 10). On Windows the Service Daemon port can be changed via the PATROL - Perform Agent Control Panel.

3. The Perform Agent and Manager Daemon port can be changed using the bgs_test_agent and bgs_test_monitor environment variables. On the Unix console these are automatically applied via the $BEST1_HOME/bgs/scripts/definePorts file).

IMPORTANT NOTE:

TSCO 11.0 and later use Web Investigate functionality where all the Investigate data collection requests will be registered using "Firewall mode" so the dynamic ports will no longer be used. In resume we no longer require the ports 30000 and 40000.
 

Ports 111, 135, 139 and 445 from the proxy host to the agentless computer.

Open RPC ports for DCOM from the proxy host to the agentless computer. This requires the customer to either allow a large range of ports as defined by the OS (range is 1024 - 65536) or they can limit the range by modifying the registry keys and rebooting the node. *** This has to be done on the agentless node. More information on how to open these OS ports can be found in the following Microsoft KB article http://support.microsoft.com/kb/250367. The example in the Microsoft article restricted the range of ports from 5000 to 5020. The disadvantage to this is if you make the range of ports to low you could run out of ports available.
 

All BMC Performance Assurance network communication between the remote agents and the console is based upon the TCP protocol. The Perform agent does not use UDP during normal operations. The only time that the Perform agent might use UDP is when an Investigate alert with an SNMP trap action has asserted (as the SNMP trap message would use UDP). An SNMP trap UDP call would use port 162. Resolution 180357 
 

Q: Does BMC Performance Assurance use HTTP, FTP, SNMP, or any other defined TCP type protocol for agent to console communication?

All communication done by the Perform product is done via TCP/IP using proprietary communication protocols. We don't use HTTP, SNMP, FTP, or any other named protocol as part of our network communication. There are some places where you can configure the product to externally run the 'ftp' command (such as the 'PC Transfer' option in Manager which is used to FTP a Manager created Visualizer file to another PC) but all the network communication done via the Perform ports is based upon our own proprietary network communication code.
 

Q: Does the remote agent ever need to initiate a network connection back to the console in the Gateway Server console?

The answer to this depends on the version of the software you are running, what features you are using, and what configuration you have chosen.
 

• In Perform version 7.1.xx and earlier the console would attempt to transfer the data using a 'PUSH' request. That is where the console would contact the remote node and then ask it to initiate a network connection back to the Service Daemon (10128) on the console. In Perform version 7.2.00 the console now only uses a 'PULL' type request which only requires the console to be able to initiate a connection to the agent.
• When using Investigate graph and drill-down requests require the remote node to initiate a connection back to the console on a set of dynamically allocated ports on the console. In Perform version 7.2.xx and later there is a 'firewall mode' option that allows Investigate to work with only communication from the console to the agent.
• In Perform version 7.1.xx and later the console receives status messages pushed from the remote node to the console via port 6768. That means that the remote nodes will attempt to initiate a connection to the console on port 6768. This functionality is for Collection Status Reporting in Manager on the console

Investigate will use port 30000 for drill downs and 40000 for graphs. If port 30000 isn't available it will try 29999, if that isn't available 29998, and so on until it finds an open port. The same basic 'subtract 1' behavior is followed when trying to find an Investigate graph port. There is no way to specify a different dynamic port range within Investigate - it will always use those ports. On Unix, each instance of the Investigate (bgsmonitor) process will allocate ports so if you are running just one version of Investigate then you should only see 30000 and 40000 in use.

For example, here is some 'netstat' output from a console machine with one running console with an active chart and drilldown against two different machines:  
On the left side is the 'local address'. This is the port in use on the console machine itself. On the right side is the 'remote address' this is the source IP address and port from the remote node side. The source port is randomly generated by the remote node - firewalls don't filter based upon source ports - they filter based upon destination ports. So, you can see that in both case the remote nodes have initiated a connection to port 30000 and port 40000 on the console.

There is another way to configure a machine in Investigate to not use these dynamic ports and have all communication sent through a network connection initiated by the Perform console to port 6767 on the remote node. This is done by flagging the machine as 'Outside the firewall'.