This chapter describes settings to configure your Collector systems to perform domain-based segmentation, and increase the memory available to Collector processes.
By default, the Collector process (panther) is assigned 30% of available system memory within a single-server installation. Within a remote Collector installation, the Collector process is assigned 70% of available memory. To set the memory available to the Collector process, use the following command:
execsql config_set_profile_value profile config MaxMemoryUsage replace setting
where:
profile specifies the name of the Collector profile that needs to be updated.
setting is the percentage of system memory available to the Collector process. Note that percentage sign must not be specified with the setting. It is recommended that you specify a percentage not higher than 90%. If the Collector process has to share resources with other software running on the system, a maximum setting of 80% is more appropriate.
Note that the required Collector profile name can either be obtained via the Reporter GUI (select Configuration, then Security, and then Collector profiles), or by executing the following command:
execsql config_get_profiles
To configure RUEI to filter (segment) monitored traffic based on domain names, do the following:
Select Configuration, then Security, then Network filters, and select the required Collector profile. Ensure that the Packet capture menu specifies the "Specified domains" option for each required Collector profile.
Create, modify, or delete the required rows in the c_domain_segments database table. The table has the following format:
ID Priority Domain Profile_ID Traffic_segment 1000 10 *.nl 2 1|1 1100 8 *.be 2 1|2 1150 3 *.oracle.* 2 1|1 1200 1 *.com 2 3|4
where:
The ID column represents a unique identifier for each row in the table.
The Priority column represents the order in which the filters are applied. The filters with the highest priority numbers are applied first, and those with the lowest are resolved last. Hence, in the above example, monitored traffic relating to the domain myshop.oracle.com would be filtered as *.oracle.* 1|1, and not the *.com 3|4 filters. Also, all domain traffic with the country code nl is monitored, while only the first half of the data stream should be monitored for domains with the country code be.
The Domain column contains the actual filter value where * can be used as a wildcard.
The Profile_ID column relates to the ID of the Collector profile for which the filters should apply. This ID can be found in c_cprofiles.
The Traffic_segment column contains the segment which should be used for the specified filter. You can specify up to 128 parts. For example, 34|128 will take the 34th segment out of 128.
To view the currently defined network filters, logon to the Reporter system as the RUEI_USER user, and issue the following command:
sqlplus /@RUEI_DB_TNSNAME
select id, prio, domain, profile_id, traffic_segment from c_domain_segments order by prio;
To insert a row into the table, issue the following command:
insert into c_domain_segments (id, prio, domain, profile_id, traffic_segment) values (c_domain_segments_seq.nextval, 1, '*.nl', 2, '1|2');
To delete a row from the table, issue the following command:
delete from c_domain_segments where id=1;
To alter a filter's priority, issue the following command:
update c_domain_segments set prio=100 where id=2;
By default, a Collector system use three threads for Network Protocol Analysis (NPA). This is controlled by the NumNPAThreads setting. Collector performance can be improved by increasing this setting.
If not currently defined, this number can be increased by using the following command:
execsql config_set_profile_value profile config NumNPAThreads add 4
If previously defined, it can be modified by using the following command:
execsql config_set_profile_value profile config NumNPAThreads replace 5
where profile specifies the name of the Collector profile that needs to be updated.
By default, the Forms socket mode setting is set to 10 minutes. To view it, issue the following command:
execsql config_get_profile_value System forms FormsSocketTimeout
To alter it, issue the following command:
execsql config_set_profile_value System forms FormsSocketTimeout replace 600
This section describes how to set up a GRE Ethernet (Layer 2) tunnel to a RUEI Collector Engine using a script. With this configuration, it does not matter where the Collector Engine is running as long as the tunnel endpoints can reach each other through the network. However the network throughput can decrease when using tunnels, as there is network throughput overhead caused by the additional headers added to the packets and the CPU time overhead caused by encapsulation and decapsulation of those packets.
A GRE tunnel between two servers using Linux is created by creating a GRE endpoint on each server. The following sections describe how to set up such an endpoint using the provided tunnelctl script.
Note:
Before attempting this procedure set up console access to the systems involved. This is required because issuing a wrong command can take a network offline, possibly severing any connection you have to the server. In that case console access is needed to repair the network.GRE Ethernet tunneling has been supported in Linux since kernel version 2.6.28, and requires an up to date version of the iproute package containing the utilities (specifically the IP utility) to set up and configure GRE Ethernet tunnel (gretap) interfaces.
This procedure uses Oracle Linux 6.4 as a base for setting up the GRE Ethernet tunnels, as OL6 provides a UEK kernel (Linux version 2.6.39-400.109.1.el6uek at time of writing) capable of setting up GRE Ethernet tunnels, as well as the correct version of the iproute package (iproute-2.6.32-23.el6.x86_64 for OL6.4) needed to add, delete or change GRE Ethernet tunnels.
Oracle Linux 5 is not supported even though it could support GRE Ethernet tunnels in its UEK kernel (Linux version 2.6.39-400.21.1.el5uek for OEL5.9) but needs a newer version (2.6.28 or higher) of the iproute package capable of setting up GRE Ethernet tunnels. Such a version of the iproute package is currently not officially supported and as such it is not covered by this procedure.
Installing and configuring a Collector is described in the Oracle Real User Experience Insight Installation Guide.
The following environment is required for GRE tunnelling:
A server running OL6 with a RUEI 12.1.0.6 Collector Engine installed and configured (can be a virtual machine).
The two endpoints are able to reach each other (for example, tested using ping). The relevant ports must have been opened in any firewalls, both on the endpoints as well as on any router in between.
The two endpoints must have an executable copy of the tunnelctl script.
root user access is available on both endpoints.
Perform the following steps to set up the endpoints:
Note the IP address of the local and remote endpoints.
Create an Identifier (ID) to be used for both endpoints, for example ABC123. This ID will be used to identify the tunnel on both sides.
Log in as root using ssh and enter the following command:
tunnelctl create gre Local_IP Remote_IP ID
where
Local_IP is the address of the current server.
Remote_IP is the address of the remote server.
ID is the identifier you created in the previous step.
Check that the tunnel has been created:
tunnelctl list
An interface named greID should be listed.
If the other endpoint is a server, repeat the steps above on the second endpoint (noting that you need to reverse the local and remote IP addresses when creating the tunnel).
If the other endpoint is a router or switch capable of duplicating streams and sending them out through a GRE Ethernet tunnel, refer to the product documentation for any steps that might be necessary.
Test the GRE tunnel by pinging from one endpoint and checking tcpdump output on the other endpoint:
Enter the following command as root on both endpoints to make sure the tunnel exists
tunnelctl list
Enter the following command as root on server A to create traffic that will be sent over the tunnel:
ping -I greID 127.1.1.1
where
greID is the tunnel interface you created earlier.
Enter the following command as root on server B to check for traffic that was sent over the tunnel:
tcpdump -i ETH -c 100 proto gre
where
ETH is the interface the tunnel uses (typically eth0), not the tunnel interface you created earlier.
You should see ARP and/or ICMP requests for the above IP address wrapped in GRE packets (GREv0) similar to these:
… IP server_A > server_B: GREv0, length 46: ARP, Request who-has 127.1.1.1 tell server_A, length 28 … IP server_A > server_B: GREv0, length 102: IP server_A > 127.1.1.1: ICMP echo request, id 62057, seq 1, length 64
Perform the following steps to set up the endpoints:
Make sure that you know the ID of the tunnel.
Log in as root using ssh and enter the following command:
tunnelctl destroy greID
where
greID is the tunnel interface you created earlier.
Check that the tunnel has been deleted:
tunnelctl list
The interface named greID should not be listed.
To enable the RUEI Collector Engine to listen to the GRE Ethernet tunnel:
Using RUEI (Configuration > Security > Collector profiles, note the collector profile that you want to configure. The default network based profile is named System network data collectors. If necessary create a new profile.
Make sure the Collector you want to configure is governed by the chosen Collector profile.
Log in to the RUEI Reporter system as the $RUEI_USER user.
Enter the following command:
execsql config_set_profile_value PROFILE config ForceInterface add greID
where
greID is the tunnel interface you created earlier.
PROFILE is the profile you choose in step 1 above.
Note that the collector must be forced to listen to the interface since it is not a physical interface and thus lacks certain internal signals used by the collector to decide if the interface is up or down. The collector would otherwise not use the interface.
Make sure there is not a firewall filtering any packets coming through the interface. It is outside the scope of this document to explain how to perform this task but below is a short list of pitfalls to take into account:
The firewall should be set up to totally ignore the interface, not set up to route everything to a single other interface in the GRE tunnel network. This is because any filtering causes CPU overhead, which can have a negative effect on throughput.
Any generic firewall rules, that is rules covering all interfaces can also apply to the interface currently being configured, must be altered not to cover this interface. As a workaround, add new rules to ignore this interface.
Disable any network throttling that might affect the interface. It is outside the scope of this document to explain how to perform this task.
Create a boot script to be executed by the system at boot time that executes the above setup commands, including the GRE Ethernet tunnel creation, firewall modification and network throttling changes.
Note:
Adding-f to the tunnelctl command makes it non-interactive. For example:
tunnelctl -f list