You can only do this if you're a PerformanceGuard administrator.
PerformanceGuard holds a configuration table for controlling servers that dynamically assign individual server port numbers to clients. Because PerformanceGuard stores information about IP traffic by server IP address, server port number and protocol ID, individually assigned server port numbers introduce large amounts of data that's of no interest.
Solve this by joining ports. The benefits can be great:
Example: Typically, it isn't important to know the dynamically allocated server port number for each client. If you join all dynamically allocated server port numbers into one static server port number of your choice, you can save a lot of disk space and improve the performance of database queries.
Example: If a server that dynamically allocates port numbers has 100 client connections, PerformanceGuard will report traffic regarding 100 different port numbers. If you join them into a single port number, you'll reduce the need for database storage by a factor of 100.
Technical Background: Joined Server Ports Database Table
Column Name |
Data Type |
Description |
---|---|---|
IP_ADDRESS |
VARCHAR2(8) |
Hexadecimal IP address of server |
VIRTUAL PORT |
NUMBER |
Port number to join into |
PROTOCOL_ID |
NUMBER |
TCP/UDP |
MAP |
VARCHAR2(4000) |
Comma-separated list of port ranges to be joined |
The Joined Server Ports database table controls servers which dynamically allocate port numbers to each client. On startup the Frontend servers will read all rows in this table. Every time the PerformanceGuard agent delivers an IP traffic report about a server to the frontend server, it will check if the server IP address and protocol ID matches any rows in the JOINED_SERVER_PORTS table by checking the IP_ADDRESS and PROTOCOL_ID columns.
If there is a match, that is if the reported server port number lies in the port range specified in the MAP column, the port number is changed to the port number specified in the PORT column before the data is stored in the database.
This way hundreds, or even thousands, of dynamically allocated port numbers may be collapsed into just one static port number and thereby reduce database disk usage by the same factor.
Example
An Oracle database server 10.0.1.3 installed on Windows by default allocates ports to clients dynamically. All of the clients first connect to port 1521, and then get individual port numbers (typically above 2000) to connect to and use for the rest of their sessions.
The following row in the JOINED_SERVER_PORTS table joins all TCP ports above 2000 on server 10.0.1.3 into TCP port number 1234:
IP_ADDRESS |
VIRTUAL PORT |
PROTOCOL_ID |
MAP |
---|---|---|---|
0A000103 |
1234 |
6 |
2000-65535 |
Manage Joined Server Ports
To manage joined server ports, select ADMINISTRATION > Server > Joined Server Ports.
The Existing tab lists already defined joined server ports in two tables, one for manually joined server ports and one for automatically joined server ports.
Manually Joined Server Ports
On startup, and thereafter every half hour, the frontend server will read all rows in this list. Every time a PerformanceGuard agent delivers a report about IP traffic to a server, the frontend server will check if the server IP address and protocol ID match any rows in the list.
If there is a match, and if the reported server port number lies in the port range specified in the Port Mapping column, the port number is changed to the virtual port number specified in the Virtual Port column before the data is stored in the database. This way hundreds or thousands of dynamically allocated port numbers may be collapsed into just one static port number. That way you reduce database disk usage by the same factor.
Automatically Joined Server Ports.
Every half hour the Frontend server automatically joins ports from servers that spam the database. That is, if there's IP data in the database, on several different ports (configurable, see the following), from the same server, using the same protocol (UDP or TCP), all the ports above port 1025, from that server and protocol, will automatically be joined to the virtual port 0.
There is no difference between the automatically joined server ports and the manually joined server ports other than the way they were created.
If you edit an automatically joined server port entry, and save the change, the entry will be moved to the manually joined server ports list.
Define New Joined Server Ports
To define new joined server ports, select ADMINISTRATION > Server > Joined Server Ports and then select the New tab.
Specify the following:
- The IP address of the server, for example 10.10.110.218.
- The single Virtual Port that you want to other ports join into. Must be a number between 0 and 65535.
- The required Protocol. Either TCP or UDP.
- The required Port-Mapping. The list of ports that you want to join into a single virtual port (the Virtual Port that you specified before). Specify the ports as a comma-separated list in which you can also include port ranges. Allowed characters: 0-9, commas, semicolons and dashes.
Example: 1,2,3-10;70-90
If you set up several joined server ports for the same IP address, make sure that your port mapping doesn't overlap.
Configure Number of Ports Required for Auto-Joining
The number of ports, from the same server (IP address) and the same protocol, required for the Frontend server to consider it as a port spammer, is configurable. To change the number of ports required, select ADMINISTRATION > Setup > Parameters and then select the Frontend tab.
The field Port spammer threshold defines number of ports required for auto-joining. When you edit the field and click Save, the new value is written to the database at once, so the next time the Frontend server auto-joins server ports, this new number will be used to detect the server port spammers. The default number is 20.
View Status of Automatically Joined Server Ports
You can use the System Status page (ADMINISTRATION > Status > System Status) to check whether automatically joined server ports have been detected. Look for Auto joined port spammers found.