Purpose
The purpose of this note is to provide advice and configuration steps to save unit CPU and memory resources.
Expectations, Requirements
It is recommended to use the latest patch release available for the release version (4.0 MR1, 4.0 MR2)
Some features, such as defining a session-ttl lower than 300s are not available on early patches.
Configuration
1. Session timer optimizations
Each traffic flow passing through the FortiGate is associated to a firewall session created and maintained on the unit. The less 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 would help to get rid of the session earlier - TCP stuck sessions in half-opened, half-closed or even established state 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 120 s ]
set tcp-halfopen-timer 30 [ default 60 s ]
set tcp-timewait-timer 0 [ default 120 s ] (*1)
set udp-idle-timer 60 [ default 120 s ]
end
end [ if vdoms are used ]
config system global
set tcp-halfclose-timer 30 [ default 120 s ]
set tcp-halfopen-timer 30 [ default 60 s ]
set tcp-timewait-timer 0 [ default 120 s ] (*1)
set udp-idle-timer 60 [ default 120 s ]
end
end [ if vdoms are used ]
(*1): A delay of 10 seconds is added on top of the value configured in 'tcp-timewait-timer', therefore a configuration of '0 second', would keep the session for 10 seconds after it is fully close. This is sufficient.
- '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 pickup 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.
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 pickup 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.
2. Remove dns-udp firewall session helper if not used.
If a significant amount of DNS transactions pass through the FortiGate and FortiGate Virtual IP 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 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
3. Do not enable non-required or 'nice to have' only features
Each feature that is enabled has its cost on the resources. Disabling nice to have features could make a difference.
Example of features :
- traffic logging (specially if the logging rate is high)
- ha session synchronization (for instance web browsing sessions do not have a requirement to be synchronized on the slave)
- Log and Archive Statistic table in GUI Dashboard : To be updated, this table requires 'content-summary' feature enabled which pushes sessions in the proxies creating extra load.
To disable on 4.1 releases:
Unset "Display DLP meta-information on the system dashboard" from the protection profiles that are in use.
Note: The default configuration is to have all protocols enabled.
To disable on 4.2 releases : do not activate in policies 'DLP Sensor' with 'content-summary'
4. Use hardware acceleration whenever possible
Hardware acceleration takes computing cycles off 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 (thanks to FA2, NP2, NP4 or Accelar ports) but also IPSec encryption/decryption, 802.3ad link aggregation, SSL offload...
For IPSec (IKE encryption/decryption) there are different configuration options to consider.
For example, AES-256 encryption is not supported on NP2 chips.
The setting of the 'ipsec local gateway' ip address and anti-replay options is important.
Refer to "Hardware acceleration Technical Note" at http://docs.fortinet.com/fgt_amc.html for more details on how to meet the hardware acceleration requirements.
5. Avoid use of GUI widgets requiring computing cycles
Particularly on low end units, some GUI widgets (Dashboard page) involving computing cycles could be removed.
The best example is the "Top sessions" widget which requires the inspection on a regular basis 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, please 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. Load first generic mib file 'FORTINET-CORE-MIB.mib' and 'FORTINET-FORTIGATE-MIB.mib' specic MIB for the release.
Samples of useful MIB entries
For SNMP, please 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. Load first generic mib file 'FORTINET-CORE-MIB.mib' and 'FORTINET-FORTIGATE-MIB.mib' specic MIB for the release.
Samples of useful MIB entries
From the legacy 3.0 MIB:
1.3.6.1.4.1.12356.1.10.0 : Number of active sessions
1.3.6.1.4.1.12356.1.9.0 : Overall memory usage
1.3.6.1.4.1.12356.1.8.0 : Overall CPU usageFrom 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."For CLI, use a command such as:diagnose system session stat
get system performance status
diagnose system top
diagnose hardware sysinfo memory
