Configuring Affinities for Interfaces

The association of a specific interface with a specific processing CPU core is called the interface's affinity with that CPU core. This affinity The assignment of a specified CoreXL Firewall instance, VSX Virtual System, interface, user space process, or IRQ to one or more specified CPU cores. causes the interface's traffic to be directed to that CPU core and the 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. SND to run on that CPU core.

Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. loads (Scalable Platform 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. Members load) affinities for interfaces during the boot from the CoreXL configuration file $FWDIR/conf/fwaffinity.conf. In this configuration file, lines that begin with the letter "i", define the affinities for interfaces.

Workflow:

Step

Instructions

Check which processing CPU cores run the CoreXL Firewall instances and which CPU cores handle the traffic from interfaces:

On a Security Gateway (each Cluster Member Security Gateway that is part of a cluster.), run in 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). or the Expert mode:

fw ctl affinity -l -r

On a Scalable Platform Security Group, run in 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.:

fw ctl affinity -l -r

On a Scalable Platform Security Group, run in the Expert mode:

g_fw ctl affinity -l -r

See fw ctl affinity.

Allocate the remaining CPU cores to run the CoreXL SND instances.

To do so, configure the affinity of interfaces to the applicable CPU cores.

For more information, see Allocation of Processing CPU Cores.

Notes:

To set the affinity of VLAN interfaces, use their physical interfaces.
If you allocate more than one processing CPU core to the CoreXL SND, it is necessary to configure affinities for interfaces explicitly to the remaining CPU cores. If you have multiple interfaces, decide which interfaces to affine to which CPU cores. Try to achieve a balance of expected traffic between the CPU cores. Examine the traffic balance with the top command.

Configuring affinities for interfaces explicitly:

Step

Instructions

Connect to the command line on the Security Gateway (each Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Member / Scalable Platform Security Group).

Configure the affinity of each interface in the $FWDIR/conf/fwaffinity.conf file.

See Configuring Affinity Settings.

For each interface, there must be a separate line that begins with the letter "i".

Each of these lines must have this syntax:

i <Name of Interface> <CPU ID>

For example, if it is necessary that the traffic from eth0 and eth1 (eth1-05 and eth1-07) goes to CPU core #0, and the traffic from eth2 (eth1-09) goes to CPU core #1, add these lines:

On the Security Gateway (each Cluster Member):

i eth0 0

i eth1 0

i eth2 1

On the Scalable Platform Security Group:

i eth1-05 0

i eth1-07 0

i eth1-09 1

Alternatively, you can choose to configure affinities for interface explicitly for only one processing CPU core, and define other CPU cores as the default affinity of the remaining interfaces.

i default <CPU ID>

For example, if it is necessary that the traffic from eth2 (eth1-05) goes to CPU core #1, and the traffic from all other interfaces goes to CPU core #0, add these lines:

On the Security Gateway (each Cluster Member):

i eth2 1

i default 0

On the Scalable Platform Security Group:

i eth1-05 1

i default 0

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

Best Practice - If you allocate only one CPU core to the CoreXL SND, it is best to have that CPU core selected automatically. To do so, leave the default automatic interface affinity and do not configure explicit affinities for interfaces to CPU cores.

Make sure the $FWDIR/conf/fwaffinity.conf file contains this line:

i default auto

Make sure that the $FWDIR/conf/fwaffinity.conf file does not contain other lines that begin with "i", so that there are no explicit affinities for interfaces configured. This makes sure that Security Gateway directs (Scalable Platform Security Group Members direct) all traffic to the remaining CPU cores.

Best Practice - In addition, see Multi-Queue.