Table of Contents:

1. Introduction
2. Firewall Priority Queues and Evaluation of Heavy Connections
   1. Firewall Priority Queues
   2. Evaluation of Heavy Connections
3. Configuration
4. Monitoring
   1. Priority Queues
   2. Evaluation of Heavy Connections
5. Limitations
6. Related solutions

(I) Introduction

Packets could be dropped by Firewall when CPU cores, on which Firewall runs, are fully utilized. Such packet loss might occur regardless of the connection's type (for example, local SSH or connection to Security Management Server server).

To help mitigate the above issue, R77.30 introduces Firewall Priority Queues feature.

(II) Firewall Priority Queues and Evaluation of Heavy Connections

Note: The Firewall Priority Queues and Evaluation of Heavy Connections are disabled by default.

• (II-A) Firewall Priority Queues

  Priority Queues (PrioQ) mechanism is intended to prioritize part of the traffic when we need to drop packets because the Security Gateway is stressed (CPU is fully utilized).

  In R77.20 and lower versions, when the CPU became fully utilized, part of the traffic was dropped regardless of the traffic type. As a result, control connections (described below) were dropped, which had serious negative impact (e.g., no SSH connectivity). In addition, several "heavy" connections could cause high CPU load on Security Gateway and cause issues for all other connections.

  R77.30 handles both aforementioned cases in the following ways:

  • Prioritizing control connections over data connections.
  • Each connection of the same priority will get equal share of CPU resources.

  R77.30 is "protecting" the CPU cores, on which Firewall is running.

  It is important to notice the differences between R77.30 Firewall Priority Queues (PrioQ) and QoS Software Blade.
  Both are prioritizing traffic. However, with the following differences:

  	R77.30 Firewall Priority Queues (PrioQ)	QoS Software Blade
  What is mitigated?	CPU load	Network downstream load
  When it is active on Security Gateway?	Only in extreme conditions (CPU is overload)	Always (from the moment the blade is enabled and policy installed)
  Is the configuration predefined or depends on policy?	Predefined	Policy driven

   

  • Explanation about Control Connections

    R77.30 Firewall assigns higher priority to control connections than to other connections.

    By default, the following services are considered by R77.30 Firewall as control connections:

    • Check Point CPMI
    • Policy installation/fetch (CPD daemon)
    • Check Point Remote Installation (CPRID daemon)
    • SSH
    • DHCP
    • OSPF
    • BGP
    • VRRP

    Not all control services get the same priority. R77.30 Firewall prioritizes some control services over the other control services.

  • Explanation about Priority Queues

    By default, there are 8 priority queues (up to 16 by manual configuration).

    Queue Priority (0=highest)	Queue Name	Type of connections	Can connections migrate?	Limited Queue Length (default=512)
    0	Routing	DHCP, VRRP, OSPF, BGP, IGMP, PIM, ...	No	Yes
    1	Control	GUI / SSH / ports 18xxx / Mgmt services (see sk52421)	Yes	Yes
    2	Cluster sync	Local / Full sync	No	Yes
    3	High priority	User defined	Yes	Yes
    4	Light Data Queue	Light connections	Yes	Yes
    5	Default Data Queue	Medium weight connection, or New connection	Yes	Yes
    6	Log notif	Log and Drop notifications	No	Yes
    7	Heavy Data Queue	Heavy connections	Yes	Yes

    The priority queues are active when the Firewall consumes 100% of CPU. When a packet of a new connection arrives, the connection is classified in order to know to which queue it is supposed to go. For example, packets of a new data connection will go to the default data queue.

    Initially, each connection is assigned to a queue by the connection type: Routing, Control, Data, etc. Nevertheless, for some connection types, the connection might migrate to a different queue. We know what is the load of each connection all the time, so the connections can migrate between the queues, and by doing so get lower/higher priority with respect to other connections.

    For example, a data connection begins its life in the Default Data Queue (Queue #5) and if this connection become heavier, it will migrate to a lower priority queue (Heavy Data Queue - Queue #7). Same goes in vice versa, if a connection become lighter, it will migrate to a higher priority queue (e.g., Light Data Queue - Queue #4).

    To decide whether a connection should migrate or not, Firewall keeps all the time the load of average connection. For each connection (by its type), Firewall knows to how many possible queues the connection was assigned and what is the CPU load caused by this connection. Based on that information, Firewall matches any weight to a queue, so that the average connection will belong to the median queue (out of all possible queues for the connection type) and each queue has an equal share of weights.
  
  
  

• (II-B) Evaluation of Heavy Connections

  This feature allows the administrator to monitor the Heavy Connections (that consume the most CPU resources) without interrupting the normal operation of Firewall.

  After enabling this feature (refer to "Configuration" section), the relevant information is available in CPView Utility (refer to "Monitoring - Evaluation of Heavy Connections" section).

(III) Configuration

Firewall Priority Queues are disabled by default.

Important Notes:

• Before enabling these features, refer to "Limitations" section.

• In R77.30, these three modes are the only officially supported modes (other modes are not supported, and therefore are not mentioned):

  Mode Number	Mode Name	Explanation
  0	Off	Default. Firewall Priority Queues and Evaluation of Heavy Connections are completely disabled.
  1	CPU Connections Statistics	Firewall Priority Queues feature is disabled, but monitoring of Heavy Connections (that consume the most CPU resources) is enabled in CPView Utility.
  9	On	Firewall Priority Queues feature is fully enabled. Note: This mode also fully enables the CoreXL Dynamic Dispatcher (refer to sk105261).

Instructions:

• To check the current mode on Security Gateway:

  [Expert@HostName]# fw ctl multik get_mode

• To fully enable the Firewall Priority Queues on Security Gateway:

  Note: In cluster environment, this procedure must be performed on all members of the cluster.

  1. Run in Expert mode:

     [Expert@HostName]# fw ctl multik set_mode 9

  2. Reboot (in cluster, this might cause fail-over).

• To enable the monitoring of Heavy Connections (that consume more than 10% of the CPU resources) in CPView Utility on Security Gateway:

  Note: In cluster environment, this procedure does not have to be performed on all members of the cluster because it enables monitoring only.

  1. Run in Expert mode:

     [Expert@HostName]# fw ctl multik set_mode 1

  2. Reboot (in cluster, this might cause fail-over).

• To completely disable the Firewall Priority Queues on Security Gateway:

  Note: In cluster environment, this procedure must be performed on all members of the cluster.

  1. Run in Expert mode:

     [Expert@HostName]# fw ctl multik set_mode 0

  2. Reboot (in cluster, this might cause fail-over).

(IV) Monitoring

Administrator can monitor the Firewall Priority Queues and Evaluation of Heavy Connections in the following ways.

• (IV-A) Monitoring - Firewall Priority Queues

  Administrator can monitor the Firewall Priority Queues in the following ways:

  Note: Firewall Priority Queues on Security Gateway must already be enabled with fw ctl multik set_mode 9 command and Security Gateway must already be rebooted.

  1. Use the sk101878 - CPView Utility.

     • Go to Advanced -> PrioQ -> Overview

       Provides general PrioQ information (cross instances)

       Example:

       

     • Go to Advanced -> PrioQ -> Instances

       Provides general information about the priority queues and information per instance including the priority queues of the specific instance.

       Note: When CPU cores are not fully utilized, all values on this screen will be 0 (zero).

       Example:

       

     • Go to I/S -> CPU -> Top-Connections

       Displays top 10-30 (configurable) connections that consume the most CPU resources (Heavy Connections).

       Example:

       

  2. Use SmartLog (supported only for Dynamic PrioQ).

     A log is issued for every Heavy Connection (that consumes more than 10% of the CPU resources) that such connection was detected and its priority is decreased.

     Example:

     

• (IV-B) Monitoring - Evaluation of Heavy Connections

  Administrator can monitor the Evaluation of Heavy Connections in the following way:

  1. Set the mode of the Firewall Priority Queues on Security Gateway to "1" (CPU Connections Statistics):

     Note: In cluster environment, this procedure does not have to be performed on all members of the cluster because it enables monitoring only.

     1. Run in Expert mode:

        [Expert@HostName]# fw ctl multik set_mode 1

     2. Reboot (in cluster, this might cause fail-over).

  2. Run the sk101878 - CPView Utility:

     [Expert@HostName]# cpview

  3. Go to I/S -> CPU -> Top-Connections.

     This screen displays top 10-30 (configurable) connections that consume the most CPU resources.

     Example:

     

(V) Limitations

1. The Firewall Priority Queues can not be enabled in the following scenarios:

   • Security Gateway is configured in VSX mode
   • SAM acceleration card is installed on the appliance
   • Carrier Grade NAT (CGN) is configured
   • Security Gateway is configured in Monitor Mode (per sk101670)
   • 6in4 tunnel (SIT interface) is configured
   • Some lines in the $FWDIR/boot/modules/fwkern.conf file are commented out (refer to sk106309).

2. When SecureXL and a CoreXL FW instance are running on same CPU core, Priority Queues and Top Connections may not function as expected.

   Such configuration is the default on 2200 appliance and on 4600 appliance.

   To resolve this, disable the synchronous dequeue feature in CoreXL by permanently setting the value of kernel parameter fwmultik_sync_processing_enabled to 0 (zero).

   • To check the current value of this kernel parameter:

     [Expert@HostName]# fw ctl get int fwmultik_sync_processing_enabled

   • To set the desired value for this kernel parameter permanently (per sk26202):

     1. Create the $FWDIR/boot/modules/fwkern.conf file (if it does not already exit):

        [Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf

     2. Edit the $FWDIR/boot/modules/fwkern.conf file in Vi editor:

        [Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf

     3. Add the following line (spaces are not allowed):

        fwmultik_sync_processing_enabled=0

     4. Save the changes and exit from Vi editor.

     5. Check the contents of the $FWDIR/boot/modules/fwkern.conf file:

        [Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf

     6. Reboot the Security Gateway.

(VI) Related solutions

• sk101878 - CPView Utility
• sk105261 - CoreXL Dynamic Dispatcher in R77.30
• sk52421 - Ports used by Check Point software
• sk98348 - Best Practices - Security Gateway Performance

Give us Feedback	Please rate this document Rating submitted [1=Worst,5=Best] Your rating was not submitted, please try again later
	Comment  Please Enter the words displayed in the image below: Please Enter the numbers you hear:   Submit Cancel Submitting rating Thank you for your feedback!