HowToFixMe
IP / Network Issue

Fortinet router: MAC table full

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

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

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.

Fix MAC table full on a Fortinet router.

Step-by-step

  1. Check current MAC table utilisation.
  2. Identify the offending VLAN or port.
  3. Enable storm-control on access ports.
  4. Enable port-security with a hard MAC limit.
  5. Long-term, refresh to a switch with a larger MAC table.

CLI / commands

get system interface
show system interface
diagnose hardware sysinfo

When the issue persists

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:

How to confirm it's actually fixed

On a Fortinet device, the test is rarely "reboot and see". Use this list:

Escalation guide

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

More frequently asked questions

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.

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.

Are there safer alternatives for non-technical users?

Yes: the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

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.

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.

Topology deep dive: where this FortiGate sits

In most of the BFSI sites I support, a FortiGate does not live alone. It hangs off a FortiLink pair of FortiGate firewalls, usually a 600F or 1100E cluster at the colo, and feeds access ports into trading desks, branch teller counters, or a payments DMZ. So before you touch the box for "router mac table full.html", map the blast radius. One access switch in a NSE/BSE colo cage can carry forty live sessions to the matching engine gateway. Pull it at the wrong second and the desk loses ticks.

Draw the layers. North of the switch: the FortiGate doing inter-VLAN routing and policy. South of it: endpoints, IP cameras on PoE, maybe a couple of FortiAP units. East-west: the stack peer or the redundant FortiLink path. The reason this matters is that a symptom on the switch (router mac table full.html) often originates one layer away. I have chased a "dead port" that turned out to be a STP block on the FortiGate side, and an "OSPF flap" that was really an MTU mismatch on the transit VLAN. Know the map and you stop fixing the wrong layer.

For DPDP-scoped traffic, the segmentation matters even more. If this switch carries a VLAN that touches customer PII, any change you make is in scope for the data-protection audit trail your CISO has to produce. Keep the change reference handy.

Configuration walkthrough

Here is the order I actually run when I sit down at a FortiGate for this scenario. Short version first: get state, prove the fault, change one thing, re-prove. Long version below, because the order is what keeps you out of trouble during a Saturday change window when the SOC bridge is already half-annoyed.

Start by snapshotting the managed-switch view from the controlling FortiGate. On FortiLink the switch is not configured directly the way a standalone Cisco box is. You drive it through config switch-controller managed-switch on the FortiGate. Confirm the switch is even in Authorized and Up state before you blame the hardware. Half my "broken switch" calls clear the moment someone re-authorizes a member that dropped after a firmware mismatch.

Then take the running config off-box. On the FortiGate: execute backup config tftp or push it to your FortiManager revision history. In a MeitY-cleared environment the config backup is not optional, it is the rollback evidence the auditor will ask for. Tag it with the change number. Only after the backup do you make the edit. Change one VLAN, one port-status, one OSPF MTU value at a time, then re-run the verification command for that exact thing. Bulk changes feel faster and cost you the whole window when one of them is wrong and you cannot tell which.

Troubleshooting commands by platform

The CLI you reach for depends on whether the switch is FortiLink-managed or standalone, and whether the real fault is on a Cisco or Juniper peer in the same fabric. In a typical Indian bank data center the core is Cisco Nexus, the firewall edge is Fortinet, and a few aggregation boxes are Juniper. So I keep all three command dialects in muscle memory.

# FortiSwitch / FortiSwitchOS managed-switch view
get system status
get switch physical-port
diagnose switch physical-ports summary
diagnose stp instance list

# From the managing FortiGate (FortiLink)
get switch-controller managed-switch
diagnose switch-controller switch-info status
execute switch-controller get-conn-status

# FortiGate firewall / routing context
get router info routing-table all
get router info ospf neighbor
diagnose ip arp list
diagnose hardware deviceinfo nic
diagnose sys session stat

# Junos / Cisco peer for interop sanity in a mixed BFSI fabric
show ospf neighbor              # Junos peer
show ip ospf neighbor           # Cisco peer

Read the output like a SOC analyst, not a tourist. diagnose switch physical-ports summary tells you link, speed, and duplex per port. If a port shows up/up but no traffic, you have a policy or VLAN problem, not a cable problem. get router info ospf neighbor stuck in ExStart almost always means MTU; stuck in Init means hellos are one-directional, usually an ACL or a VLAN mismatch. Match the symptom to the state, not to a guess.

India compliance and deployment notes

Costs first, because every Indian network lead I know gets asked this before they get asked anything technical. A FortiGate FortiCare renewal runs roughly INR 85,000 to INR 2,00,000 per year depending on the bundle and the contract term (about $1,000 to $2,400 USD). On a GeM tender the line item shows up as the SKU plus a separate FortiCare 24x7 entry; PSU banks and state utilities buy it that way so the AMC is auditable. RMA replacements under an active contract are zero rupees for the part but you still budget courier and the engineer visit on the AMC.

On compliance: under the DPDP Act and the RBI baseline for banks, any change to a device carrying customer data needs a logged approval and a rollback plan. CERT-In wants security incidents reported inside six hours, so if this symptom turns out to be an ARP-poisoning or spoofing event rather than a config slip, you are on a clock. Keep the FortiGate logs forwarded to your FortiAnalyzer or SIEM, because "we did not have logs" is the answer that turns a routine event into a finding. For MeitY-empanelled cloud and data-center work, the device firmware should be on a supported LTS branch, not a one-off interim build.

A real deployment I did

Last year I was on a night change for a private bank in Bengaluru, migrating a branch aggregation layer onto a FortiLink-managed FortiGate pair. The exact scenario in this guide (router mac table full.html) bit us at about 1 a.m. Everything looked green on the dashboard, but one VLAN of teller terminals could not reach the core. The dashboard lied because the controller reported the member as authorized while the data plane was quietly dropping frames.

What fixed it was boring and that is the point. We backed out the bulk push, re-applied it one VLAN at a time, and ran diagnose switch physical-ports summary after each. The fourth VLAN exposed the problem: a native-VLAN mismatch against the Cisco Nexus uplink that the earlier bulk apply had masked. Ten minutes to find once we stopped trusting the GUI and started reading the per-port state. We closed the window on time, logged the change number for the DPDP trail, and I went home. The lesson I keep relearning: the device tells the truth at the CLI, the dashboard tells you a summary, and on a bad night the summary is wrong.

Extended FAQs

Is this safe to do during business hours on a BFSI floor?

No. Treat anything that touches a FortiGate carrying transaction VLANs as a change-window job. Get the change number, stage the rollback, and tell the SOC bridge before you start so an alert from your own work does not get escalated as an incident.

FortiLink-managed or standalone, does it change the fix?

Yes, a lot. FortiLink-managed switches are driven from the FortiGate under config switch-controller, so your commands run there, not on the switch console. Standalone FortiSwitchOS gives you the full local CLI. Confirm which mode you are in before you start typing or you will be on the wrong console for ten frustrating minutes.

How do I keep this audit-clean for DPDP and RBI?

Back up the config before the change, tag it with the change ticket, keep logs forwarded to FortiAnalyzer or your SIEM, and record the rollback step. If the event is a security one, file with CERT-In inside six hours. The paperwork is the difference between a clean audit and a finding.

When do I stop troubleshooting and open a Fortinet TAC case?

The moment you suspect real hardware failure, or the symptom survives a clean maintenance-window reload. Pull execute tac report first so the case starts with data instead of a back-and-forth. Confirm your FortiCare entitlement is active or the case stalls at the entitlement check.