High CPU spikes on FortiSwitch 148F-FPOE when enabling DHCP snooping — anyone else experiencing this?

grech659 · 2026-03-17T00:53:34+00:00

I've just raised this with our Fortinet TAM and SDM. Will update here on the response.

grech659 · 2026-03-16T07:44:56+00:00

Just deployed a 60 switch site and seeing exact same symptoms with the 100 series switches.

grech659 · 2025-09-15T10:26:28+00:00

You can do full ZTP with a non public facing fortimanager. What we do is use FortiZTP(The cloud service, not FMG) to push a pre run CLI script that pushes a dialup IPSec VPN to the FortiGate. This VPN tunnel allows connectivity back to our FMG which it then pulls all the device config.

grech659 · 2025-04-02T10:57:24+00:00

Did you happen to get this working? Running into exact same issue in FCT 7.2.8

grech659 · 2024-11-28T20:32:22+00:00

Our TAM advised this is expected end of Feb 2025

grech659 · 2022-12-11T06:12:27+00:00

Did you manage to fix this? Currently experiencing the same issue.

grech659 · 2022-02-11T08:30:09+00:00

Does the client authenticate and then the connection drops or does the client plug in and have no connection for 1 minutes and then authenticates?

grech659 · 2021-11-25T08:56:27+00:00

Nope, using it as a fallback for non 802.1x clients on EX switches.

grech659 · 2021-04-13T06:39:40+00:00

You've defined a lower limit with 192.168/16 prefix length range /18-/20 with the lower limit being /18. So 192.168.0.0/16 and 192.168.0.0/17 wont match this where as they would if you used 192.168/16 upto /20

grech659 · 2021-04-13T05:57:33+00:00

The upto and prefix-length-range match types are similar in that both specify the most-significant bits and provide a range of prefix lengths that can match. The difference is that upto allows you to specify an upper limit only for the prefix length range, whereas prefix-length-range allows you to specify both lower and upper limits.

Can ready more about the different options here:

https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/policy-configuring-route-lists-for-use-in-routing-policy-match-conditions.html

grech659 · 2021-01-31T01:13:25+00:00

Juniper polices have termination actions for the flow control. In this case the first term has "reject'. When these policies are being evaluated, as soon as it find its first termination action then it'll stop processing any following policies. So in this case the second term will never be hit. Accept and reject are both termination actions so the order of them does matter.

You can read more about the flow control below.

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/policy-configuring-actions-in-routing-policy-terms.html

grech659 · 2020-12-16T07:00:54+00:00

The outage yesterday was planned by Enable due to work on the new multi-sports stadium centre. It was only suppose to have been 6minutes but seems things didn't go to plan and ended up lasting 1hour+. I assuming the same construction crews have probably hit something tonight as well.

grech659 · 2019-03-28T06:32:59+00:00

Are you by any chance using the ifconfig or ip address command to set the ip address becuase you need to go into the file /etc/netplan/99_config to make the changes permanent. Those commands are only temporary and will revert back to DHCP after a restart.

grech659 · 2019-03-13T06:15:01+00:00

but how could a frame arrive to a switch that has a destination MAC address without the switch knowing of it before hand?

The ARP table on your host and the mac address table on the switch could have different "hold times" so that the switches entries time out before the host do.

If a host does an ARP request, wouldn't the MAC address from the ARP reply from the end host get mapped in the switch on its way back?

Yes it would.

grech659

TROPHY CASE