It’s not neighbors, the Meraki cloud controller mib exposes all of its managed devices for that organization/network.
Even if the device is powered off (as shown in output below, device is not online).
You can’t even utilize the IP address to do snmp discovery on either since all devices will show its natted/public IP address (the ip address Meraki cloud sees the device connecting from).
I’m not sure if it is exposed, but the devices also run LLDP and CDP in addition to this and this would be physical neighbors, but I highly doubt this is included in SNMP of the cloud controller.
You could (like Adam suggested) treat this somehow as the WLC controller implementation and show devices statuses in a subpage/tab, but this would be very specific to Meraki and the code would not re-usable for any other environments (kinda like Citrix netscaler implementation with its vservers / service groups / services)
And then there is also the second issue, how would you add two environments, ALL controller SNMP queries must be sent to snmp.meraki.com:16100 with a user generated by Meraki (and assigned to your organization)
In our case we have dozens of organizations, we would not be able to add them or we would have to add them uniquely by setting a wildcard cname to snmp.meraki.com (eg. CNAME *.meraki.customer.xyz snmp.meraki.com) and add each organization uniquely (for example customer-x.meraki.customer.xyz:16100)
And then pray that snmpengineID is unique also, else observium rejects it (you could workaround this by injecting the entry manually in db, done it before for some edge case where 2 devices report same snmpengineid <.>).
Anyhow we didn’t even suggest implementing it this way as we thought it would be too much of an edge case considering how devices are monitored now in observium.
If Mike or Adam still feel up to this challenge, you can count us in to test and provide plenty of test environments, we run pretty much every product of Meraki somewhere.
Kind regards
From: observium <observium-bounces@observium.org> On Behalf Of Mike Stupalov via observium
Sent: Saturday, September 12, 2020 12:55
To: Observium <observium@observium.org>; Adam Armstrong via observium <observium@observium.org>
Cc: Mike Stupalov <mike@observium.org>
Subject: Re: [Observium] Inventorying Merakis
Adam Armstrong via observium wrote on 11.09.2020 19:24:
It’s not neighbours, it’s inventory. These are downstream components of the controller.
No, this is exactly network attached neighbors (to this controller).
Inventory is modules inside device and/or stacked devices.
There are even remote ip addresses and interfaces (and remote hostname, platform, sysname)
through which these devices are connected.
All as for other neighbors protocols :)
Example:
MERAKI-CLOUD-CONTROLLER-MIB::devMac.2.2.0.96.5.120 = Hex-STRING: 02 02 00 60 05 78
MERAKI-CLOUD-CONTROLLER-MIB::devName.2.2.0.96.5.120 = STRING: Health Center, SE
MERAKI-CLOUD-CONTROLLER-MIB::devStatus.2.2.0.96.5.120 = INTEGER: offline(0)
MERAKI-CLOUD-CONTROLLER-MIB::devContactedAt.2.2.0.96.5.120 = STRING: 2011-6-9,20:26:14.0,+0:0
MERAKI-CLOUD-CONTROLLER-MIB::devClientCount.2.2.0.96.5.120 = INTEGER: 0
MERAKI-CLOUD-CONTROLLER-MIB::devMeshStatus.2.2.0.96.5.120 = INTEGER: gateway(0)
MERAKI-CLOUD-CONTROLLER-MIB::devPublicIp.2.2.0.96.5.120 = IpAddress: 98.173.209.211
MERAKI-CLOUD-CONTROLLER-MIB::devSerial.2.2.0.96.5.120 = STRING: VRT-2207619483000
MERAKI-CLOUD-CONTROLLER-MIB::devProductCode.2.2.0.96.5.120 = STRING: MR16-HW
MERAKI-CLOUD-CONTROLLER-MIB::devProductDescription.2.2.0.96.5.120 = STRING: Meraki MR16 Cloud Managed AP
It’d not make sense in neighbours, neighbours are physical links.
Adam.
From: observium <observium-bounces@observium.org> On Behalf Of Mike Stupalov via observium
Sent: 11 September 2020 17:17
To: Observium <observium@observium.org>; Lars Joergensen via observium <observium@observium.org>
Cc: Mike Stupalov <mike@observium.org>
Subject: Re: [Observium] Inventorying Merakis
Hi,
I think this is more useful as "Neighbours" discovery (like LLDP/CDP)..
Lars Joergensen via observium wrote on 10.09.2020 10:58:Hi Mike,
There’s more in the controller. A few examples:
MERAKI-CLOUD-CONTROLLER-MIB::networkName.45.55.105.66.69.97.111.101 = STRING: INMUM
MERAKI-CLOUD-CONTROLLER-MIB::devName.104.58.30.30.159.8 = STRING: INMUM-MX-01
MERAKI-CLOUD-CONTROLLER-MIB::devClientCount.104.58.30.30.103.216 = INTEGER: 21
MERAKI-CLOUD-CONTROLLER-MIB::devSerial.104.58.30.30.103.216 = STRING: Q2KN-XXXX-XXXX
MERAKI-CLOUD-CONTROLLER-MIB::devProductCode.104.58.30.30.103.216 = STRING: MX64-HW
MERAKI-CLOUD-CONTROLLER-MIB::devProductDescription.104.58.30.30.103.216 = STRING: Meraki MX64 Cloud Managed Router
MERAKI-CLOUD-CONTROLLER-MIB::vlanNumber.105.55.67.49.117.98.111.101.1 = INTEGER: 1
MERAKI-CLOUD-CONTROLLER-MIB::vlanNumber.105.55.67.49.117.98.111.101.15 = INTEGER: 15
MERAKI-CLOUD-CONTROLLER-MIB::vlanNumber.105.55.67.49.117.98.111.101.16 = INTEGER: 16
MERAKI-CLOUD-CONTROLLER-MIB::vlanNumber.105.55.67.49.117.98.111.101.510 = INTEGER: 510
MERAKI-CLOUD-CONTROLLER-MIB::vlanName.105.55.67.49.117.98.111.101.1 = STRING: Data
MERAKI-CLOUD-CONTROLLER-MIB::vlanName.105.55.67.49.117.98.111.101.15 = STRING: Voice
MERAKI-CLOUD-CONTROLLER-MIB::vlanName.105.55.67.49.117.98.111.101.16 = STRING: Misc
MERAKI-CLOUD-CONTROLLER-MIB::vlanName.105.55.67.49.117.98.111.101.510 = STRING: Guest
But, as Adam said, pulling it looks like an absolute shitfest of a nightmare. I will get our inventory guys to pull via the Meraki dashboard APIs instead.
Lars
From: observium <observium-bounces@observium.org> On Behalf Of Mike Stupalov via observium
Sent: 9. september 2020 17:31
To: Observium <observium@observium.org>; Adam Armstrong via observium <observium@observium.org>
Cc: Mike Stupalov <mike@observium.org>
Subject: Re: [Observium] Inventorying Merakis
Adam Armstrong via observium wrote on 09.09.2020 18:06:I think he means SNMP to the Meraki controller, not to the individual devices.
I also mean Meraki controller, answer same.
I have access to any Meraki device(s) ;)
In general supporting wireless stuff is an absolute shitfest of a nightmare, but maybe pulling just the inventory wouldn’t be too horrible.
Adam.
From: observium <observium-bounces@observium.org> On Behalf Of Mike Stupalov via observium
Sent: 09 September 2020 15:22
To: Observium <observium@observium.org>; Lars Joergensen via observium <observium@observium.org>
Cc: Mike Stupalov <mike@observium.org>
Subject: Re: [Observium] Inventorying Merakis
Lars Joergensen via observium wrote on 09.09.2020 16:17:Hi Mike,
Meraki does provide full SNMP access to their dashboard – that’s what I added into Observium. It’s just that Observium doesn’t seem to know about it. I can provide the MIB if interested?
Meraki have very-very limited snmp support, there no inventory information inside.
We are already detecting and monitoring everything that is possible for these devices.
They also have an extensive API, but I guess SNMP is more in line with what observium does.
Lars
From: Mike Stupalov <mike@stupalov.ru> On Behalf Of Mike Stupalov
Sent: 9. september 2020 13:55
To: Observium <observium@observium.org>; Lars Joergensen via observium <observium@observium.org>
Cc: Lars Joergensen <DKLARJ@chr-hansen.com>
Subject: Re: [Observium] Inventorying Merakis
Hi,
Lars Joergensen via observium wrote on 09.09.2020 14:11:Hi
We have a bunch of Merakis in Observium, and we got the nice graphs and stuff. Then somebody asked for serial numbers for inventory purposes, and … they’re not there.
I did an SNMP walk on a single Meraki device, and that’s really sparse, explaining the lack of info in Observium. Then I added the Meraki dashboard (available at snmp.meraki.com), and let Observium have a look at that. It basically told me that it resides in San Francisco. Doing an SNMP walk on that does reveal all the necessary info, though, so it is there.
Any plans on parsing the Meraki dashboard into Observium and get info on devices that way? If not, we can pull the serials from elsewhere, but it would be cool to know if it’s coming.
Parsing any dashboard (any web page) for any device completely pointless occupation.
These pages are dynamic, they can change at the whim of the manufacturer.
The only possible option (besides snmp) any common (documented) API.
But as I know, Meraki doesn't even support that.
Disclaimer: This e-mail, including any attachments, is for the intended recipient only. If you have received this e-mail by mistake please notify the sender immediately by return e-mail and delete this e-mail and any attachments, without opening the attachments, from your system. Access, disclosure, copying, distribution or reliance on any part of this e-mail by anyone else is prohibited. This e-mail is confidential and may be legally privileged. Chr. Hansen does not represent and/or warrant that the information sent and/or received by or with this e-mail is correct and does not accept any liability for damages related thereto. https://www.chr-hansen.com/en/legal-notice
_______________________________________________observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
Mike Stupalov
Observium Limited, http://observium.org
_______________________________________________observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
Mike Stupalov
Observium Limited, http://observium.org