Yes, i click the X for delete th SM, from the oldest SM (oldest SMs are sure SM withdrawn from the customer because replaced) but, if i sort for Health and CNMaestro doesn't sort for Health (like my last image), i can't start the cancellation, I should see all the pages because sorting seems random.
If you opened a Ticket for this problem, okay. It should be easy to fix with a patch.
PS: i have last CNMAestro On Promises.
We have done some work on out network (updating AP's from cnMaestro etc...), we have got some problems but resolved.
Now we still have many alarms from that problems (for exemple "Configuration update failed due to device timeout") and will be very useful CLEAR that messages because they increase over time.
Thank you!
Same issue of several devices with alarm, "Configuration Update Failed Due To Device Timeout". The issue seems to happen when cnMaestro *thinks* that it was unable to complete a configuration job. One specific example where a job appears to fail (but actually works) is when you change the VLAN of an ePMP SM. The job will start, the SM's VLAN will update, the SM will reassociate and get a new IP address on the new VLAN, but the job (on cnMaestro) will eventually just error out. And then the alarm stays active, forever, so it seems.
I agree with dkeltgen.
Maybe It's ok not to clear the offline devices if you, Cambium, don't want but i think remove that kind of alarm (device timeout, updates etc...) will be very useful and "clean"
We have 2700 alarms and we don't know how delete them :(
I have created a topic in "Your Ideas"
A solution for clear the Alarms? Set "Acknowledgement " isn't a solution.
I can make, almost, the birthday to this error :) 316d
1 Like
For those specific Configuration Failed alarms they can be cleared by successfully pushing configuration. Since PMP is template-based you can push a trivial template and that should result in a successful configuration update with no actual change made on the device.
Template:
{
}
I recommend testing against a lab device or single SM first to verify that the device doesn't reboot from this template. I would not expect this to cause a reboot but I prefer caution if attempting to do this on a large number of devices.
This is for future updates but is impossible clear old alarms, right?
No, this solution would work for any Configration Failed alarm, including old alarms. It would take the device out the error state by successfully pushing a configuration.
For other types of alarms view the alarm Details and check the Resolution text. It will often give a suggestion as to how to clear the alarm by bringing the device out of the error state.
1 Like
So we need to push the previous template in EVERY antenna with this error?
We have 3500 errors by now...
:|
No, not specifically the previously pushed template. It would likely fail again anyway. Any template can be pushed, including a trivial one with no functional change. As long as the job completes successfully the alarm will clear.
For example, this template should result in a successful push every time since no configuration is actually being edited. Test on a single device first to verify the device does not reboot, before doing a select-all.
{
}
What about alarms that are wrong?
GPS Software Version
GPS software is out-of-dateView Details
87d 14h 15m
ACTIVE
But yet on the AP...
Version
AXN_5.1._8174
GPS firmware is up-to-date
It's working!!!
Thank you Jordan, now i have only 640 errors :D
Is possible insert this template in a previous template to avoid pushing 2 templates for every device?
I suggest anyway a clear alarm button (maybe that keep offline devices as alarm but clear the others alarms like configuration updates etc...)
Rynet, we recently made an update to fix this in 1.6.1, the latest release, so "AXN_5.1._8174" is recognized as up-to-date. The alarm should automatically clear itself the next time the device registers to cnMaestro.
Cloud is already running 1.6.1. Are you running in cloud or on-premises?
Telemar, merging that empty template with a previous template wouldn't change anything since the template is blank. Is it correct to assume you mean automatically pushing the blank template immediately after pushing your other template in order to clear a configuration failure alarm?
If that is the case, I do not think it is the correct approach. If the template you're pushing results in configuration failure every time then I think there is something that must be corrected on that end rather than trying to clear alarms with this work around.
What is the failure error in the configuration job when you push the template you mentioned?
"Configuration update failed due to device timeout"
BTW the update works well but the alarm grows with that error.
Please email me a copy of the template that fails to jordan.stipati [.at.] cambiumnetworks.com. Also let me know what type of device this template is for (PMP or ePMP).
The configuration push should not fail by timeout if the configuration change is in fact applied to the device correctly.
@Jordan wrote:...The configuration push should not fail by timeout if the configuration change is in fact applied to the device correctly.
Yes, but neither should successful software upgrades. CNUT comes to mind.
Luis, are you talking about timeout failures in cnMaestro or a separate issue in CNUT?
Cnut, but maybe both actually.
When I last upgraded the firmware I got indications that the updates had failed. However, when I would go to the SM to see what happened, the unit was successfully updated. Returning to CNUT and doing a refresh would clear the "failures". If I remember correctly this also happened with cnMaestro, of course there's no way to "refresh" once the job showed as failed. The cnMaestro part I'll have to confirm when I upgrade to 15.2.
This reminds me, when is 15.2 comming out? ;)