FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
pjang
Staff
Staff
Article Id 347232
Description

This article describes a known-issue that may occur on the FortiGate when attempting to load/modify the members of an Address Group.

This issue requires that a very large number of Address Objects and Address Groups be present in the configuration. The following symptoms related to this issue are as follows:

  • Slow GUI loading times when attempting to add Address Objects as members to an Address Group and/or when attempting to search for Address Objects by name.
    • The issue can also occur in the CLI when attempting to use the '?' character to list possible members to add to an Address Group (config firewall addrgrp).
  • High CPU usage/spikes for httpsd and newcli processes during the above loading process.
  • Many Address Objects and Address Groups are present in the FortiGate configuration (i.e. thousands of Address Objects, hundreds of Address Groups, and especially when there are nested Address Groups).
Scope FortiGate.
Solution

The issue is related to a series of checks that must occur so that the FortiGate can determine whether member objects can be added to an Address Group (e.g. checking address group nesting, checking if objects are routing-enabled, preventing infinite loops for group memberships, etc.). These checks can become highly-demanding on the CPU when the number of configured Address Objects is extremely high (i.e. thousands of objects configured), and as a result, the CPU usage and GUI loading times can increase while these checks are being performed.

 

These checks only trigger when the FortiGate is assessing member objects to see if they can be added to an Address Group, so GUI/CLI sections that only show existing objects added to Address Groups do not apply to this issue (i.e. checking the list of objects that are already assigned to an Address Group should be a fast operation).

 

The Fortinet Development team is working on optimizing these checks as part of Issue #1007566, and this issue should be resolved in the upcoming v7.4.6 and v7.6.1. This should reduce CPU usage significantly while also reducing the delay required to display the list of objects that can be added to an Address Group.

 

Workaround:

The recommendation is to create and modify Address Groups in the CLI. Where possible, use the exact name of the Firewall Address Object(s) that should be added to the Address Group, or perform partial-match searches to reduce the number of objects that need to be checked by the FortiGate.

 

Example:

 

FortiGate # config firewall addrgrp

FortiGate (addrgrp) # edit test_group
new entry 'test_group' added

 

FortiGate (test_group) # set member Test ? <----- Use the question-mark character to display available partial-matches.
*name Address name.
Test_10.0.0.100/32 address
Test_10.0.0.101/32 address
Test_FQDN address

 

FortiGate (test_group) # append member Test_10.0.0.100/32

FortiGate (test_group) # end

 

Related article:

Technical Tip: Add a new member to address group without removing the current address from CLI

Contributors