Meraki

---
name: meraki
description: "Expert coverage of Cisco Meraki cloud-managed networking: Dashboard management, MX security/SD-WAN, MS switches, MR wireless, AutoVPN, Dashboard API v1, action batches, licensing, and hybrid deployment patterns. Use for \"Meraki\", \"Meraki Dashboard\", \"AutoVPN\", \"MX appliance\", \"MS switch\", \"MR access point\", \"Meraki API\", \"cloud-managed network\", \"Meraki SD-WAN\", \"vMX\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `routing-switching` skill."
license: MIT
---

# Cisco Meraki

This skill covers Cisco Meraki cloud-managed networking across all product families. Areas of expertise include:

- Meraki Dashboard (SaaS management plane) and organizational hierarchy
- MX security and SD-WAN appliances (firewall, AutoVPN, IDS/IPS, content filtering)
- MS managed switches (port profiles, VLANs, stacking, L3 routing)
- MR wireless access points (SSIDs, RF management, Air Marshal, splash pages)
- Dashboard REST API v1 for programmatic management
- Action Batches for bulk API operations
- Webhooks for real-time event notification
- MT IoT sensors and MV smart cameras
- Licensing models (co-term vs per-device, MX license tiers)
- Hybrid deployments (Meraki + traditional networking)
- When to choose Meraki vs traditional (Catalyst, Nexus, Juniper)

## How to Approach Tasks

1. **Classify** the request:
   - **Design** -- Load `references/architecture.md` for Dashboard hierarchy, AutoVPN topology, product selection
   - **Configuration** -- Provide Dashboard GUI paths and API endpoints
   - **Troubleshooting** -- Use Dashboard tools (live tools, event log, packet capture) and API
   - **Automation** -- Apply Dashboard API v1, action batches, webhook, or Meraki Python SDK guidance
   - **Best practices** -- Load `references/best-practices.md` for API patterns, network design, licensing, Meraki vs traditional

2. **Gather context** -- Number of sites, device types (MX/MS/MR), existing network infrastructure, internet connectivity at each site, licensing tier

3. **Analyze** -- Apply Meraki-specific reasoning. Meraki's cloud-managed model has different constraints than traditional networking (no direct CLI, limited protocol customization, cloud dependency).

4. **Recommend** -- Provide Dashboard GUI paths, API endpoints, or SDK examples. Always note when a feature requires a specific license tier.

5. **Verify** -- Suggest Dashboard live tools, event log, or API queries to validate configuration

## Core Architecture

### Cloud-Managed Model

Every Meraki device maintains a persistent HTTPS connection to Meraki's cloud infrastructure:
- Configuration stored entirely in Meraki cloud (no on-premises management server)
- Configuration changes pushed to devices within seconds of Dashboard save
- If cloud connectivity is lost, devices continue forwarding with last-known configuration
- Management plane is cloud-dependent; data plane operates independently
- All management traffic uses TCP 443 (HTTPS) and TCP/UDP 7351

### Organizational Hierarchy

```
Organization (company or MSP customer account)
  |- Network (logical site grouping)
  |    |- MX Appliance
  |    |- MS Switches (can be stacked)
  |    |- MR Access Points
  |    |- MT Sensors
  |    |- MV Cameras
  |
  |- Network (another site)
  |    |- ...
  |
  |- Templates (configuration templates applied to multiple networks)
```

- **Organization**: Top-level container. API key scoped to org.
- **Network**: Logical site. Can be combined (appliance + switch + wireless in one network) or split.
- **Templates**: Apply consistent configuration across networks (SSIDs, firewall rules, VLANs). Template changes propagate to all bound networks.
- **Tags**: Label networks and devices for filtering and bulk operations.

### Dashboard Access

- URL: `dashboard.meraki.com`
- Authentication: Email/password + optional SAML/SSO
- RBAC: Organization Admin, Network Admin, or custom roles with granular permissions
- Audit log: tracks all configuration changes with user, timestamp, and details

## MX Security and SD-WAN

### Stateful Firewall

- Layer 3/7 firewall rules (source, destination, protocol, port, application)
- Inbound and outbound rules per VLAN/subnet
- Geo-IP blocking: deny traffic by country
- Application-aware rules using NBAR-like DPI

### AutoVPN

Automated IPsec VPN between MX appliances:

**How it works:**
1. Each MX registers its public IP and local subnets with Meraki cloud
2. Cloud orchestrates IKE/IPsec parameters between peers
3. Tunnels established automatically -- no manual IKE/IPsec configuration
4. Topology: Hub-and-Spoke or Full Mesh

**Hub-and-Spoke:**
- Spoke MX forwards all or specific traffic to hub MX
- Hub handles inter-site routing, centralized firewall, internet breakout
- Multiple hubs supported for redundancy (primary and secondary)

**Full Mesh:**
- Direct spoke-to-spoke tunnels
- Lowest latency between branches
- More tunnels but no hub bottleneck

**Configuration:**
```
Security & SD-WAN > Site-to-site VPN
  VPN mode: Hub (Mesh) or Spoke
  Hubs: Select hub networks (if spoke)
  Subnets: Auto-detected from VLANs; toggle participation per subnet
```

### SD-WAN Traffic Shaping

- Per-application traffic shaping with bandwidth limits (upload/download)
- Priority levels: High, Normal, Low
- WAN link preferences: steer apps over preferred WAN link (e.g., voice over MPLS, bulk over broadband)
- Health monitoring: continuous latency, jitter, and packet loss per WAN link
- Automatic failover when link health degrades below threshold

### IDS/IPS

- Snort-based engine with Cisco Talos signatures (auto-updated)
- Modes: Detection (log), Prevention (block), Disabled
- Custom allow-lists for false positives
- **Requires**: Advanced Security or Secure SD-WAN Plus license tier

### Content Filtering

- Category-based URL filtering (Cisco Talos)
- SafeSearch enforcement for search engines
- HTTPS inspection (requires certificate deployment)
- Custom allow/deny lists

### MX Models

| Model | Max Users | Stateful Throughput | Use Case |
|---|---|---|---|
| MX67/MX68 | 50/300 | 450/750 Mbps | Small branch |
| MX84 | 500 | 500 Mbps | Mid-size branch |
| MX95/MX105 | - | 1/3 Gbps | Branch and campus edge |
| MX250/MX450 | - | 6/10 Gbps | Data center / campus |
| vMX | - | Varies | AWS, Azure, VMware virtual deployment |

### Non-Meraki VPN Peers

MX supports site-to-site VPN to non-Meraki endpoints:
- Manual IPsec configuration (IKE version, encryption, DH group, PSK)
- Supports BGP-over-VPN for dynamic routing (limited BGP features)
- Use case: Connect Meraki branch to traditional HQ firewall (ASA, Palo Alto, FortiGate)

## MS Managed Switches

### Port Profiles

Reusable port configurations applied to switch ports:
- VLAN assignment (access or trunk)
- PoE settings (enabled/disabled, power budget)
- STP settings (PortFast, BPDU Guard)
- Port scheduling (time-based PoE)
- Apply profiles in bulk via Dashboard or API

### Layer 3 Routing

Select MS models support inter-VLAN routing:
- MS250, MS350, MS355, MS390, MS410, MS425
- Static routes and OSPF (MS390 with firmware 16+)
- Configure SVIs (Switch Virtual Interfaces) with IP addresses
- Useful for local routing at branch sites without a dedicated router

### Stacking

Physical stacking for high availability:
- MS390: up to 8 switches per stack
- MS410/MS425: up to 4 switches per stack (virtual stacking)
- Stack acts as a single logical switch in Dashboard
- Automatic failover if a stack member fails

### Key Features

- RSTP/MSTP spanning tree
- QoS: DSCP marking, CoS queuing
- ACLs: per-port and VLAN-based access control
- Dynamic ARP Inspection, DHCP Snooping, IP Source Guard
- RADIUS/MAB/802.1X per-port authentication
- Adaptive Policy: SGT-like segmentation using group policies (requires MR + MS390)

## MR Wireless Access Points

### SSID Configuration

- Up to 15 SSIDs per AP
- Authentication: WPA2/WPA3 PSK, 802.1X (RADIUS), open, MAC-based
- VLAN assignment per SSID
- Bandwidth limits per SSID and per client
- Client isolation: prevent client-to-client communication on same SSID

### RF Management

- Auto channel and power (Radio Resource Management)
- Band steering: guide dual-band clients to 5 GHz
- Channel bonding: 20/40/80/160 MHz channel widths (Wi-Fi 6/6E)
- Floor plan upload with AP placement visualization and coverage heatmaps

### Air Marshal

Dedicated RF scanning for wireless security:
- Rogue AP detection and classification
- Rogue AP containment (deauthentication of clients connected to rogues)
- Wireless intrusion detection
- Configurable alert thresholds

### Packet Capture

Remote on-AP packet capture accessible from Dashboard:
- Capture on specific SSID, AP radio, or wired uplink
- Download PCAP file for Wireshark analysis
- No need for on-site engineer

## Dashboard REST API v1

### Base Configuration

```
Base URL: https://api.meraki.com/api/v1
Authentication: X-Cisco-Meraki-API-Key: <api_key>
Content-Type: application/json
```

### Resource Hierarchy

```
/organizations
/organizations/{orgId}/networks
/organizations/{orgId}/devices
/networks/{networkId}/devices
/networks/{networkId}/clients
/networks/{networkId}/appliance/vlans
/networks/{networkId}/appliance/firewall/l3FirewallRules
/networks/{networkId}/switch/accessPolicies
/networks/{networkId}/wireless/ssids
/devices/{serial}/switchPorts
```

### Common Operations

```bash
# List organizations
GET /organizations

# List networks in org
GET /organizations/{orgId}/networks

# Get device details
GET /devices/{serial}

# Update switch port
PUT /devices/{serial}/switch/ports/{portId}
Body: {"vlan": 100, "type": "access", "poeEnabled": true}

# Get live clients
GET /networks/{networkId}/clients?timespan=3600

# Update firewall rules
PUT /networks/{networkId}/appliance/firewall/l3FirewallRules
Body: {"rules": [{"comment":"Block Telnet","policy":"deny","protocol":"tcp","destPort":"23","destCidr":"Any","srcPort":"Any","srcCidr":"Any"}]}

# Get VPN status
GET /organizations/{orgId}/appliance/vpn/statuses
```

### Rate Limiting

- Default: 10 API calls per second per organization
- Rate limit response: HTTP 429 with `Retry-After` header
- Meraki Python SDK handles rate limiting automatically with exponential backoff
- Use action batches for bulk operations to reduce API call count

### Pagination

Large result sets use cursor-based pagination:
```
Response Header: Link: <https://api.meraki.com/api/v1/...?startingAfter=xxx>; rel=next
```

Follow the `rel=next` link until no more pages remain.

### Action Batches

Bulk API operations in a single atomic call:
- Up to 100 actions (synchronous) or 1000 actions (asynchronous)
- All-or-nothing: if any action fails, the batch rolls back
- Use cases: mass VLAN deployment, bulk port configuration, multi-site firewall updates

```python
import meraki
dashboard = meraki.DashboardAPI('<api_key>')
dashboard.organizations.createOrganizationActionBatch(
    organizationId='12345',
    actions=[
        {'resource': '/networks/L_111/appliance/vlans',
         'operation': 'create',
         'body': {'id': 10, 'name': 'Prod', 'subnet': '10.0.10.0/24',
                  'applianceIp': '10.0.10.1'}},
        {'resource': '/networks/L_222/appliance/vlans',
         'operation': 'create',
         'body': {'id': 10, 'name': 'Prod', 'subnet': '10.0.11.0/24',
                  'applianceIp': '10.0.11.1'}},
    ],
    confirmed=True,
    synchronous=False
)
```

### Webhooks

Real-time event notifications via HTTP POST:
- Configure: Network > Alerts > Webhooks
- Events: device offline, VPN tunnel change, client association, IDS/IPS alert
- Payload: JSON with event type, timestamp, organization, network, and device context
- Shared secret for payload validation

## Licensing

### Per-Device Licensing (Current Model)

- Each device has its own license term (1, 3, 5, or 7 years)
- Different devices can have different expiry dates
- Licenses reusable -- can be reassigned to replacement hardware
- Default for new organizations

### MX License Tiers

| Tier | Features |
|---|---|
| **Enterprise** | SD-WAN, AutoVPN, content filtering, traffic shaping |
| **Advanced Security** | Enterprise + IDS/IPS, AMP, URL category filtering |
| **Secure SD-WAN Plus** | Advanced Security + Meraki Insight (WAN/app health monitoring) |

**All MX devices in an organization must have the same license tier.**

### License Expiration

- Meraki devices become non-functional 30 days after license expiration
- Dashboard access is revoked for expired organizations
- Devices stop receiving configuration updates
- **Critical**: Plan license renewals well in advance. Meraki is a subscription service.

## Common Pitfalls

1. **Cloud dependency underestimated** -- All configuration requires internet access to Dashboard. If WAN connectivity to Meraki cloud fails, existing config continues but no changes can be made. Plan for WAN redundancy at critical sites.

2. **AutoVPN subnet conflicts** -- AutoVPN advertises all local subnets automatically. Overlapping subnets at different sites cause routing conflicts. Plan CIDR allocation carefully across all sites.

3. **MX license tier mismatch** -- All MX devices in an org must share the same license tier. Upgrading one MX to Advanced Security requires upgrading all MX devices.

4. **API rate limiting** -- 10 calls/second per org is easily exceeded with multi-site automation scripts. Use action batches for bulk operations and implement exponential backoff.

5. **Template binding gotchas** -- Changes made directly to a template-bound network are overwritten when the template pushes. Make all changes in the template, not the bound network.

6. **Missing PoE budget planning** -- MS switches have finite PoE power budgets. Adding more APs or phones than the budget supports causes unpredictable power cycling. Check Dashboard > Switch > PoE before deploying new powered devices.

7. **Expecting CLI access** -- Meraki devices have no traditional CLI. Engineers accustomed to Cisco IOS must adapt to Dashboard-only management. Local status page (my.meraki.com) provides limited diagnostics only.

8. **vMX throughput expectations** -- vMX virtual appliances have lower throughput than physical MX. Size appropriately for cloud workloads. vMX is not a replacement for a physical MX at a high-traffic site.

## Reference Files

Load these when you need deep knowledge:

- `references/architecture.md` -- Dashboard internals, device-to-cloud communication, AutoVPN mechanics, product family details, template system. Read for architecture and design questions.
- `references/best-practices.md` -- API patterns, network design, licensing strategy, Meraki vs traditional decision framework, hybrid deployment guidance. Read for design and operations questions.