System and feature operation with WAN optimization
This section contains the following information:
HA
You can configure WAN optimization on a FortiGate HA cluster. The recommended best practice HA configuration for WAN optimization is active-passive mode. When the cluster is operating, all WAN optimization sessions are processed by the primary unit only. Even if the cluster is operating in active-active mode, HA does not load-balance WAN optimization sessions.
You can also form a WAN optimization tunnel between a cluster and a standalone FortiGate unit or between two clusters.
In a cluster, only the primary unit stores the byte cache database. This database is not synchronized to the subordinate units. So, after a failover, the new primary unit must rebuild its byte cache. Rebuilding the byte cache can happen relatively quickly because the new primary unit gets byte cache data from the other FortiGate unit that it is participating with in WAN optimization tunnels.
Memory usage
To accelerate and optimize disk access and to provide better throughput and less latency, FortiOS WAN optimization uses provisioned memory to reduce disk I/O and increase disk I/O efficiency. In addition, WAN optimization requires a small amount of additional memory per session for comprehensive flow control logic and efficient traffic forwarding.
When WAN optimization is enabled you will see a reduction in available memory. The reduction increases when more WAN optimization sessions are being processed. If you are thinking of enabling WAN optimization on an operating FortiGate unit, make sure its memory usage is not maxed out during high traffic periods.
In addition to using the system dashboard to see the current memory usage you can use the get test wad 2 command to see how much memory is currently being used by WAN optimization.
Distributing WAN optimization processing
The wad-worker balancing algorithm supports a more balanced dispersal of traffic to the wad processes even if the bulk of the traffic is coming from a small set of sources or single source.
By default, dispatching traffic to WAD workers is based on source affinity. This may negatively affect performance when users have another explicit proxy in front of the FortiGate. Source affinity causes the FortiGate to process the traffic as if it originated from the single (or small set of ) IP address of the outside proxy. This results in the use of one, or a small number, of WAD processes.
By disabling wad-source-affinity the traffic is balanced over all of the WAD processes. The WAD dispatcher will not assign the traffic based on the source IP address, but will assign the traffic to available workers in a round-robin fashion.
To configure WAD source affinity:
config system global
set wad-source-affinity {enable | disable}
end
|
Handling the traffic by different WAD workers results in losing cached related benefits of using source affinity, as there is the memory cache on the current wad worker and if a new connection is handled by another worker, the cache will not be hit. This is explained by the warning message that appears when it is disabled: WARNING: Disabling this option results in some features to be unsupported. IP-based user authentication, disclaimer messages, security profile override, authentication cookies, MAPI scanning, and some video caches such as YouTube are not supported. Do you want to continue? (y/n) |
Distributing WAN optimization to multiple CPU cores
By default WAN optimization is handled by half of the CPU cores in a FortiGate unit. For example, if your FortiGate unit has 4 CPU cores, by default two will be used for WAN optimization. You can use the following command to change the number of CPU cores that are used.
config system global
set wad-worker-count <number>
end
The wad-worker-count can be between 1 and the total number of CPU cores in your FortiGate unit. Adding more cores may enhance WAN optimization but reduce the performance of other FortiGate systems.
Identity policies and load balancing
WAN optimization and firewall policies compatibility varies depending on the type of policy:
-
WAN optimization is not compatible with firewall load balancing.
-
WAN optimization is compatible with source and destination NAT options in firewall policies (including firewall virtual IPs). If a virtual IP is added to a policy, the traffic that exits the WAN optimization tunnel has its destination address changed to the virtual IP mapped to IP address and port.
-
WAN optimization is compatible with user identity-based and device identity security policies. If a session is allowed after authentication or device identification the session can be optimized.
Traffic shaping
Traffic shaping works for WAN optimization traffic that is not in a WAN optimization tunnel. So traffic accepted by a WAN optimization policy on a client-side FortiGate unit can be shaped on ingress. However, when the traffic enters the WAN optimization tunnel, traffic shaping is not applied.
In manual mode:
-
Traffic shaping works as expected on the client-side FortiGate unit.
-
Traffic shaping cannot be applied to traffic on the server-side FortiGate unit.
In active-passive mode:
-
Traffic shaping works as expected on the client-side FortiGate unit.
-
If transparent mode is enabled in the WAN optimization profile, traffic shaping also works as expected on the server-side FortiGate unit.
-
If transparent mode is not enabled, traffic shaping works partially on the server-side FortiGate unit.