Description
This article describes 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 an 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, when enabling 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 an Auxiliary session (reflect session) and allow the asymmetric traffic to be offloaded to hardware. If not enable,d auxiliary sessions on FGT-1, FGT-1 use 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 output below 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, dev=7->5/5->7). After that, FortiGate received a reply packet on port2, which triggered the creation of an auxiliary/reflect session (dev=7->6/6->7), which is attached to the same session.
Note that an auxiliary session is not a separate session. It is an extension of the main session used for asymmetric traffic.
It is showing interface index numbers 7 and 6, both sessions are offloaded to hardware, which results in higher performance.
Use the 'auxiliary-session" with caution.
In case there are multiple available paths to a specific destination, used in SD-WAN, the following need to be considered:
Reply traffic after FortiOS v7.0.1 onwards:
With Auxiliary Sessions enabled (default=disabled), reply traffic does a policy-route lookup, SD-WAN rule match, and then route-table. Firstly, the SD-WAN rule lookup conditions will be satisfied. Auxiliary-session will then trigger every packet to be re-routed via the best path that a member on that rule offers. As explained above, asymmetric routing will occur. It needs to be considered that the reply traffic may be SNAT-ed via specific member/s (usually when having multiple default-routes), which may cause packet drops in specific environments.
ADVPN deployments:
When enabling auxiliary sessions, consider the impact of routing in both traffic directions. In topologies such as SD-WAN hub and spoke or ADVPN deployments, the symmetry of the return traffic is important for maintaining the stability of the session. It is expected that the spoke selects the outbound interface and path, and the other nodes obey and reply symmetrically. It is recommended to disable auxiliary in these scenarios, and others where incoming and return traffic symmetry is expected.
