Send netdisco-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Meraki Dashboard integration: current extension and
upstream direction (Andy Millett)
--- Begin Message ---
Hi mailing list,
I’m writing to share an update on the Meraki integration work discussed around
NetDisco issue #1369:
https://github.com/netdisco/netdisco/issues/1369
The work started from osmogr’s netdisco-meraki project, which provided a
valuable, working foundation for bringing Meraki Dashboard data into NetDisco.
We’re grateful for that initial implementation. Building on it, we’ve developed
and tested a more complete site-local extension against a NetDisco deployment:
https://github.com/osmogr/netdisco-meraki
The extension keeps SNMP discovery as NetDisco’s normal device-discovery path
and uses the Dashboard API to enrich information that SNMP does not provide
reliably. It currently provides:
- Device enrichment by a unique serial match, including firmware/software
version, chassis/serial identity, MAC address, and location, while retaining
the SNMP-discovered management IP.
- Meraki MS switch port names and state, native VLAN and VLAN membership, plus
available topology/neighbour information. MX/Z appliance VLAN interfaces,
routed addresses, and verified management CIDR data are also represented.
- Available STP and PoE state, supported power-supply inventory, and MR
access-point SSID/BSSID and radio band/channel/power data, using NetDisco’s
existing tables.
- Client MAC/IP observations through NetDisco’s native macsuck and arpnip
workers. Wired clients are placed only when the Dashboard serial and switch
port map to known NetDisco records. Wireless clients are associated with a
uniquely matched AP on a logical wireless interface, with SSID observations
stored separately. This supports the built-in AP Client Count report and adds
AP-total and AP-by-SSID reports.
- Pagination, rate-limit and transient-error handling, and snapshot
reconciliation that preserves existing data when an API response is incomplete
or invalid. A Meraki macsuck hook also reconciles VLAN 0 duplicates when a
recent API observation provides a matching nonzero VLAN.
The NetDisco integration is currently a standalone site-local extension: worker
plugins are loaded through extra_worker_plugins, the reports through
extra_web_plugins, and discovery/client data is handled in worker phases. It
does not require a NetDisco core fork or schema change. merakisync handles
initial or targeted inventory work; merakiclients handles recurring client
updates. On our test deployment we reduced the client poll to hourly because
the normal macsuck and arpnip waves already take a substantial portion of their
hourly cycle. The current client path still launches native per-device ingest
commands, so reducing that fan-out and aligning client data with normal
per-device worker processing is an important next step.
We validated the extension on a NetDisco 2.112 test host. In one client-poll
check, 1,074 current AP client associations were visible across 247 APs, and
the AP-total and per-SSID counts reconciled. This is representative validation,
not exhaustive coverage of every Meraki family or client-movement case.
Our proposed longer-term direction is to fetch and paginate each network’s
client snapshot once, stage only complete results, then let normal per-device
macsuck/arpnip workers consume the relevant observations. That should avoid a
separate command per affected device and make API data easier to schedule and
reconcile alongside NetDisco’s existing collection.
There are known limits: Dashboard does not reliably identify the client’s
physical radio band, the API does not provide the signal-quality history needed
for RSSI/SNR reporting in our test organization, and client placement reflects
the online/recent API view rather than a continuous event stream. We’re also
considering how best to align API requests with a shared NetDisco HTTP
transport if that is the project’s preferred direction.
SNMP::Info device recognition is a separate workstream in netdisco/snmp-info PR
#627; it is not part of these API integration changes:
https://github.com/netdisco/snmp-info/pull/627
I’ve asked in the original repository and issue discussion about the preferred
contribution route but haven’t yet heard back. I’d appreciate maintainers’
advice: should we prepare a draft PR against osmogr’s repository, continue this
as a separately maintained extension, or propose moving the appropriate pieces
into NetDisco itself? We want to preserve credit for the original work and
follow the project’s preferred architecture before publishing a fork or opening
a PR.
The current implementation and its detailed change history are available in our
working copy; I can provide a fork or draft PR for review once we’ve agreed on
the right destination.
Finally, it would be remiss of me not to mention that a substantial amount of
the work on this has been done with the use of Codex.
Thanks,
Andy
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
