Fortinet white logo
Fortinet white logo

Hyperscale Firewall Guide

Global hardware logging settings

Global hardware logging settings

Global hardware logging settings control how hardware logs are generated (by NP7 processors or by the CPU) and control global log settings such as the NetFlow version.

From the GUI:

  1. Go to Log & Report > Hyperscale SPU Offload Log Settings.

  2. Set Log Module to:
    • Hardware Log Module to use NP7 processors for hardware logging.
    • Host to use the CPU for hardware logging. If you select Host you cannot change the NetFlow version.
  3. If Log Module is set to Hardware Log Module you can select the Netflow version to V9 or V10.
  4. Select Apply to save your changes.

From the CLI:

config log npu-server

set log-processor {hardware | host}

set log-processing {may-drop | no-drop}

set netflow-ver {v9 | v10}

set enforce-seq-order {disable | enable}

set syslog-facility <facility>

set syslog-severity <severity>

end

Log Module (log-processor)

Select how the FortiGate generates hardware logs. You can select :

  • Hardware Log Module (hardware), the default, to use NP7 processors for hardware logging .

  • Host (host) to use the FortiGate CPUs for hardware logging (called host logging).

    Setting the log module or log processor is not available for all FortiGate models that support hyperscale firewall features. If the option is not available, then NP7 processors are used to generate hardware logs.

    Both log processor options also support software session logging.

If you set log module to Hardware Log Module (hardware) (and for FortiGate models that don't support selecting Host) the following limitations apply:

  • The interface through which your FortiGate communicates with the remote log server must be connected to your FortiGate's NP7 processors. Depending on the FortiGate model, this usually this means you can't use a management or HA interface to connect to the remote log server. See FortiGate NP7 architectures for information about the interfaces that are connected to NP7 processors and the interfaces are not for your FortiGate model.
  • The interface through which your FortiGate communicates with the remote log server can be in any VDOM and does not have to be in the hyperscale VDOM that is processing the traffic being logged.
  • The interface through which a FortiGate 4800F or 4801F communicates with the remote log server must be in a hyperscale firewall VDOM. This can be the VDOM that is processing the traffic being logged, or another VDOM assigned to the same NP7 processor group, see NP7 processor groups and hyperscale hardware logging.

  • The vd= field in generated traffic log messages includes the VDOM name followed by trailing null characters. If possible, you can configure your syslog server or NetFlow server to remove these trailing null characters.
  • Normally the PID= field in traffic log messages contains the policy ID of the firewall policy that generated the log message. But, if the policy that generated the traffic log message has recently changed, the PID= field can contain extra information used by the NP7 policy engine to track policy changes. You can extract the actual policy ID by converting the decimal number in the PID= field to hexadecimal format and removing all but the last 26 bits. These 26 bits contain the policy ID in hexadecimal format. You can convert this hex number back to decimal format to generate the actual policy ID.
  • If log-mode is set to per-session, NP7 hardware logging may send multiple session start log messages, each with a different start time. Creating multiple session start log messages is a limitation of NP7 processor hardware logging, caused by the NP7 processor creating extra session start messages if session updates occur. You can work around this issue by using host logging or by setting log-mode to per-session-ending. This setting creates a single log message when the session ends. This log message records the time the session ended as well as the duration of the session. This information can be used to calculate the session start time.

  • Syslog logging over TCP is not supported. Syslog over UDP is supported.

If you set log module to Host (host), all hardware logging functions are supported. There are no restrictions on the interface through which your FortiGate communicates with the remote log server. Host logging also supports syslog logging over TCP. With host logging enabled, NP7 processors send session information to the CPU, which maintains a session table of NP7 sessions and software sessions in software and system memory. Host logging then uses this session table to create log messages. Host logging has the following limitations:

  • Host logging can reduce overall FortiGate performance because the FortiGate CPUs handle hardware logging instead of offloading logging to the NP7 processors.
  • Host logging may not provide the NHI, stats, OID, gateway, expiration, and duration information for short-lived sessions.
  • Host logging does not support Netflow v9.

Netflow version (netflow-ver)

Select the NetFlow version to use for hardware logs.

NetFlow V10 is compatible with IP Flow Information Export (IPFIX), is the default. You can also choose NetFlow V9.

Host hardware logging does not support NetFlow v9.

CLI-only global hardware logging options

log-processing {may-drop | no-drop} change how the FortiGate queues CPU or host logging packets to allow or prevent dropped packets. This option is only available if log-processor is set to host. In some cases, hyperscale firewall CPU or host logging packets can be dropped, resulting in lost and incorrect traffic statistics.

  • may-drop the default CPU or host log queuing method is used. Log message packet loss can occur if the FortiGate is very busy.

  • no-drop use an alternate queuing method that prevents packet loss.

enforce-seq-order enable to send NetFlow software session logs in strict order by sequence number. If disabled (the default), due to how log packets are processed, in some cases packets with higher sequence numbers may be sent after packets with lower sequence numbers. If your NetFlow collector needs the packets to be in the correct order by sequence number you can enable this option. Enabling this option can reduce performance. You can disable this option if your NetFlow collector can accept packets out of order without causing errors. Enabling or disabling this option while the FortiGate is processing traffic is not recommended. This option should only be changed during a maintenance window.

syslog-facility set the syslog facility number added to hardware log messages. The range is 0 to 255. The default is 23 which corresponds to the local7 syslog facility.

syslog-severity set the syslog severity level added to hardware log messages. The range is 0 to 255. The default is 5, which corresponds to the notice syslog severity.

Global hardware logging settings

Global hardware logging settings

Global hardware logging settings control how hardware logs are generated (by NP7 processors or by the CPU) and control global log settings such as the NetFlow version.

From the GUI:

  1. Go to Log & Report > Hyperscale SPU Offload Log Settings.

  2. Set Log Module to:
    • Hardware Log Module to use NP7 processors for hardware logging.
    • Host to use the CPU for hardware logging. If you select Host you cannot change the NetFlow version.
  3. If Log Module is set to Hardware Log Module you can select the Netflow version to V9 or V10.
  4. Select Apply to save your changes.

From the CLI:

config log npu-server

set log-processor {hardware | host}

set log-processing {may-drop | no-drop}

set netflow-ver {v9 | v10}

set enforce-seq-order {disable | enable}

set syslog-facility <facility>

set syslog-severity <severity>

end

Log Module (log-processor)

Select how the FortiGate generates hardware logs. You can select :

  • Hardware Log Module (hardware), the default, to use NP7 processors for hardware logging .

  • Host (host) to use the FortiGate CPUs for hardware logging (called host logging).

    Setting the log module or log processor is not available for all FortiGate models that support hyperscale firewall features. If the option is not available, then NP7 processors are used to generate hardware logs.

    Both log processor options also support software session logging.

If you set log module to Hardware Log Module (hardware) (and for FortiGate models that don't support selecting Host) the following limitations apply:

  • The interface through which your FortiGate communicates with the remote log server must be connected to your FortiGate's NP7 processors. Depending on the FortiGate model, this usually this means you can't use a management or HA interface to connect to the remote log server. See FortiGate NP7 architectures for information about the interfaces that are connected to NP7 processors and the interfaces are not for your FortiGate model.
  • The interface through which your FortiGate communicates with the remote log server can be in any VDOM and does not have to be in the hyperscale VDOM that is processing the traffic being logged.
  • The interface through which a FortiGate 4800F or 4801F communicates with the remote log server must be in a hyperscale firewall VDOM. This can be the VDOM that is processing the traffic being logged, or another VDOM assigned to the same NP7 processor group, see NP7 processor groups and hyperscale hardware logging.

  • The vd= field in generated traffic log messages includes the VDOM name followed by trailing null characters. If possible, you can configure your syslog server or NetFlow server to remove these trailing null characters.
  • Normally the PID= field in traffic log messages contains the policy ID of the firewall policy that generated the log message. But, if the policy that generated the traffic log message has recently changed, the PID= field can contain extra information used by the NP7 policy engine to track policy changes. You can extract the actual policy ID by converting the decimal number in the PID= field to hexadecimal format and removing all but the last 26 bits. These 26 bits contain the policy ID in hexadecimal format. You can convert this hex number back to decimal format to generate the actual policy ID.
  • If log-mode is set to per-session, NP7 hardware logging may send multiple session start log messages, each with a different start time. Creating multiple session start log messages is a limitation of NP7 processor hardware logging, caused by the NP7 processor creating extra session start messages if session updates occur. You can work around this issue by using host logging or by setting log-mode to per-session-ending. This setting creates a single log message when the session ends. This log message records the time the session ended as well as the duration of the session. This information can be used to calculate the session start time.

  • Syslog logging over TCP is not supported. Syslog over UDP is supported.

If you set log module to Host (host), all hardware logging functions are supported. There are no restrictions on the interface through which your FortiGate communicates with the remote log server. Host logging also supports syslog logging over TCP. With host logging enabled, NP7 processors send session information to the CPU, which maintains a session table of NP7 sessions and software sessions in software and system memory. Host logging then uses this session table to create log messages. Host logging has the following limitations:

  • Host logging can reduce overall FortiGate performance because the FortiGate CPUs handle hardware logging instead of offloading logging to the NP7 processors.
  • Host logging may not provide the NHI, stats, OID, gateway, expiration, and duration information for short-lived sessions.
  • Host logging does not support Netflow v9.

Netflow version (netflow-ver)

Select the NetFlow version to use for hardware logs.

NetFlow V10 is compatible with IP Flow Information Export (IPFIX), is the default. You can also choose NetFlow V9.

Host hardware logging does not support NetFlow v9.

CLI-only global hardware logging options

log-processing {may-drop | no-drop} change how the FortiGate queues CPU or host logging packets to allow or prevent dropped packets. This option is only available if log-processor is set to host. In some cases, hyperscale firewall CPU or host logging packets can be dropped, resulting in lost and incorrect traffic statistics.

  • may-drop the default CPU or host log queuing method is used. Log message packet loss can occur if the FortiGate is very busy.

  • no-drop use an alternate queuing method that prevents packet loss.

enforce-seq-order enable to send NetFlow software session logs in strict order by sequence number. If disabled (the default), due to how log packets are processed, in some cases packets with higher sequence numbers may be sent after packets with lower sequence numbers. If your NetFlow collector needs the packets to be in the correct order by sequence number you can enable this option. Enabling this option can reduce performance. You can disable this option if your NetFlow collector can accept packets out of order without causing errors. Enabling or disabling this option while the FortiGate is processing traffic is not recommended. This option should only be changed during a maintenance window.

syslog-facility set the syslog facility number added to hardware log messages. The range is 0 to 255. The default is 23 which corresponds to the local7 syslog facility.

syslog-severity set the syslog severity level added to hardware log messages. The range is 0 to 255. The default is 5, which corresponds to the notice syslog severity.