This behavior is by design. DOWN APs should still remain down and the alert should work fine for them. Only change is that we are removing APs, which are not mentioned in SNMP response we get from controller. We marked such APs as DOWN in previous versions, but it was causing false DOWN alerts. In 10.2 we are polling bsnAPIfOperStatus (1.3.6.1.4.1.14179.2.2.2.1.12) to decide whether an AP is UP or DOWN and we are removing thin APs that are no longer in controller's SNMP response.
Then I am doing something wrong? I have only the controller(s) being monitored and via this monitor it polls the APs that are attached and shows them as all up. I simulated an AP failure by unplugging it from the network, it is then removed from the AP listed associated with that controller and my list has no “down” APs and I get no alerts.
Ok. Could you please open a support ticket, so we can further investigate your issue. We will need two snmp walks of your controller. Create first walk when all thin APs are UP in Orion and second snmp walk + diagnostics after you unplug one AP and Orion removes it from the list. Please, use our tool (<Orion install directory>\SnmpWalk.exe) when doing snmp walks.
Afsprau--
Upon opening a support ticket would you please post back with the ticket number and any solutions you receive from support?
It is much appreciated!
DH
After working with support for a couple of weeks on this and providing diagnostics support has come to the conclusion that is it working as designed. They have given me a SQL workaround that makes Solarwinds perform more like it did before the 10.2 upgrade. I have not done this workaround yet and still question whether I want to.
To other users of NPM 10.2 for wireless monitoring, how do you use the software? Do you monitor thin client APs and if so are you able to alert on when an AP goes down, or does the thin AP completely disappear from Solarwinds when it dies?
I am trying to determine if NPM is a viable option to monitor my wireless environment, in my current setting it seems like it is not. I want to make sure that I am not doing something different from a wireless perspective that is causing my issues.
See my feature request here - Wireless AP Monitoring Enhancements
I find the usability of the wireless monitoring in Orion useless. We've rarely had it successully tell us when an AP went down or become disassociated with the controller. 10.2 only makes the problem worse.
What we want to see is:
Thank you,
That is my same exact thought. I have 1000 APs spread across 40 sites and do not want to add each thin AP to NPM. The benefit of using a thin AP and a controller is centralized management and monitoring … When a site adds an AP it auto associates with the controller onsite and should show up in NPM.
WCS can identify when an AP has gone done, even though it has been disassociated with the controller, when an AP actually is removed manual intervention to remove it is okay. This is what is needed before wireless in NPM is useful. As of right now we will be looking for a different vendor for a workable solution.
Thank you all for your thorough input.
We are looking at this (91415)
Throw me into this one! I have some Aruba Controllers in addition to several Cisco WISMs. The Cisco's seem to still alert me when a thin client goes down, but I am getting nothing on the Aruba's now (I was before 10.2). I upgraded to 10.2.1 today just hoping it would fix my problems but no dice. I sort of like being able to see the down and up AP's in the view, and we actually had great success polling our controllers and getting down and up alerts for the Aruba AP's in the past. Is their a work around to bring the old view back or at least a known fix to just get the Aruba down events. I can live not seeing the down AP's in the console, but I have to get notified via the alert.
Hi Steve,
Can you please open support ticket? We will look at your issue.
Thanks
What does your Down/Up alerts look like on your WISMs, I am unable to get any alerting on mine.
I am having this problem as well if anybody has came up with a solution. I didn't like to have to remove thin ap from NPM via SQL, but knowing there is a down AP is better than it not even showing. I checked the event log to see if NPM recorded it as down, but there is no mention about the AP going down or being removed.
I have been asked to provide the workaround that I was given so listed is the content of a WL_AP_Disappear.SQL file I was given.
Workaround to mark AP as down instead of removing it:
1) Stop Orion services
2) Run attached SQL script file against your Orion DB
3) Start Orion services
4) Orion should mark disappeared APs as down
SQL script is attached. Please ensure you have a full database backup before proceeding.
Note. I never did try this workaround.
UPDATE NPM_SETTINGS SET CacheTablesXML='<!-- Configuration for NPM cache tables -->
<CacheTables version="1.2">
<TableTypes>
<Type TableType="0" Suffix="" />
<Type TableType="1" Suffix="_DETAIL" />
<Type TableType="2" Suffix="_HOURLY" />
<Type TableType="3" Suffix="_DAILY" />
</TableTypes>
<StatisticsProcedures>
<SSPBase ID="0" NameBase="NPM_HST_WL_" />
<SSPBase ID="1" NameBase="NPM_HST_EW_" />
<SSPType NameSuff="DetailToHourly" SrcTableType="1" DstTableType="2" DateFunction="dbo.DateAndHourOnly" />
<SSPType NameSuff="HourlyToDaily" SrcTableType="2" DstTableType="3" DateFunction="dbo.DateOnly" />
</StatisticsProcedures>
<TablesDefinition>
<!-- GENERIC -->
<Table Name="NPM_NV_GENERIC" ID="0" ParentID="">
<DeleteUnavailable Delete="1" />
</Table>
<!-- WIRELESS -->
<Table Name="NPM_NV_WL_CONTROLLERS" ID="1" ParentID="" SSPBaseID="0" HstSource="NPM_NV_WL_CONTROLLERS_V">
<DeleteUnavailable Delete="1" />
<UnManaged SrcTableName="Nodes" SrcKeyColumn="NodeID" SrcValColumn="UnManaged" DstKeyColumn="NodeID" />
</Table>
<Table Name="NPM_NV_WL_APS" ID="2" ParentID="1" SSPBaseID="0" HstSource="NPM_NV_WL_APS_V">
<DeleteUnavailable Delete="1" Condition="(AP_RogueAP=1)" />
<UnManaged SrcTableName="Nodes" SrcKeyColumn="NodeID" SrcValColumn="UnManaged" DstKeyColumn="NodeID" />
</Table>
<Table Name="NPM_NV_WL_INTERFACES" ID="3" ParentID="2" SSPBaseID="0" HstSource="NPM_NV_WL_INTERFACES_V">
<DeleteUnavailable Delete="1" Condition="(Rogue_RogueInterface=1)" />
<UnManaged SrcTableName="NPM_NV_WL_APS" SrcKeyColumn="ID" SrcValColumn="UnManaged" DstKeyColumn="ParentID" />
</Table>
<Table Name="NPM_NV_WL_CLIENTS" ID="4" ParentID="3" SSPBaseID="0" HstSource="NPM_NV_WL_CLIENTS_V">
<DeleteUnavailable Delete="1" Condition="" />
<UnManaged SrcTableName="NPM_NV_WL_INTERFACES" SrcKeyColumn="ID" SrcValColumn="UnManaged" DstKeyColumn="ParentID" />
</Table>
<!-- ENERGY WISE -->
<Table Name="NPM_NV_EW_DEVICE" ID="5" ParentID="" SSPBaseID="1" HstSource="NPM_NV_EW_DEVICE_V">
<DeleteUnavailable Delete="0" />
<UnManaged SrcTableName="Nodes" SrcKeyColumn="NodeID" SrcValColumn="UnManaged" DstKeyColumn="NodeID" />
</Table>
<Table Name="NPM_NV_EW_NEIGHBOR" ID="6" ParentID="5" SSPBaseID="1">
<DeleteUnavailable Delete="0" />
<UnManaged SrcTableName="NPM_NV_EW_DEVICE" SrcKeyColumn="ID" SrcValColumn="UnManaged" DstKeyColumn="ParentID" />
</Table>
<Table Name="NPM_NV_EW_ENTITY" ID="7" ParentID="5" SSPBaseID="1" HstSource="NPM_NV_EW_ENTITY_V">
<DeleteUnavailable Delete="0" />
<OrionLink MethodName="EW_CreateInterfacesLink" />
<UnManaged SrcTableName="Interfaces" SrcKeyColumn="InterfaceID" SrcValColumn="UnManaged" DstKeyColumn="OrionLink" />
</Table>
<Table Name="NPM_NV_EW_EVENT" ID="9" ParentID="7" SSPBaseID="1">
<DeleteUnavailable Delete="1" Condition="" />
<UnManaged SrcTableName="NPM_NV_EW_ENTITY" SrcKeyColumn="ID" SrcValColumn="UnManaged" DstKeyColumn="ParentID" />
</Table>
</TablesDefinition>
<PropTypeTableName>
<!-- GENERIC -->
<PropType ID="0" GroupID="0" Priority="0" TableID="0" RecordIDColumn="OrionNodeID" Note="Generic" />
<!-- WIRELESS -->
<PropType ID="1" GroupID="1" Priority="0" TableID="2" RecordIDColumn="OrionNodeID" Note="AutonomousAP" />
<PropType ID="2" GroupID="1" Priority="1" TableID="3" RecordIDColumn="SuffValue1" Note="AutonomousAPInterface" />
<PropType ID="3" GroupID="1" Priority="2" TableID="4" RecordIDColumn="StackIndex" Note="AutonomousAPInterfaceClient" />
<PropType ID="4" GroupID="2" Priority="0" TableID="1" RecordIDColumn="OrionNodeID" Note="Controller" />
<PropType ID="5" GroupID="2" Priority="1" TableID="2" RecordIDColumn="SuffValue2" Note="ControllerThinAP" />
<PropType ID="6" GroupID="2" Priority="2" TableID="3" RecordIDColumn="SuffValue1" Note="ControllerThinAPInterface" />
<PropType ID="7" GroupID="2" Priority="3" TableID="4" RecordIDColumn="StackIndex" Note="ControllerThinAPInterfaceClient" />
<!-- ENERGY WISE -->
<PropType ID="8" GroupID="3" Priority="0" TableID="5" RecordIDColumn="OrionNodeID" Note="EnergyWise" />
<PropType ID="12" GroupID="3" Priority="1" TableID="6" RecordIDColumn="SuffValue1" Note="EnergyWiseNeighbor" />
<PropType ID="9" GroupID="3" Priority="1" TableID="7" RecordIDColumn="SuffValue1" Note="EnergyWiseEntity" />
<PropType ID="11" GroupID="3" Priority="2" TableID="9" RecordIDColumn="SuffValue2" Note="EnergyWiseEvent" />
</PropTypeTableName>
</CacheTables>'
I have ran this script, but am still having a similar problem. I have a Thin AP that apparently has bounced a couple of times, but came back with same IP address. NPM is still marking the same AP as up and down twice. Meaning there are three showing for the same AP and they all have the same IP address.
Hi rscreed92,
please open support ticket and upload diagnostics. Looks like you have different issue that other guys here.
Thanks
I ran the script and it now functions like it did in the past and I am now receiving alerts when an AP goes down. Thanks for passing it on!
