Prove Meraki is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The laptop never associated. The spoke never registered. WAN2 is Ready while WAN1 is Failed. Policy never allowed the VLAN. STP is discarding the AP uplink. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught org → network → SSID vs MX L3 vs AutoVPN. Here you learn the five Dashboard tools you actually open, in order, when someone asks you to prove Meraki is working. Official paths only — documentation.meraki.com.

Hero · one cloud, five sites

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you rebuild a healthy hub at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open Firewall or Access control until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to Dashboard. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the network is the right one, then the Event log, then the WAN / application. Side B proves the wireless client handshake. Side C proves the AutoVPN spoke and the switch neighbor. On a messy Sev-2, do them in this order until a field lights up.

Side A — Picker, Event log, WAN, Traffic (MX / network-wide)

1. Name the organization and the network

   Top-left picker. If the ticket is BR-PUNE and the picker says HQ-Lab, stop. The factory lesson is this miss. Source: Managing Multiple Networks with Configuration Templates; Combined Dashboard Networks.

2. Open Event log, not Firewall

   Path: Network-wide → Monitor → Event log. Combined network: drop-down next to Event log → for security appliances (or APs / switches). Filter Client = MAC / hostname / custom name. Use Before for the ticket window. Timestamps use the network time zone. Source: How to Use the Meraki Event Log.

3. Read the MX event types that close a “is it working?” ticket

   Appliance status = primary uplink events. Meraki VPN = AutoVPN connectivity. Filtering = content filtering / Security Center URL blocks. DHCP / IP conflict. VRRP = warm spare. Offline devices keep events locally and upload later with the original timestamps — late rows are not “Dashboard invented them.”

4. If the complaint is WAN or “no internet,” open Appliance status

   Path: Security & SD-WAN → Monitor → Appliance status → Uplink. Quote Active (healthy and sending client traffic), Ready (healthy, waiting on Primary uplink), Failed (cannot reach the Meraki cloud), Not Connected, or Disabled. Pair with Event log primary uplink status change — official: uplink: 0 = Internet 1, uplink: 1 = Internet 2. Also Bad Gateway: No_lan_connectivity vs No_inet_connectivity. Source: How to Configure MX and Z-Series Uplink Settings; Connection Monitoring for WAN Failover.

5. If the WAN is Active and they named an app, open Traffic analytics

   Path: Network-wide → Monitor → Traffic analytics (requires Detailed / hostname visibility). Quote application, destination hostname or IP, usage, flows, clients. Then, if you suspect an L7 deny, Event log filter L7 deny (NBAR: destination port, protocol, destination IP, NBAR ID). HTTP Hostname / Geo IP L7 rules use the legacy engine and do not write Event log rows — official caveat. Source: Next-Gen Traffic Analytics with NBAR; Hostname Visibility.

Org / network:   Techclick-Lab / BR-PUNE   (picker, not HQ-Lab)
Path:            Network-wide → Monitor → Event log
Combined:        for security appliances
Quote:           02:04 IST · Appliance status · uplink: 1
                 02:04 IST · Meraki VPN · VPN Registry: Disconnected
Then:            Security & SD-WAN → Monitor → Appliance status → Uplink
Quote:           WAN1 Failed · WAN2 Active
Do not:          Save a new L3 allow from an empty HQ-Lab Event log

Side B — Wireless Event log / client

1. Open the AP Event log for that MAC, not Firewall

   Same page: Event log drop-down → for access points. Client = MAC / hostname / custom name. Official troubleshooting also: Network-wide → Monitor → Clients (docs also say Network Wide → Monitor → Client) and jump to Event log filtered by that MAC. Source: How to Use the Meraki Event Log; Common Wireless Event Log Messages; Wireless Issue Resolution Guide.

2. Read association, then 802.1X, then DHCP

   Success shape (official example): 802.11 association channel: 36, rssi: 53 → 802.1X authentication identity → 802.1X EAP success → RADIUS response group / vlan. Failure shape: 802.1X EAP failure then 802.11 disassociation. WPA-PSK success is a WPA authentication row. Hourly 802.1X re-authentication on WPA2-Enterprise is official normal rekey (3600 s) — not a loop.

3. If association succeeded and DHCP failed, leave wireless policy alone

   Official DHCP trap: VLAN tagging on the SSID or the upstream switch port. Path to check addressing: Wireless → Configure → Access Control → Client Addressing. Quote the Event log DHCP row, then the SSID VLAN, then the switch port VLAN — that is isolate. Changing the PSK is not.

Path:            Network-wide → Monitor → Event log
Combined:        for access points
Client:          aa:bb:cc:dd:ee:ff
Quote:           802.11 association channel: 36, rssi: 46
                 802.1X EAP failure identity: priya@lab.example vap: 0
If DHCP after EAP success:
                 Wireless → Configure → Access Control → Client Addressing
                 then Switching → Ports VLAN vs SSID VLAN

Side C — VPN Status + Switch port / STP / CDP

1. Open VPN Status on the spoke, not the hub rebuild

   Path: Security & SD-WAN → Monitor → VPN Status. Org-wide view: Organization → Monitor → VPN Status. If site-to-site VPN is not enabled on the selected network, the Security & SD-WAN link is hidden — use the Organization tab. Source: VPN Status Page; Meraki Auto VPN — Configuration and Troubleshooting.

2. Read Status, Registry, NAT Type, then exported subnets

   Status: green = all peers reachable, yellow = some unreachable, red = peer unreachable. VPN Registry Connected / Disconnected. NAT Type Unfriendly = upstream NAT blocking hole-punch. Routing Errors = overlapping / conflicting subnets. Exported subnets tab: Name, Yes/No, Subnet, Router IP (from Addressing & VLANs). Latency 50% / 90% and Usage graphs are AutoVPN only — official: not collected for IPsec peers.

3. If the AP or wired client is dark, open the switch port

   Path: Switching → Switches → the switch → Summary (visual) or Ports (visual + detail). Network-wide: Switching → Switch ports. Quote RSTP state: Enabled / Forwarding / Blocking / Disabled. Blocking symbol = STP discarding or LACP disabled. LLDP is the Dashboard neighbor column (search lldp:"MR24"). CDP is official on Voice VLAN advertisements and PoE (Power Consumption / Power Request / Power Available) — not a separate “CDP neighbors” menu. MS Event log types: Spanning Tree, Switch port, Status (port carrier). Source: How to Monitor Switch Ports; Switch Ports; Troubleshooting PoE on MS switches.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

MEVD-01 — Prove the Event log (is Meraki even working?)

01:42 · P2. Slack: “Is Meraki even working?” Someone already drafted a Corp rebuild. The last engineer left the picker on HQ-Lab.

First tool: say the org and the network out loud. Switch to the ticket network. Then Network-wide → Monitor → Event log. Combined: pick the product type. Filter Client if they named a user. Set Before to just after the complaint. Official: Event log uses the network time zone.

If the log is empty on HQ-Lab: that is the proof you were in the wrong store. It is not a tenant outage. Switch to BR-PUNE and search again.

If the log has rows: quote type + time + device. Appliance status / Meraki VPN / 802.11 / Spanning Tree each send you to a different second tool. The Event log is the pointer, not the WAN verdict.

MEVD-02 — Prove the spoke (VPN Status)

02:05 · P2. Pune users associate on Corp. They cannot open the HQ file server. L1 wants the hub MX rebuilt.

First tool: on BR-PUNE, Security & SD-WAN → Monitor → VPN Status. If the VPN Status link is missing, site-to-site VPN is not enabled on this network — use Organization → Monitor → VPN Status.

Proof field: peer HQ-LAN Status red; VPN Registry Disconnected or Connected; exported subnet for the file-server VLAN Yes or No; NAT Type / Routing Errors. Association on Corp already proved wireless. Rebuilding a green hub is change-control, not isolate.

MEVD-03 — Prove the WAN (Appliance status / Traffic analytics)

02:20 · P1. Whole Pune floor lost internet after a 02:00 ISP change. Traffic analytics looks empty. Someone wants a new L7 allow.

First tool: Security & SD-WAN → Monitor → Appliance status → Uplink. Quote WAN1 Failed or Not Connected, WAN2 Active or still Ready.

Proof field: Ready means healthy and not carrying — official: awaiting failover from Primary uplink under Security & SD-WAN → Configure → SD-WAN & traffic shaping → Primary uplink. Pair Event log primary uplink status change (uplink: 0 / uplink: 1) and Bad Gateway (No_lan_connectivity vs No_inet_connectivity). Historical loss to 8.8.8.8 can show 100% if ICMP is blocked upstream while the uplink still works — official. Do not declare the circuit dead from that graph alone.

If the WAN is Active and they named Salesforce, then Traffic analytics (Detailed) or client Application details. Empty analytics with Traffic analysis = Disabled / Basic is expected.

MEVD-04 — Prove the handshake (Wireless Event log / client)

02:40 · P2. Priya cannot join Corp. The SSID is up. L1 wants 802.1X disabled.

First tool: Event log for access points, Client = aa:bb:cc:dd:ee:ff. Or Clients → priya-mbp → Event log.

Proof field: 802.11 association channel / rssi then 802.1X EAP failure (or success + DHCP fail). Association without EAP success is a credential / RADIUS problem, not an MX Layer 3 deny. If every client on one AP fails DHCP, official next click is Wireless → Configure → Access Control → Client Addressing and the upstream trunk VLAN — not a PSK change.

MEVD-05 — Prove the port (RSTP + LLDP / CDP)

03:00 · P2. MR-PUNE-3F is dark. Users say the switch “killed Wi-Fi.” Someone wants RSTP disabled network-wide.

First tool: Switching → Switches → MS-PUNE-3F → Ports. Find the AP uplink. Quote the visual blocking symbol and RSTP state Blocking / STP discarding. Quote LLDP = MR-PUNE-3F so you know you have the right port. Event log for switches, type Spanning Tree / Switch port / Status.

Proof field: Blocking means RSTP is discarding to break a loop — official wording: the port discards traffic because it would introduce a routing loop. That is isolate. Disabling RSTP is how you melt the floor. CDP belongs on PoE / Voice VLAN (Power Available vs Power Consumption), not as a substitute for RSTP state.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Cisco Meraki — How to Use the Meraki Event Log (Network-wide → Monitor → Event log; combined-network drop-down; Client / Before filters; MX / MR / MS event types)
• Cisco Meraki — How to View Old Event Logs (Before field + Search)
• Cisco Meraki — VPN Status Page (Security & SD-WAN / Organization → Monitor → VPN Status; Status colours; Registry; NAT Type; exported subnets; primary-WAN caveat)
• Cisco Meraki — Site-to-site VPN Troubleshooting (VPN Status first; Unfriendly NAT; Registry Disconnected)
• Cisco Meraki — Meraki Auto VPN — Configuration and Troubleshooting
• Cisco Meraki — How to Configure MX and Z-Series Uplink Settings (Appliance status → Uplink; Active / Ready / Failed / Disabled / Not Connected)
• Cisco Meraki — Connection Monitoring for WAN Failover (Event log primary uplink; uplink: 0 / uplink: 1)
• Cisco Meraki — Next-Gen Traffic Analytics with NBAR (Network-wide → Configure → General → Traffic analysis; Detailed enables Traffic analytics; L7 deny Event log)
• Cisco Meraki — Hostname Visibility (Network-wide → Monitor → Traffic analytics; < 0.1% exclusion)
• Cisco Meraki — Common Wireless Event Log Messages and Issues (802.11 association channel/rssi; 802.1X EAP; vap/radio)
• Cisco Meraki — Troubleshooting Wireless Issues (Event log filtered by client MAC)
• Cisco Meraki — Clients List and Details Page Overview (Access point, Signal, Channel; Event log jump)
• Cisco Meraki — Event Log Shows Wireless Client Authenticating Every Hour (WPA2-Enterprise 3600 s rekey)
• Cisco Meraki — How to Monitor Switch Ports (Switching → Switches → Ports; RSTP state; blocking symbol; LLDP)
• Cisco Meraki — Switch Ports (Switching → Monitor → Switch Ports; RSTP; Voice VLAN CDP/LLDP; search lldp:"…")
• Cisco Meraki — Troubleshooting PoE on MS Switches (CDP Power Consumption / Power Request / Power Available)
• Cisco Meraki — MS Event Log Entries and Definitions (Spanning Tree, Switch port, Status)
• Cisco Meraki — Combined Dashboard Networks
• Cisco Meraki — Clients Usage Page Overview (Network-wide → Monitor → Clients)

Related: Blog 1 · Meraki session factory · Cisco Meraki interview hub · AutoVPN / SD-WAN · SSID security · MS switching · All lessons