Kernel Debug Syntax

Description

During a kernel debug session, Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. / Cluster Member Security Gateway that is part of a cluster. / Scalable Platform Security Group Member Member of a Security Group in ElasticXL Cluster, Maestro, and Scalable Chassis. Acronym: SGM. prints special debug messages that help Check Point Support and R&D understand how it processes the applicable connections.

Important:

In Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., you must configure and perform the kernel debug procedure on all cluster members in the same way.
On Scalable Platforms (Maestro and Chassis), you must connect to the applicable Security Group A logical group of Security Appliances (in Maestro) / Security Gateway Modules (on Scalable Chassis) that provides Active/Active cluster functionality. A Security Group can contain one or more Security Appliances / Security Gateway Modules. Security Groups work separately and independently from each other. To the production networks, a Security Group appears a single Security Gateway. In Maestro, each Security Group contains: (A) Applicable Uplink ports, to which your production networks are connected; (B) Security Appliances (the Quantum Maestro Orchestrator determines the applicable Downlink ports automatically); (C) Applicable management port, to which the Check Point Management Server is connected..

Action Plan to Collect a Kernel Debug

Note - See the Kernel Debug Procedure, or the Kernel Debug Procedure with Connection Life Cycle.

Step	Action	Instructions
1	Configure the applicable debug settings: Restore the default settings. Allocate the debug buffer.	In this step, you prepare the kernel debug options: Restore the default debug settings, so that any other debug settings do not interfere with the kernel debug. Allocate the kernel debug buffer, in which Security Gateway / Cluster Member / each Security Group Member holds the applicable debug messages.
2	Configure the applicable kernel debug modules and their debug flags.	In this step, you prepare the applicable kernel debug modules and their debug flags, so that Security Gateway / Cluster Member / each Security Group Member collects only applicable debug messages.
3	Start the collection of the kernel debug into an output file.	In this step, you configure Security Gateway / Cluster Member / each Security Group Member to write the debug messages from the kernel debug buffer into an output file.
4	Stop the kernel debug.	In this step, you configure Security Gateway / Cluster Member / each Security Group Member to stop writing the debug messages into an output file.
5	Restore the default kernel debug settings.	In this step, you restore the default kernel debug options.

Kernel Debug Behavior on Security Gateways with 72 and more CPU Cores

When you enable the kernel debug, all CoreXL Performance-enhancing technology for Security Gateways on multi-core processing platforms. Multiple Check Point Firewall instances are running in parallel on multiple CPU cores. Firewall instances on a Security Gateway start to print their applicable debug messages.

To present the complete chronological overview, the Security Gateway performs real-time merge of these debug messages in RAM.

The more CPU cores the Security Gateway has, the more CPU and RAM resources this real-time merge consumes.

Therefore, starting in R82, by default, the kernel debug behaves differently on Security Gateways with 72 and more CPU cores:

When you run the kernel debug without redirecting the output to a file

This is the comparison of the kernel debug behavior of the "fw ctl kdebug -T" command when you do not redirect the debug output to a file:

New Kernel Debug Behavior on Security Gateways with 72 and more CPU cores	Legacy Kernel Debug Behavior on Security Gateways with fewer than 72 CPU cores
The Security Gateway writes the debug messages to default temporary output files (`/var/log/debug.log*`). For Firewall: `/var/log/debug.log` `/var/log/debug.log.header` `/var/log/debug.log.kernel` `/var/log/debug.log.<VS_ID>.<CoreXL_FW_ID>` For SecureXL Check Point product on a Security Gateway that accelerates IPv4 and IPv6 traffic that passes through a Security Gateway. in the UPPAK mode: `/var/log/debug.log.uppak` The Security Gateway does not show any output on the screen in real time. Note - You can run the "`fw ctl kdebug -T`" command in the background, and run the "`tail –f`" commands on all the temporary debug files. After you stop the kernel debug, the Security Gateway: Performs the merge of all debug messages saved in the temporary output files. Shows the merged output on the screen. Deletes the temporary output files (unless you specify to keep them).	The Security Gateway keeps the debug messages in RAM. The Security Gateway shows the merged output on the screen in real time.

New Kernel Debug Behavior on Security Gateways with 72 and more CPU cores

Legacy Kernel Debug Behavior on Security Gateways with fewer than 72 CPU cores

The Security Gateway writes the debug messages to default temporary output files (/var/log/debug.log*).
- For Firewall:
  
  /var/log/debug.log
  
  /var/log/debug.log.header
  
  /var/log/debug.log.kernel
  
  /var/log/debug.log.<VS_ID>.<CoreXL_FW_ID>
- For SecureXL Check Point product on a Security Gateway that accelerates IPv4 and IPv6 traffic that passes through a Security Gateway. in the UPPAK mode:
  
  /var/log/debug.log.uppak
The Security Gateway does not show any output on the screen in real time.

Note - You can run the "fw ctl kdebug -T" command in the background, and run the "tail –f" commands on all the temporary debug files.
After you stop the kernel debug, the Security Gateway:
1. Performs the merge of all debug messages saved in the temporary output files.
2. Shows the merged output on the screen.
3. Deletes the temporary output files (unless you specify to keep them).

The Security Gateway keeps the debug messages in RAM.
The Security Gateway shows the merged output on the screen in real time.

When you run the kernel debug and redirect the output to a file

This is the comparison of the kernel debug behavior of the "fw ctl kdebug -T" command when you redirect the debug output to a file (/<Path>/<Name of File>.<Extension of File>):

New Kernel Debug Behavior on Security Gateways with 72 and more CPU cores	Legacy Kernel Debug Behavior on Security Gateways with fewer than 72 CPU cores
The Security Gateway writes the debug messages to temporary output files (in the same directory of the output file you specified): For Firewall: `/<Path>/<Name of File>.<Extension of File>.header` `/<Path>/<Name of File>.<Extension of File>.kernel` `/<Path>/<Name of File>.<Extension of File>.<VS_ID>.<CoreXL_FW_ID>` For SecureXL in the UPPAK mode: `/<Path>/<Name of File>.<Extension of File>.uppak` The Security Gateway does not show any output on the screen in real time. Note - You can run the "`fw ctl kdebug -T`" command in the background, and run the "`tail –f`" commands on all the temporary debug files. After you stop the kernel debug, the Security Gateway: Performs the merge of all debug messages in the temporary output files. Deletes the temporary output files (unless you specify to keep them).	The Security Gateway writes the debug messages to the specified output file. The Security Gateway does not show any output on the screen in real time. Note - You can run the "`tail –f`" command on the specified output file.

New Kernel Debug Behavior on Security Gateways with 72 and more CPU cores

Legacy Kernel Debug Behavior on Security Gateways with fewer than 72 CPU cores

The Security Gateway writes the debug messages to temporary output files (in the same directory of the output file you specified):
- For Firewall:
  
  /<Path>/<Name of File>.<Extension of File>.header
  
  /<Path>/<Name of File>.<Extension of File>.kernel
  
  /<Path>/<Name of File>.<Extension of File>.<VS_ID>.<CoreXL_FW_ID>
- For SecureXL in the UPPAK mode:
  
  /<Path>/<Name of File>.<Extension of File>.uppak
The Security Gateway does not show any output on the screen in real time.

Note - You can run the "fw ctl kdebug -T" command in the background, and run the "tail –f" commands on all the temporary debug files.
After you stop the kernel debug, the Security Gateway:
1. Performs the merge of all debug messages in the temporary output files.
2. Deletes the temporary output files (unless you specify to keep them).

The Security Gateway writes the debug messages to the specified output file.
The Security Gateway does not show any output on the screen in real time.

Note - You can run the "tail –f" command on the specified output file.

CLI Syntax

When there are differences in the syntax, this section provides the CLI syntax for the new kernel debug (see Kernel Debug Behavior on Security Gateways with 72 and more CPU Cores) and the legacy kernel debug.

Notes:

The syntax below applies to both Gaia Clish The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell). / Gaia gClish The name of the global command line shell in Check Point Gaia operating system for Security Appliances connected to Check Point Quantum Maestro Orchestrators and for Security Gateway Modules on Scalable Chassis. Commands you run in this shell apply to all Security Gateway Module / Security Appliances in the Security Group. and the Expert mode.
The syntax below applies to the Security Gateway, each Cluster Member, and Scalable Platform Security Group.

Important - To run these commands in the Expert mode on a Scalable Platform Security Group, you must use the "g_fw ..." command instead of the "fw ..." command.

CLI syntax to see the built-in help for the kernel debug

Kernel Debug Mode

Kernel Debug Syntax

New Kernel Debug

and

Legacy Kernel Debug

fw ctl debug -h

New Kernel Debug

fw ctl ndebug -h

Legacy Kernel Debug

fw ctl kdebug -h

CLI syntax to restore the default kernel debug settings

To reset all debug flags and enable only the default debug flags in all kernel modules:

fw ctl debug 0

To disable all debug flags including the default flags in all kernel modules:

Best Practice - Do not run this command, because it disables even the basic default debug messages.

As a result, the /var/log/messages file will not show these basic default debug messages.

fw ctl debug -x

CLI syntax to allocate the kernel debug buffer

For an approximate total memory utilization, refer to sk160955.

fw ctl debug -buf 8200 [-v {"<List of VSIDs>" | all} -k]

Notes:

Security Gateway / Cluster Member / each Security Group Member allocates the kernel debug buffer with the specified size for each CoreXL Firewall instance.
The maximum supported buffer size is 8192 kilobytes..

CLI syntax to allocate the user space debug buffer

The size of the user space debug buffer should be at least the size of the maximum kernel debug buffer of 8200.

Use the "-b <User Space Buffer Size>" parameter as part of the syntax.

Kernel Debug Mode

Kernel Debug Syntax

New Kernel Debug

fw ctl ndebug -b 8200 <other required parameters>

Legacy Kernel Debug

fw ctl kdebug -b 8200 <other required parameters>

Note - Security Gateway / Cluster Member / each Security Group Member allocates the user space debug buffer with the specified size for each CoreXL Firewall instance.

CLI syntax to configure the debug modules and debug flags

General syntax:

fw ctl debug [-d <Strings to Search>] [-F "<Source IP>,<Source Port>,<Dest IP>,<Dest Port>,<Protocol Number>"] [-H "<IP Address>"] [-v {"<List of VSIDs>" | all} -k] [-k] -m <Name of Debug Module> {all | + <List of Debug Flags> | - <List of Debug Flags>} [-U]

fw ctl debug [-s "<String to Stop Debug>"] [-F "<Source IP>,<Source Port>,<Dest IP>,<Dest Port>,<Protocol Number>"] [-H "<IP Address>"] [-v {"<List of VSIDs>" | all} -k] [-k] -m <Name of Debug Module> {all | + <List of Debug Flags> | - <List of Debug Flags>}[-U]

To see a list of all debug modules and their flags:

Note - The list of kernel modules depends on the Software Blades you enabled on the Security Gateway / ClusterXL / Security Group.

fw ctl debug -m

To see a list of debug flags that are already enabled:

fw ctl debug

To enable all debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> all

To enable the specified debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> + <List of Debug Flags>

To disable the specified debug flags in the specified kernel module:

fw ctl debug -m <Name of Debug Module> - <List of Debug Flags>

CLI syntax to collect the kernel debug output in the 'Gateway' mode

Kernel Debug Mode

Kernel Debug Syntax

New Kernel Debug

fw ctl ndebug [-b <User Space Buffer Size>] [-p <List of Fields>] [-k] -T [-M] [-w] [-U] [-c <Number of CoreXL Firewall Instances in Debug Thread>] [-I "<List of CoreXL Firewall Instances>" | all}] -o /<Path>/<Name of Output File>

Legacy Kernel Debug

fw ctl kdebug [-b <User Space Buffer Size>] [-p <List of Fields>] [-k] -T -f -o /<Path>/<Name of Output File> [-m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]]

CLI syntax to collect the kernel debug output in the 'VSNext' / 'Legacy VSX' mode - from specific Virtual Systems

Kernel Debug Mode

Kernel Debug Syntax

New Kernel Debug

fw ctl ndebug [-b <User Space Buffer Size>] [-p <List of Fields>] [-k] -T [-v {"<List of VSIDs>" | all}] [-M] [-w] [-U] [-c <Number of CoreXL Firewall Instances in Debug Thread>] [-I {"<List of CoreXL Firewall Instances>" | all}] -o /<Path>/<Name of Output File>

Legacy Kernel Debug

fw ctl kdebug [-b <User Space Buffer Size>] [-p <List of Fields>] -v {"<List of VSIDs>" | all} -k -T -f -o /<Path>/<Name of Output File> [-m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]]

CLI Parameters

CLI Parameters for the 'fw ctl debug' command (for the new kernel debug and the legacy kernel debug)

Note - Only supported parameters are listed.

Parameter

Description

0 | -x

Controls how to disable the debug flags:

0

Resets all debug flags and enables only the default debug flags in all kernel modules.

-x

Disables all debug flags, including the default flags in all kernel modules.

Best Practice - Do not use the "-x" parameter, because it disables even the basic default debug messages.

-d <Strings to Search>

When you specify this parameter, the Security Gateway / Cluster Member / Security Group:

Examines the applicable debug messages based on the enabled kernel debug modules and their debug flags.
Collects only debug messages that contain at least one of the specified strings into the kernel debug buffer.
Writes the entire kernel debug buffer into the output file.

Notes:

These strings can be any plain text (not a regular expression) that you see in the debug messages.

Separate the applicable strings by commas without spaces:

-d String1,String2,...,StringN

You can specify up to 10 strings, up to 250 characters in total.

-s "<String to Stop Debug>"

When you specify this parameter, the Security Gateway / Cluster Member / Security Group:

Collects the applicable debug messages into the kernel debug buffer based on the enabled kernel debug modules and their debug flags.
Does not write any of these debug messages from the kernel debug buffer into the output file.
Stops collecting all debug messages when it detects the first debug message that contains the specified string in the kernel debug buffer.
Writes the entire kernel debug buffer into the output file.

Notes:

This one string can be any plain text (not a regular expression) that you see in the debug messages.
String length is up to 50 characters.

-F "<Source IP>,<Source Port>,<Dest IP>,<Dest Port>,<Protocol Number>"

Specifies the capture filter (for both accelerated and non-accelerated traffic):

<Source IP> - Specifies the source IP address
<Source Port> - Specifies the source Port Number (see IANA Service Name and Port Number Registry)
<Dest IP> - Specifies the destination IP address
<Dest Port> - Specifies the destination Port Number (see IANA Service Name and Port Number Registry)
<Protocol Number> - Specifies the Protocol Number (see IANA Protocol Numbers)

Notes:

The "-F" parameter uses the Kernel Debug Filters.

For more information, see Kernel Debug Filters.

For the Source IP address:

simple_debug_filter_saddr_<N> "<IP Address>"

For the Source Ports:

simple_debug_filter_sport_<N> <1-65535>

For the Destination IP address:

simple_debug_filter_daddr_<N> "<IP Address>"

For the Destination Ports:

simple_debug_filter_dport_<N> <1-65535>

For the Protocol Number:

simple_debug_filter_proto_<N> <0-254>

Value 0 means "any".
This parameter supports up to 5 capture filters (up to 5 instances of the "-F" parameter in the syntax).

The kernel debug performs the logical "OR" between all specified simple capture filters.

-H "<IP Address>"

Creates an IP address filter.

For more information, see Kernel Debug Filters.

This parameter supports up to 3 capture filters (up to 3 instances of the "-H" parameter in the syntax).

Example - Capture traffic only to and from the Host 1.1.1.1:

fw ctl debug –H "1.1.1.1"

-m <Name of Debug Module>

Specifies the name of the kernel debug module, for which you print or configure the debug flags.

{all | + <List of Debug Flags> | - <List of Debug Flags>}

Specifies which debug flags to enable or disable in the specified kernel debug module:

all

Enables all debug flags in the specified kernel debug module.

+ <List of Debug Flags>

Enables the specified debug flags in the specified kernel debug module.

You must press the space bar key after the plus (+) character:

+ <Flag1> [<Flag2> ... <FlagN>]

Example: "+ drop conn"

- <List of Debug Flags>

Disables the specified debug flags in the specified kernel debug module.

You must press the space bar key after the minus (-) character:

- <Flag1> [<Flag2> ... <FlagN>]

Example: "- conn"

-v {"<List of VSIDs>" | all -k}

Important - The new kernel debug command "fw ctl ndebug" also contains this parameter.

In the VSNext mode:

Specifies the list of Virtual Gateways.
A VSNext Gateway automatically filters the collected kernel debug information for debug messages only for these Virtual Gateways.

In the Legacy VSX Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. mode:

Specifies the list of Virtual Systems.
A Legacy VSX Gateway Physical server that hosts VSX virtual networks, including all Virtual Devices that provide the functionality of physical network devices. It holds at least one Virtual System, which is called VS0. automatically filters the collected kernel debug information for debug messages only for these Virtual Systems.

Notes:

This parameter "-v" is supported only in VSNext / Legacy VSX mode.
If you use this parameter "-v", you must also uses the parameter "-k".

Syntax:

-v "<List of VSIDs>"

Monitors the debug messages only from the specified Virtual Gateways / Virtual Systems.

To specify the Virtual Gateways / Virtual Systems, enter their VSID number separated with commas and without spaces:

"VSID1[,VSID2,VSID3,...,VSIDn]"

Example: -v "1,3,7"

To see the IDs of Virtual Gateways / Virtual Systems, run:

In Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. Clish / Gaia gClish:

show virtual-system all
In the Expert mode:

vsx stat -v

-v all

Monitors the debug messages from all configured Virtual Gateways / Virtual Systems.

This is the default.

-e <Expression>

-i <Name of Filter File>

-i -

-u

Specifies the INSPECT filter for the debug:

-e <Expression>

Specifies the INSPECT filter.

See the R82 CLI Reference Guide > Chapter "Security Gateway Commands" > Section "fw" > Section "fw monitor".
-i <Name of Filter File>

Specifies the file that contains the INSPECT filter.
-i -

Specifies that the INSPECT filter arrives from the standard input.

The Security Gateway / Cluster Member / Security Group prompts to enter the INSPECT filter on the screen.
-u

Removes the INSPECT debug filter.

Notes:

These are legacy parameters ("-e" and "-i").
When you use these parameters ("-e" and "-i"), the Security Gateway / Cluster Member / Security Group cannot apply the specified INSPECT filter to the accelerated traffic.
For new debug filters, see Kernel Debug Filters.

-z

The Security Gateway / Cluster Member / Security Group processes some connections in both SecureXL code and in the Host appliance code (for example, Passive Streaming Library (PSL Passive Streaming Library. Packets may arrive at Security Gateway out of order, or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases, a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with the Passive Streaming Library (PSL) technology. (1) The PSL is an infrastructure layer, which provides stream reassembly for TCP connections. (2) The Security Gateway makes sure that TCP data seen by the destination system is the same as seen by code above PSL. (3) The PSL handles packet reordering, congestion, and is responsible for various security aspects of the TCP layer, such as handling payload overlaps, some DoS attacks, and others. (4) The PSL is capable of receiving packets from the Firewall chain and from the SecureXL. (5) The PSL serves as a middleman between the various security applications and the network packets. It provides the applications with a coherent stream of data to work with, free of various network problems or attacks. (6) The PSL infrastructure is wrapped with well-defined APIs called the Unified Streaming APIs, which are used by the applications to register and access streamed data.) - an IPS Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System). infrastructure, which transparently listens to TCP traffic as network packets, and rebuilds the TCP stream out of these packets.).

The Security Gateway / Cluster Member / Security Group processes some connections in only in the Host appliance code.

When you use this parameter, kernel debug output contains the debug messages only from the Host appliance code.

-k

The Security Gateway / Cluster Member / Security Group processes some connections in both kernel space code and in the user space code (for example, Web Intelligence).

The Security Gateway / Cluster Member / Security Group processes some connections only in the kernel space code.

When you use this parameter, kernel debug output contains the debug messages only from the kernel space.

Note - You must use this parameter to collect the SecureXL debug messages in the VSNext / Legacy VSX mode.

-p <List of Fields>

By default, when the Security Gateway / Cluster Member / Security Group prints the debug messages, the messages start with the applicable CPU ID and CoreXL Firewall instance ID.

You can print additional fields in the beginning of each debug message.

Notes:

These fields are available:

all, proc, pid, date, mid, type, freq, topic, time, ticks, tid, text, errno, host, vsid, cpu.
When you specify the applicable fields, separate them with commas and without spaces:

Field1,Field2,...,FieldN
The more fields you specify, the higher the load on the CPU and on the hard disk.

-U

Specifies to merge the debug information from the HyperFlow feature.

This information is available only for the "PSL" debug module.

CLI Parameters for the 'fw ctl ndebug' command (for the new kernel debug)

Note - Only supported parameters are listed.

Parameter

Description

-b <User Space Buffer Size>

Specifies the size of the user space debug buffer.

This buffer size should be at least the size of the maximum kernel debug buffer of 8200.

-p <List of Fields>

By default, when the Security Gateway / Cluster Member / Security Group prints the debug messages, the messages start with the applicable CPU ID and CoreXL Firewall instance ID.

You can print additional fields in the beginning of each debug message.

Notes:

These fields are available:

all, proc, pid, date, mid, type, freq, topic, time, ticks, tid, text, errno, host, vsid, cpu.
When you specify the applicable fields, separate them with commas and without spaces:

Field1,Field2,...,FieldN
The more fields you specify, the higher the load on the CPU and on the hard disk.

-k

The Security Gateway / Cluster Member / Security Group processes some connections in both kernel space code and in the user space code (for example, Web Intelligence).

The Security Gateway / Cluster Member / Security Group processes some connections only in the kernel space code.

When you use this parameter, kernel debug output contains the debug messages only from the kernel space.

Note - You must use this parameter to collect the SecureXL debug messages in the VSNext / Legacy VSX mode.

-T

Prints the time stamp in microseconds in front of each debug message.

Best Practice - Always use this parameter to make the debug analysis easier.

-M

Disables the merge of all temporary debug files at the end of the kernel debug.

This is helpful if you want to analyze an individual dedicated temporary debug file.

Important - Use the "-M" parameter together with the "-w" parameter.

-w

Specifies not to delete the temporary debug files.

-U

Specifies to merge the debug information from the HyperFlow feature.

-c <Number of CoreXL Firewall Instances in Debug Thread>

Specifies the number of CoreXL Firewall Instances in each internal debug thread.

The default is 4.

Best Practice - Do not use this parameter, unless Check Point R&D or Support explicitly asked you to do so.

-I {"<List of CoreXL Firewall Instances>" | all}

Specifies the list of CoreXL Firewall Instances.

-I "<List of CoreXL Firewall Instances>"

Monitors the debug messages only from the specified CoreXL Firewall Instances.

To specify the CoreXL Firewall Instances, enter their ID number separated with commas and without spaces:

"ID1[,ID2,ID3,...,IDn]"

Example: -I "1,3,7"

To see the IDs of CoreXL Firewall Instances, run:

fw ctl multik stat

-I all

Monitors the debug messages from all configured CoreXL Firewall Instances.

This is the default.

-v {"<List of VSIDs>" | all -k}

In the VSNext mode:

Specifies the list of Virtual Gateways.
A VSNext Gateway automatically filters the collected kernel debug information for debug messages only for these Virtual Gateways.

In the Legacy VSX mode:

Specifies the list of Virtual Systems.
A Legacy VSX Gateway automatically filters the collected kernel debug information for debug messages only for these Virtual Systems.

Notes:

This parameter "-v" is supported only in VSNext / Legacy VSX mode.
If you use this parameter "-v", you must also uses the parameter "-k".

Syntax:

-v "<List of VSIDs>"

Monitors the debug messages only from the specified Virtual Gateways / Virtual Systems.

To specify the Virtual Gateways / Virtual Systems, enter their VSID number separated with commas and without spaces:

"VSID1[,VSID2,VSID3,...,VSIDn]"

Example: -v "1,3,7"

To see the IDs of Virtual Gateways / Virtual Systems, run:

In Gaia Clish / Gaia gClish:

show virtual-system all
In the Expert mode:

vsx stat -v

-v all

Monitors the debug messages from all configured Virtual Gateways / Virtual Systems.

This is the default.

Notes:

This parameter "-v" is supported only in VSNext / Legacy VSX mode.
If you use this parameter "-v", you must also uses the parameter "-k".

-o /<Path>/<Name of Output File>

Specifies the path and the name of the debug output file.

Best Practice - Always use the largest partition on the disk - /var/log/. The Security Gateway / Cluster Member / Security Group can generate many debug messages within short time. As a result, the debug output file can grow to large size very fast.

CLI Parameters for the 'fw ctl kdebug' command (for the legacy kernel debug)

Note - Only supported parameters are listed.

Parameter

Description

-b <User Space Buffer Size>

Specifies the size of the user space debug buffer.

This buffer size should be at least the size of the maximum kernel debug buffer of 8200.

-p <List of Fields>

By default, when the Security Gateway / Cluster Member / Security Group prints the debug messages, the messages start with the applicable CPU ID and CoreXL Firewall instance ID.

You can print additional fields in the beginning of each debug message.

Notes:

To see the list of available fields, run:

fw ctl kdebug –h
When you specify the applicable fields, separate them with commas and without spaces:

Field1,Field2,...,FieldN
The more fields you specify, the higher the load on the CPU and on the hard disk.

-k

The Security Gateway / Cluster Member / Security Group processes some connections in both kernel space code and in the user space code (for example, Web Intelligence).

The Security Gateway / Cluster Member / Security Group processes some connections only in the kernel space code.

When you use this parameter, kernel debug output contains the debug messages only from the kernel space.

Note - You must use this parameter to collect the SecureXL debug messages in the VSNext / Legacy VSX mode.

-v {"<List of VSIDs>" | all -k}

In the VSNext mode:

Specifies the list of Virtual Gateways.
A VSNext Gateway automatically filters the collected kernel debug information for debug messages only for these Virtual Gateways.

In the Legacy VSX mode:

Specifies the list of Virtual Systems.
A Legacy VSX Gateway automatically filters the collected kernel debug information for debug messages only for these Virtual Systems.

Notes:

This parameter "-v" is supported only in VSNext / Legacy VSX mode.
If you use this parameter "-v", you must also uses the parameter "-k".

Syntax:

-v "<List of VSIDs>"

Monitors the debug messages only from the specified Virtual Gateways / Virtual Systems.

To specify the Virtual Gateways / Virtual Systems, enter their VSID number separated with commas and without spaces:

"VSID1[,VSID2,VSID3,...,VSIDn]"

Example: -v "1,3,7"

To see the IDs of Virtual Gateways / Virtual Systems, run:

In Gaia Clish / Gaia gClish:

show virtual-system all
In the Expert mode:

vsx stat -v

-v all

Monitors the debug messages from all configured Virtual Gateways / Virtual Systems.

This is the default.

-T

Prints the time stamp in microseconds in front of each debug message.

Best Practice - Always use this parameter to make the debug analysis easier.

-f

Collects the debug data until you stop the kernel debug in one of these ways:

When you press the CTRL+C keys.
When you run the "fw ctl debug 0" command.
When you run the "fw ctl debug -x" command.
When you kill the "fw ctl kdebug" process.

-o /<Path>/<Name of Output File>

Specifies the path and the name of the debug output file.

-o /<Path>/<Name of Output File> -m <Number of Cyclic Files> [-s <Size of Each Cyclic File in KB>]

Note - The feature is supported only in the legacy kernel debug syntax "fw ctl debug -o ...".

Saves the collected debug data into cyclic debug output files.

When the size of the current <Name of Output File> reaches the specified <Size of Each Cyclic File in KB> (more or less), the Security Gateway / Cluster Member / Security Group renames the current <Name of Output File> to <Name of Output File>.0 and creates a new <Name of Output File>.

If the <Name of Output File>.0 already exists, the Security Gateway renames the <Name of Output File>.0 to <Name of Output File>.1, and so on - until the specified limit <Number of Cyclic Files>. When the Security Gateway reaches the <Number of Cyclic Files>, it deletes the oldest files.

The valid values are:

<Number of Cyclic Files> - from 1 to 999
<Size of Each Cyclic File in KB> - from 1 to 2097150