| Description |
This article explains how users’ experience can be improve on a fluctuating SD-WAN member link. |
| Scope | FortiOS. |
| Solution |
There are two FLAGS in the session table named dirty and may_dirty. Usually, may_dirty is very common, as it means this session is the same since it was first logged in the session table i.e. the routing information has not changed. However, dirty is less common because it means the routing information has changed and the FortiGate needs to perform a re-evaluation of the session. This re-evaluation will lead to it choosing a different exit interface for traffic, which can result in termination of the established session with the server a user or client connects to. The source port used to connect with the server will change during re-evaluation, making the server reset the connection. If this was caused by link fluctuation, it means the SLA moving in and out will be frequent, and will result in a poor and frustrating experience for the users – this is because the routing changes frequently through SD-WAN, which will dirty the session and make FortiGate perform re-evaluation, leading to abrupt termination of the user’s session with the server.
Below is an example setup to demonstrate this:
Client (10.10.10.10) ------FGT(sdwan)------SQL_Server(200.200.200.200)
The SQL server can be reached over 2 ISP links called ISP1 and ISP2. ISP1 is the preferred link, while ISP2 is a lower preference. The SD-WAN rule selected ISP1, and the user has an SQL active connection over ISP1. However, whenever ISP1 moved out of SLA, user connections to the SQL server are terminated, and a new connection is then established over ISP2. Once ISP1 is back in SLA, the connection terminates again, and a new connection is setup with ISP1. This back and forth experience and lack of stable and steady connection to the server is not desirable. The recommended action in this situation is to instruct FortiGate to not re-evaluate sessions if routing information changes occur on an existing session.
The command to do this is as follows:
The default setting is preserve-session-route disable. With this setting, the FortiGate re-evaluates the session and redirects the traffic to the newly chosen interface. With preserve-session-route enable however, the FortiGate will not re-evaluate the session, but the session will remain established through whatever interface it was on before the route change occurred. When this feature is enabled, sessions that match the interface on which it is enabled will have the route_preserve flag.
A user with IP address 10.10.10.10 establishes a session with the SQL server on IP address 200.200.200.200 through TCP port 1433. SD-WAN selected ISP1 as the best route for the connection.
After a while, the ISP1 link falls out of SLA and SD-WAN chooses ISP2 as the new best route to reach the SQL server.
The FortiGate keeps the user’s established session on ISP1. As such, the user is not aware of the route change on the FortiGate.
After the client (10.10.10.10) and the server (200.200.200.200) ended the session, FortiGate started establishing sessions to the server over an ISP2 link.
|
