This article describes the log entries and possible fix for the traffic disruptions that may be related to this behavior:
logdesc="Virtual WAN Link volume status" interface="name" msg="The member(1) resume normal status to receive new sessions for internal adjustment."
logdesc="Virtual WAN Link volume status" interface="name" msg="The member(1) enters into conservative status with limited ablity to receive new sessions for too much traffic."
Note: 'ablity' should read 'ability'. Intentionally left as such in this article, to match exact searches
The logs are strictly connected to the SDWAN setup, when SDWAN is configured with 'Volume'-based load-balance method.
With 'Volume' method, the FortiGate distributes the work load based on the amount of packets going through the interfaces.
The FortiGate uses the volume weight that is assigned to each interface to calculate a percentage of the total bandwidth that’s allowed to go through each interface.
The FortiGate then distributes the bandwidth between the interfaces accordingly.
For example, let’s take an SDWAN setup with 2 members (wan1, wan2) and with volume-ratio set to wan1=20 wan2=50 (<100). This translates into:
wan1 = (20 out of 70)% = 28.5%
wan2 = (50 out of 70)% = 71.5%
(Note: the ratio is assigned from 0-255. It is possible to assign any values in this range. Also lower than a total sum of 100%, but this makes it less manageable.
Note the CLI helper:
volume-ratio :: Measured volume ratio (this value / sum of all values = percentage of link volume, 1 - 255)
Assigning low values will trigger the member to reach its capacity a lot sooner, or with very little traffic).
When the traffic load reaches 28.5% on wan1, the log message is recorded and 'the member enters into conservative status'.
This means that no new sessions can be created over wan1 until the traffic volume over this interface is back under the threshold. New sessions can still be created over wan2, if this member is also under the 71.5% threshold.
If an IP-pool is used for NAT (configured for 'any' interface but mapped to wan1), the traffic will likely fail even if the session starts on wan2. For this situation you may need to use dynamic IPpool.
A common change is to use a higher value for the member that is often saturated (for example, instead of values 20/50, use 40/60 = which are actual percentages since their sum is 100).
A better approach of keeping sessions stable and which overcomes this problem is to change the load-balance method of the SDWAN:
# config system virtual-wan-link
set load-balance-mode source-destination-ip (default: source-ip-based)
#config system sdwan
set load-balance-mode source-dest-ip-based (default: source-ip-based)