Fortinet FortiSwitch 108E won't boot at all: Diagnose & Fix

Topology deep dive

On every BFSI floor I have wired, the FortiSwitch 108E 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 108E 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 108E 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 108E 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 108E 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 "S108EXXXXXXXXXX"
    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 108E 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 108E 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 108E 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

Last month a 108E in a Bengaluru NBFC core cage dropped half its ports at 9:15 a.m. on a settlement day, which is exactly when you do not want a switch acting up.

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 108E 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 108E 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 108E 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 108E 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.