Print Download PDF Send Feedback

Previous

Next

Special Scenarios and Configurations

In This Section:

Default Number of Active RX Queues

Changing the Status of an Interface with Enabled Multi-Queue

Adding a Network Interface

Changing the Affinity of CoreXL Firewall instances

Processing Packets that Arrive in the Wrong Order on an Interface that Works in Monitor Mode

Default Number of Active RX Queues

In Gateway mode - Changing the number of CoreXL Firewall instances when the Multi-Queue is enabled on some, or all interfaces

For best performance, the Multi-Queue calculates the default number of active RX queues based on this formula:

Number of active RX queues = (Number of CPU cores) - (Number of CoreXL Firewall instances)

This configuration is set automatically when you configure the Multi-Queue. When you change the number of CoreXL Firewall instances, the number of active RX queues changes automatically, if it is not set manually.

In VSX mode - Changing the number of CPU cores, to which the FWK processes are assigned

For best performance, the Multi-Queue calculates the default number of active RX queues based on this formula:

Number of active RX queues = The lowest CPU ID, to which an FWK process is assigned

For example:

[Expert@GW:0]# fw ctl affinity -l

Mgmt: CPU 0

eth1-05: CPU 0

eth1-06: CPU 1

VS_0 fwk: CPU 2 3 4 5

VS_1 fwk: CPU 2 3 4 5

[Expert@GW:0]#

In the example above:

Changing the Status of an Interface with Enabled Multi-Queue

Scenario

Instructions

To change the status of an interface to DOWN

The Multi-Queue saves the configuration when you change the status of an interface to down.

Since the number of interfaces with Multi-Queue enabled is limited to five, you may need to disable the Multi-Queue on an interface after you change its status to down. This is needed to enable the Multi-Queue on other interfaces.

To disable Multi-Queue on non-active interfaces

Follow these steps:

  1. Activate an interface.
  2. Run the cpmq set command and disable the Multi-Queue on that interface.
  3. Deactivate the interface.

To change the status of an interface to UP

You must reset the IRQ affinity for the Multi-Queue interfaces if, in this order, you:

  1. Enabled Multi-Queue on the interface.
  2. Changed the status of the interface to down.
  3. Rebooted the Security Gateway.
  4. Changed the interface status to up.

This problem does not occur if SecureXL Affinity is set to Automatic mode (sim affinity -a).

To set the static Multi-Queue affinity of interfaces again, run:

cpmq set affinity

Note - To change the state of an interface, see the R80.20 Gaia Administration Guide.

Adding a Network Interface

When you add a network interface card to a Security Gateway, the Multi-Queue configuration can change due to the way the operating system indexes the interfaces.

If you added a network interface card to a Security Gateway, make sure to run the Multi-Queue configuration again, or run:

cpmq reconfigure

If a reconfiguration change is required, the Multi-Queue prompts you to reboot the Security Gateway.

Changing the Affinity of CoreXL Firewall instances

For best performance, we recommend that you do not assign both CoreXL SND instance and a CoreXL Firewall instance to the same CPU core.

When you change the affinity of CoreXL Firewall instances to CPU cores that are assigned with one of the Multi-Queue queues, we recommend that you configure the number of active RX queues again based on this formula:

Active RX queues = The lowest CPU number, to which a CoreXL Firewall instance is assigned

You can configure the number of active RX queues with this command:

cpmq set rx_num {igb | ixgbe} {default | <value>}

Processing Packets that Arrive in the Wrong Order on an Interface that Works in Monitor Mode

Best Practice - If you enable Multi-Queue on an interface that works in Monitor Mode, then enable the Symmetric Hash for Receive-Side Scaling (RSS). This lets the corresponding interface drivers handle better packets that arrive in the wrong order (for example, TCP "SYN-ACK" that arrives before the TCP "SYN"). As a result, the same CPU core handles the applicable Client-to-Server and Server-to-Client packets.

Follow the instructions in sk101670 to download and run the special shell script asym2sym.sh on the Security Gateway or Cluster Members.