In this post we want to share some of the most seen reasons for slow performance on FortiGate appliances with you. This are experiences we’ve made in our support department and is not a concluding list.
Traffic shapers
Traffic shaping is an evergreen topic. We have already written two blog posts about traffic shaping. The biggest problem on traffic shaping is, that most administrators that configure the shaping, are not aware how the shaper and also the shaped traffic behaves when a shaper is set in place. You can find the blog posts here:
The main problem is, that the traffic shaper drops packets in some cases. Those packets, if they are TCP based packets, are then retransmitted from the sender. This causes an even higher volume of traffic at the end. The result may be a lovely called “self-induced-DoS”. That means, that our system is overloaded by all the retransmitted packets.
Logging too much
Logging is a performance intensive workload on the FortiGate.
Also, it is easy possible to configure the logging in a way, that huge amounts of log messages are generated what causes the system to overload under the logging task.
DoS policies
DoS policies are very common to be set and forget afterwards. At latest when you need to troubleshoot problems with blocked incoming connections you will notice, that it is not a good idea to implement DoS policies without notifications enabled.
Therefore we recommend to configure alert email messages for DoS policy matches as soon as the first DoS policy is set to block.
Bandwith limit on interfaces
Those bandwith limits that can be configured on interfaces are nothing more than traffic shapers. You can see if you have any bandwith limits configured by executing the following CLI command on your FortiGate:
sh full | grep 'inbandwidth\|outbandwidth' -f
We have a whole dedicated blog post that handles throughput troubleshooting on the FortiGate:
Too much UTM inspection
The rule is simple: Inspect as little as possible but as much as necessary.
If you inspect too much traffic and you FortiGate is not sized correctly, this may become a performance issue on the FortiGate. Also, Proxy based inspection and full SSL inspection are using more ressources and may cause issues in high load situations.
We have a dedicated blog post that describes the difference between flow and proxy based inspection:
Local reports
FortiGate devices, which have local disk storage, can generate local reports. The FortiGate local report has a predefined template and creating custom reports is not possible. Local reports are being generated on the FortiGate appliance and therefore consume local system ressources.
A good alternative to local reports are FortiAnalyzer reports since the load is being offloaded to the FortiAnalyzer.
You can find local reports under “Log & Report -> Reports -> Local Reports”.
Too large networks
In other words: An overload situation. The overload may be caused by just too much traffic (bandwith overload) or a mix of multiple of the above and below mentioned reasons.
Incompatible third-party transceivers or duplex mismatches
Problems on transceiver modules or duplex mismatches can cause reduced bandwith and also CRC errors. If a CRC error occours, in most cases the packet has to be retransmitted. This also causes higher CPU load.
MTU not set correctly
A wrong MTU can cause fragmentation (what needs ressources), packet loss (what causes retransmits, what also needs ressources), more overhead (smaller payload equals to more packets and this causes more overhead at the end).
A sidenote: Jumbo frames are supported by the FortiGate and may reduce the overhead in your network.
We have a dedicated blog post that describes how to self determine the optimal MTU size:
Even if it is possible to “reverse engineer” the MTU, we recommend you to get this information from your provider.
Slow DNS servers
DNS server are a very crucial part of a connection in regards of the performance. Before a client can send a request to a server, in most cases the client needs to resolve the dns name of the server into an ip address. If this process is not fast enought, the user will notice a delay while waiting for a webpage or application.
In general, DNS lookups are made once at the beginning when a client connects to a server. The answer to this request is then stored for some time. Therefore, in many cases only the initial connection to a server is slower.
Since some security checks (rbl, webfilter, spf, dkim, and many more) rely on the DNS protocol, also those security mechanisms may be impacted by slow DNS servers.
And a bonus topic: Bugs
Like every Software, the FortiGate is written by humans. And since humans are not faultless by nature, the software also has bugs. From time to time it happens, that a FortiOS bug has influence to the system performance. Most of the known issues in FortiOS are documented in the release notes of the FortiOS version.
