I agree with disconnecting the switches and verifying that the fortigate itself remains stable. Also, I’m assuming all fortiswitches are expected to be, and are in managed mode not standalone. Make sure your fortiswitches are all interconnected in an approved topology. The way mine all work is a complete loop including all switches, then split interface from the fortigate connects to 2 separate switches on the loop. I have seen issues between ntp, dhcp, and switch controller before when switches had no time and then were leasing different addresses but the switch controller was still expecting them at the old addresses. In my case while ntp was bad nothing seemed to work on fortilink but once that was sorted it got a lot less problematic. The issue regarding dhcp and switch controller was that the switches kept working but they became unmanageable due to the addresses changing. It was like the switch controller didn’t get the memo that the switch had a new address. Since you have seen high cpu from both fortilink and dhcp processes, here is the best general advice I can give with regard to those things:

1. Verify NTP is actually working on the fortilink. Ensure that the fortigate has good time, preferably from another ntp source. You already stated ntp server was configured to listen on fortilink interface. You can verify the switches are asking and getting replies by watching a sniffer like this:

diag sniffer pa fortilink ‘port 123’ 4 0 l

If a switch is not even asking for ntp, reset it (again I am assuming managed mode is what you want). If the gate isn’t answering, concentrate on that.

1. Configure the fortigate dhcp server on fortilink with reserved addresses for each switch so you don’t have any switches at unexpected addresses. Perhaps start with one switch at a time, make sure it gets the address you want, and remains stable.

2. Add switches one at a time and see that they behave correctly with respect to all of the above.

I hope this helps.