Wireless Access

Hello,

I think this must be very basic question, but let me ask.

We are running AP-105 RAPs with Aruba 3400 controllers.  OS 5.0.4.4

When I checked Monitoring - All Access Points, I can see AP which does not have any .bg clients. I come close that AP and found that AP was not working. Therefore, I rebooted AP on Configuration - AP Installation screen.

Before I reboot that AP, the status of AP is just normal on Monitoring - All Access Points, also normal on Configuration - AP Installation.

I could PING to that RAP also. Therefore PING cannot be used to detect non-working AP.

My question is - how to effectively detect those non-working APs? Using Air Monitor? (I do not think so)

Only thing I can do is to develop automated web-pilot program to check if .bg clients is 0 under certain AP.

Mike,

You would open a support case and they would determine why or IF the AP is not working.  Just because the AP does not say it has  any b/g clients does not mean it is not working.  It could be a configuration issue or a bug.

On the commandline, you can type 'show ap debug-log ap-name <name of ap>" to see if it came up, as a start..

Hi cjoseph,

Thank you very much for your response.

The APs I was talking about has been up and running almost 140 days. My understanding is that 140days is very good enough for continious running (I believe that any access points should be rebooted sometime)

In this question, I would rather asking practical way - effectively detect non-working APs, so that I can reboot them. 

I can create a script to run 'show ap debug-log ap-name <name of ap>' to periodically check each AP. Could you tell me what message is mostly shown if AP is not working?

Let me correct that OS is 5.0.4.6 (A problem reported in 5.0.4.4 - High cpu usage in Access points, therefore I upgraded to 5.0.4.6)

If your problem before was high utilization I am not sure how you would detect if the access point is "alive" programatically.  Ideally the controller, when it has missed enough heartbeats from the access point will mark it down and send and AP down trap.  If an access point is "UP" but not functional, I think looking for the trap is the best way to troubleshoot if it is responsive or not.  Polling each access point periodically for logs might just contribute to the utilization problem.

My case is - Access Points is indicated as UP but not functioning.

If I can reach to those APs, I can connect serial interface to see the status, but I cannot (physically) attach serial cable.

If we can login to AP using telnet or SSH, I may be able to run some commands to see the status.

Do you know how to login to Access Points? My APs are AP-105, configured as Remote Access Points. Establishes IPSec SA with controllers.

---

@mikek8877 wrote:

My case is - Access Points is indicated as UP but not functioning.

 

If I can reach to those APs, I can connect serial interface to see the status, but I cannot (physically) attach serial cable.

 

If we can login to AP using telnet or SSH, I may be able to run some commands to see the status.

 

Do you know how to login to Access Points? My APs are AP-105, configured as Remote Access Points. Establishes IPSec SA with controllers.

Quite frankly, Mike8877, that should NEVER happen.  It should also not be something that you should have to troubleshoot.  If it ever happens, please open a support ticket so that they determine the origin and fix it.  There could be users with the same issue and your setup could provide the key to resolve the issue.

You should never have to poll access points for status using external tools, ever.

Hi cjoseph,

I understand what you posted. RAP is connected with IPSec, so it must not be accessed by any methods.

But network admins have monitoring tools for routers and stuff, and their thought may be extended if there is a convenient monitoring tools to detect non-functioning APs.   Sometimes recovery speed is most important, rather than right approach to fix the problem properly.

Lastly, would you please introducing any commands from controller which can be helpful to obtain AP status to resolve the problem?

Is there any command to invoke AP core dump towards controller?

---

@mikek8877 wrote:

Hi cjoseph,

 

I understand what you posted. RAP is connected with IPSec, so it must not be accessed by any methods.

 

But network admins have monitoring tools for routers and stuff, and their thought may be extended if there is a convenient monitoring tools to detect non-functioning APs.   Sometimes recovery speed is most important, rather than right approach to fix the problem properly.

 

Lastly, would you please introducing any commands from controller which can be helpful to obtain AP status to resolve the problem?

Is there any command to invoke AP core dump towards controller?

---

I am not saying that a RAP should not be accessed externally or even a regular Campus AP.  There is just no interface besides polling that access point through the controller to obtain meaningful information.  If an access point is loaded, management functions like polling will take a back seat to other functions.  That does not mean that the access point is inoperable; that just means that it is proritizing functions.  There is no definitive way to poll an AP to determine whether it is up or not, outside of the doing it through the controller (ping does not count in this case).  Since the controller itself determines if an access point is up or not through normal communication with the AP, it is supposed to detect whether not the AP is up way before a human could attempt to poll it.

We can run through a long list of commands to run on that AP, but polling all access points for that could increase utilization and not buy you anything.  You can run any command that begins with "show ap" to poll information, if that is the plan.

Long story short, we need to ensure that the software works, like it should in this scenario and not put the burden on our users to troubleshoot a non-functioning ap.

An excellent troubleshooting document, from clients, to AP to controller is here:  http://community.arubanetworks.com/aruba/attachments/aruba/campus-wlan-and-high-density-wi-fi/112/1/Troubleshooting%20Cheat%20Sheet-Aug2007.pdf