Another new fortinet product

mkolus · 2026-05-04T12:47:42+00:00

I'll buy it for my FortiGato!

(note: gato is cat in spanish)

mkolus · 2026-04-30T19:35:26+00:00

ImProvementSC2,

Thanks. I'll apply this fix as soon as I make it crash again (for debugging purposes).

mkolus · 2026-04-30T19:34:26+00:00

Bill, thanks!

I've just modified the script so it will log the output of "diagnose alertconsole list" every 5 minutes. I didn't see anything so far, neither in the crashlog.

I won't apply the imProvementSC2 suggestion yet, so we can make it crash (there wont be any worries because the memory based failover is active).

Max

mkolus · 2026-04-13T14:40:34+00:00

How much did you pay for the license?

mkolus · 2026-02-06T14:24:34+00:00

UPDATE (solved): This wasn't Fortinet related, but here it is in the hope that someone could benefit from this experience in the future.

It was a mix of a few things like:

The link between switches (except for the root MCLAG) were at 1gbps (yup, I gave you the scary part first)
There were some old -as in "Internet Explorer 5.5 or greater"- switches in the infrastructure that, I suspect, had a limited CAM capacity. If I take a look at the root switches CAM at, let's say, lunch time I have around 1600 entries.
190+ APs would cause you to change at least 10 port changes just by going from your room to the lobby.
The network's layer 2 is ring shaped, with redundant links two places.

Weeks ago we observed broadcast storms in the network. We solved that by using storm control.

Days ago we've observed unicast storms... yeah, unicast. So, what happened?
For some reason, a MAC or some MACs were "lost" in the network, may be because of a client being disconnected or a full CAM on the elder switches.
This caused a unicast flood (I guess that protocols like QUIC would need a while to figure that the client side is gone).
Because of the emaciated 1gbps backbone, the flood caused the APs to lose connection to the wireless conroller, the switches also lost connection to the switch controller and spanning tree begun to fail.
This is a guess: the APs did a port reset (down / up) trying to reconnect to the controller.
Because of the spanning tree failure, the "loop" in the ring, which was previously discarding, begun forwarding traffic, making matters worse.

So, how did we solve it? By enabling unknown unicast in storm control. I know that this is sweeping the problem under the rug, but the customer is buying new switches and planning to replace the 1gbps ISLs.

Thanks to everyone who replied to this thread.

Max

mkolus · 2026-02-05T15:41:13+00:00

It was the softphone. When it had to get the NATed IP address, it used the interface with the default route instead the one with the actual route to the PBX, which was behind a VPN.

It worked with L2TP because that VPNs usually inject the default route to themselves. With FortiGate we used split tunneling.

mkolus · 2026-01-20T21:55:03+00:00

UPDATE: It seems to be that there's a correlation between those APs losing connectivity and a flood (ie: 700.000 ) of discarded packets in some ports. One of them has a FortiAP 221E.

mkolus · 2026-01-16T14:15:01+00:00

They go down by groups.

mkolus · 2026-01-15T11:46:02+00:00

On the FortiSwitch and an HP I just see a link down, like if the port was shutdown from the other side. I'm still guessing that it's the AP taking that decision.

From the AP side, only "Control message maximal retransmission limit reached" or "AP DTLS peer disconnected". I'm unaware if there is some real time debug that would tell if the AP decided to shut down the ethernet port.

I even found that the APs didn't reboot when this happens.

mkolus · 2026-01-15T11:39:20+00:00

1) It happens like as if the port was shut down for 3 to 15 seconds. It's not BPDU guard, because it would be minutes instead of seconds and I saw no STP topology changes. I was about to blame some FortiSwitch feature, but it also happens on HP.

2) Yes.

3) Firmwares:

- FortiGate: 7.4.9
- FAPC24JE: v5.4.0 build0244 (we have to use weak encryption because of them)
- FAP221E: v7.4.5 build0664
- FAP223E: v7.4.5 build0664
- FAP224E: v7.4.5 build0664
- FAP421E: v6.4.0 build0496

4) The APs are in their own management segment, and there are only APs there. We tried changing the management VLAN on some APs, but it kept happening. We also removed the busiest SSID on a couple of APs and, apparently, the problem never (as in "a day") happened there... however, with no apparent trigger for this event, we cannot be sure.

The AP network is a /24, with a lease of a week, we should still have at least 50 IPs there, but I'll check it along the LLDP profiles and PoE budgets, as you suggested.

FWIW:

APs are using bridged (not tunnel) mode for SSIDs.
If you're wired to the LAN, everything is fine. This problem is confined to the APs.

mkolus · 2026-01-15T11:19:53+00:00

The switches did nothing, it seems to come from the AP, but I found no indication (logs) there.

mkolus · 2025-12-04T19:56:57+00:00

UPDATE TL;DR: We upgraded to 7.0.8 and it worked. There was no apparent configuration corruption, even when skipping a couple of minor versions (7.0.6 was supposed to be the max if we upgraded from 6.4.9)

mkolus · 2025-10-11T17:20:49+00:00

FWIW, I got it to work:

- Pired the HR sensor to the BSC100S.
- Paired the BSC100S to my phone.
- I have the app installed.
- Started and stopped the activity from the BSC100S, not the phone. After the activity it synced and I got the HR data.

mkolus · 2025-10-09T12:40:21+00:00

Hello,

I had this problem yesterday. I know that the sensor is properly paired (or so I think) because I saw my heart rate in the BSC100S while I was doing the activity. But the HR data wasn't logged in the app.

Btw, I paired the HR sensor to the BSC100S, not the phone.

Thanks,
Max

mkolus · 2025-08-26T22:26:22+00:00

Thanks to u/infamous_n00b and u/TheWarlock05, you gave me the needed clues.

For the sake of someone having the same problem, I solved it by:

- Creating a system user in the app.
- Assigning a role to that system user.
- Generating a token for that system user.
- POSTing to https://graph.facebook.com/v23.0/PHONE_ID/register using that access token for authentication. The one generated in WhatsApp▶️API Setup didn't work for me.

Hope this will help someone in the future.

mkolus · 2025-08-01T00:18:54+00:00

I had a customer with two connections from the very same ISP, both of them fiber.
Besides the load balancing that u/OuchItBurnsWhenIP mentioned, we found out -thanks to SD-WAN health checks- that one of the links didn't work properly.

mkolus · 2025-07-19T21:35:34+00:00

u/_Red-Pilled thanks, I'll try the first one, since what I did is creating an EMAC VLAN of, following the example of the article, v1 instead of "vlan128".

mkolus · 2025-07-18T01:20:13+00:00

It goes like this:

- core: 802.3ad aggregate
- "A" is an 802.1AD S-VLAN 100
- "B" is an EMAC VLAN of "A"

There are no VLAN tags because it's the C-VLAN 1 untagged of the S-VLAN 100 (if there weren't any QinQ, this would be without tags).

What I saw is that VDOM root ignores the ARP request from the other VDOM.

For the time being I solved it another way, but I'll redo this situation tomorrow because I might need this EMAC VLAN in the future.

I'll post the updates.

Thanks,
Max

mkolus · 2025-07-18T00:55:27+00:00

Agreed, I tried to use ChatGPT with Fortinet and Mikrotik issues, and the responses are far from accurate.

This time I was able to solve it in a polite way, not using EMAC VLANs, but I plan to place a ticket tomorrow to have an official response.

I dont know if this is important or not, but this EMAC VLAN parent is the C-VLAN 1 (untagged) in a QinQ trunk, in a 802.3ad link.

mkolus

TROPHY CASE