Cisco Meraki
Read the Meraki estate (access points, switches and MX appliances) into the network pane over the Dashboard API v1. Read only.
| Category | Network |
| Authentication | Dashboard API key |
| Reaches | api.meraki.com |
| Needs an agent | No |
| Demo mode | Yes, off by default |
Capabilities
Section titled “Capabilities”network.listSites, network.listDevices, network.getDevice,
network.listUplinks, network.listClients, network.listEvents
Which lights up the network page, gated by the module.network
module.
Meraki is one of only two network connectors that reach a cloud API, so a managed deployment can run it with no agent at all.
Preparing Meraki
Section titled “Preparing Meraki”Create a dedicated read-only dashboard administrator for this. It matters more here than with most connectors: a Meraki API key inherits the permissions of the administrator it belongs to and cannot be scoped down. A key made from a full-access account is a full-access key sitting in our vault, and there is no control we can apply from this side.
- In the Meraki dashboard, Organization, Administrators: add an administrator with read-only organisation access.
- Sign in as that administrator, then My Profile, API access: generate an API key. It is shown once.
- Organization, Settings, Dashboard API access: make sure API access is enabled for the organisation.
- Note the organisation ID. It is in the dashboard URL, or from
GET /organizations.
Configuring it in Plugboard
Section titled “Configuring it in Plugboard”Admin, Connectors, Cisco Meraki, Configure.
Settings
Section titled “Settings”| Field | Default | Value |
|---|---|---|
baseUrl |
https://api.meraki.com |
The Dashboard API host. Leave it alone unless Meraki tells you otherwise |
organizationId |
empty | Your Meraki organisation ID |
demoMode |
false |
Return a sample network, making no API calls |
Configure the host here, not a versioned path. https://api.meraki.com/api/v1
produces a 404 that reads exactly like a bad API key.
Secrets (encrypted)
Section titled “Secrets (encrypted)”| Field | Value |
|---|---|
apiKey |
The dashboard API key from the read-only administrator |
What you get
Section titled “What you get”| Networks | Every Meraki network in the organisation, ready to map to a campus |
| Devices | Access points, switches and appliances with model, serial, MAC, LAN IP and firmware |
| Status | Online, offline, alerting or dormant, with the time it was last reported |
| WAN uplinks | Per interface, with status and public IP |
| Clients | Optional, and only when client tracking is on |
| Events | Recent network events |
Alerting counts as up. A device that is alerting is reachable and reporting. It has a problem the Meraki dashboard should show, not a connectivity problem your desk should be paged for. Mapping it to down would fire your outage alerting for a whole comms cupboard every time one switch ran warm.
A status Meraki reports that we do not recognise comes back as unknown, never as down.
What it cannot do
Section titled “What it cannot do”- Write anything. Read only, by construction. There is no capability here that changes a Meraki configuration.
- Report uplink loss and latency. Those live on a separate per-network time-series endpoint that is expensive against the rate limit. The pane says “not reported” rather than showing a zero somebody reads as a perfect link.
- Cover two organisations. One connector instance per school. A Meraki organisation already contains many networks, so one instance covers every campus, but a school with one organisation per campus after a merger cannot configure two.
- Report client counts per device on the inventory pass. Client counts come from the client capability, which is off unless you turn tracking on.
The rate limit is the thing to understand
Section titled “The rate limit is the thing to understand”Meraki allows ten requests per second per organisation, bursting to thirty in two seconds, and that budget is shared across every application touching the organisation, including whatever else your school already runs against it.
This connector is built around that. It asks organisation-wide questions in preference to per-network ones wherever Meraki offers both, so one call covers every device on every campus instead of one call per campus per poll.
What you should not do is hold down Refresh from every connector on the network pane. That spends your allowance on your key, and Meraki’s rate limit lands on your school, not on us. The pane limits the button for that reason, and the background sweep polls without being asked.
Troubleshooting
Section titled “Troubleshooting”| Symptom | Cause |
|---|---|
| A sample network appears | demoMode is still on |
| 404 on everything | baseUrl carries a path. Set the host only |
| 401 or “invalid API key” | The key was revoked, or belongs to an administrator who has been removed |
| Connection test passes, no devices | Wrong organizationId, or the administrator has no access to that organisation |
| Some campuses missing | Their Meraki networks are not mapped to a Plugboard campus yet |
| 429 from Meraki | Something else is using the same organisation’s allowance. Stop refreshing by hand |
| Devices appear with no campus | Map each Meraki network to a campus on the network pane |
| No clients, ever | Client tracking is off. It is off until an administrator turns it on |
Related
Section titled “Related”UniFi and network hardware over SNMP fill the same pane. All three run at once and are merged. A school with Meraki wireless and Cisco switches should configure both, and they share one connector slot.