Description
This article describes general advice and configuration steps to save unit CPU and memory resources.
Scope
It is recommended to use the latest patch release available for the release version.
Solution
- Session timer optimizations:
Each traffic flow passing through the FortiGate is associated to a firewall session created and maintained on the unit. The fewer sessions the FortiGate manages, the less CPU resource is used to maintain them. There are different possibilities to reduce the number of concurrent sessions :
- When a traffic flow stops, the associated session would remain in the FortiGate until a timer expires.
This is true for TCP and UDP sessions (different timers are involved).- Reducing the timer will help to get rid of the session earlier.
- TCP stuck sessions in half-opened, half-closed, or even established states can also be released earlier.
- Some protocols such as DNS are more likely to create a lot of sessions because they are based on short transactions.
- In this case, it is recommended to change the timer for this protocol to a suitable but short value.
- 'Global' timers configuration:
config global <- If VDOMs are used.
config system global
set tcp-halfclose-timer 30 <- Default 120s.
set tcp-halfopen-timer 5 <- Default 10 s.
set tcp-timewait-timer 0 <- Default 1s
set udp-idle-timer 60 <- Default 180 s.
end
end <- If VDOMs are used.
- 'Per vdom' timers configuration:
The following timers are vdom based so this configuration should be repeated for each vdom.
config vdom <- If VDOMs are used.
(vdom) # edit <vdom_name>
(<vdom_name>) # config system session-ttl
(session-ttl) # set default 300 <- Default 3600.
(session-ttl) # config port
(port) # edit 0 (*2)
(1) # set protocol 17
(1) # set timeout 10
(1) # set end-port 53
(1) # set start-port 53
# end
(session-ttl) # end
# end <- If VDOMs are used.
(*2): 'edit 0' would pick up the next available index in the table for more convenience. In this example, entry 1 is created.
Note: If needed, other protocols specific timers could be added. It is better to shorten the default timer and increase the timer for specific traffic on a protocol/port based. For instance, you may want your oracle or citrix or telnet or SSH sessions to last longer if no activity is seen.
- Remove dns-udp firewall session helper if not used.
If a significant amount of DNS transactions pass through the FortiGate and FortiGate Virtual IP address DNS translation or DNS server is not used, the dns-udp session helper should be removed to limit kernel resource processing for each DNS traffic.
To do this from the CLI:
config global [ optionally if using vdoms ]
config system session-helper:
- Type 'show' to list all session helper defined and identify the 'edit' reference for the helper named 'dns-udp' :
../..
edit 14
set name dns-udp
set port 53
set protocol 17
next
../..
This is 14 in the following example.
- Delete the dns-udp helper providing its 'edit' reference:
(session-helper) # delete 14
(session-helper) # end
- Disable non-required or 'nice to have' features:
Each feature that is enabled has a resource cost. Disabling ‘nice to have’ features could make a difference.
For example:
- Traffic logging (especially if the logging rate is high).
- HA session synchronization (for instance, web browsing sessions do not need to be synchronized on the secondary unit).
- The Log and Archive Statistic table in GUI Dashboard: To be updated, this table requires the 'content-summary' feature to be enabled, which pushes sessions in the proxies and creates an extra load.
- Use hardware acceleration whenever possible:
Hardware acceleration takes computing cycles off of the FortiGate CPU. It should be used as much as possible.
For example, changing the ports used to maximize accelerated traffic makes a significant difference.
It is important to choose the ports used for traffic in a way that maximizes the ratio of hardware accelerated sessions.
Hardware acceleration can be done to offload traffic processing on interfaces, but also the IPsec encryption/decryption, 802.3ad link aggregation, SSL offload.
Refer to 'Hardware acceleration Technical Note' in this document for more details.
- Avoid use of GUI widgets requiring computing cycles:
Particularly on low end units, some GUI widgets (Dashboard page) involving computing cycles can be removed.
The best example is the 'Top sessions' widget, which requires regular inspection of the full session table, especially if the session table is large.
Verification:
CPU, memory and session resources can monitored through SNMP or CLI commands.
For SNMP, refer to the proprietary MIB file for the version of code being used. This is available at http://support.fortinet.com in the Download Firmware section. First, load the generic MIB file 'FORTINET-CORE-MIB.mib' and the specific 'FORTINET-FORTIGATE-MIB.mib' file for the release.
Examples of useful MIB entries:
- .1.3.6.1.4.1.12356.101.4.1.8.0: Number of active sessions.
- .1.3.6.1.4.1.12356.101.4.1.4.0: Overall memory usage.
- .1.3.6.1.4.1.12356.101.4.1.3.0: Overall CPU usage.
From the new structure using MIBS: FORTINET-CORE-MIB.mib + FORTINET-FORTIGATE-MIB.mib.
- Monitor each CPU load individually:
.1.3.6.1.4.1.12356.101.4.4.2.1.2.<processeur_id> with <processor_id> =1,2,3 or 4
Mib description: 'The processor's CPU usage (percentage), which is an average calculated over the last minute.'
In the CLI, use commands like the following:
diagnose system session stat
get system performance status
diagnose system top
diagnose hardware sysinfo memory
- Schedule updates such as Antivirus, IPS, and firmware updates during off-peak hours.
- Prefer logging on dedicated platforms such as FortiAnalyzer, FortiCloud or syslog servers. Avoid using memory or disk logging.
- Decrease the packet logging on policy or in the sniffer.
Note:
Configure automation stitches to monitor CPU utilization and send alerts or take specific actions, such as restarting a process, when thresholds are exceeded.
