IP / Network Issue

Juniper switch: MAC table full

Q: Where can I find the Juniper official documentation?

https://kb.juniper.net/ — search the product family + feature name.

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

⚡ At a glance

Vendor	Juniper
Operating system	Junos OS
Category	IP / Network Issue
Skill level	Intermediate to advanced
DIY-able?	Yes with CLI access; some scenarios need JTAC + RMA.

What this guide covers

Fix MAC table full on a Juniper switch.

Step-by-step

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

CLI / commands

show interfaces terse
show interfaces ge-0/0/0 extensive
show chassis hardware

When the issue persists

Open a JTAC case with the tech-support bundle.
Provide the timeline + recent changes.

Frequently asked questions

Will this work on my specific Junos OS version?

The procedure reflects current Junos OS behaviour. Older releases may need minor syntax adjustments. use the CLI help (? or tab-completion) to verify.

Should I open a JTAC 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 Juniper official documentation?

https://kb.juniper.net/, 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.

All Juniper fix guides → /juniper/
All vendor guides → /vendors/

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

References

Juniper support portal: https://support.juniper.net
Juniper knowledge base: https://kb.juniper.net/
Juniper security advisories: https://supportportal.juniper.net/s/global-search/Security%20Advisory
Open a case: https://supportportal.juniper.net/s/case

Reference material, not professional advice. Validate against your specific Junos OS version and test in a non-production environment before applying.

Common patterns we see

When this symptom shows up on a Juniper 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 Juniper 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.

Quick verification

Before you walk away from a Juniper device fix, run through:

1. Reproduce the original trigger: does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.

Escalation guide

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

Cosmetic / minor: log a ticket via the Juniper app or web portal. Response 1-3 business days.
Mid-impact: phone support. Have your serial number ready.
Critical (production down, safety issue): in-person dealer / TAC visit. Bring proof of purchase.
Out of warranty: third-party repair shop with manufacturer-certified technicians.

Topology deep dive. Juniper L2/L3 in a BFSI core ring

The Mumbai BFSI core ring I cover ties NSEL primary to BSE Wadala DR over a dark-fibre pair carrying OSPF area 0 between two MX240 routers, with EX4600 distribution downstream and EX4300 access at the floor edge. The switch mac table full symptom shows up at the L2/L3 boundary on the EX4600 where the SVI/irb sits, and the truth is, half the time the "Juniper bug" turns out to be a Windows server team misconfiguration on the host side, surfacing through Juniper because Junos is the only platform that logs it loudly.

What separates a fast root-cause from a four-hour ticket is one habit: collect show route forwarding-table, show ethernet-switching table, and show arp together, time-aligned, before changing anything. Junos timestamps each table cleanly enough to correlate, and the auditor at the next RBI inspection will ask for the artifact anyway.

Configuration walkthrough: L2/L3 sanity on EX/MX

# L2 tables
show ethernet-switching table
show ethernet-switching table interface ge-0/0/12
show ethernet-switching mac-learning-log

# L3 tables
show route 10.20.30.40
show route forwarding-table destination 10.20.30.40
show arp no-resolve | match 10.20.30
show ipv6 neighbor

# OSPF / BGP if applicable
show ospf neighbor
show ospf route
show bgp summary

# VRRP/HSRP equivalent
show vrrp detail
show vrrp brief

# Static routes
show configuration routing-options static
show route protocol static

Routing-instance gotcha: if you have multiple routing-instances (which every BFSI deployment does), every show route needs a table <instance-name> suffix, otherwise you are looking at the wrong RIB. I have seen junior engineers spend an hour debugging a route that was perfectly installed in the right RIB while they kept staring at the wrong one.

Troubleshooting commands by platform

The switch mac table full fault rarely lives in just one layer. Run these in order, time-aligned, so the JTAC engineer can correlate them later:

SRX side (security platform)

show version invoke-on all-routing-engines
show chassis routing-engine
show chassis cluster status
show chassis cluster information
show security flow session summary
show security policies hit-count
show security log

EX/QFX side (access/distribution)

show virtual-chassis status
show virtual-chassis vc-port
show interfaces diagnostics optics ge-0/0/24
show ethernet-switching table
show spanning-tree interface
show lacp interfaces

MX side (core)

show route summary
show bgp summary
show isis adjacency
show mpls lsp
show pfe statistics traffic

Cross-vendor reality check: at BFSI scale, your Juniper is one of 6 vendors in the same path. Cisco N9K leaf-spines for the DC fabric, Palo Alto VM-series for the Internet edge, F5 BIG-IP for app load-balance, Arista for the trading fabric, and Juniper SRX/EX for the branch. If a packet drops, you need the same time-aligned capture from every device. I keep a capture-everything.sh wrapper on the bastion that fans out to every box over SSH and dumps the show output into one timestamped folder.

India compliance and deployment notes

The switch mac table full ticket does not exist in a vacuum, it sits inside the audit trail your regulator will ask for. In Indian BFSI deployments, three frameworks touch this gear:

RBI cyber-security framework (2016, refreshed 2024). requires change records, audit logs retained 180 days minimum, and a documented rollback for every production change. Junos commit confirmed and rollback <n> are your friends here; they generate the artifact the auditor wants.
SEBI cyber-security circular for market intermediaries, same artifact requirements, plus a 6-hour incident reporting clock for severity-1 events. The clock starts when you detect, not when you understand. So your symptom capture matters even before root cause.
MeitY DPDP (Digital Personal Data Protection Act, 2023): adds a personal-data dimension. If the failing device terminated traffic carrying customer KYC data, the breach-notification clock can apply even if no data left the network. Document the negative finding in your incident note.

Procurement angle: SRX340 and SRX380 are both on the MeitY common-list of approved network gear for government and PSU deployments. GeM tender pricing for the SRX340 base bundle ran INR 4.85L on the last refresh I ran for a Karnataka PSU; SRX380 base bundle was INR 7.2L. SmartNet 24x7x4 renewals run INR 85,000 to INR 1.2L per year for the 340, INR 1.4L to INR 1.8L per year for the 380. AMC outside SmartNet, via a local Tier-2 SI, lands at about 60 to 70 percent of SmartNet pricing but the response SLA degrades from 4 hours to next-business-day in practice.

For the BSNL/MTNL backhaul leg, the L2 handoff is usually GigE on copper from the BSNL Exchange to the colo demarc. Tata Communications, Reliance Jio, and Airtel give you fibre handoff at the colo entry. Mixing copper handoff with the SRX ge-0/0/x port works fine, but the SFP/SFP+ choice on the BSNL side has been the cause of 3 of the last 11 "link flap" tickets I have closed, and the BSNL NOC will not admit it until you show the captured optic diagnostics from the Juniper side, which is why show interfaces diagnostics optics matters so much.

Real-world deployment I did. duplicate IP / asymmetric routing on MX240

March 2026, a mid-tier broker-dealer's NSEL colo. The switch mac table full symptom showed as intermittent failed login from one specific Mumbai branch to the trading rail. Other branches clean. show route 10.42.18.0/24 on the MX240 showed two next-hops with equal preference, one valid, one stale from a circuit that had been replaced six weeks ago. show route forwarding-table picked the stale one for 50 percent of flows.

The stale route had been pushed by a manual static during the original circuit cutover and never removed. Junos was doing the right thing, equal-cost load balance across two next-hops: but one of the two was a black hole. Fix: delete routing-options static route 10.42.18.0/24 next-hop 192.0.2.17, commit, validate forwarding table. Failed-login rate from that branch dropped to zero inside 4 minutes. Wrote a python script the next morning that audits the forwarding-table against the current ISP demarc inventory every Monday at 06:00 IST and mails the diff to the NOC. Zero recurrence in the 11 weeks since.

Extended FAQs

How fast can I get a Juniper SRX/EX replacement in a Tier-2 Indian city?

Realistic numbers from the last 12 months: Bengaluru/Mumbai/Pune/Hyderabad get 6 to 9 hours under SmartNet 4-hour. Jaipur, Indore, Coimbatore typically slip to next-business-day. Patna, Ranchi, Guwahati can stretch to 2 business days. Budget for the slip; do not promise the CISO the contract terms.

Does Juniper sell direct in India or via partners?

Via partners (Tech Pacific, Inflow Technologies, Redington), plus the Juniper India direct team for the top 50 accounts. SmartNet attaches to the partner PO, which means the partner is your first call for any RMA, Juniper India only takes the case after partner triage. Knowing your partner SE's mobile number matters more than knowing JTAC's number.

Is the switch mac table full symptom covered by SmartNet?

Software defects and hardware faults are both covered. Configuration errors and operator mistakes are not. JTAC will work the case but the SLA clock does not apply to "operator-induced" tickets. So the symptom capture matters: if you can show a hardware or software cause cleanly, the 4-hour clock starts. If the JTAC engineer concludes "config error", you bought yourself a free Junos tutorial but no SLA-backed replacement.