Skip to main content
ssanga
Staff & Editor
Staff & Editor
September 2, 2025

Technical Tip: ‘cid’ Daemon Consumes Excessive CPU Resources (99%)

  • September 2, 2025
  • 0 replies
  • 1196 views
Description This article describes a workaround and solution for an issue where the ‘cid’ daemon consumes nearly 99% CPU when large packets arrive through the FortiSwitch to the FortiGate.
Scope FortiGate v7.4.6, v7.4.7, v7.4.8.
Solution

When 'set device-identification' is enabled on a FortiLink-based Interface (for example, VLAN) in FortiGate, the cid daemon may consume 99% CPU when large packets arrive through the FortiSwitch to the FortiGate.

diagnose sys top-all 1 100 1
Run Time: 3 days, 13 hours and 51 minutes
4U, 0N, 7S, 88I, 0WA, 0HI, 1SI, 0ST; 15919T, 9814F
cid 10387 R 99.9 0.2 3

Capture the output of 'diagnose cid stats' multiple times for comparison.


diagnose cid stats
.
scan.tap.event.triggered: 730395557049 <---
scan.tap.read: 730397526554
scan.tap.copying: 730395557042
scan.tap.ipv4_bypass: 94729
scan.tap.ipv6_bypass: 1607
scan.tap.ring.head: 15843888          <---

 

diagnose cid stats
.
scan.tap.event.triggered: 730423672237  <---
scan.tap.read: 730425641742
scan.tap.copying: 730423672229
scan.tap.ipv4_bypass: 94729
scan.tap.ipv6_bypass: 1607
scan.tap.ring.head: 15843888          <---

The above outputs show that while the scan.tap.event.triggered counter is incrementing, the scan.tap.ring.head counter remains the same (not advancing).

This indicates one of two scenarios:

  1. No traffic was scanned between runs (possible on lightly loaded devices).
  2. The ring head is stuck as it is hitting a known issue reported under bug 1165172.

From the above output, since scan.tap.event.triggered is incrementing, the FortiGate is not idle, thereby ruling out case 1.

Further confirmation comes from the scan.tap.read and scan.tap.copying values, which differ significantly, showing that the cid-scan process is continuously receiving events but cannot properly advance the ring buffer.


This is because FortiGate is receiving a large packet, causing scan.tap.ring.head to advance incorrectly into the body of the packet, preventing it from pointing to the header of the next packet.
As a result, the buffer cannot advance, and CPU utilization spikes.

This issue has been resolved in FortiOS versions:
v7.6.4 (available to download from the Fortinet support portal).
v8.0.0 (scheduled to be released in February 2026).

These timelines for firmware release are estimates and may be subject to change.

Workaround: Disable device detection on the interface.


config system interface

    edit <interface>
        set device-identification disable

end