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.

CAUTION:
These are advanced parameters and are usually modified by IBM Technical Support only.
Table 1. K-TAP configuration parameters
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.
0: "slow" verdict.  KTAP sends information about the session to STAP to ask whether or not the traffic should be  intercepted.
1: "fast" verdict.  KTAP decides on its own.
In both cases, the network/exclude network parameters are checked against the incoming IP.
From 10.1.4, the value is 1 after upgrade.

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
  • 0=KTAP sends ioctl to the STAP to confirm that the session is the database connection configured in the IE by checking the process ID
  • 1= K-TAP does not send the request to S-TAP as long as session's db2_shmem_size matches the attached shared memory segment.
ktap_fsmon_buffer_size 4194304 FAM buffer size
Table 2. A-TAP and PCAP configuration parameters
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

  1. STAP_UPLOAD_FEATURE indicator by default is turned on (1) so custom KTAPs when compiled automatically uploaded to appliance

  2. 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)

  3. 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.