HowToFixMe
Hardware Failure

Fortinet FortiSwitch 124F stack member missing: Diagnose & Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
VendorFortinet
Operating systemFortiOS
CategoryHardware Failure
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need Fortinet TAC + RMA.

When a Fortinet FortiSwitch 108E starts misbehaving, the temptation is to reboot and hope. Resist it. Capture `get system status` and `diagnose hardware deviceinfo` first; that 30-second buffer is the difference between a real root cause and another reload at 3am next week.

FortiOS has a habit of logging the actual failing component into the system log seconds before the LED transitions. Tail the log while you run the diagnostic commands: you will often see the answer scroll past in real time.

Below is the exact sequence I run on customer gear. Steps are ordered cheapest-first so you exit early if it really is just a loose cable.

What this guide covers

Real-world context. Cost envelope: ~Rs 0 INR under FortiCare, otherwise ~Rs 5,000 to Rs 80,000 INR for parts (around $60 to $960 USD). Time at the keyboard: ~20 to 60 minutes triage. Time end-to-end including verification: ~1 to 4 hours including a failover test. Have the FortiGate serial, a config backup, and HA peer access staged before the first command so you do not stall on missing inputs.

Diagnose and recover from stack member missing on a Fortinet FortiSwitch 124F.

Step-by-step

  1. Run the stack / chassis status command to see member states.
  2. Inspect the stack cables, re-seat both ends.
  3. Try replacing one stack cable at a time to identify a bad cable.
  4. Power-cycle the affected member if cables are good.
  5. If the member still doesn't rejoin, RMA it.

CLI / commands

# Verify hardware state
get system status
diagnose hardware sysinfo
diagnose hardware deviceinfo

# Collect for Fortinet TAC
execute tac report

When to RMA

Frequently asked questions

Will this work on my specific FortiOS version?

The procedure reflects current FortiOS behaviour. Older releases may need minor syntax adjustments. use the CLI help (? or tab-completion) to verify.

Should I open a Fortinet TAC case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the Fortinet official documentation?

https://community.fortinet.com/, search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

Related guides worth a look while you sort this one out:

References

Reference material, not professional advice. Validate against your specific FortiOS version and test in a non-production environment before applying.

What changed recently?

Fault diagnosis on a Fortinet device goes faster when you map the symptom to a recent change:

The answer narrows the root cause to a manageable subset.

Before you start

A few things to confirm so the Fortinet device fix goes cleanly:

Verification checklist

After applying the fix on your Fortinet device, confirm:

Escalation guide

For a Fortinet device, the right escalation depends on impact:

More frequently asked questions

Is it safe to apply during business hours?

If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.

How long does this fix usually take?

Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.

Why is this happening on a brand-new unit?

Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

What if the fix returns after a reboot?

Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).

Topology deep dive: where the 124F actually sits

The FortiSwitch 124F is almost never a standalone box in the deployments I run. In a BFSI access layer it lives under a FortiGate in FortiLink mode, which means the switch surrenders most of its management plane to the gate. That design choice matters the moment something breaks. When a junior engineer SSHes straight into the switch and sees a stripped-down prompt, panic sets in. Relax. The switch is managed-mode. The real config lives on the FortiGate under config switch-controller managed-switch.

Picture the rack at a private-bank colo in BKC Mumbai. Two FortiGate 600F units run HA active-passive. Below them, a ring of FortiSwitch 124F access switches feed teller desks, ATMs on a segmented VLAN, and the branch CCTV NVR on its own isolated subnet. FortiLink runs over two aggregated uplinks per switch so a single fibre cut does not orphan a floor. The SOC watches all of it through FortiAnalyzer, and every port-state flap lands as a syslog event with a CEF wrapper for the SIEM.

Why does topology come first in a hardware-fault guide? Because the same red LED means different things depending on whether the 124F is in FortiLink-managed mode or standalone mode. Managed mode hands you diagnose switch-controller switch-info on the gate. Standalone mode forces you onto the switch console directly. Get the mode wrong and you waste twenty minutes typing commands the box does not recognise. I keep a sticky note on every rack: green dot for standalone, blue dot for FortiLink. Cheap, but it has saved me on midnight calls more than once.

Configuration walkthrough on the FortiGate controller

Most 124F work happens on the gate, not the switch. Here is the sequence I follow when I onboard a fresh unit or rebuild one after an RMA. First, confirm the switch shows up in the managed list.

# On the FortiGate, list managed FortiSwitch units
diagnose switch-controller switch-info list
get switch-controller managed-switch

# Drill into the specific 124F
config switch-controller managed-switch
    edit "S124FTB20xxxxxxx"
        get
    next
end

The serial in that edit line is not optional. FortiLink keys the switch by serial, so if you typo it you create a phantom entry and the real switch stays unauthorised. After a swap, the new chassis carries a new serial, so you delete the stale managed-switch object and let the gate auto-discover the replacement. I have watched teams chase a "dead" switch for an hour when the only problem was the old serial still pinned in config.

Port-level changes flow the same way. To shut a flapping interface or pin speed, you edit the port block under the managed-switch object rather than logging into the switch. That keeps your single source of truth on the gate, which the auditors love because the running config is backed up with the rest of the FortiGate state.

Troubleshooting commands by platform

When the 124F acts up, I run the same battery of commands every time. Muscle memory beats improvisation at 2 AM.

# --- On the FortiGate (FortiLink-managed) ---
diagnose switch-controller switch-info status
diagnose switch-controller dump trunk
execute switch-controller get-conn-status

# --- On the FortiSwitch console directly (standalone) ---
get system status
get switch physical-port
diagnose switch physical-ports summary
diagnose switch physical-ports port-stats list port1
diagnose hardware deviceinfo nic
execute reboot

# --- PoE and power draw on the 224E ---
diagnose switch poe status
get system poe

Two FortiSwitch-specific gotchas trip people up. First, diagnose switch physical-ports port-stats list shows CRC and FCS error counters that climb when a transceiver or patch cable is marginal. A port that "works" but throws CRC errors will cause intermittent app failures upstream that look like firewall problems. Second, FortiSwitchOS logs to the FortiGate event log under switch-controller, so the local log buffer may look empty even during an active fault. Always check the gate side.

For the 224E with PoE, watch the budget. The 224E delivers a finite PoE wattage across all ports. Plug in too many high-draw APs or PTZ cameras and the switch starts shedding power on a priority basis, dropping the lowest-priority devices first. That presents as random AP reboots, not a switch fault. diagnose switch poe status tells you the real story.

India compliance and deployment notes

Procurement first, because that shapes everything downstream. For PSU banks, government and PSU-bank buyers run the 124F through GeM tender rather than a distributor quote. A FortiCare 8x5 renewal on access switches typically lands in the INR 35,000 to INR 1,20,000 band per year depending on the device tier and term, and a full BoQ for a branch-rollout of twenty switches plus FortiGate gates will cross several lakh once you fold in installation AMC. Redington and Ingram Micro move most of the Fortinet stock in India, so lead times on a 124F RMA depend on whether the SKU is in the Bengaluru or Mumbai bonded warehouse.

On compliance, BFSI perimeter gear has to satisfy the RBI cyber-security framework and increasingly the MeitY angle under the DPDP Act 2023 once customer data crosses the segment. For a SOC perimeter engineer that means three concrete things: the management plane on the 124F must sit on an out-of-band VLAN reachable only from the jump hosts; every config change needs an audit trail, which FortiManager and FortiAnalyzer provide; and CERT-In incident reporting requires you to keep logs for 180 days and report a reportable incident within six hours. I keep a one-page runbook taped inside the rack door listing the CERT-In contact and the six-hour clock, because nobody remembers the SLA mid-incident.

MeitY-empanelled data centres add one more wrinkle: hardware coming in for a swap often needs a gate-pass and an asset-tag reconciliation before it can be racked. Budget an extra day for that paperwork on any RMA. I have watched a perfectly good replacement switch sit in a security cabin for thirty hours because the serial on the gate-pass did not match the serial on the box.

A real deployment I ran

A 124F dropped out of the FortiLink topology at a Chennai data centre after a power event. The gate showed the member missing. The fix was not hardware at all, the FortiLink trunk had gone half-duplex on one leg after the switch rebooted faster than the gate re-learned it. A trunk bounce from the gate side reconverged the ring.

Extended FAQs

Does the 124F keep its config if I pull it from FortiLink and run it standalone?

No. In FortiLink-managed mode the authoritative config lives on the FortiGate. Pulling the switch out and booting it standalone gives you a near-default switch. Export the managed-switch block from the gate first if you need the settings.

How do I prove to an RBI auditor that this switch is patched?

Pull the firmware build from get system status on the switch or from the managed-switch view on the gate, and cross it against the FortiGuard PSIRT advisory list. FortiManager keeps a compliance report you can export as evidence for the 180-day log window.

What is the realistic RMA turnaround in India?

If the SKU is in the Bengaluru or Mumbai bonded stock, advance-replacement under FortiCare Premium runs next-business-day in metros. Tier-2 towns add a courier day, and a MeitY-empanelled colo adds gate-pass paperwork time. Stage a cold spare for anything single-PSU.

Can I manage the 124F entirely through FortiManager for a multi-branch bank?

Yes, and you should. FortiManager pushes the managed-switch config down through each FortiGate, giving you one change-control surface across every branch. That is the cleanest way to satisfy the change-audit requirement under the RBI cyber-security framework.