Allocating a CPU Core for Heavy Logging

If the Security GatewayClosed Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. generates very large number of logs, it may be advisable to allocate a processing CPU core to the fwd daemon, which generates the logs.

Note - This change decreases the number of CPU cores available for CoreXLClosed 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.

Important Notes for Cluster:

To allocate a processing CPU core to the fwd daemon:

See Configuring Affinity Settings.

Step

Instructions

1

Connect to the command line on the Security Gateway (each Cluster Member).

Note - On Scalable Platforms (Maestro and Chassis), you must connect to the applicable Security GroupClosed 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..

2

Log in to the Expert mode.

3

Run:

cpconfig

4

Enter the number of the Check Point CoreXL option.

5

Decrease the number of CoreXL Firewall instances.

See Configuring IPv4 and IPv6 CoreXL Firewall instances.

6

Exit from the cpconfig menu.

7

Examine which processing CPU cores run the CoreXL Firewall instances and which CPU cores handle the traffic from interfaces.

  • On the Security Gateway (each Cluster Member), run:

    fw ctl affinity -l -r

  • On the Scalable Platform Security Group, run:

    g_fw ctl affinity -l -r

See fw ctl affinity.

8

Back up the $FWDIR/conf/fwaffinity.conf file.

  • On the Security Gateway (each Cluster Member), run:

    cp -v $FWDIR/conf/fwaffinity.conf{,_BKP}

  • On the Scalable Platform Security Group, run:

    g_cp -v $FWDIR/conf/fwaffinity.conf{,_BKP}

9

Edit the $FWDIR/conf/fwaffinity.conf file.

The same syntax applies to the Security Gateway (each Cluster Member) and the Scalable Platform Security Group:

vi $FWDIR/conf/fwaffinity.conf

10

Allocate one of the remaining CPU cores to the fwd daemon.

To do so, configure the affinityClosed The assignment of a specified CoreXL Firewall instance, VSX Virtual System, interface, user space process, or IRQ to one or more specified CPU cores. of the fwd daemon to that CPU core.

n fwd <CPU ID>

For example, to affine the fwd daemon to CPU core #2, add this line:

n fwd 2

Note - It is important to avoid the CPU cores that run the CoreXL SND instances only if these CPU cores are explicitly defined for the affinities for interfaces. If affinity of interfaces is configured in the Automatic mode, the fwd daemon can use all CPU cores that do not run CoreXL Firewall instances. Traffic from interfaces is automatically diverted to other CPU cores.

11

Save the changes in the file and exit the editor.

12

On the Scalable Platform Security Group, copy the $FWDIR/conf/fwaffinity.conf configuration file to all other Security Group MembersClosed Member of a Security Group in ElasticXL Cluster, Maestro, and Scalable Chassis. Acronym: SGM.:

asg_cp2blades $FWDIR/conf/fwaffinity.conf

13

Load the new configuration.

  • To load it immediately:

    • On the Security Gateway (each Cluster Member), run:

      $FWDIR/scripts/fwaffinity_apply

    • On the Scalable Platform Security Group, run:

      g_all $FWDIR/scripts/fwaffinity_apply

  • To load it later, reboot.

    • On the Security Gateway (each Cluster Member), run:

      reboot

    • On the Scalable Platform Security Group, run:

      g_reboot -a