HowToFixMe
Deployment Automation

Fortinet FortiSwitch 224E: How to deploy with the vendor's controller / manager

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

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

Automating against Fortinet gear at scale means respecting FortiOS as an API surface, not just a CLI. The FortiSwitch 108E platform exposes a structured interface, and execute tac report plus end are the two operations that show up in almost every automation pipeline.

I have run automation against Fortinet fleets ranging from a dozen units to several thousand, and the failure modes concentrate at credential handling and at the 'activate' step. Plan for both.

Below is a pattern I use in real change pipelines. It is not Hello-World; expect to adapt it to your CMDB, your IPAM, and your Fortinet TAC-friendly change format.

What this guide covers

Real-world context. Budget honestly for ~Rs 0 INR under FortiCare, otherwise ~Rs 5,000 to Rs 80,000 INR for parts (around $60 to $960 USD), because the cheap path looks tempting until a part shows up wrong. You will burn ~20 to 60 minutes triage hands-on and roughly ~1 to 4 hours including a failover test once verification is done. Before you touch anything, line up the FortiGate serial, a config backup, and HA peer access. those three are what saves you when the first attempt does not stick.

How to deploy with the vendor's controller / manager for Fortinet FortiSwitch 224E (FortiOS).

Step-by-step

  1. Choose the automation surface: vendor controller, API, or CLI scripting.
  2. Verify reachability + credentials from your automation host.
  3. Test the change on a single device + maintenance window.
  4. Roll out in waves of 10-20 devices to limit blast radius.
  5. Pre-collect baseline, push the change, post-collect; diff.
  6. Roll back any device whose post-check fails.

Sample CLI invocation

# Manual baseline
get system status
diagnose hardware sysinfo
get system interface

# Push change (via vendor CLI)
config
config system interface
  edit "port1"
    set ip 10.0.0.1 255.255.255.0
    set allowaccess ping https ssh
  end
end

# Verify
get system interface

Best practices

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.

Common patterns we see

When this symptom shows up on a Fortinet device, three patterns repeat:

1. Recent firmware update changed behavior, the symptom started within a week of an OTA push. Rollback or wait for the hotfix. 2. Environmental trigger. temperature, humidity, line voltage, network changes. Look at what changed in the environment. 3. Cumulative wear, components like batteries, gaskets, fans degrade over time. Replace the consumable rather than chasing a software fix.

Knowing which pattern applies saves time on the wrong fix.

Safety + preconditions

Before any work on a Fortinet device:

Verification checklist

After applying the fix on your Fortinet device, confirm:

When to call Fortinet support instead

Escalate if:

More frequently asked questions

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.

Should I update firmware first or last?

Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.

Will the procedure work on the international variant?

Some features and firmware paths are region-locked. Check the model spec sheet to confirm your variant supports the menu option referenced. If you're outside the US/EU, look for the regional support portal.

How often should I run preventive checks?

Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.

Topology deep dive: where the 224E actually sits

The FortiSwitch 224E 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 224E 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 224E 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 224E 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 224E
config switch-controller managed-switch
    edit "S224ETB20xxxxxxx"
        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 224E 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 224E 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 224E 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 224E 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

On a recent rollout I onboarded a batch of 224E switches at a Tier-2-town branch network for a regional bank. The single biggest time-sink was not the switches at all, it was reconciling serials between the GeM purchase order, the gate-pass, and the FortiGate managed-switch list. Once the serials lined up, FortiLink auto-discovered every unit and the SOC saw them in minutes.

Extended FAQs

Does the 224E 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 224E 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.