Description
This article explains the effect of the auxiliary sessions option on SD-WAN deployments and the problems it resolves.
Scope
FortiGate setups in SD-WAN Deployments.
Solution
Consider the scenario below with 2 FortiGates (FGT-1/FGT-2) which are connected by 2 SD-WAN members port1/port2.
PC1 behind FGT-1 sends traffic which is routed by FGT-1 using port1, traffic is received by FGT-2 using port1, but then SLA change happens at FGT-2 and port2 is now the preferred port for return traffic.
By default, when performing route lookups for reply direction, FortiGate considers only routes through the same ingress interface used in the original direction.
This is done to preserve session symmetry, however, this also prevents reply traffic from switching to a better-performing member which can impact sensitive applications such as voice and video.
Now if you enable Auxiliary Sessions on both FGT-1/FGT-2, 2 issues can be resolved:
- FGT-2 can route back the reply traffic using port2 which is the best-performing member.
- FGT-1 will create Auxiliary session (reflect session) and allows the asymmetric traffic to be offloaded to hardware, if you do not enable auxiliary sessions on FGT-1, FGT-1 uses the system CPU to handle asymmetric traffic.
The Auxiliary sessions option is configured per VDOM, it is possible to enable using the command below:
Note : Auxiliary Sessions are disabled by default.
# config system settings
set auxiliary-session enable
end
The below output shows how the auxiliary session looks on FGT-1:
The session was established initially symmetrically from port3 to port1 (interface index numbers 7 and 5) after that FortiGate received a reply packet on port2, this triggered creation of an auxiliary/reflect session which is attached to the same session.
It is showing interface index numbers 7 and 6, both sessions are offloaded to hardware which results in higher performance.
