Traffic shaping using traffic shaping policies is not supported. Other methods of traffic shaping are supported if the following configuration is used:

config system npu

set default-qos-type policing

end

ECMP weight-based load balancing is not supported. Weight-based load balancing does not direct more traffic to routes with higher weights.

HA hardware session synchronization is currently only supported between two FortiGates using a direct connection between the HA hardware session synchronization interfaces. You can't use a switch for this connection and you can't synchronize sessions between more than two FortiGates.

FGSP failover may not work as expected.

UDPv6 session are no longer offloaded to NP7 processors after deleting and then re-adding a hyperscale firewall policy for them.

Sessions are lost if a policy route is deleted or an interface is shut down.

For FortiOS 6.2.6, Hyperscale firewall VDOM names should be created using special naming conventions. See Hyperscale firewall VDOMs require a specific naming convention.

The get system ha status command should display information about the total number of hardware session-sync sessions.

Per-session log messages for ICMP traffic accepted by a hyperscale firewall policy are not available.

Hairpin configurations will only work if the firewall destination address is set to All.

The FortiGate MIB does not support traps or queries for NAT64 and NAT46 hyperscale firewall policies.

Some TFTP functionality is not compatible with hyperscale firewall features.

When viewing a hyperscale firewall policy from the GUI, the displayed Hit count is always 1.

Only one hardware session synch interface can be configured in an HA configuration.

If you have set up hardware logging to use the CPU to send log messages to a syslog server, after adding a new hyperscale firewall policy, there may be a delay of a few minutes before the FortiGate can correctly display information about traffic accepted by this policy. This includes traffic information displayed on the GUI or by using diagnose commands such as diagnose sys npu-session list. After this initial delay, the FortiGate will display current session information.

Example hardware logging configuration that can result in this issue:

config log npu-server

set log-processor host

...

config server-group

edit <name>

set log-format syslog

end

If hardware logging using NetFlow is enabled, each NP7 processor sends a NetFlow template update message to configured NetFlow servers when the template-tx-timeout timer expires. If your FortiGate has multiple NP7 processors, the FortiGate will send multiple template update messages, one for each NP7 processor.

It is possible to create a hyperscale firewall policy where the address range of an IP pool in the policy overlaps with the IP address of one or more destination servers. Traffic will not flow in this configuration because the system will not send ARP requests to the server. Future versions will prevent incorrectly configuring this kind of overlap.

In a hyperscale firewall policy, setting the service to All and selecting Negate service causes a system error because this configuration is invalid.

Under high CGNAT traffic load that causes high CPU usage and causes the FortiGate to enter conserve mode, the FortiGate may unexpectedly restart after writing an event log message similar to the following:

date=xxxxxxxx time=xxxxx logid="0100032200" type="event" subtype="system" level="critical" vd="root" eventtime=xxxxxxxxxxxxx tz="+0300" logdesc="Device shutdown" msg="Fortigate had experienced an unexpected power off!"

The problem is not related to the power system; the message appears and the restart occurs even though the power system is working correctly.

Using the diagnose sys npu-session list {46 | 64} command to display NAT64 or NAT46 sessions being processed by the NP7 processor doesn't display any information if filtering options are enabled (for example, using the diagnose sys npu-session filter ... command).

When setting up an FGCP cluster of two FortiGates with hyperscale firewall features enabled, both FortiGates to be added to the cluster must have the same split interface configuration. If the split interface configuration is different on one of the FortiGates, when it joins the cluster it will continuously restart. This occurs because splitting interfaces requires the FortiGate to restart and this mechanism currently does not work correctly when forming a cluster.

The recommended workaround is to split the interfaces on both FortiGates before configuring HA. For example, use the following command to split port24:

config system global

set split-port "port24"

end

Changing the split interface configuration is not recommended after the cluster has formed. If you need to change the split interface configuration, remove the FortiGates from the cluster and change the split interface configuration of each FortiGate separately and then set up the cluster again.

When setting up an FGCP cluster of two FortiGate-4200Fs, 4201Fs, 4400Fs, or 4401Fs with hyperscale firewall features enabled, both FortiGates to be added to the cluster must have the same port-path-option configuration:

config system npu

config port-path-option

set ports-using-npu {ha1 ha2 aux1 aux2}

end

If the port-path-option configuration is different on one of the FortiGates, when it joins the cluster it will continuously restart. This occurs because changing the port-path-option configuration requires the FortiGate to restart and this mechanism currently does not work correctly when forming a cluster.

Changing the port-path-option configuration is not recommended after the cluster has formed. If you need to change the port-path-option configuration, remove the FortiGates from the cluster and change the port-path-option configuration of each FortiGate separately and then set up the cluster again.

If your FortiGate has one hyperscale VDOM, IPv4 traffic matched by policy routes in that VDOM is offloaded by the NP7 processor as long as you edit the policy route twice. If you don't edit the policy route twice, the traffic is sent to the CPU. IPv6 traffic matched by IPv6 policy routes is always sent to the CPU.

If your FortiGate has multiple hyperscale firewall VDOMs, for all VDOMs other than the first VDOM, IPv4 traffic matched by IPv4 policy routes is offloaded by the NP7 processor as long as you edit the policy route twice. If you don't edit the policy route twice, the traffic is dropped. IPv6 traffic matched by IPv6 policy routes is always dropped.

It is recommended that you contact Fortinet Support for assistance with IPv4 or IPv6 policy routing in hyperscale firewall VDOMs

FGCP HA hardware session synchronization may not synchronize all hyperscale firewall sessions to the backup FortiGate if the hyperscale firewall session includes one or more overload IP pools. The session loss rate on the backup FortiGate depends on the percentage of resource retries during session setup. The more IP pool resources that are available, the lower the session loss rate.