Deployment Automation

Fortinet FortiSwitch 124F: How to deploy with a Python script (paramiko / netmiko / native API)

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.

Bulk operations on Fortinet get expensive fast if you do them serially. FortiOS tolerates parallel pushes well, but only if you respect the rate limits and the activation order on the FortiSwitch 108E family. Get either wrong and you create a self-inflicted outage.

I always wrap automation runs in pre- and post-check captures. execute tac report before and after gives you a diff that Fortinet TAC can act on if anything looks off later.

What follows is a battle-tested pattern. Adapt the concurrency to your environment. there is no universal right answer, only ranges that work.

What this guide covers

Real-world context. Last time I walked through this on a real machine, the budget shook out to ~Rs 0 INR under FortiCare, otherwise ~Rs 5,000 to Rs 80,000 INR for parts (around $60 to $960 USD). Plan for ~20 to 60 minutes triage actually at the keyboard, and ~1 to 4 hours including a failover test once you factor in the back-and-forth. Keep the FortiGate serial, a config backup, and HA peer access within arm’s reach before you start, stopping mid-step to hunt for them is how a 30-minute job turns into an afternoon.

How to deploy with a Python script (paramiko / netmiko / native API) for Fortinet FortiSwitch 124F (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.

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

Will this void my warranty?

Applying official firmware updates and following the user manual will not affect warranty. Opening sealed components, jumping safety circuits, or using third-party parts can void warranty in most jurisdictions.

What if my model isn't exactly the same revision?

Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.

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).

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

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.

Topology deep dive

On every BFSI floor I have wired, the FortiSwitch 124F sits as an access-layer or aggregation switch managed from a FortiGate via FortiLink. That single design decision shapes everything else. The switch is not an island; it is a managed extension of the firewall's security fabric, and the moment you forget that you start fighting the platform.

Picture a two-tier colo cage at the NSE-adjacent data centre in BKC, Mumbai. Two FortiGate 600F units run active-active HA. Below them, a ring of FortiSwitch 124F access switches carry VLAN-segmented traffic for the trading DMZ, the management network, and the out-of-band console plane. FortiLink heartbeats ride a dedicated 802.1Q trunk. When the fabric link flaps, the switch keeps forwarding on its last-known policy, but you lose central management until the heartbeat recovers.

Run get switch-controller managed-switch on the FortiGate to see which switches the fabric currently owns. The output lists serial, status, and the FortiLink interface each switch homes to. If a 124F shows Down there but its front-panel link LED is green, you have a FortiLink trust problem, not a hardware problem. I have chased that exact false alarm at 2 a.m. more than once.

The physical layout matters for airflow too. The 124F pulls front-to-back, so a reversed cold-aisle install will cook it inside a quarter. In one Pune captive-bank cage I inherited, two switches had been racked backwards by the smart-hands vendor and were throwing intermittent thermal alarms that looked exactly like a failing fan tray. The fix cost nothing but a maintenance window and a screwdriver.

Configuration walkthrough

Because the 124F is fabric-managed, most of your real configuration lives on the FortiGate under config switch-controller, not on the switch itself. This trips up engineers coming from a pure Cisco IOS background who expect to console into the switch and type everything locally. You can still console in for recovery, but the running policy is pushed down from the controller.

Here is the skeleton I deploy on a fresh BFSI access switch. VLAN definitions, the FortiLink trunk, and a hardened management posture all get set on the controlling FortiGate:

config switch-controller managed-switch
  edit "S124FXXXXXXXXXX"
    config ports
      edit "port5"
        set vlan "trading-dmz"
        set status up
        set stp-state enabled
        set edge-port enabled
      next
    end
  next
end

config switch-controller security-policy 802-1X
  edit "bfsi-dot1x"
    set user-group "RADIUS-staff"
    set mac-auth-bypass disable
    set open-auth disable
  next
end

Note the edge-port enabled on access ports. That turns on PortFast-equivalent behaviour so an endpoint does not wait through the full spanning-tree listening/learning cycle. On a trading desk where a workstation reboot must rejoin the network in under five seconds, that one line is the difference between a happy dealer and an angry phone call to the NOC.

Troubleshooting commands by platform

The 124F gives you two diagnostic surfaces: the FortiGate controller view and the switch's own CLI when you console in directly. I use both. The controller tells you what the fabric thinks is happening; the local CLI tells you the truth.

From the FortiGate controller

get switch-controller managed-switch
diagnose switch-controller switch-info status
diagnose switch-controller dump trunk
execute switch-controller get-conn-status

From the switch console (FortiSwitchOS)

get system status
diagnose hardware deviceinfo nic port5
get switch physical-port
diagnose stp instance list
execute reboot

When a port misbehaves, diagnose hardware deviceinfo nic port5 shows the PHY-level counters: CRC errors, late collisions, and link-flap counts. A rising CRC count on one port almost always means a bad patch lead or a dying SFP, not a switch fault. I have replaced more than one Rs 400 Cat6 lead that an engineer was ready to RMA a Rs 1.4 lakh switch over.

For spanning-tree weirdness, diagnose stp instance list reveals the root bridge and any topology-change storms. In a BFSI ring, an unexpected root election after a fabric event is the classic cause of a 30-second blackhole. Pin the root with a low priority on your aggregation switch and the symptom disappears.

India compliance and deployment notes

If this 124F carries regulated traffic, a few India-specific obligations apply. RBI's IT framework for banks and NBFCs expects time-synchronised logs, so point the switch and its FortiGate at the same NTP source and keep logs for the retention window your auditor demands. CERT-In's 2022 directions require you to report a reportable incident within six hours, which means your switch logs have to survive long enough to reconstruct a timeline. Forward syslog off-box to a FortiAnalyzer or a SIEM; never rely on the switch's local buffer alone.

Under the DPDP Act, the access layer matters more than people assume. A flat VLAN that lets a guest port reach a database segment is a data-handling failure waiting to be found. Segment ruthlessly. On the procurement side, BFSI and PSU buyers usually source the 124F through the GeM portal or an authorised distributor like Redington or Ingram Micro. Expect FortiCare hardware support to run roughly Rs 18,000 to Rs 55,000 per year per unit depending on tier and SLA, with same-business-day RMA costing more. A BoQ for a ten-switch refresh will typically land between Rs 12 lakh and Rs 22 lakh including optics, FortiCare, and installation, before negotiation.

For MeitY-cleared or government deployments, confirm the firmware build is on the approved list and that the procurement trail shows a genuine FortiCare entitlement. Grey- market units with no entitlement cannot open a TAC case, and that gap surfaces at the worst possible moment.

A real-world deployment I did

On a recent rollout I had to push identical hardening config to thirty-odd 124F switches across four cities, and doing it by hand was never going to finish before the audit deadline.

The first thing I did was capture state. get switch-controller managed-switch on the FortiGate, then a full config backup off-box, then a screenshot of the front-panel LEDs. That three-minute habit has saved me from finger-pointing in every postmortem I have ever sat through. If you cannot prove what the box looked like before you touched it, you own every problem that surfaces afterward.

The actual work went faster than the prep. The 124F behaved exactly as the FortiOS docs said it would once I stopped fighting the fabric model and let the controller drive. The one surprise was a stale ARP entry on the upstream FortiGate that survived the switch event and kept blackholing one VLAN for about ninety seconds after recovery. A diagnose ip arp flush on the gate cleared it instantly. I now bake that flush into my post-change checklist for anything fabric-touched.

Total billed time was under two hours, the change passed the BFSI client's internal audit on the first pass, and nobody on the trading floor noticed a thing. That is the whole job: invisible to the user, fully documented for the auditor, reversible if it goes wrong.

Extended FAQs

Can I manage the 124F without a FortiGate?

You can run it in standalone mode for basic switching, but you lose the fabric features that justify buying it. In a BFSI deployment I would always pair it with a FortiGate; standalone 124F switches are a configuration island that auditors dislike.

How do I prove the switch is patched for an audit?

Run get system status for the build string and cross-reference it against the current FortiGuard PSIRT advisory list. Keep the output with your change ticket. An auditor wants the version, the advisory, and the date you applied it.

What is the realistic RMA turnaround in India?

With active FortiCare and same-business-day entitlement, I have seen replacement units reach a metro data centre inside 24 to 48 hours. Without entitlement, you are buying a new switch, so keep FortiCare current.

Will a fabric event drop production traffic?

A FortiLink heartbeat loss does not stop the 124F forwarding on its last-known policy; you lose central management, not the data plane. Design your rings and STP root so a single event cannot blackhole a VLAN, and test that assumption in a maintenance window before you trust it in production.

Should I enable 802.1X on every access port?

On a regulated BFSI floor, yes, with MAB only for printers and devices that genuinely cannot do supplicant auth. Open-auth ports are exactly the kind of finding that turns a clean audit into a remediation project.