Before the tools — the one mindset that saves you hours
Meraki's whole pitch is cloud-managed visibility: instead of SSHing into a box, you open dashboard.meraki.com and every tool is one click away. But that convenience hides a trap — students fire the wrong tool first and waste an hour.
One sentence to memorise: "Symptom picks the tool, not the other way round." A user says "slow Wi-Fi" → start at the Event Log, not Packet Capture. A switch port is dead → start with Cable Test, not Insight. Drill this in — Troubleshooting is the single largest domain on the ECMS 500-220 exam at 30% weighting.
The ground truth. View live in the browser or download a .pcap for Wireshark. Captures kept ~7 days for Intelligent Capture.
A searchable timeline of auth, DHCP, roaming and dis-associate events. Filter by MAC, hostname or device.
Paid add-on. Splits a problem into Network-Layer vs App-Layer performance scores so you stop blaming the wrong thing.
One-click checks run from the device: Ping, Cable Test, Throughput, MAC table, ARP, Blink LEDs. No CLI, no SSH.
A user phones the helpdesk: "Internet hi nahi chal raha." Which tool answers fastest whether their device even authenticated and got an IP?
You want to inspect the real DHCP DISCOVER/OFFER exchange byte-by-byte. Where do you go?
Network-wide > Monitor > Packet capture, where you pick the device, interface and filter, then view live or download the .pcap.The cable test on a switch port reports a fault at "8 metres". What does that most likely mean?
① Packet Capture — the ground truth
When logs disagree and theories fly, the packet capture settles the argument. Meraki runs it from the Dashboard: Network-wide > Monitor > Packet capture. Pick the device (MX, MS or MR), choose the interface, optionally add a filter expression, then View output below (live in the browser) or Download .pcap for Wireshark.
Finance laptops on VLAN 30 keep landing on a wrong subnet. Sneha suspects a rogue DHCP server. Instead of guessing, she captures port 67/68 on the MX and watches who answers the DISCOVER.
▶ Watch a rogue-DHCP capture unfold
Click Play. Each stage lights up as Sneha drives the capture from the Dashboard.
port 67 or port 68
10.30.0.1
Capture options you'll actually use
Use host, port, net. Example: host 10.20.30.40 and port 443. Narrow first — full captures get noisy fast.
Set a packet count or time limit. The Dashboard truncates long captures — set a sensible window so you don't miss the event.
On MR & MS — captures auto-trigger on anomalies, store in the cloud (~7 days), and are downloadable later. Great for "it only breaks at 9 AM".
On MS, mirror source ports to one destination port + a laptop running Wireshark. The destination port stops serving clients — that's expected.
Symptom you see: you configure a port mirror, plug in your laptop, and get zero traffic — or the mirrored client loses its connection. Cause: the mirror destination port stops processing normal protocols — it becomes a one-way "black hole" that only spits out copied frames and serves no client. If you forget to disable the mirror afterward, the next onsite tech inherits a dead port. Also: MS120/125/130 cannot capture on switch ports connected to another MS switch in the same Dashboard network. Mirror only as long as you need, then turn it off.
You mirror four 1 Gbps uplink ports to a single 1 Gbps destination port during a busy hour. Your capture shows gaps and missing packets. Why?
Sneha runs a Dashboard packet capture on the MX LAN with filter port 67 or port 68 and sees TWO DHCP OFFERs for one DISCOVER. What has she found?
② Event Log — the network's diary
The Event Log lives at Network-wide > Monitor > Event log. Every association, 802.1X/PSK auth, DHCP lease, roam and dis-associate gets a timestamped line. The superpower is the Client filter: type a MAC, hostname or custom name and the log collapses to one user's story. Add the device filter and event-type filter to slice further.
A developer complains her laptop "drops every few minutes". Rahul filters the Event Log to her hostname and immediately sees a repeating 802.11 disassociation → reassociation pattern every ~90 seconds — a roaming/sticky-client problem, not an outage.
Network-wide > Monitor > Event log Client: lakshmi-lt (hostname, MAC, or custom name) Device: AP-3F-04 Event types: association, disassociation, 802.1X, DHCP
10:00:12 association AP-3F-04 ch149 -58 dBm 10:00:13 WPA2 auth success 10:00:14 DHCP lease 10.30.10.55 (4h) 10:01:44 disassociation reason: client idle timeout 10:03:11 disassociation reason: client idle timeout 10:04:40 disassociation reason: client idle timeout
The Event Log for one client shows association then 802.1X auth failure repeating, but no DHCP line ever appears. Where is the fault?
Rahul filters the Event Log to one laptop and sees disassociation → reassociation every ~90 seconds. What's the most likely root cause?
③ Meraki Insight — "network or app to blame?"
The hardest helpdesk question is "the app is slow — is it your network or their cloud?" Meraki Insight (MI) answers it. Web App Health assigns each monitored application a Performance Score, split into Network-Layer (latency, loss, jitter to the app) and Application-Layer (server response time, goodput). A score under 80% turns red and lists the affected networks.
Salesforce "is slow" across one branch. Priya opens Insight: the Network-Layer score is green (96%) but the Application-Layer score is red (61%). Translation: her LAN/WAN is healthy — the slowness is in the SaaS app / its CDN path. She closes the ticket against her network with evidence, not opinion.
▶ Insight splits the blame — watch it decide
"Salesforce slow" enters; Insight separates network from app and points the finger.
Insight shows a Web App with Network-Layer = 96% (green) and Application-Layer = 61% (red). What does this tell Priya?
④ Live Tools — one-click checks, no CLI
Live Tools run from the device itself, straight in the Dashboard. On a switch: Switch > Monitor > Switches, click the switch name (not the checkbox), then the Tools tab. The MX has its own Live Tools too, including a traceroute / per-hop loss view. The headline tools:
From the device to any host. Verifies reachability + latency. Behaviour differs slightly per platform (MX/MS/MR) but the answer is the same: can it get there?
TDR on copper (ANSI/TIA-568). Reports pair status + fault distance. Copper only — fibre needs DOM, not Cable Test.
Measures real link throughput from the device. Confirms whether the pipe delivers the speed the user expects.
Blink LEDs to find the right device in a rack; the MAC table / ARP tools show what's learned on each port — perfect for "which port is this device on?".
A barcode scanner on port 14 is dead. Karthik runs Cable Test from the Dashboard before driving 40 km onsite: it reports an open pair at 11 m. He tells the onsite tech exactly where to look — saving a wasted trip.
▶ Live Tools diagnosis ladder
"Port 14 device is dead" — climb the ladder one rung at a time.
1. Run Cable Test before dispatching a tech — it often turns a 40 km trip into a 2-minute remote diagnosis. 2. Pair the MAC table with the Event Log: "no MAC learned + no association event" = L1/physical; "MAC learned + auth failure" = L2/auth. 3. For intermittent issues, enable Intelligent Capture so the capture exists before you knew you needed it. 4. Always disable a port mirror when you're done — a forgotten mirror destination is a silent dead port.
Karthik runs Cable Test on a switch port and it reports "open pair at 11 m". A colleague says "just run it again on the fibre uplink the same way." What's the issue with that advice?
🤖 Ask the AI Tutor
Tap any question — instant context-aware answer. No login, no waiting.
Pre-curated answers from Meraki Documentation + community Q&A. For complex prod issues, paste your capture filter + Event Log slice into chat.techclick.in.
Common mistakes — symptom first, then cause
Symptom: you start a capture and see nothing. Cause: your BPF filter is too tight (typo in the host/port), the wrong interface is selected, or the traffic simply isn't crossing that device. Loosen the filter, confirm the interface, and verify the path with Ping first.
Symptom: one client's Event Log is full of disassociations and you declare an outage. Cause: you filtered to a single client and assumed it represented everyone. Clear the filter — if other clients are healthy, it's a client/RF issue, not an outage.
Symptom: hours spent tuning Wi-Fi while users still complain. Cause: the Application-Layer score was red and the Network-Layer score was green — the fault was always in the SaaS app. Read both scores before you touch anything.
📝 Wrap-up — six more
You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 Explain it back (self-explanation)
In one or two lines, write the rule that decides which tool you reach for first. Typing it yourself locks it into memory far better than re-reading.
👫 Teach a friend
Explain to a teammate why the mirror destination port loses connectivity, and why an oversubscribed mirror can fake "network loss". If you can teach it in 30 seconds, you own it.
⏰ Spaced recall — get a nudge in 3 days
Want a one-question recap emailed in 3 days so this sticks? Opt in (we only use it for this reminder).
📒 Glossary
- Packet Capture
- A live snapshot of traffic on a Meraki device — viewable in the browser or downloadable as a
.pcapfor Wireshark. - Intelligent Capture
- Auto-triggered, cloud-stored captures on MR & MS (~7-day retention) — great for intermittent faults you can't reproduce on demand.
- Event Log
- A searchable, timestamped timeline of association, auth, DHCP, roaming and dis-associate events, filterable by client and device.
- Meraki Insight (MI)
- A paid add-on adding Web App Health and WAN Health analytics — per-app performance scoring split into Network-Layer and Application-Layer.
- Performance Score
- A 0–100% Insight metric; below 80% turns red. Network-Layer covers latency/loss/jitter; Application-Layer covers server response time and goodput.
- Cable Test
- A copper-only TDR Live Tool (ANSI/TIA-568) reporting pair status and fault distance; fibre uses DOM instead.
- Port Mirror
- Copies traffic from source ports to one destination port for analysis; the destination port stops serving normal clients while active.
- Goodput
- The true application payload data rate (excluding overhead/retransmits) — one of Insight's Application-Layer thresholds.
📚 Sources
- Cisco Meraki Documentation — Packet Capture Overview (live view, .pcap download, Intelligent Capture, ~7-day retention). documentation.meraki.com
- Cisco Meraki Documentation — Meraki Event Log (Network-wide > Monitor > Event log; client + device filtering). documentation.meraki.com
- Cisco Meraki Documentation — Using the MS Live Tools & Using the Ping Live Tool & Using the MX Live tools. documentation.meraki.com
- Cisco Meraki Documentation — MI Web App Health Overview (Network-Layer vs Application-Layer, <80% threshold) & MI WAN Health Overview. documentation.meraki.com
- Cisco Meraki Documentation — Packet Captures and Port Mirroring on the MS Switch (destination-port behaviour, oversubscription). documentation.meraki.com
- The Meraki Community — Real-time traffic/session monitoring thread & Packet Capture on a Mirrored Port thread. community.meraki.com
- Cisco Learning Network — 500-220 ECMS Exam Topics (Troubleshooting = 30% of blueprint). learningnetwork.cisco.com
What's next?
That's the full Meraki visibility toolbox — Packet Capture, Event Log, Insight and Live Tools. You can now diagnose a complaint top-to-bottom before the second phone call comes in. Keep building: browse the rest of the Techclick lesson library to deepen your cloud-managed networking skills.