Skip to main content
knandagopal
Staff
Staff
February 13, 2026

Troubleshooting Tip: Troubleshooting high SoftIRQ CPU utilization on specific cores

  • February 13, 2026
  • 0 replies
  • 512 views
Description This article describes how to identify and troubleshoot high softirq CPU utilization on specific CPU cores of a FortiGate device. High softirq usage is typically related to heavy packet processing handled by the CPU, such as high traffic load, broadcast storms, deny traffic, or lack of NPU offloading (for example, IPsec traffic not being offloaded).
Scope FortiGate v7.2, v7.4, NP7.
Solution

FortiGate devices experiencing high CPU usage under softirq on specific or multiple cores.

 

First, check which FortiGate (FGT) model is experiencing high CPU usage. Run the command get system performance status to verify the CPU utilization, particularly the softirq usage.

 

get system perf stat
CPU states: 0% user 0% system 0% nice 49% idle 0% iowait 0% irq 51% softirq
CPU0 states: 0% user 0% system 0% nice 26% idle 0% iowait 0% irq 74% softirq
CPU1 states: 0% user 0% system 0% nice 21% idle 0% iowait 0% irq 79% softirq
CPU2 states: 0% user 0% system 0% nice 29% idle 0% iowait 0% irq 71% softirq
CPU3 states: 0% user 0% system 0% nice 1% idle 0% iowait 0% irq 99% softirq
CPU4 states: 0% user 0% system 0% nice 35% idle 0% iowait 0% irq 65% softirq
CPU5 states: 0% user 1% system 0% nice 37% idle 0% iowait 0% irq 62% softirq
CPU6 states: 0% user 0% system 0% nice 42% idle 0% iowait 0% irq 58% softirq
CPU7 states: 0% user 0% system 0% nice 0% idle 0% iowait 0% irq 100% softirq
CPU8 states: 3% user 0% system 0% nice 97% idle 0% iowait 0% irq 0% softirq
CPU9 states: 0% user 0% system 0% nice 100% idle 0% iowait 0% irq 0% softirq
CPU10 states: 0% user 0% system 0% nice 100% idle 0% iowait 0% irq 0% softirq
CPU11 states: 1% user 0% system 0% nice 99% idle 0% iowait 0% irq 0% softirq
Memory: 16394800k total, 3841128k used (23.4%), 12137944k free (74.0%), 415728k freeable (2.6%)
Average network usage: 7024 / 4117 kbps in 1 minute, 7255 / 4519 kbps in 10 minutes, 7028 / 4695 kbp

 

  1. Make sure to check the session rate and session count.
  2. Check the top processes consuming high CPU by running the command 'diagnose system top'.

 

diagnose system top

Run Time:  0 days, 0 hours and 14 minutes

0U, 0N, 0S, 100I, 0WA, 0HI, 0SI, 0ST; 16010T, 12504F

        mvl.user     2153      S       2.4     0.5    7

          httpsd     5294      S       0.6     0.2    11

          httpsd     5295      S       0.2     0.2    0

 initXXXXXXXXXXX        1      S       0.2     0.2    10

          newcli     5229      S       0.2     0.2    0

           snmpd     3312      S       0.2     0.1    3

          fltund     3343      S       0.2     0.1    2

   lnkmt_passive     3327      S       0.2     0.1    8

            node     3304      S       0.0     0.4    1

 

If no process shows high CPU usage but the softirq count remains high, this typically indicates packet-processing load rather than user-space process consumption.

 

High softirq may be caused by:

  • Large traffic volumes.

  • Broadcast or multicast storms.

  • High volumes of denied traffic.

  • Asymmetric routing.

  • DDoS-type traffic.

  • Network loop.

 

If IPsec tunnels are configured, confirm whether traffic is offloaded to the NPU.

 

Sometimes, broadcast traffic, a high volume of traffic passing through the FortiGate, or a large amount of denied traffic may not be noticeable. However, high softirq utilization may be observed on certain CPU cores or across all CPU cores.

 

If any IPsec tunnels are configured on the FortiGate, ensure that NPU drop counters are checked.

 

diagnose vpn tunnel list name Test_Tunnel

 

list ipsec tunnel by names in vd 0

------------------------------------------------------

name=H5_H4_ISP1 ver=2 serial=f 114.16.36.18:0->150.4.132.35:0 nexthop=114.16.36.17 tun_id=150.4.132.35 tun_id6=::150.4.132.35 status=up dst_mtu=1500 weight=1

bound_if=7 real_if=7 lgwy=static/1 tun=intf mode=auto/1 encap=vpnid-ipip/16952 options[4238]=npu create_dev frag-rfc  role=sync-primary accept_traffic=1 overlay_id=5

proxyid_num=1 child_num=0 refcnt=5 ilast=0 olast=0 ad=/0

stat: rxp=76710 txp=119705 rxb=11516661 txb=11686688

dpd: mode=on-demand on=1 status=ok idle=5000ms retry=3 count=0 seqno=418

natt: mode=none draft=0 interval=0 remote_port=0

fec: egress=0 ingress=0

proxyid=H5_H4_ISP1 proto=0 sa=1 ref=65 serial=1

  src: 0:0.0.0.0-255.255.255.255:0

  dst: 0:0.0.0.0-255.255.255.255:0

  SA:  ref=57 options=10227 type=00 soft=0 mtu=1426 expire=1014/0B replaywin=2048

       seqno=7b2c esn=0 replaywin_lastseq=00008e59 qat=0 rekey=0 hash_search_len=1

  life: type=01 bytes=0/0 timeout=3298/3600

  dec: spi=d69141f8 esp=aes-gcm key=36 yyyyyyyyyyyy

       ah=null key=0

  enc: spi=92a09839 esp=aes-gcm key=36 xxxxxxxxxxxxx

       ah=null key=0

  dec:pkts/bytes=19926/2976476, enc:pkts/bytes=31522/5418584

  npu_flag=00 npu_rgwy=150.4.132.35 npu_lgwy=114.16.36.18 npu_selid=6 dec_npuid=0 enc_npuid=0

 

Sometimes, traffic may not be offloaded to the NPU even when NPU offloading is explicitly enabled for the IPsec tunnel. If the NPU flag is displayed as npu_flag=00 while NPU offloading is enabled, the traffic is processed by the CPU. If multiple IPsec tunnels are configured, this can significantly increase CPU load and eventually cause high softirq utilization. In such cases, the lack of NPU offload for IPsec traffic may also result in increasing NP7 drop counters.

 

Additionally, run the following command to check for packet drops on the NPU:

 

diagnose npu np7 dce-drop all

 

When packet drops are observed, rebooting the FortiGate may temporarily mitigate the issue.

 

Related documents: