This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Thin AP down alert unreliable

Hi All

Having trouble getting the thin AP down alert working consistently (on Cisco 5508 controller). As I understand it, the way it should work is this: when NPM sees that an AP that was previously there has gone, it is marked as down (or unknown?) Next time it polls, if the AP is still missing, it is removed from the list of APs altogether.

So, I'm trying to get the out-of-the-box alert working to tell me when this happens. However, it only seems to work maybe 1 time out of 10. I've tried adjusting the timings to try and compensate for the fact that the APs are only down/unknown temporarily. I've changed the polling interval on the controller to 120 seconds, whilst the alert is checked every 15 seconds and is supposed to trigger if the conditions are true for more than 1 second.

However, if I deliberately shut down an AP and keep refreshing the page, I can see the AP transition to down/unknown (with the grey symbol) and stay that way for approximately 2 minutes before disappearing. During this time, the alert is never sent, although a separate event is logged saying thin AP disappeared.

But every now and then, the alert will be triggered because an AP has dropped off and I will get the alert email. Which is great, but the fact that I am unable to reproduce this on demand doesn't exactly fill me with confidence that I'm actually going to be notified when an AP drops off.

I saw in another thread that the trigger condition should actually be if the status is unknown, as opposed to down, which is what it's set to by default. However I've tried both with no joy. Possibly the weirdest part is that it does seem to work intermittently.

Is anyone else using this and have they managed to get it working reliably?

I'm using NPM 10.6.1.

Thanks!

Paul

  • What he said........ same issues here.

  • How it works:

    1. When the controller reports the APs as Down (we poll the status from OID), AP is Down in NPM

    2. When the controller does not report the AP anymore (we are not able to poll the AP), AP is Disappeared in NPM

    3. When "RemoveDisappearedAPs" is set to True in  \SolarWinds\Orion\WirelessSolarWinds.Wireless.Collector.dll the Disappeared AP is removed from NPM with next poll

    4. When "RemoveDisappearedAPs" is set to False in  \SolarWinds\Orion\WirelessSolarWinds.Wireless.Collector.dll the Disappeared AP is NEVER removed from NPM


    Advanced Alert "Alert me when a Thin Wireless Access Point goes down" is triggered only for Down APs and as Trigger Action is used "Log the Alert to the NetPerfMon Event Log".

    Event "Thin AP Disappeared" is generated only for disappeared APs (this has nothing to do with Advanced Alert).


    If you would like to trigger Advanced Alert "Alert me when a Thin Wireless Access Point goes down" also for APs that are in state Disappeared, just edit the existing alert. The trick is: Disappeared=Unknown in Advanced Alert Manager.

    APAlert.png


  • Thanks for the info, very informative. I've changed it to unknown or down and it seems to be alerting more consistently now.


    However, I do have a couple of follow-up questions:

    • If I set RemoveDisappearedAPs to false, is there a way to delete them manually? I can see it being useful being able to always see which APs are currently missing, but obviously if one is decommissioned you wouldn't want to see it.
    • Getting it to alert on reset is still not really working. I had a bunch of AP down alerts overnight but only one AP reconnected alert, even though they all rejoined. I guess if an AP has been removed there is nothing to really reset as such. I wonder if maybe a completely separate 'AP connected' alert would be better?
    • No, you can not delete them via web console (new feature request?) You can delete them directly from database with SQL but I don't advice you to do it.
    • The alert with new Status Condition has only sense when RemoveDisappeardeAPs is set to False. That could be the reason why only the Event is generated for disappeared APs by default and it is not used in Advanced Alert. When the AP is removed from device and it come later back, it has different ID in database and can not be mapped to triggered alert.
  • Noob question on an old-ish post...

    When you say edit \SolarWinds\Orion\WirelessSolarWinds.Wireless.Collector.dll do you really mean \SolarWinds\Orion\WirelessSolarWinds.Wireless.Collector.dll.config or do I need to edit the DLL to set RemoveDisappearedAPs?

    Follow-up: What are the steps to apply the setting (ie restart which services, etc.)?

    Thanks.

  • yes, the config file.

    NOTE!!!

    a) when you upgrade the value will be reverted, and if you do not change it quickly enough all of your historical AP are deleted

    b) if you have a primary/backup controller configuration solarwinds records twice the number of AP you actually have. They will be either be down or deleted on the backup controller, so the choice is either:

    1. bad AP-down alerts

    or

    2. bad- Ap-down alerts and you lose AP-related historical statistics

    emoticons_cry.png