Troubleshooting Tip: Possible Reasons and resolutions for a specific session not being offloaded to NPU

shahrukh_khan · ‎03-28-2025

Description

This article provides the various reasons and resolutions for a specific session not being offloaded to NPU.

Scope

FortiGate.

Solution

To clarify the underlying reason, it is essential to first gain a comprehensive understanding of the offload field within a specific session.

npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000

vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0

The expression 'offload=0/0' provides significant insights into traffic management and resource allocation within a given session. It can be defined as 'offload=(forward_direction)/(reverse_direction),' where the numerator represents the amount of traffic directed forward and the denominator denotes the traffic directed in reverse.

In this specific instance, both values are zero, indicating that there is currently no traffic being processed in either direction.

Under typical circumstances in the majority of cases, this field is often displayed as:

offload=0/0': Session is not offloaded.
'offload=4/4: Session offload successful with NP4 Accelerator Chip.
'offload=8/8': Session offload successful with NP6 Accelerator Chip.
'offload=9/9: Session offload successful with NP7 Accelerator Chip.

Different reasons why the session will not be offloaded to NPU:

Upon conducting a thorough verification of the session list, A potential reason could be identified as to why the session was not successfully offloaded to the Network Processing Unit (NPU).

This could be attributed to specific criteria or conditions that the session may not meet for offloading.

To illustrate this, below is an example of the generated output from the session list obtained through the 'diagnose sys session list' command. This output provides key insights into active sessions, including their statuses, types, and associated resources, which can help in further diagnosing the offloading issue. Below is the annotated example for reference:

npu_state=0x4000000

npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000

vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0

no_ofld_reason: " "<==============

total session 1

When the "offload" value is displayed as '0/0', it indicates that the session has not been successfully offloaded to the Network Processing Unit (NPU).

In such instances, it is essential to investigate the reason for the offload failure, which is usually articulated under the 'no_ofld_reason' section in the output.

This additional information can provide insights into potential issues such as resource limitations, configuration errors, or compatibility problems that prevent successful offloading to the NPU. Understanding these details can aid in troubleshooting and optimizing session handling efficiency.

Some of the reasons for offload failure could be:

no_ofld_reason: mac-host-check

==============================

When Device Identification is activated on a network interface, it means that the system is equipped with the capability to automatically detect and recognize connected devices, including their type and operating parameters.

This feature plays a crucial role in maintaining network security and efficiency. If a device is not successfully identified, perhaps due to a lack of proper configuration or compatibility issues, the 'mac-host-check' feature will come into play.

This mechanism functions as a safeguard by preventing session offloading. In practical terms, this means that any traffic associated with an unidentified device will not be distributed across multiple sessions, thereby ensuring that the network can maintain performance levels and security protocols.

This procedure helps to minimize potential vulnerabilities that could arise from unidentified devices attempting to access network resources.

config system interface

edit "port1"

set vdom "root"

set ip 10.5.208.142 255.255.192.0

set allowaccess ping https ssh http telnet fgfm

set type physical

set device-identification enable

set snmp-index 2

end

no_ofld_reason: Disabled-by-policy:

If the Network Processing Unit (NPU) offload feature is disabled within the firewall policy settings, the status will be displayed as 'Disabled-by-policy.'. This designation indicates that the offloading capability is intentionally turned off due to the current security and performance policies established by the network administrator.

config firewall policy

edit <policy_id>

set auto-asic-offload disable

end

config system npu

set fastpath disable

end

no_ofld_reason: non-npu-intef:

This typically indicates that the ingress interface, specifically, the interface on which the session is received, does not support NPU (Network Processing Unit) Offloading.

This situation arises due to the limitations inherent in certain NP processors, where specific types of interfaces are unable to facilitate NP offloading. For example, encounter this behavior with software-based interfaces or with loopback/virtual interfaces, which commonly do not possess the necessary hardware capabilities for offloading tasks to the NPU.

loopback/virtual interface: A loopback interface is a logical interface within a networking device that is designed to remain operational at all times. This characteristic makes it particularly useful for establishing and maintaining IPSec tunnels, which are utilized to secure data transmission over IP networks.
Unlike physical interfaces that can go down due to connectivity issues, a loopback interface is inherently stable and is often used for testing, routing, and management purposes. It’s important to note that because the loopback interface is virtual, meaning it does not correspond to any physical hardware, it does not support Network Utility Protocol (NUP) offloading. This limitation arises because NUP offloading typically relies on the characteristics of physical interfaces to optimize network performance, such as reducing CPU load during packet processing.

config system interface

edit "Loopback_1"

set vdom "root"

set allowaccess ping

set type loopback

set alias "Virtual Interface"

set role lan

set snmp-index 15

set ip-managed-by-fortiipam disable

end

Note:

For devices with NP7, running on v7.0.6 and v7.2.1 and above, hardware acceleration is supported on Loopback interfaces.

For more information, refer to this KB article:

Software switch: A software switch is a virtual switch that can be configured on certain models of FortiGates, such as the FortiGate-100E and FortiGate-200E. This virtual switch allows multiple network interfaces to operate as if they are part of a hardware switch, enabling them to share a common IP address and seamlessly connect to the same subnet. The interfaces under the virtual switch can include Ethernet ports, VLANs, or other configured interfaces, which facilitate efficient traffic management and resource allocation. By consolidating these interfaces into a single broadcast domain, the software switch simplifies network administration and enhances communication between devices on the same network

As the CPU is used to maintain the MAC-Port binding table the session could not be offloaded to NPU.

config system interface

edit "Software_Switch"

set vdom "root"

set ip 172.16.1.1 255.255.255.0

set allowaccess ping

set type switch

set alias "Virtual Switch"

config system switch-interface

edit "Software_Switch"

set vdom "root"

set member "port5" "port6" "port7"

end

PPPoE Interface: A PPPoE (Point-to-Point Protocol over Ethernet) Link is widely utilized for establishing connections between Internet Service Providers (ISPs) and end-user networks, with the connection typically terminating on a virtual interface, such as an Ethernet interface on a router.
This setup facilitates the authentication and encapsulation of data packets transmitted over Ethernet networks. To optimize the packet processing, the determination of the most efficient path for routing data is managed by Parallel Path Processing software.
This sophisticated software allows for the concurrent handling of multiple data streams, enhancing overall network throughput and reducing latency. However, certain limitations within specific software architectures or frameworks can hinder the capability to offload session management tasks to the Network Processing Unit (NPU).

no_ofld_reason: offload-denied Halper:

When session helpers are configured on a device, any traffic that aligns with the criteria set by these session helpers will not be offloaded to the Network Processing Unit (NPU). This is crucial because the NPU is designed to handle high-speed packet processing, and the presence of session helpers can redirect certain types of traffic for inspection or processing by the CPU instead.

FortiGates come with several built-in session helpers, notably the DNS (Domain Name System) helper and the SIP (Session Initiation Protocol) helper.

config system session-helper

edit 1

set name dns-udp

set protocol 17

set port 53

set name sip

set protocol 17

set port 5060

If an Intrusion Prevention System (IPS) profile is configured within the Unified Threat Management (UTM) profile, any traffic that is dropped due to a match with the IPS profile will not be offloaded to the Network Processing Unit (NPU).

This is an important consideration because when the IPS identifies and responds to potential threats, it requires a deeper inspection of the traffic rather than the high-speed processing typically handled by the NPU.

no_ofld_reason: redie-to-IPS:

This log could be observed when the traffic is sent to IPS for further analysis and offloading is performed on the verdict received from IPS.

If the issue is observed after upgrading the firmware to v7.4.3, it could be matched with BUG ID 1024576.

This issue is resolved in 'IPSE 7.4.4:0541, IPSE 7.6.0:1012'.

As a workaround, disable 'TLS 1.3 hybridized Kyber support' under the browser and change the tcp-mss for the sender and receiver to a value less than or equal to 1450 for firewall policies.

For more information, refer to this KB article:

no_ofld_reason: Local:

Any traffic that originates from the device itself is classified as local traffic. This includes management activities such as FortiGuard updates, as well as other internal communications initiated by the device. Such local traffic is not offloaded to the Network Processing Unit (NPU), meaning it is processed by the CPU instead.

This approach is taken to ensure that critical management functions and updates are handled directly by the device's CPU, which can provide more robust handling of tasks that may require specific context or real-time processing.

As a result, while local traffic may not benefit from the high-speed capabilities of the NPU, this configuration helps maintain system integrity and the reliability of essential updates and management functions.

no_ofld_reason: not-established:

If a Denial of Service (DoS) policy is configured and traffic is dropped as a result of that policy, the affected traffic will not be offloaded to the Network Processing Unit (NPU). This decision is made to ensure that potentially harmful traffic is inspected and managed directly by the CPU, as offloading it to the NPU could compromise the device's ability to respond effectively to security threats.

When establishing a DoS policy, it's essential to review and adjust the threshold values set within the policy to align with the specific network requirements. An overly aggressive threshold may inadvertently block legitimate traffic, leading to performance issues or service disruptions. Therefore, a careful evaluation of these parameters is critical to maintaining network stability while effectively protecting against DoS attacks.

npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0x0000/0x0000

vlifid=0/0, vtag_in=0x0000/0x0000 in_npu=0/0, out_npu=0/0, fwd_en=0/0, qid=0/0

no_ofld_reason: not-established <----

total session 1

no_ofld_reason: npu-flag-off:

For information regarding the NPU flag, refer to this KB article:

Furthermore, specific reason codes can be verified using flow debug, particularly in the context of IPSec tunnels.

When analyzing passthrough traffic for an IPSec tunnel, if the flow debug shows the error code 'offloading-check failure with reason_code=1', this indicates that NPU offloading for the IPSec tunnel configuration under the Phase-1 interface is disabled.

This scenario can arise if certain configurations or security features are not compatible with NPU offloading, requiring traffic to be processed by the CPU instead.

2024-07-23 17:28:51 id=65308 trace_id=262 func=nipsec_set_ipsec_sa_enc line=965

msg="IPSec encrypt SA (p1/p2/spi={DCI1-KVDC-TH1/KVDC-LO10-TH1/0xd06d1331}) offloading-check failed, reason_code=1"

config vpn ipsec phase1-interface

edit tunnel_name

set npu-offload disabled

end

2024-07-23 17:28:51 id=65308 trace_id=262 func=nipsec_set_ipsec_sa_enc line=965

msg="IPSec encrypt SA (p1/p2/spi={DCI1-KVDC-TH1/KVDC-LO10-TH1/0xd06d1331}) offloading-check failed, reason_code=2"

In the flow debug of an IPSec tunnel, if the error 'offloading-check failed, reason_code=2' is observed, this indicates that NPU offloading is not supported by the device. This situation is commonly encountered with virtual machine (VM) deployments of FortiGates in public cloud environments, such as Azure or AWS.

These cloud environments typically lack dedicated NPUs and rely solely on the CPU for traffic processing.

As a result, the performance of IPSec tunnels in these scenarios may not match that of hardware-based devices equipped with NPUs.

2024-07-23 17:28:51 id=65308 trace_id=262 func=nipsec_set_ipsec_sa_enc line=965

msg="IPSec encrypt SA (p1/p2/spi={DCI1-KVDC-TH1/KVDC-LO10-TH1/0xd06d1331}) offloading-check failed, reason_code=3"

The error message 'offloading-check failed, reason_code=3' signifies a compatibility issue with the encryption settings configured for the IPSec tunnel. Specifically, it indicates that the offloading feature does not support the type of encryption currently in use.

This situation typically arises during the Phase-2 configuration of the IPSec tunnel, where the selected encryption algorithms may not be compatible with the capabilities of the Network Processing Unit (NPU).

To resolve this issue, it is crucial to review the encryption algorithms currently configured in the IPSec settings. Ensure that the chosen algorithms are supported by the NPU. Commonly supported algorithms include AES, 3DES, and SHA, among others. Selecting a compatible encryption algorithm can successfully eliminate the error and enable proper IPSec tunnel functionality.

Refer to the FortiGate cookbook for a list of which encryption algorithms support NPU offloading: Encryption algorithms

config vpn ipsec phase2

edit "myPhase2"

set phase1name "myPhase1"

set proposal aes256-sha256

Related document:

Hardware acceleration

Troubleshooting Tip: Possible Reasons and resolutions for a specific session not being offloaded to NPU

You are leaving our website