Network Management

Is there any way to get airwave to pull in an Aruba AP that was previously deleted from airwave?  The AP is up and working but airwave sees it as a suspected rogue.  It doesn't show as new, mismatched, or ignored.  Can this AP be 'undeleted' to get it back in to airwave?   

I am interested in any response to this question.

I have an AP105 in the same condition.  It was up in a different location (different vlan) discovered, provisioned and then moved to it's current location and reprovisioned for the name (location) that's when it came to it's current condition in Airwave, as you described.

I am going to do a purge > save > reset tomorrow AM, remove it from the master controller, delete the "rogue" event in AMP, reconnect it and then try to provision it again it.

The first thing to check is that the AP's controller is currently being monitored by Airwave. Did the AP associate to a different controller that is not being monitored by that Airwave server?

Asumming that isn't the case, Airwave will periodically poll controllers for new AP discovery. Please verify "Thin AP Discovery Polling Period" has not been disabled on the controller's Group's Basic page (it is enabled be default). If that is on, AMP should automatically discover any new APs and add them to the "New Devices" list (or automatically approve if you have it configured that way).

If the thin AP discovery is enabled, then please verify the AP is "up" on the controller (run "show ap active" and verify the AP in question is present).

Thanks for the ideas; but for me, everything is set correct and working.  Adding a different AP goes well and is discovered by AMP, etc.  It is just this one AP tha tis bothersome. :smileymad:

The first thing to check is that the AP's controller is currently being monitored by Airwave. Did the AP associate to a different controller that is not being monitored by that Airwave server?

AMP is set to read/write for the controller and we only have a single controller.  The AP shows up fine on the controller.  Other APs are working fine in AMP.  New ones show up as new and can be configured. 

Asumming that isn't the case, Airwave will periodically poll controllers for new AP discovery. Please verify "Thin AP Discovery Polling Period" has not been disabled on the controller's Group's Basic page (it is enabled be default). If that is on, AMP should automatically discover any new APs and add them to the "New Devices" list (or automatically approve if you have it configured that way).

Thin AP discovery is set to 15 minutes, no changes from default have been made.  

If the thin AP discovery is enabled, then please verify the AP is "up" on the controller (run "show ap active" and verify the AP in question is present).

AP in question is present and active.  It even has clients attached.  Show ap database shows it without any flags.

So I went and took the AP down that was not being discovered properly by AMP.  New one installed works fine.

I brought the "non-functioning" AP back to my office - console connection - boot to factory default the AP - reset and it comes up fine - provision to a group (without renaming it) shows in AMP as new - I "move" it to a folder and all is fine until I provision a "name"  - then it shows as down and is classified by Rapids as "Valid".  Just plain strange - I suspect there is something with the AP. ???:smileymad:

If you haven't already, please try searching for the AP's LAN MAC in Airwave's search box to make sure the AP isn't already on the AMP in a place you weren't expecting (or with a name you weren't expecing).

If still no luck, please examine the AMP Event log (System > Event Log) for any system errors that might be causing the problem.

Not there. Thanks for the idea though. 

Time for a TAC case.

The  AP's LAN mac does not show up with a search in Airwave.

I don't see anything in the event log that looks unusual or related to this AP.

Are there any errors in the async_logger_client log file (viewable on the System > Status page)?

Yes, these 3 lines are repeated many times but I don't see any correlation to the AP that is being classified a rogue.

Mon Mar  5 05:23:08 2012: node_id 4013.2892863, topic snmp_trap: Use of uninitialized value $client_mac in concatenation (.) or string at /usr/local/airwave/lib/perl/Mercury/Daemon/Monitoring/Client.pm line 548, <$__ANONIO__> line 8337915.
Mon Mar  5 05:23:18 2012: node_id 4013.2892899, topic snmp_trap: Use of uninitialized value in numeric eq (==) at /usr/local/airwave/lib/perl/Mercury/Daemon/Monitoring/Client.pm line 540, <$__ANONIO__> line 8337915.
Mon Mar  5 05:23:18 2012: node_id 4013.2892899, topic snmp_trap: Use of uninitialized value $client_mac in delete at /usr/local/airwave/lib/perl/Mercury/Daemon/Monitoring/Client.pm line 90, <$__ANONIO__> line 8337915.

There are a number of these for the particular AP in question:

Mon Feb 27 08:42:52 2012: node_id 1266, topic interface_bandwidth: Failed reading bandwidth data for ap 'Rm18' (id: 1266)

None recently - last one was Feb 27.

Thu Feb 23 11:17:03 2012: node_id 359, topic thin_ap_status: RRDtool update of ap_is_up/440 (/var/airwave/rrd/ap_is_up/440) error: (rrdcached: illegal attempt to update using time 1330017410 when last update time is 1330017412 (minimum one second step)) Thu Feb 23 11:17:03 2012: node_id 359, topic thin_ap_status: RRDtool update of ap_sysuptime/440 (/var/airwave/rrd/ap_sysuptime/440) error: (rrdcached: illegal attempt to update using time 1330017410 when last update time is 1330017412 (minimum one second step))

About 10 of these in a group:

Sat Feb 25 11:13:54 2012: node_id 726, topic association_tables: Use of uninitialized value $model in index at /usr/local/airwave/lib/perl/Mercury/Utility/UserAgent.pm line 129, <$__ANONIO__> line 102857780.

And this one shows up again:

Wed Feb 29 02:39:43 2012: node_id 100, topic thin_ap_status: RRDtool update of ap_is_up/174 (/var/airwave/rrd/ap_is_up/174) error: (rrdcached: illegal attempt to update using time 1330504769 when last update time is 1330504780 (minimum one second step)) Wed Feb 29 02:39:43 2012: node_id 100, topic thin_ap_status: RRDtool update of ap_sysuptime/174 (/var/airwave/rrd/ap_sysuptime/174) error: (rrdcached: illegal attempt to update using time 1330504769 when last update time is 1330504780 (minimum one second step))

Those errors are not related to thin AP discovery.

The last thing to check is whether the controller is properly reporting the AP over SNMP. I remember a controller bug a while ago where under certain rare cirumstances APs could stop showing up in the SNMP tables (which is how Airwave discovers them).

Please use this command on Airwave's CLI to walk the controller and see if the missing AP's name is present in the results (substitute CONTROLLER_IP with the controller's IP, and COMMUNITY with the controller's community string):

[root@your_amp mercury]# s2w CONTROLLER_IP COMMUNITY wlanAPName -OX

 Let me know if you are using SNMPv3 to monitor the controller and I will give that command.

fyi - I have a TAC case open at this time.

Here is the output from you command:

[root@slu-amp mercury]#

 s2w [controller-ip] [snmp-string] DE-1010 -OX

DE-1010: Unknown Object Identifier (Sub-id not found: (top) -> DE-1010)
[root@slu-amp mercury]#

Sorry, the 'wlanAPName' in the command should not be substituted with the name of the AP. 'wlanAPName' is the OID we want to walk.

Sorry I misinterpreted.  That command returns all AP names but NOT the one in question - DE-1010 (which shows up on the local controller).

We are not using SNMPv3.

The command returns a list of APs that does not include the missing AP. 

Ok. One last thing to confirm: does the AP's LAN MAC end in EF or FF? I have tracked down the controller SNMP bug I referred to before and it seems to be triggered by specific MAC addresses. Unfortunately there is no available workaround. The bug has already been fixed and the fix will be included in a future release. What firmware version is your controller running?

Yes, for me.-  

Yes, it ends in FF.  Controller is running 6.1.2.6.

Thanks for all your help!

You are welcome! Please mark this topic as resolved if you are satisfied with this resolution :smileyhappy:

I have not seen a "resolution" or "work-around"; just an explanation.  I ca except that explanation, but it does on solve resolve our issue.

Still waiting on TAC for my issue, they are looking at possibly replacing the AP.  We will see.

Yeah, I agree.  If and when a new controller code fixes this, I'll mark it as resolved. 

I was given two bug IDs, by TAC, that are (or may be) relevant.  Can someone here pull those out of the database for review?  Please?

The bug id are : 54939 and 60800

Thanks.

54939 is the defect I was referring to before. It has been fixed and will be available in a future release. 60800 is a duplicate of the same issue.

So is that the solution?  To wait untill a future release?  Will it be the next release?  Just wondering if I need to press for a replacement AP.  Is it the AirWave or the controller code that will be fixed?

---

@phil wrote:

So is that the solution?  To wait untill a future release?  Will it be the next release?  Just wondering if I need to press for a replacement AP.  Is it the AirWave or the controller code that will be fixed?

---

The problem is that the controller is not sending information on APs whose mac address ends in EF or FF when being polled via SNMP.  The AP works fine on the controller, but Airwave does not receive information on that AP from the controller when it polls it via SNMP.

The bug is in the controller code.

Again, the AP will work just fine, it is just that Airwave does not receive information about the AP via SNMP when polling the controller.  With that being said, there is nothing wrong with the AP or Airwave, so you cannot RMA the AP.  Since you have a tac case open, you can request to be notified when the fix will appear in shipping code by the TAC engineer.

Thank you.  I can accept that explanation, no problem.

Thanks to Muir for tracking this down.