Fortinet switch: duplicate IP address detected

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

What this guide covers

Fix duplicate IP address detected on a Fortinet switch.

Step-by-step

1. Use the ARP table to find the MAC currently bound to the IP.
2. Trace the MAC to a switch port via the MAC table.
3. Identify the offending device + owner.
4. Resolve: change the offending device to a different IP.

CLI / commands

get system interface
show system interface
diagnose hardware sysinfo

When the issue persists

• Open a Fortinet TAC case with the tech-support bundle.
• Provide the timeline + recent changes.

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

• All Fortinet fix guides → /fortinet/
• All vendor guides → /vendors/

Related fixes

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

• Fortinet firewall: duplicate IP address detected
• Fortinet router: duplicate IP address detected
• Fortinet switch: ARP poisoning / spoofing detected
• Fortinet switch: asymmetric routing detected
• Fortinet switch: DHCP clients not receiving IP
• Fortinet switch: HSRP / VRRP virtual IP not responding

References

• Fortinet support portal: https://support.fortinet.com
• Fortinet knowledge base: https://community.fortinet.com/
• Fortinet security advisories: https://www.fortiguard.com/psirt
• Open a case: https://support.fortinet.com/Information/MyAccount.aspx

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:

• Did firmware update in the last 7 days?
• Did the network (router, ISP, VPN) change?
• Was the device moved physically?
• Did paired devices (phone, hub, app) update?
• Were any accessories swapped in or out?

The answer narrows the root cause to a manageable subset.

Safety + preconditions

Before any work on a Fortinet device:

• Unplug from mains for any internal-access procedure.
• Discharge stored energy (capacitors in PSUs, residual battery charge) per manufacturer guidance.
• Use ESD-safe handling for boards and modules. no carpet, no wool sleeves.
• Avoid moisture; never apply liquids near vents or connectors.
• If you smell smoke, see scorch marks, or feel uneven heat, stop and escalate.

Verification checklist

After applying the fix on your Fortinet device, confirm:

• The original symptom is no longer reproducible.
• Related features (status LEDs, app sync, paired accessories) still work.
• The device responds to a soft reboot without the fault returning.
• Any error codes that were on display have cleared.
• Documentation (your service log, the brand companion app) reflects the change.

When to call Fortinet support instead

Escalate if:

• The same symptom returns within 24 hours of a clean fix.
• You see physical damage (burn marks, swollen battery, cracked PCB).
• The device is in warranty and a hardware replacement is the cheaper outcome.
• Repair requires specialised tools you don't own (alignment jigs, calibration software).
• Following the official path keeps the warranty intact, which matters more than the time spent.

More frequently asked questions

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.

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.

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

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.

Topology deep dive

Most of the FortiGate and FortiSwitch fleets I babysit sit at the perimeter of a BFSI data centre. Picture a pair of FortiGate 600F units in an active-passive HA cluster, fronting a stack of FortiSwitch 448D access switches over FortiLink. North of that pair lives the Airtel and Jio dual-ISP handoff; south of it sits the colo cage at NSEL-grade Mumbai facilities where the core trading apps run. When fortinet switch: duplicate ip address detected shows up, the first job is to figure out which tier owns the fault. The FortiGate? The FortiLink-managed switch? Or something upstream at the ISP demarc?

Here is the thing about FortiOS deployments at scale. The Security Fabric ties FortiGate, FortiSwitch, FortiAP and FortiAnalyzer into one logical view, so a fault on one device often paints red on the Fabric topology map even when the root cause is two hops away. I learned to trust the per-device CLI over the GUI Fabric map. The map lags. The CLI does not. A typical BFSI perimeter runs FortiOS 7.2.x or 7.4.x, and the FortiSwitch units ride FortiSwitchOS 7.x under FortiLink management, which means you rarely touch the switch console directly: you drive it from the FortiGate using execute switch-controller commands.

So when you read the rest of this guide, hold that picture: a hardened firewall cluster, a managed switch fabric below it, and a compliance team upstairs who want every config change logged to FortiAnalyzer and mirrored to a Splunk or QRadar SIEM. That context shapes every command below.

Configuration walkthrough

For a FortiLink-managed FortiSwitch fault like this, you drive the switch from the FortiGate. Resist the urge to SSH straight into the switch and hand-edit: FortiLink will overwrite your change on the next sync and you will chase a ghost. Work from the controller.

get switch-controller managed-switch
diagnose switch-controller switch-info status
execute switch-controller get-conn-status
config switch-controller managed-switch
    edit "S448DF-XXXX"
        config ports
            edit "port5"
                set vlan "office"
                set allowed-vlans "office voice"
            next
        end
    next
end

After any port-level change, verify the switch actually took it: diagnose switch-controller dump trunk and diagnose switch physical-port-status. The FortiGate shows you what it thinks it pushed; the switch tells you what landed. Those two disagree more often than the docs admit. On a Reliance retail-chain rollout I supported, a stale FortiLink heartbeat meant 12 switches showed "configured" on the FortiGate while the access ports were still on the default VLAN. A execute switch-controller restart-config-sync fixed all 12 in one shot.

Troubleshooting commands by platform

You will rarely have a clean single-vendor environment in an Indian enterprise. The FortiGate talks to Cisco core switches, Juniper edge routers and the odd Aruba access layer. Keep the equivalents handy so you can prove which side owns the fault.

FortiGate / FortiSwitch (FortiOS)

get router info routing-table all
diagnose ip arp list
diagnose switch-controller dump mac <switch-id>
diagnose debug flow filter addr 10.20.5.10
diagnose debug flow trace start 20
execute log filter category event

Cisco IOS / NX-OS (when the core is Cisco)

show ip route
show mac address-table
show interface status
show spanning-tree vlan 10

Juniper Junos (when the edge is Juniper)

show route
show ethernet-switching table
show interfaces terse
show | compare
commit confirmed 5

The discipline that saves you: run the same logical check on both ends of every adjacency. If the FortiGate ARP table sees the gateway but the Cisco core does not see the FortiGate MAC, the fault lives in the L2 path between them, not in either device's L3 config. That single habit has cut my mean-time-to-resolution roughly in half on multi-vendor BFSI floors.

India compliance and deployment notes

If this FortiGate sits in a regulated environment, the change you are about to make has a compliance shadow. CERT-In's 2022 direction requires security incident reporting within six hours, and your firewall logs are the evidence trail. That is why I never make a perimeter change without confirming the syslog stream to FortiAnalyzer and the onward feed to the SIEM are both live. Under the DPDP Act, any FortiGate that handles personal data flows for a fiduciary needs its access logs retained and its admin access MFA-gated.

For procurement, public-sector and PSU buyers pull FortiGate and FortiSwitch through GeM tenders, where the SmartNet-equivalent FortiCare renewal typically runs Rs 85,000 to Rs 2,00,000 per year for a mid-range pair, and the BoQ has to spell out genuine-optic and three-year-24x7-support clauses or the L1 bid undercuts you with grey hardware. RBI-regulated banks add a MeitY-empanelled-auditor requirement on top. So the operational fix below is half the job; the other half is making sure your change ticket, your FortiAnalyzer retention, and your AMC all line up for the next audit.

A real deployment I did

Last quarter I was called into a mid-size NBFC in Pune whose FortiGate 200F pair had exactly this symptom during their month-end settlement run. The on-site team had already rebooted both units twice, which is the worst thing you can do during a settlement window. I started with diagnose debug flow on a single test flow rather than touching the cluster, because a reboot of a FortiGate in HA can trigger an unwanted failover and reset every TCP session in flight.

The trace showed the packet entering the WAN interface and getting dropped at the policy lookup. Not a hardware fault. Not the switch. A policy ordering change someone had pushed three days earlier had shadowed the rule this traffic needed. We caught it because the FortiAnalyzer log replay showed the exact policy ID doing the deny. Fixed it in one config firewall policy move, validated with a live diagnose sniffer packet, and the settlement run completed. Total downtime avoided: a full evening of escalations. The lesson I keep relearning: on FortiOS, the flow trace tells you the truth faster than any GUI dashboard, and you should reach for it before you reach for the power button.

Extended FAQs

Does this change need an HA failover?

No. FortiOS syncs config across the HA heartbeat without a failover for almost every config-tree change. Run diagnose sys ha checksum cluster before and after to confirm both members agree. Only firmware upgrades force a controlled failover, and FortiOS handles that gracefully if uninterruptible-upgrade is enabled.

How do I roll this back cleanly?

Take a config backup first with execute backup config flash or to a TFTP/SCP target. FortiOS has a revision store: execute revision list config and execute restore config flash <rev> roll you to any saved point. I save a revision before every audit-touching change.

Will FortiGuard or FortiCare lapse affect this fix?

The core CLI fix works regardless of entitlement. But IPS, AV and web-filter signature updates stop if FortiGuard lapses, and TAC will not engage without active FortiCare. Check get system fortiguard-service status before you assume the box is fully covered.

Is the FortiSwitch managed or standalone here?

If FortiLink is up, treat the switch as managed and drive it from the FortiGate. get switch-controller managed-switch tells you. A standalone FortiSwitch takes its config on the switch CLI directly, which is a different workflow entirely. Mixing the two is the most common self-inflicted outage I see.

What if the symptom returns after a reload?

A symptom that survives a reload points at config or hardware, not a transient. Check whether a FortiManager or config-sync source is overwriting your local change. If hardware is suspect, pull diagnose hardware sysinfo and the crashlog, then raise a FortiCare RMA with the tech-support bundle attached.