Linux and UNIX systems: K-TAP parameters
These parameters affect the behavior of the K-TAP.
These parameters are located in the [TAP] section of the S-TAP properties.
guard_tap.ini | Default value | Description |
---|---|---|
ktap_installed | 1 | Is Kernel Monitor module installed: 0=NO, 1=YES. ktap_installed and tee_installed are mutually exclusive; only one can be set to on. |
ktap_request_timeout | 5 | The timeout, in seconds, for waiting for K-TAP reply. K-TAP sends ioctl to S-TAP to ask for some information, and waits for the reply from S-TAP. It can have any value. |
ktap_dbgev_ev_list | 0 | It is used to enable K-TAP trace log either through GUI or through guard_tap.ini file: 0=disable, 1=enable ktap trace log located under /var/tmp directory |
ktap_dbgev_func_name | all | List of functions to log in K-TAP trace log. all= all the functions or we can specify specific function such as accept so we log in the log file only the accept functions. If you specify a function that is not relevant to the K-TAP trace log it won't log anything to the log. |
ktap_fast_tcp_verdict | 1 | For TCP connections. |
ktap_fast_file_verdict | 1 | For TLI connection, K-TAP sends ioctl to S-TAP to confirm that session is the database connection configured in our IE by checking ports and Ips, when ktap_fast_file_verdict is set to 1, then K-TAP does not send the request to S-TAP as long as session's ports are in the range. it can have either 1 or 0 values (1). |
ktap_buffer_size | 4194304 | Advanced. The size of theK-TAP buffer in Bytes. The range of values is between 1 MB and 16 MB |
ktap_buffer_flush | 0 | Advanced. The way to send messages from K-TAP to S-TAP. If = 1 the S-TAP reads the entire K-TAP buffer and process all the packets in the buffer. If ktap_flush_buffer=0 , the S-TAP reads a fixed amount rather than the entire buffer. |
ktap_local_tcp | 0 | 1=only intercept local connections (although previously intercepted connections will still be captured) (this parameter is used for TCP connections) |
khash_table_length | 24593 | Number of sessions that can be stored in the Khash table. It is an integer and can have any value. |
khash_max_entries | 8192 | Length of the table that contains all the information for the specific session. It is an integer and can have any value. |
ktap_fast_shmem | 1 | For db2 shared memory connection
|
ktap_fsmon_buffer_size | 4194304 | FAM buffer size |
Parameter | Default value | Description |
---|---|---|
atap_exec_location | /var/guard | Location of the executable that is used when activating A-TAP by enabling the encryption box in the inspection engine section |
pcap_read_timeout | 0 | only PCAP traffic (non-K-TAP): how long should S-TAP wait between PCAP sampling. Do not change this value without consulting with Technical Support, after examining the problem and determining the losses (not capturing all the traffic) are caused due to PCAP/S-TAP related bottleneck. |
pcap_dispatch_count | 16 | Optimization of PCAP capturing; number of packets to bundle (group) before reporting back to S-TAP. Grouping the packets together can reduce the PCAP-to-S-TAP communication, and boost performance. Do not change this value without consulting with Technical Support, after examining the problem and determining the losses (not capturing all the traffic) are caused due to PCAP/S-TAP related bottleneck. |
pcap_buffer_size | -1 | Size of PCAP socket buffer. This parameter is used for LINUX only. This integer's default value is -1, means to get the maximal buffer possible. Any other case, this is buffer size in kilobytes. 0 is not legal - if it is 0, it means 60 other than that it can be any value up to 65535. Larger buffer mean that it's likely to have losses when there are busts of high volume traffic. The scenario; Burst of high traffic, PCAP captures everything, but the S-TAP (or PCAP-to-S-TAP flow) is not fast enough and cannot keep up with the traffic. To avoid losses, the yet-to-be-processed packets are buffered. The larger the buffer is, the more resilient against higher and longer bursts of high traffic. Do not change this value without consulting with Technical Support, after examining the problem and determining the losses (not capturing all the traffic) are caused due to PCAP/S-TAP related bottleneck. |
pcap_backup_ktap | 1 | When this parameter is enabled, always start PCAP regardless if ktap_installed is enabled or not, as long as there is DB2 defined in IE. |
Add parameter to control use of custom KTAP modules distribution via GIM GUI
GIM users - Compile a custom built KTAP into a custom bundle and use it on other database servers.
Non-GIM users - No custom bundles needed, custom KTAP could be compiled and copied between databases server manually.
Parameter Name: GIM_ALLOW_CUSTOM_BUNDLES
Valid values: '1' - allow custom bundles installations . '0' - Reject custom bundle installations
Default value: 1
During GIM scratch installation (DB server) - User can specify a new optional installation parameter, --install_custom_bundles.
If specified, custom bundles installations (for example, custom bundle STAP) will be allowed (GIM_ALLOW_CUSTOMED_BUNDLES will be set to '1') on that DB server. Otherwise won't be allowed (GIM_ALLOW_CUSTOMED_BUNDLES will be set to '0').
During GIM upgrade (via GIM GUI) from a GIM version that did NOT have this parameter - Default value will be '1' (in order not to disable this functionality for customers that might have been using this feature until now).
This parameter can be set to either '1' or '0' when using the configurator utility on the DB server.
This parameter cannot be set to '1' from the GUI if the previous value is '0'.
Note: This functionality will be checked during installation time (on the DB server) and NOT while you are assigning or scheduling a bundle installation or a parameter update (like all the other params are validated).
Affected features: BUNDLE-GIM, configurator.sh, consolidated installer
GuardAPI commands and custom KTAP bundle
In v10
STAP_UPLOAD_FEATURE indicator by default is turned on (1) so custom KTAPs when compiled automatically uploaded to appliance
In order to compile custom GIM bundle to include new custom KTAP, user need to run grdapi make_bundle_with_uploaded_kernel_module command (need to have exact syntax of the command)
In order to use already compiled CUSTOM BUNDLE on any server customer need to turn on GIM_ALLOW_CUSTOM_BUNDLES indicator to 1 (for security reasons this have to be done manually on each DB server). Turning GIM_ALLOW_CUSTOM_BUNDLES indicator back to off could be done from appliance.