Bonding - Load Sharing Mode

In This Section Bond Failover in Load Sharing Mode Creating an Interface Bond in Load Sharing Mode Setting Critical Required Interfaces Verifying that the Bond is Functioning Properly

In Bonding Load Sharing mode:

• All slave interfaces are active, and connections are balanced between the bond slave interfaces, similar to the way ClusterXL Load Sharing balances connections between Cluster Members.
• Each connection is assigned to a specific slave interface. For the individual connection, only one slave interface is active. On failure of that interface, the bond fails over the connection to one of the other slave interfaces, which adds the failed interface connection to the connections it is already handling.
• All the slave interfaces of a bond must be connected to the same switch. The switch itself must support and be configured for Bonding, by the same standard (for example, 802.3ad, or XOR) as the Security Gateway bond.

Note - Bonding Load Sharing mode requires SecureXL to be enabled on each Cluster Member.

Bond Failover in Load Sharing Mode

In Bonding Load Sharing mode, when the Security Gateway is part of a cluster, bond internal failover can occur in one of these cases:

• An active interface detects a failure in the link state, in a monitored interface.
• ClusterXL detects a failure in sending or receiving Cluster Control Protocol (CCP) keep-alive packets.

Either of these failures will induce a failover within the interface bond, or between Cluster Members, depending on the circumstances.

When a failure is detected, a log is recorded. You can see it in SmartConsole > Logs & Monitor > Logs.

Creating an Interface Bond in Load Sharing Mode

Follow the instructions in the R80.30 Gaia Administration Guide - Chapter Network Management - Section Network Interfaces - Section Bond Interfaces (Link Aggregation).

Setting Critical Required Interfaces

Note - The Critical Required Interfaces feature is supported for ClusterXL only.

A bond in Load Sharing mode is considered to be down when fewer than a critical minimal number of slave interfaces remain up. When not explicitly defined, the critical minimal number of slave interfaces, which must remain up, in a bond of n interfaces is n-1. Failure of an additional slave interface (when n-2 slave interfaces remain up) will cause the entire bond interface to be considered down, even if the bond contains more than two slave interfaces.

If a smaller number of slave interfaces will be able to handle the expected traffic, you can increase redundancy by explicitly defining the critical minimal number of slave interfaces. Divide your maximal expected traffic speed by the speed of your slave interfaces and round up to a whole number to determine an appropriate number of critical slave interfaces.

To define the critical number of slave interfaces explicitly, create and edit the following file:

$FWDIR/conf/cpha_bond_ls_config.conf

Each line of the file should be written in the following syntax:

<Name_of_Bond> <critical_minimal number_of_slave>

For example, if bond0 has 7 slave interfaces, and bond1 has 6 slave interfaces, file contents could be:

bond0 5

bond1 3

In this example:

• bond0 would be considered down when 3 of its slave interfaces have failed.
• bond1 would be considered down when 4 of its slave interfaces have failed.

Verifying that the Bond is Functioning Properly

Verify that the bond interface is UP, by displaying the bond information.

1. Run this command:
   • In Gaia Clish:

     show cluster members interfaces all

   • In Expert mode:

     cphaprob -am if

   Make sure that the bond status is reported as UP.

2. Run this command:
   • In Gaia Clish:

     show cluster bond {all | name <Name of Bond>}

   • In Expert mode:

     cphaprob show_bond <Name of Bond>

   Check that the bond is correctly configured.