cnMaestro Blind Spot - add SNMP polling

cnMaestro has some major blindspots in the network since it is 100% dependent on the agent running in every radio.


The number of SM’s registered to an AP should be pulled from the AP itself, rather than determined by the number of properly functioning agents on SM’s. Example: we logged into an AP that maestro showed there would be 5 SM’s, but there were 12.

Scheduled tasks to all SM’s are only good if we can hit all SM’s. We need an alert to tell us when an AP has registered SM’s that are not being managed properly by cnMaestro.

2 Likes

I don't agree with adding snmp polling between cnmaestro and the SM that doesn't solve the main issue and just adds another protocol to manage, they have the ability to run their own more efficient stat protocol and its working.

They calculate based on cnmaestro counts and that's whats annoying, but I've always said theirs an issue that the AP doesn't report it's SM count from the actual AP it reports how many SM's are attached in cnmaestro... which is nuts, it should show both "X sm on AP, X sm in CNmaestro" or something to show that hell show a minor alarm on the AP for each SM connected to the AP that isn't bootstrapped to CNMastro, that's what the alarms are for or should be.

Since the factory started shipping cnmaestro factory compatible firmware I haven't had many issues I don't think with radios not bootstrapping what reason are you having? Are your AP's not pushing the config? Or is it that you have SM's on the network with the old 13.x that didn't have cnmaestro support (i had this issue, i forced CNUT to upgrade entire network to 14.x so that cnmaestro could take over)

1 Like

I understand what you are saying and agree to most of it.  If the agent on the AP would report its stats, and/or if cnMaestro would handle that data in a way that helps us find discreprencies better; I would be good with that.  It's strange and frustrating to me that things like uptime and SM count are handled the way they are.  The SM count is a big deal because if it is wrong, and I push a job to all SM's like say a password change.  It will tell me that it was successful in its push to all the SM's....but low and behold there are some stragglers on the AP that never made it into the job.  As for software upgrades, cnut will be needed for some time yet as distributors and resellers empty their shelves of products with older firmware.  in time, you are right that snmp woudlnt be needed for that, but currently it would be nice during a full field upgrade in cnmaestro that a failed agent attempt could fall to snmp cnut style to upgrade the radio.

We have had issues with the agents themselves stopping or quitting or...not quite sure, but they hang up.  the SM's, and in some cases the AP's, are running proper code, the server address is set, but the agent wont connect.  only fix was a cnut based software upgrade.

There is more data that I would like to pull in for other reasons outside of cnMaestro where I will be using snmp, so I hope they dont remove that from the radios altogether.  Though, like you said, if i could pull it in via the agent, and could trust the agents to always work, then I would rather pull that data from the server.