Traffic Flow Aggregation

For services that must have consistent forward and return paths, when the actual traffic flow forward and return paths are inconsistent, flow aggregation can be implemented in the cluster to aggregate traffic flows to the same device for processing.

For TCP proxy, SSL proxy, mail proxy, and content security services, the forward and reverse paths must be consistent. Otherwise, the services may be interrupted. When using these functions in the cluster, you can use the following methods to ensure consistent forward and return paths:

(Recommended) Deploy proper networking.
Enable the cluster traffic aggregation function.

Enabling the traffic aggregation function affects device performance. Therefore, ensure that the forward and return paths of traffic are consistent and the traffic aggregation function is disabled.

Traffic Flow Aggregation (General Mechanism)

Figure 1 shows the general mechanism for traffic flow aggregation.

Figure 1 Schematic diagram for general traffic flow aggregation

In the following example, the Client establishes a TCP connection with the Server for the first time.

The Client sends a TCP packet to the Server.
FW_1 receives traffic (does not know whether it is the first packet) and notices that the traffic must be aggregated. It performs the hash algorithm based on the packet's source/destination IP address to identify the Director of the flow (FW_2 in this example) and forwards the traffic to the Director.
The Director checks whether it has a session for this packet and finds that it is the first packet. It identifies the data flow as the first packet and sends it back to FW_1. If the Director has a session for the packet, it will directly forward the packet to the Owner for processing.
FW_1 creates a session, marks itself as the Owner, and forwards the TCP flow to the Server.
FW_1 backs up the session to all other members in the cluster.
The return traffic arrives at FW_3. The forward and return paths are inconsistent.
If the session is not backed up to FW_3 before FW_3 receives the traffic (does not know whether it is the first packet) and notices that the traffic must be aggregated. It performs the hash algorithm based on the packet's source/destination IP address to identify the Director of the flow (the hash result should be consistent with that on FW_1) and forwards the traffic to the Director.
The Director forwards the packet to the Owner.
The Owner replies to the Client.

If the return traffic arrives at FW_3 after FW_3 receives session backup information from the Owner, FW_3 will find the Owner based on session information and forwards the return traffic to the Owner.